Core Web Vitals: What Each One Measures and How to Fix It
Three metrics, one of which replaced another in 2024, and a persistent confusion about which data Google actually uses. Here is what each measures, what genuinely moves it, and why a perfect Lighthouse score can coexist with failing Core Web Vitals.
Lab data is not what you are graded on
Start with the distinction that causes most wasted effort. Lab data comes from Lighthouse or PageSpeed Insights running a single simulated load on specified hardware. It is reproducible, excellent for debugging, and not what Google ranks on.
Field data comes from the Chrome User Experience Report: real Chrome users, real devices, real networks, aggregated over 28 days and assessed at the 75th percentile. That means a quarter of your visitors can have a worse experience than your reported figure.
Chasing a green Lighthouse score while field data stays poor is common and expensive. Fix what field data says is broken, and use lab tools to diagnose why.
Largest Contentful Paint
LCP measures when the largest visible element finishes rendering, usually a hero image or a headline block. Good is under 2.5 seconds at the 75th percentile.
The dominant cause of poor LCP is render-blocking resources. Every stylesheet in the head blocks first paint, so a page loading a dozen separate CSS files cannot paint until the last arrives. Combining them into one request routinely removes close to a second on mobile. Third-party stylesheets and fonts are worse, because they add a DNS lookup and connection to another origin.
After that, look at the LCP element itself. If it is an image, it should not be lazy-loaded, should be served in a modern format, and benefits from fetchpriority="high". Compress it properly with our Image Compressor and convert with the Image to WebP Converter.
Interaction to Next Paint
INP replaced First Input Delay in March 2024 and is considerably stricter. FID measured only the delay before processing started on the first interaction. INP measures the full time from interaction to the next visual update, across all interactions during the visit, and reports close to the worst.
Good is under 200 milliseconds. Poor INP almost always means long JavaScript tasks blocking the main thread: heavy third-party scripts, large event handlers, or expensive re-renders.
The fixes are breaking long tasks into smaller chunks, deferring non-critical scripts, and auditing third-party tags ruthlessly. Tag managers accumulate scripts nobody has owned for years, and each one competes for the same main thread.
Cumulative Layout Shift
CLS measures unexpected movement of visible content. Good is under 0.1. It is the easiest of the three to fix and the most irritating to users, who tap the wrong thing because the page moved under them.
Nearly all of it comes from four causes: images without explicit width and height, ads or embeds injected without reserved space, web fonts swapping and changing text metrics, and content inserted above existing content such as a banner.
Setting width and height on every image is the single highest-value fix and costs nothing. The browser reserves the correct space before the file arrives. For fonts, font-display: swap plus a well-matched fallback minimises the shift when the real font loads.
Where to start
Open Search Console, not Lighthouse. The Core Web Vitals report groups URLs by issue using field data, which tells you what real users experience and how many pages are affected.
Then work in this order: eliminate render-blocking CSS, set dimensions on images, audit third-party scripts, and only then optimise application JavaScript. The first two are mechanical, carry no content risk, and usually deliver most of the improvement.
Field data updates on a 28-day rolling window, so be patient. A fix deployed today will not show fully in your report for a month.
Key takeaways
- Google ranks on field data from real users at the 75th percentile, not your Lighthouse score.
- LCP is usually render-blocking CSS. Combining stylesheets into one request is the biggest single win.
- INP replaced FID in March 2024 and is stricter — it measures all interactions, not just the first.
- Most CLS comes from images without width and height. Setting them costs nothing.
- Field data moves on a 28-day rolling window, so allow a month before judging a fix.
Frequently asked questions
What are good Core Web Vitals scores?
Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. Each is assessed at the 75th percentile of real visits over a rolling 28-day window, which means three quarters of your visitors must meet the threshold. That framing matters: an average that looks fine can still fail, because averages hide the slow tail where a quarter of your audience actually lives.
Why does my Lighthouse score not match Search Console?
Because they measure different things. Lighthouse runs a single simulated load on specified hardware and network conditions, which is lab data. Search Console reports field data from real Chrome users on real devices and connections, aggregated over 28 days. Your visitors have slower phones, worse networks and more browser extensions than your test environment. Lighthouse is a debugging tool that tells you why something is slow; field data tells you whether it is slow for the people who matter, and that is what Google uses.
What replaced First Input Delay?
Interaction to Next Paint became a Core Web Vital in March 2024, replacing First Input Delay. The change matters because INP is considerably stricter. FID measured only the delay before the browser began processing the very first interaction, which meant a page could score well while being sluggish throughout. INP measures the full duration from interaction to the next visual update, considers every interaction during the visit, and reports close to the worst one. Many sites that passed FID comfortably now fail INP.
How do I fix Cumulative Layout Shift?
Start by setting explicit width and height attributes on every image, which lets the browser reserve the correct space before the file loads and eliminates the most common cause. Then reserve fixed space for ads, embeds and anything injected by JavaScript. Use font-display swap with a fallback font whose metrics are close to your web font, so text does not reflow noticeably when the real font arrives. Finally, avoid inserting content above existing content, such as banners that push the page down after load.
Do Core Web Vitals matter more than content?
No, and Google has been explicit about this. Relevance and content quality outweigh page experience signals, and a fast page with weak content will not outrank a slower page that genuinely answers the query. Core Web Vitals function as a tie-breaker between comparable pages. The stronger argument for fixing them is commercial rather than algorithmic: faster pages have measurably lower bounce rates and higher conversion, and that effect is usually worth more than the ranking nudge.
How long until improvements show in Search Console?
Field data is calculated over a rolling 28-day window, so a fix deployed today will only be fully reflected roughly a month later. You may see the trend begin to move within a week or two as new data enters the window and old data leaves it. This lag catches teams out: it is common to deploy a fix, check after three days, see no change, and conclude it did not work. Verify the fix in lab tools immediately, then wait for field data to catch up.