How to fix failing Core Web Vitals

What counts as passing?

A page passes when all three metrics clear their threshold at the 75th percentile of real visits: Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200 milliseconds, and Cumulative Layout Shift at or under 0.1. The percentile matters — it means the slowest quarter of your visitors decides the outcome, so the fast desktop experience you check on is not the one being measured.

Two clarifications save a lot of wasted effort. INP replaced First Input Delay, and it is stricter: it measures every interaction across the visit and reports near the worst, rather than the first tap alone. And the assessment is per-URL, aggregated into groups of similar pages when a single URL has too little traffic — which is why a fix on one template can move a whole section of the report at once.

How do you fix LCP?

Identify the element first — every Lighthouse run names it, and it is usually either the hero image or the headline text. The fix depends entirely on which. If it is an image, it must not be lazy-loaded, must be served in a modern format at roughly the size it displays, and should be fetched at high priority rather than discovered late in the page. If it is text, the delay is nearly always something blocking the render before that text can paint: a stylesheet from another domain, a web font loading without a fallback, or content that only appears once JavaScript has run.

The structural version of this fix is to render the important part of the page on the server, so the first paint doesn't depend on a script finishing. The page you're reading takes that to its conclusion: server-rendered text as the largest element, no third-party requests at all, and a Content-Security-Policy that blocks them from being added by accident — which is what keeps its own Lighthouse report near-perfect in production.

How do you fix INP?

Cut main-thread work, starting with the code you didn't write. On most marketing sites the interaction delay comes from tag managers, chat widgets, analytics, heatmaps, and testing tools, each firing handlers on every click. Audit what is loaded, delete what no longer earns its place — there is usually more than anyone expects — and load what survives after interaction rather than during page load.

What remains is your own JavaScript. Long tasks are the enemy: a single 400ms block means any tap during it waits. Break heavy work into smaller chunks, hydrate interactive parts rather than the whole page, and keep expensive computation out of event handlers. This is the metric where a page builder's widget sprawl shows up most — and where deleting beats optimizing almost every time. On a recent build for a staffing company, an Elementor site held to a strict budget measured 0ms Total Blocking Time on mobile, throttled: not because the builder is fast, but because nothing unnecessary was loaded around it.

How do you fix CLS?

Reserve space for everything before it arrives. Layout shift is content pushing other content after paint, so every fix is a variation on declaring size up front: width and height on every image and video, a fixed container height for ads, embeds, and anything loaded asynchronously, and no banner or notice injected above existing content once the page is visible.

<!-- Shifts: the browser learns the height when the file arrives -->
<img src="/hero.jpg" alt="">

<!-- Doesn't shift: space is reserved from the first layout pass -->
<img src="/hero.jpg" alt="" width="1600" height="900">

Fonts are the other common source: a fallback with different metrics reflows the text when the web font swaps in. Self-host the font, preload it, and set size-adjust metrics on the fallback so the swap changes nothing about the layout. CLS is the most fixable of the three — a score of zero is a normal outcome, not an exceptional one, and anything above 0.1 is usually three or four specific elements rather than a systemic problem.

Why do the lab and the field disagree?

Because they measure different things, and only one of them counts. A Lighthouse run is a single simulated load on a modelled device and network; Search Console and the Chrome UX Report show what actually happened to real visitors over a rolling 28-day window. Use the lab run to diagnose — it names the LCP element and the long tasks — and use the field data to decide whether you are done.

The practical consequence is patience. A fix deployed today enters the field report gradually and takes weeks to show its full effect, so verify the change locally, confirm it on a lab run against production, and then wait rather than re-optimizing on the assumption it didn't work.

When is it a rescue, and when is it a rebuild?

It is a rescue when the causes are additions — a heavy hero, an unaudited tag stack, missing dimensions, a font loaded from someone else's domain. Those are removable, and the work is measured in days. On a rebuild of a B2B site with the CMS kept in place, moving the rendering to a front end built for the job took Total Blocking Time from roughly 1,050ms to 100ms on mobile — the same class of problem, solved once at the source.

It is a rebuild when the theme or builder generates the problem markup on every page, so each fix has to be re-applied after every content change or update. That is the real test: not how bad the numbers are today, but whether they will stay fixed. If you want the specifics of holding a page fast with no third-party requests at all, the build note on scores under a strict CSP covers the header and its trade-offs — and Core Web Vitals rescues are a standing part of my web development work, separate from any rebuild.

Questions