Skip to content
Prestigious Software Software home
SEO· 6 min read

Core Web Vitals in 2026: what Google measures and the quick wins for slow sites

Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift explained in plain language, with the thresholds that matter and the fixes that move the numbers most.

Key takeaways

  • The three Core Web Vitals are LCP (loading), INP (responsiveness) and CLS (visual stability).
  • Good means LCP within 2.5 seconds, INP within 200 milliseconds and CLS of 0.1 or less, at the 75th percentile.
  • Google uses real-user field data, so lab scores alone do not tell the full story.
  • Images, JavaScript and late-loading content cause most problems, and most fixes are straightforward.

Core Web Vitals are Google’s attempt to measure how a page feels to real visitors: how quickly the main content appears, how quickly the page responds when you interact with it and whether things jump around while it loads. They are part of Google’s page experience signals, and more importantly, they track closely with whether people stay or leave.

This guide explains the three metrics as they stand today, the thresholds to aim for and the fixes that usually make the biggest difference.

The three metrics

MetricWhat it measuresGoodNeeds improvementPoor
Largest Contentful Paint (LCP)When the largest image or text block in view finishes rendering≤ 2.5 s2.5–4.0 s> 4.0 s
Interaction to Next Paint (INP)How quickly the page visibly responds to clicks, taps and key presses≤ 200 ms200–500 ms> 500 ms
Cumulative Layout Shift (CLS)How much visible content moves unexpectedly while the page is used≤ 0.10.1–0.25> 0.25

INP replaced the older First Input Delay (FID) metric as a Core Web Vital in March 2024. FID only measured the delay before the first interaction started being processed. INP looks at responsiveness across the whole visit, which makes it a much better reflection of how sluggish a page feels, and also much harder to pass for JavaScript-heavy sites.

How Google measures them

Google assesses Core Web Vitals using field data from real Chrome users, collected in the Chrome User Experience Report (CrUX) over a rolling 28-day window. A page or site passes a metric when at least 75% of visits meet the “good” threshold. Mobile and desktop are assessed separately.

Where to check your scores

  • PageSpeed Insights: shows field data for a URL or origin when available, plus a lab diagnosis.
  • Google Search Console: the Core Web Vitals report groups similar pages and shows which fail and why.
  • Chrome DevTools Performance panel: records interactions and shows exactly what blocks them.
  • The web-vitals JavaScript library: lets you collect the same metrics from your own visitors and send them to your analytics.

Fixing Largest Contentful Paint

LCP is usually a hero image or the main heading. It is slow when the server responds slowly, when the browser discovers the main image late or when the image is too heavy.

  • Serve HTML quickly: use static generation or caching and a CDN so the first byte arrives fast.
  • Make the LCP image discoverable in the HTML, not injected later by JavaScript or set as a CSS background.
  • Do not lazy-load the LCP image; give it high fetch priority instead.
  • Resize and compress images, and use modern formats such as WebP or AVIF with responsive sizes.
  • Self-host critical fonts and preload them, and avoid render-blocking CSS and scripts in the head.

Fixing Interaction to Next Paint

INP problems come from the browser’s main thread being busy when the user interacts, usually with JavaScript.

  • Ship less JavaScript: remove unused libraries, split code by route and prefer server-rendered components where possible.
  • Break up long tasks so the browser can respond to input between chunks of work.
  • Give immediate visual feedback on interaction, then do heavy work afterwards.
  • Load third-party scripts such as chat widgets, tag managers and A/B testing tools late, or remove the ones nobody uses.
  • Avoid very large DOM sizes and expensive layout recalculations on each interaction.

Fixing Cumulative Layout Shift

Layout shift happens when something appears or resizes after the surrounding content has already rendered, pushing what the user is reading out of place.

  • Set width and height (or an aspect ratio) on images, videos and embeds so space is reserved.
  • Reserve space for ads, banners and cookie notices instead of inserting them above content.
  • Avoid inserting new content above what the user is looking at, unless it is in response to their action.
  • Use font loading strategies and fallback font metrics that minimise reflow when web fonts arrive.
  • Animate with transform and opacity rather than properties that change layout.

How much do Core Web Vitals affect rankings?

Google has been clear that page experience is one signal among many, and that relevance and quality of content matter far more. A slow page with the best answer can still outrank a fast page with a poor one. The stronger reason to care is commercial: faster, more stable pages keep more visitors, and most businesses see the benefit in engagement and conversions before they see it in rankings.

Quick wins checklist

  1. Check Search Console to see which page groups fail and on which metric.
  2. Compress and correctly size the largest images, starting with hero images.
  3. Remove unused third-party scripts and delay the rest until after the page is interactive.
  4. Add dimensions to every image and embed.
  5. Serve pages from a CDN with caching, ideally as static or pre-rendered HTML.
  6. Preload the main font and the LCP image.
  7. Measure INP with real-user data and fix the slowest interactions.
  8. Re-check field data after 28 days, since that is how long the rolling window takes to reflect changes.

This website is built as a static export served from a CDN, which is one of the simplest ways to get strong scores by default. If your site is struggling with Core Web Vitals, we can audit it and give you a prioritised list of fixes.

Sources and further reading

Share this article

Written by the Prestigious Software team

We design, build and run web platforms, SaaS products and mobile apps. About us

Our team reviews each article. Claims based on standards or research link to primary sources; examples are illustrative unless identified as client work.

Keep reading

Want this kind of thinking on your project?

Book a free call and we’ll look at your product together.

Book a call