What Google is actually measuring
Core Web Vitals are three metrics Google uses to approximate whether a page feels good to use. They're deliberately user-centric: rather than measuring server response or file sizes, each one measures something a person would notice.
Largest Contentful Paint asks: how long until the main thing appears? Not the first pixel — the largest meaningful element, usually a headline or hero image. Google's threshold is 2.5 seconds. Above 4 seconds is classified as poor.
Interaction to Next Paint asks: when I tap something, how long before anything visibly happens? It replaced First Input Delay in 2024 because FID only measured the first interaction and was too easy to pass while still feeling sluggish. The threshold is 200ms.
Cumulative Layout Shift asks: does the page move around while I'm reading it? Every time content jumps because an image or ad loaded late, CLS accumulates. The threshold is 0.1, and this is the one users complain about most viscerally — it's what makes you tap the wrong button.
Why it matters commercially, not just for rankings
Core Web Vitals are a confirmed ranking factor, but the ranking effect is modest — roughly a tiebreaker between pages of comparable relevance. If your content doesn't match intent, no amount of speed will rescue it.
The conversion effect is larger and more direct. Bounce probability rises sharply with load time, and on any site with meaningful traffic the difference between a two-second and a four-second page is a calculable amount of revenue.
This reframes the work usefully. Performance isn't an engineering vanity metric; it's a conversion lever with an unusually clear cause-and-effect chain. That also makes it one of the easier technical investments to justify to a finance team.
Fixing LCP
LCP problems almost always trace to one of four causes: slow server response, render-blocking resources, unoptimised images, or client-side rendering.
Start by identifying what the LCP element actually is — PageSpeed Insights tells you. Usually it's a hero image or the main headline. If it's an image, it needs to be correctly sized, served as WebP or AVIF, and crucially not lazy-loaded. Lazy-loading your LCP image is a common own-goal that delays the exact element being measured.
Fonts are the other frequent culprit. A web font that blocks text rendering delays LCP directly. Use font-display: swap, preconnect to the font origin, and preload the specific font files you need above the fold.
If your page is client-rendered, the browser downloads an empty shell and then builds the page in JavaScript. That's structurally slow for LCP and no amount of tuning fully fixes it — the answer is server rendering or static generation for anything public-facing.
Fixing INP and CLS
INP is a JavaScript problem in nearly all cases. Long tasks block the main thread, so a tap can't be processed until the thread frees up. The fixes are ship less JavaScript, break long tasks into smaller chunks, and defer anything not needed for the initial interaction.
Third-party scripts deserve particular scrutiny. Chat widgets, analytics, A/B testing tools and tag managers each add main-thread work, and they're typically added by marketing without a performance review. Audit them periodically and remove what isn't earning its cost.
CLS is usually the easiest of the three to fix and the most annoying to users. Set explicit width and height attributes on every image so the browser reserves space before the file arrives. Reserve space for ads, embeds and anything injected after load. Never insert content above existing content unless it's in response to a user action.
One CLS cause that catches people out: web fonts. If your fallback font has different metrics than your web font, text reflows when the real font loads. size-adjust and the font metric override descriptors solve this.
What order to do it in
Measure first, using field data rather than lab data. The Core Web Vitals report in Search Console shows what real users experienced, which is what Google actually uses. Lab tools like Lighthouse are useful for debugging but run on a simulated device and can disagree with reality.
Then fix in this order: CLS first because it's usually cheap and the user-experience win is immediate; LCP second because it has the largest ranking and conversion effect; INP last because it's typically the most invasive to fix, often requiring real architectural change.
Finally, protect the gains. Performance regresses quietly — a new marketing tag here, an unoptimised image there. Set a performance budget, add it to CI if you can, and re-check monthly. A site that hit 95 at launch and was never checked again is usually well below it a year later.