Core Web Vitals are a growth lever, not a checklist
Speed is not a vanity metric. It is the cheapest conversion-rate optimization most sites never ship.
Core Web Vitals are Google’s three field-measured metrics for how a page feels to a real person on a real connection. Largest Contentful Paint (LCP) should land at or under 2.5 seconds, Interaction to Next Paint (INP) at or under 200 milliseconds, and Cumulative Layout Shift (CLS) at or under 0.1. The number that counts is the 75th percentile of real visits over a rolling 28-day window — not the score your laptop returns on office wi-fi. That distinction is the whole game: a site can pass every lab test and still fail in the field, because the median Indian visitor arrives on a mid-range Android over patchy mobile data. Treat the three as an ongoing budget rather than a pre-launch checkbox and they become the cheapest conversion work available, because every fix compounds across every page and every campaign you will ever run.
What are Core Web Vitals, exactly?
LCP measures when the largest element in the viewport finishes rendering — nearly always a hero image, a background, or a large block of headline text. INP replaced First Input Delay in March 2024 and is stricter: rather than timing only the first interaction, it looks at the latency of every click, tap and key press across the visit and reports close to the worst one. CLS measures how much content jumps around while the page settles, scored as a unitless product of how much moved and how far it travelled. Two things matter here. First, these are field metrics, not lab estimates: Lighthouse approximates them, but Google reports on the Chrome User Experience Report, collected from real Chrome users who opted into sharing data. Second, passing means hitting the threshold for 75% of visits, so the slowest quarter of your audience is exactly the group that decides whether the page passes or fails, which is why lab and field scores often disagree.
Which metric should you fix first?
Almost always LCP, for two reasons. It is usually the worst of the three metrics on a content or marketing site, and the fixes are the most mechanical — you rarely need to touch application logic to move it, just image handling and render-blocking resources. It is also the metric most directly tied to bounce, because it marks the moment a visitor can actually tell whether they are in the right place at all; everything before that moment is a blank or half-drawn screen. The exception is an application rather than a marketing site. If people spend twenty minutes inside a dashboard, filtering, sorting and clicking through screens, INP is what they experience as “slow” and LCP barely registers after the first load, since it only happens once per session. So diagnose before you prioritise: pull your own field data and see which threshold you are actually failing, rather than optimising whichever metric happens to be the most interesting one to fix.
How do you fix LCP without a rewrite?
Start with the hero image, because it is the LCP element on most pages and it is usually shipped at the wrong size in the wrong format. Serve it as WebP or AVIF instead of a full-resolution JPEG, generate a srcset so a 360px phone stops downloading a 1200px file meant for a desktop monitor, set explicit width and height so the browser reserves the space before the bytes arrive, mark it fetchpriority="high" so the browser fetches it before less important assets, and preload it in the head. Do not lazy-load it: loading="lazy" on the LCP element actively delays the exact metric it is meant to help, a mistake baked into most default CMS templates. None of this requires touching application logic or scheduling a framework migration — it is layout and asset handling, typically an afternoon of work once you know which image is the culprit, which a quick look at Chrome DevTools will confirm.
Then look at what blocks the render. Every stylesheet in the <head> is render-blocking by definition, and every font loaded without font-display: swap can hold your text hostage while it downloads. Add preconnect hints for font and CDN origins so DNS, TCP and TLS are not negotiated in series at the exact moment they are needed. None of this requires a framework migration; it is an afternoon of work on most sites, which is precisely why it keeps getting skipped in favour of something that sounds more strategic.
What actually breaks INP?
Long tasks on the main thread. When JavaScript occupies the main thread for more than 50 milliseconds, the browser cannot respond to anything else until that task finishes, so every interaction that lands during that window queues behind it and the tap or click appears to do nothing. INP reports close to the worst of these delays across the whole visit, not just the first one, which is why a page that felt fine on load can still fail the metric once someone starts actually using it. The usual culprits are third-party tags — analytics, chat widgets, consent managers, ad scripts — loaded synchronously and given the same execution priority as the code that makes the page actually work, so a chat widget’s initialisation script can block a button tap as effectively as broken application code. The fix starts with knowing what is actually running, because most teams underestimate how many third-party scripts have accumulated on a page nobody has audited in months.
The fixes are unglamorous. Audit what third parties you are actually loading and remove the ones nobody has read a report from in six months. Defer everything not needed for first interaction. Break long-running work into smaller chunks so the browser can respond between them. We keep a hard rule on our own builds that a tag has to earn its place with a named owner and a stated purpose, because tag managers accumulate scripts the way a garage accumulates half-empty paint tins.
Why does CLS still happen in 2026?
Because layout shift is caused by things that arrive late, and most sites have more late arrivals than they realise. Images and iframes without explicit dimensions are the classic case: the browser does not know how much space to reserve until the file downloads, so content jumps the moment it arrives — and the fix, explicit width and height attributes with CSS handling the responsive sizing, has been available and well documented for years, yet keeps recurring because CMS uploads routinely strip it out. The subtler causes are less obvious: cookie banners and promotional bars injected above existing content after the initial render, ad slots that resize themselves once the creative loads, and web fonts that swap in at different metrics to the fallback font, shifting every line of text they touch. The principle is the same in every case: reserve the space before the element exists, whether that means a fixed-height container, a CSS-sized ad slot, or a fallback font matched with size-adjust.
This is also the one vital that is cheap to protect permanently, since dimensions written into a template stay written.
How do you stop the numbers drifting back?
Performance regresses by default, and it does so quietly. Someone adds a tracking tag, someone uploads an uncompressed image through the CMS, a plugin update pulls in a new dependency — and three months later you are back where you started with nobody able to name the single change that did it, because no individual change looked significant on its own. The fix is a performance budget stated in numbers your team can actually check: a page-weight ceiling, a maximum script count, a target LCP, enforced at the point where changes land rather than in a quarterly audit nobody reads. We benchmark LCP, INP, CLS and TTFB at the start of every project and re-run them before each release, treating performance as a feature with a named owner rather than a task belonging to whoever last complained about it. That ongoing discipline, not a one-time fix, is the difference between a site that is fast at launch and one that is still fast in December.
Where this connects to the rest of the work
Speed sits upstream of nearly everything else you are paying for. Paid traffic gets more expensive when the landing page loses a share of its clicks before it paints, so slow pages quietly inflate the cost of every PPC campaign. Search visibility depends on pages being crawlable and fast enough that Google is willing to render them, which is why performance work sits inside our SEO engagements rather than beside them. And most of the fixes above live in the front end, so they belong in the same conversation as front-end development and the wider web development build.
If you want the cheapest possible version of this, read the hero-image post next. It is one fix, usually under an hour, and it moves LCP further on more sites than anything else on this list.