Performance is more than a good score. A website has to become visible quickly, respond to input without delay and remain stable while it loads. That is what Core Web Vitals are for: they translate technical loading and interaction problems into metrics that are closer to real user experience than file sizes or server timings alone.
For companies, this matters because performance affects perception, conversion, SEO and maintainability. A beautiful website that loads late on mobile devices, stutters during interaction or jumps because late content appears does not feel high-quality. That is why performance optimization belongs to the foundation of modern web development and to a measurable quality strategy like the one described in our article Quality Is Measurable: Performance, Accessibility and SEO.
What are Core Web Vitals?
Google describes Core Web Vitals as metrics for real-world user experience across loading performance, responsiveness and visual stability. The current Core Web Vitals are:
- Largest Contentful Paint (LCP): measures when the largest visible content element in the viewport has loaded. A good LCP is 2.5 seconds or less.
- Interaction to Next Paint (INP): measures responsiveness across interactions. A good INP is 200 milliseconds or less.
- Cumulative Layout Shift (CLS): measures unexpected layout shifts. A good CLS is 0.1 or less.
According to web.dev and Google Search Central, assessment uses the 75th percentile. A page should therefore not only be fast in its best lab run, but work well for the majority of real page views.
Optimizing LCP: make the main content visible sooner
LCP is often the most important first performance lever because users quickly notice whether the main content becomes visible. The LCP candidate is often a hero image, a large heading, a text block or a product image.
Practical measures:
- Improve server response: reduce TTFB, use caching, avoid unnecessary redirects and keep dynamic rendering from becoming too expensive.
- Prioritize hero images: do not lazy-load the most important image, deliver it early, size it correctly and consider
fetchpriority="high"where appropriate. - Use modern image formats: deliver WebP or AVIF with suitable dimensions,
srcsetandsizesinstead of sending one large desktop image to every device. - Reduce render-blocking resources: keep critical CSS lean and remove unnecessary JavaScript from the initial path.
- Use CDN and edge caching: deliver static assets close to users and avoid repeated work.
LCP is rarely solved by a single trick. A poor LCP often comes from several smaller bottlenecks: slow server response, an oversized image, blocking fonts, too much client-side JavaScript and missing caching.
Optimizing INP: respond quickly to interaction
INP replaced First Input Delay as a Core Web Vital and is stricter because it does not only look at the first interaction. It measures how long it takes until the page visibly responds after a user action. That includes clicks, taps and keyboard input.
Common causes of poor INP:
- large JavaScript bundles
- long tasks on the main thread
- expensive event handlers
- unnecessary re-renders
- third-party scripts doing work at the wrong time
- complex DOM structures
Practical optimization mostly means doing less work at the critical moment. Code splitting, server-side rendering, lean components, debouncing, Web Workers for expensive calculations and careful hydration can make a visible difference. Interactions should not have to wait until an entire app bundle has been parsed, compiled and executed.
Optimizing CLS: keep layout stable
CLS measures whether visible content shifts unexpectedly. This happens when images load without fixed dimensions, ad slots are inserted late, fonts reflow text or banners appear above existing content.
Good countermeasures:
- Set width and height for media: images, videos and embeds need fixed dimensions or a stable
aspect-ratio. - Reserve space for dynamic content: ads, cookie banners, recommendation boxes and form messages should not push existing content around unpredictably.
- Load fonts predictably: choose
font-displaydeliberately, configure metric-compatible fallback fonts and load only required weights. - Implement animations correctly: avoid layout properties such as
top,left,widthandheightwhentransformis enough.
Visual stability is easy to underestimate, but it is central to trust. If a button moves away at the moment of a click, the website feels broken.
Images: usually the biggest lever
Images are the largest performance factor on many websites. An image should only be transferred at the size that makes sense for the current viewport. That sounds obvious, but it is often implemented poorly.
A robust image strategy includes:
- responsive variants with
srcsetandsizes - WebP or AVIF where support and quality make sense
- real image dimensions in the markup
- lazy loading for images below the first viewport
- prioritization of the LCP image
- sensible compression without visible artifacts
For editorial sites, landing pages and product pages, the first large image deserves its own review. If that asset arrives late, it does not help much that everything further down the page is perfectly lazy-loaded.
Fonts: fewer weights, clear loading priority
Web fonts can strengthen branding, but they can also harm LCP and CLS. Problems often come from too many font weights, external font providers without a good caching strategy and fallbacks with very different metrics.
In practice, these measures help:
- load only required weights and character sets
- self-host fonts when the project benefits from it
- preload important fonts, but not every font by default
- configure
font-displaydeliberately - choose fallback fonts that do not cause large text shifts
The best font stack is not the one with the most variants. It is the one that fits the brand and renders reliably fast.
JavaScript: less work in the browser
JavaScript is often the reason a page looks loaded but is not yet pleasant to use. Large bundles must be downloaded, parsed, compiled and executed. On fast developer machines this can look harmless; on average mobile devices it becomes a real INP problem.
Useful measures:
- avoid making every UI element a client component
- split routes and heavy features with code splitting
- remove unused dependencies
- identify and break up long tasks
- minimize hydration
- defer expensive calculations or move them to Web Workers
Performance optimization is also product work: which interaction must be available immediately? Which feature can load later? Which library is convenient but too heavy for the specific job?
Caching: speed also comes from repetition
Caching determines whether returning users and search engine crawlers trigger the same work again and again. Static assets should be cached for a long time and versioned with hashed filenames. HTML and API responses need a more deliberate strategy because they change more often.
Proven patterns:
- long cache lifetimes for versioned CSS, JS and image files
- CDN caching for public content
stale-while-revalidatewhen slightly stale content is acceptable- targeted revalidation after content updates
- compression with Brotli or gzip
Caching does not replace clean architecture, but it prevents every request from behaving like the first page view.
Third-party scripts: every script needs a reason
Analytics, consent tools, chat widgets, A/B testing, maps, video embeds and ad networks can strongly affect performance. They often live outside your own code quality standards, but they use the same main thread and network connection as the website itself.
That is why every third-party script should be reviewed regularly:
- Is it truly needed?
- Does it load before or after the main content?
- Can it load only after consent or interaction?
- Is there a lighter alternative?
- Does it block rendering or interactions?
web.dev recommends auditing third-party JavaScript regularly and loading it efficiently. In practice, this is one of the most honest performance tests: if a tool has no clear business value, it should not permanently cost loading time.
Lab data vs. field data
A common mistake is looking only at one Lighthouse run. Lab data is useful because it is reproducible and helps with debugging. PageSpeed Insights explicitly notes, however, that lab data may not capture real-world bottlenecks. Field data from the Chrome User Experience Report shows real user experience over a recent collection period, but is less detailed for debugging.
Both perspectives matter:
- Lab data: useful for development, pull requests, regressions and concrete diagnosis.
- Field data: decisive for understanding how real users experience the website.
- RUM data: your own real-user monitoring helps identify differences by page, device, country and user group.
Professional performance work combines these views. A good Lighthouse score is a starting point, but Core Web Vitals have to remain stable in the field.
A pragmatic performance checklist
For most websites, this workflow is useful:
- Check PageSpeed Insights for important page types: homepage, landing page, article, contact page, product or service page.
- Identify the LCP element and optimize it deliberately.
- Set a JavaScript budget and remove unnecessary client-side work.
- Review images and fonts systematically.
- Prevent layout shifts with fixed dimensions and reserved space.
- Audit third-party scripts.
- Check caching rules for assets, HTML and APIs.
- Watch field data after release, not only the lab score.
This turns performance from a one-time project into part of normal quality assurance.
