Core Web Vitals for people who'd rather be building

Core Web Vitals get discussed as an SEO chore, which is the least interesting framing available. They are three measurements of whether your page is annoying to use: does it show up, does it respond, does it hold still. Google happens to rank on them. Users react to them whether Google exists or not.

Here is what each one measures, and the order to fix them in — which is not the order they are usually listed.

The three metrics

INP replaced First Input Delay in March 2024. The change matters: FID only measured the delay before the browser started processing your first interaction, which was a generous metric that most sites passed. INP measures the full round trip — input to visible update — across every interaction in the visit. Plenty of sites that comfortably passed FID do not pass INP.

Field data beats lab data

The most common mistake is optimising for Lighthouse. Lighthouse is a lab tool: one simulated device, one throttled connection, one run, on your machine. Useful for diagnosis, meaningless as a verdict.

What Google actually uses is field data — the Chrome User Experience Report, collected from real Chrome users on real hardware and real networks. It is assessed at the 75th percentile, so a quarter of your visitors can have a worse experience than your score suggests.

Two consequences worth internalising. Your mid-range Android users, not your laptop, decide your score. And field data lags — it is a rolling 28-day window, so a fix today shows up in a few weeks. Do not panic and revert something that worked.

Check PageSpeed Insights for field data on a specific URL, and Search Console’s Core Web Vitals report for site-wide groupings.

Fix LCP first

LCP is almost always the biggest win, because it is almost always one element: the hero image, or the headline if there is no image.

Find out what your LCP element is before changing anything. PageSpeed Insights names it. It is frequently not what you assumed.

Then, in order of impact:

1. Serve it in a modern format at a sensible size. A 2.4 MB JPEG hero is the single most common cause of a failing LCP. WebP or AVIF, resized to the largest dimension it is actually displayed at, usually removes 70–90% of the bytes.
2. Do not lazy-load it. loading="lazy" on the hero image actively delays LCP. Lazy-load everything below the fold; never the thing at the top.
3. Raise its priority. fetchpriority="high" tells the browser to fetch it ahead of other resources.
4. Remove render-blocking resources. Stylesheets and synchronous scripts in the head block the first paint. Inline the critical CSS, defer the rest.

<img src="/hero.webp"
     width="1600" height="900"
     fetchpriority="high"
     decoding="async"
     alt="Descriptive alt text">

On a typical marketing site those four steps often take LCP from four seconds to under two, and they are all configuration rather than architecture.

Fix CLS second

CLS is the easiest of the three to fix and the most irritating to experience. It is the page moving under your thumb just as you tap.

There is essentially one cause: something arrived late and nothing had reserved space for it.

• Put width and height on every image. Browsers use the ratio to reserve the box before the file arrives. This one attribute pair fixes most CLS on most sites.
• Reserve space for embeds and ads with a fixed-height container. An iframe that pops in at 250px tall pushes everything below it.
• Never inject content above existing content after load. Cookie banners, promo bars and notification strips belong in an overlay or in space that was already allocated.
• Watch web fonts. A fallback font with different metrics swapping to your real font reflows text. font-display: swap plus size-adjust on the fallback, or self-hosting, keeps this small.

Fix INP last

Not because it does not matter, but because it is the hardest and usually the least broken. If LCP and CLS are bad, they are costing you far more.

INP is a main-thread problem. The browser cannot paint a response while JavaScript is busy, so long tasks translate directly into sluggish taps.

• Ship less JavaScript. Nothing else comes close. Audit your bundle; a date library or an icon set imported wholesale is a common and easy win.
• Break up long tasks. Anything over 50ms blocks interaction. Chunk the work and yield between pieces.
• Debounce expensive handlers on input, scroll and resize.
• Animate only transform and opacity. Animating width, top or box-shadow forces layout and paint on every frame.

That last point is worth taking seriously even on a site with very little JavaScript. A heavy CSS animation can hurt INP on a mid-range phone as effectively as a bad script.

The font shortcut

One change fixes a piece of all three metrics: self-host your fonts.

A Google Fonts stylesheet costs a DNS lookup, a TLS handshake and a request before the browser even discovers which font files it needs — all on the critical path. Then the fallback renders, the real font arrives, and the text reflows.

Download the woff2 files, subset them to the characters you actually use, and serve them from your own origin. On this site the fonts are embedded directly in the HTML as base64, which removes the request entirely. That is unusual and only sensible because the subsets are small, but self-hosting alone gets you most of the benefit.

The order that works

If you do nothing else:

1. Find your LCP element. Compress it, do not lazy-load it, give it fetchpriority="high".
2. Add width and height to every image on the page.
3. Self-host your fonts.
4. Delete the JavaScript you are not using.

Four steps, no rearchitecting, and they will move a typical failing site into the green. Then measure with field data, wait for the window to catch up, and only chase the remaining milliseconds if the numbers say you need to.

Performance work has a natural stopping point. Find it, and go back to building.