Core Web Vitals measure three aspects of page experience: how fast the main content appears, how quickly the page responds to interaction, and how much it moves around while loading. They are a ranking signal, and a comparatively modest one — their larger value is in conversion.
Field data versus lab data
Before optimising anything, know which numbers matter.
Field data comes from real users on real devices and networks. This is what is used as a ranking signal and what reflects actual experience.
Lab data comes from a simulated load in a controlled environment. Useful for debugging and for comparing before and after, and it will not match field data.
Teams routinely optimise a lab score to 100 while field data stays poor, because real users are on slower devices, worse networks, and visiting pages the lab test never ran. Always validate against field data, and remember it reflects a trailing window, so improvements take weeks to appear.
Largest contentful paint
LCP measures when the largest visible element finishes rendering. The target is under 2.5 seconds for 75% of visits.
The LCP element is usually a hero image, a heading, or a large block of text. Identify which it is before optimising, because the fix differs entirely.
If it is an image: serve it in a modern format, size it correctly for the viewport rather than shipping a 3000px image to a phone, preload it, and never lazy-load it. Lazy-loading the hero image is one of the most common self-inflicted LCP problems.
If it is text: the delay is usually font loading. Use font-display: swap, preload the font files, subset them to the characters you need, and self-host rather than fetching from a third party.
In all cases: reduce server response time, eliminate render-blocking resources in the head, and check for redirect chains on the initial request. A 400ms redirect is 400ms of LCP you cannot recover.
Interaction to next paint
INP measures responsiveness across the whole visit — how long from a user interaction to the next visual update. The target is under 200 milliseconds.
The cause is almost always JavaScript occupying the main thread when the user clicks. Four fixes, in order of typical impact.
Ship less JavaScript. Audit the bundle. Large libraries used for one feature, polyfills for browsers nobody uses, and duplicate dependencies are routine findings.
Break up long tasks. Any task over 50 milliseconds blocks interaction. Splitting work and yielding to the main thread between chunks is often a small change with a large effect.
Defer what is not needed immediately. Analytics, chat widgets, personalisation and A/B testing scripts rarely need to run before the user can interact.
Audit third-party tags. Tag managers accumulate scripts nobody owns. Each one competes for the main thread. Removing three unused tags often does more than a week of code optimisation.
Cumulative layout shift
CLS measures unexpected movement of visible content. The target is under 0.1.
The causes are few and well understood.
- Images without dimensions. Set width and height attributes, or an aspect ratio, so the browser reserves space.
- Ads and embeds. Reserve the space with a container of fixed minimum height, even if the slot is sometimes empty.
- Fonts. A fallback font with different metrics causes a reflow when the web font loads. Size-adjust descriptors largely eliminate this.
- Content inserted above existing content. Cookie banners, notification bars and late-loading promotions. Overlay them rather than pushing content down.
- Animating layout properties. Animate transform and opacity rather than width, height or top.
CLS is usually the cheapest of the three to fix and the one with the most visible effect on how the site feels.
A sensible order of work
- Get field data by page template, not for the site as a whole. The problem is usually concentrated in one or two templates.
- Fix CLS first — cheapest, fastest, most noticeable.
- Fix LCP next, starting with the single LCP element on the worst template.
- Fix INP last, since it usually requires JavaScript work that takes longer.
- Re-measure after four weeks, because field data lags.
Where the big wins usually are
Three changes account for a disproportionate share of improvement across most sites.
Image handling. Correct formats, correct sizes, correct loading attributes. On image-heavy sites this alone can move LCP by seconds.
Third-party script discipline. An audit of what is loading, who owns it, and whether it is still needed. Most sites can remove several.
Server response time. Caching, a CDN, and database query optimisation. Everything else is downstream of how long the first byte takes.
What not to over-invest in
Moving from “needs improvement” to “good” is worth real effort. Moving from “good” to a perfect score rarely changes rankings and often costs more engineering time than it returns.
Likewise, a slow page that nobody visits is not a priority. Weight the work by traffic and by commercial value, which means fixing the template that serves your top landing pages before anything else. This fits naturally into a broader technical SEO audit.
Finding the problem pages
Site-wide averages hide everything. The useful analysis groups pages by template and sorts by traffic.
Pull field data grouped by URL pattern — the article template, the category template, the homepage, the product pages — and multiply each template’s failure rate by its share of traffic. The resulting ranking tells you where an hour of engineering time buys the most, and it frequently contradicts intuition. A heavy, slow page type that receives 2% of visits is not the priority it appears to be.
Within the worst template, look at one representative page in detail rather than running the whole site through a tool. Templates fail for one or two shared reasons, and fixing those fixes every page using them.
Keeping the gains
Performance regresses quietly. A new tag, a larger hero image, an extra font weight — each small, and collectively they undo a quarter’s work within a few months.
Three defences work without much ongoing effort. Set a performance budget: a maximum JavaScript bundle size and image weight per template, enforced in the build so exceeding it fails the pipeline. Run a lab test on every pull request against key templates, so a regression is visible in review. And review field data monthly, by template, as a standing item rather than when someone notices the site feels slow.
The governance point matters more than the tooling: someone has to own page weight, or every team will add to it and nobody will remove anything.
Frequently asked questions
How much do Core Web Vitals affect rankings?
They are a real but modest signal, and they act mainly as a tiebreaker between pages of similar relevance. Content quality and links matter considerably more.
Why does my lab score differ from field data?
Lab tests use one simulated device and connection on one page. Field data aggregates real users across devices, networks and pages. Field data is what counts.
How long until improvements show?
Field data is reported over a trailing 28-day window, so expect four to six weeks before an improvement is fully reflected.
Does a CDN fix Core Web Vitals?
It helps LCP by reducing network latency and improving server response time. It does nothing for INP or CLS, which are determined by what the page does once it arrives.
