A client sent me a screenshot of a 98 performance score and asked why their mobile bounce rate was still terrible. The lab test was run on a simulated desktop connection against a cached page. Their actual users were on mobile networks in the Caribbean, and their field data told a completely different story.
That gap is the first thing to understand about Core Web Vitals. The number in the testing tool is a diagnostic. The number that affects your business, and the one search engines use, comes from real visitors on real devices.
Once you accept that, the work gets much simpler, because the same handful of causes explain nearly everything I find.
The three metrics, in the language I actually use with clients
Largest Contentful Paint. How long until the biggest visible thing finishes loading. Target under 2.5 seconds. Almost always your hero image or a heading blocked by a font or a stylesheet.
Interaction to Next Paint. When someone taps something, how long before the screen visibly responds. Target under 200 milliseconds. This is the metric that replaced First Input Delay and it is much harder to fake, because it measures every interaction in the session rather than the first one. It is nearly always JavaScript occupying the main thread.
Cumulative Layout Shift. How much the page jumps around while loading. Target under 0.1. Nearly always images without dimensions, injected banners, or fonts swapping.
That is it. Everything else in the report is supporting detail.
Fix one: the hero image
Roughly half the LCP failures I see are a single oversized image at the top of the page.
The pattern is always similar. A designer supplied a 4000 pixel wide photograph. It got uploaded at full size. It is served as a PNG or an unoptimized JPEG. It is lazy loaded, which delays the one image that should never be delayed. And there is no width or height attribute, so it also causes layout shift.
The fix takes twenty minutes. Serve modern formats, size the image to its largest actual display width rather than its source width, set explicit width and height, and remove lazy loading from anything visible without scrolling. Add a preload hint for the hero specifically.
I have seen this one change take LCP from over four seconds to under two on sites where the team had spent weeks arguing about frameworks.
Fix two: the third party scripts nobody audits
Open your network tab and count the domains your page contacts. On a typical marketing site I find between fifteen and forty. Analytics, two tag managers, a chat widget, a heatmap tool, three ad pixels, a review widget, a font service, a cookie banner, and something nobody remembers installing.
Each one costs a connection, main thread time, or both. The chat widget alone is frequently the single largest INP contributor on a site, because it loads a full application to render a button.
My process: list every third party script, name the person who owns it and the decision it informs, and delete anything without both. On average I remove between a quarter and a third of them, and nobody notices anything except that the site got faster.
For what survives, defer aggressively. Nothing that is not required for the first render should block it. Load the chat widget on interaction rather than on page load. This is also one of the strongest arguments for server side tracking, which moves work off the user's device entirely.
Fix three: fonts
Web fonts cause both LCP and CLS problems and the fixes are well known and rarely applied.
Self host rather than calling a font service, which removes a DNS lookup and a connection on the critical path. Preload the specific font files you use above the fold. Use font-display: swap so text renders immediately in a fallback. Then choose a fallback whose metrics are close to your web font, so the swap does not cause a visible reflow.
And subset. Most sites load the full character set of four weights when they use two weights and Latin characters. That is often several hundred kilobytes of nothing.
I care about this beyond speed, because typography is identity, and I have strong opinions about which faces read as generic. But the performance argument is separate and simpler: you probably load four times the font data you need.
Fix four: layout shift from injected content
Cookie banners, promo bars, ad slots, and dynamically loaded recommendation widgets all insert themselves after the page has rendered and push everything down.
Reserve the space. If a banner is 60 pixels tall, the container should be 60 pixels tall from the first paint whether or not the banner has arrived. If an ad slot might be 250 or 600 pixels, pick one and hold it.
This is unglamorous CSS work and it is the difference between a page that feels solid and a page that feels broken, which readers interpret as a signal about the company. The relationship between perceived reliability and conversion is real, and it is part of the same trust economy I described in trust signals that lift conversion.
What I check before I believe any number
Field data over lab data, always. If you have enough traffic to have real user measurements, that is the only number that counts. Lab tests tell you what to fix, not whether you have a problem.
Mobile over desktop. Most sites are majority mobile and desktop scores hide everything.
Templates over pages. Test one page of each template type: homepage, category, product or article, contact. Fixing a template fixes thousands of pages at once, which is the same leverage argument as site architecture.
Percentiles over averages. The 75th percentile is what gets assessed and it is where the problems live. Your average visitor is fine. Your slow quarter is the one leaving.
What Core Web Vitals will not do for you
It will not rank a page that deserves nothing. Speed is a tiebreaker and a user experience factor, not a substitute for being the best answer. I have watched teams spend a quarter chasing a green score while their content problem went untouched, and they gained nothing.
The honest framing: it is a threshold, not a slope. Get out of the failing range on your key templates, then go work on something that actually differentiates you, using the priorities in the technical SEO checklist and, if you are mid project, a disciplined migration sequence.
Where it does compound is on feed driven traffic. Discover and social visitors are mobile, impatient, and unforgiving, and a slow page bleeds them at a rate that makes the whole channel uneconomic. I made that case in Google Discover strategy.
The four hour version
If you have half a day, do this in order. Optimize and preload the hero image on your top three templates, with explicit dimensions. Audit third party scripts and delete anything without a named owner. Self host and subset your fonts with a metric matched fallback. Reserve space for every injected element.
That sequence, in my experience, resolves the majority of failing sites without touching the framework, without a rebuild, and without a performance consultant. Then check your readability while you are in there, because a page that loads in 1.8 seconds and reads like a legal filing has traded one abandonment problem for another. A quick pass through a readability scorer usually finds more upside than the last 200 milliseconds of load time ever will.