Core Web Vitals 2026

A retail client rebuilt their catalogue pages last spring and shipped with a Lighthouse performance score of 98. Six weeks later Search Console still showed the same URLs in the "needs improvement" bucket and mobile conversion had not moved. The redesign was not the problem; the measurement was. Their lab score came from a simulated fast connection with nobody clicking anything, while the field data Google reads was dominated by mid-range Android phones tapping a filter control that took 380 milliseconds to respond.

That gap between what a performance tool tells you and what Core Web Vitals in 2026 measures is where most performance budgets go without effect. Below: what the three metrics are, which one you are most likely failing, and which fixes have evidence behind them.

The Three Metrics and the Numbers You Have to Beat

Nothing about the thresholds changed for 2026. INP replaced First Input Delay in March 2024, the last structural change to the set.

Metric	Measures	Good	Needs work	Poor
Largest Contentful Paint (LCP)	How long until the main content appears	≤ 2.5 s	2.5–4.0 s	> 4.0 s
Interaction to Next Paint (INP)	How fast the page responds to taps and clicks	≤ 200 ms	200–500 ms	> 500 ms
Cumulative Layout Shift (CLS)	How much the layout jumps around	≤ 0.1	0.1–0.25	> 0.25

Two details in the fine print do most of the damage. First, the score is taken at the 75th percentile of real visits over a rolling 28-day window, not the median. You are graded on your fourth-worst visitor out of five, usually someone on an older phone and a congested mobile network. Optimising for your own laptop tells you almost nothing.

Second, mobile and desktop are assessed separately and the spread is wide — roughly half of mobile origins pass all three, against something closer to 57 percent on desktop. If you only check one, check mobile.

You will also see claims that a "Core Web Vitals 2.0" with a new visual stability metric has arrived. It has not. There are community proposals for a successor to CLS, but Google's documented set is still LCP, INP and CLS, and planning around an unshipped metric wastes a quarter.

INP Is the One You Are Probably Failing

Independent 2026 analyses put the share of sites missing the 200 millisecond INP threshold at around 43 percent, comfortably the most-failed of the three. The reason is structural: FID only measured the delay before the browser began handling your first interaction. INP measures the full time from interaction to the next painted frame, across essentially every interaction on the page, and reports near the worst of them.

That turned a metric almost everyone passed into one that punishes the standard modern front-end build. The Chrome team's own priority list puts three fixes at the top:

1. Break up long tasks. Any single task over 50 milliseconds blocks the main thread from responding. Yield back to the browser between chunks of work instead of running 400 milliseconds of initialisation in one go.
2. Ship less JavaScript. Not "minify more" — ship less. Run Chrome DevTools' coverage tool on your busiest page and you will typically find a third of the bundle is never executed. Tag managers are the usual offender, because tags get added and never removed.
3. Avoid enormous rendering updates. Large DOM trees make every layout recalculation expensive, and rendering competes with interaction handling for the same thread.

None of these are configuration changes. They are engineering work in your application code, which is why INP failure rates have stayed high two years after the metric landed.

LCP: The Download Is Almost Never the Problem

This is where most teams optimise the wrong thing. About 40 percent of origins in the Chrome UX Report miss the 2.5 second LCP threshold, and on 73 percent of mobile pages the LCP element is an image — so the instinct is to compress harder.

Chrome's field data says that instinct is mostly wrong. On the majority of origins with poor LCP, less than 10 percent of the p75 LCP time is spent actually downloading the image. At the 75th percentile those pages wait around 1,290 milliseconds between the first byte of HTML arriving and the browser even requesting the LCP image. Half the budget is gone before the download starts.

It goes to two places, both fixable without touching the image file:

• Discoverability. On 35 percent of pages with an image LCP, the URL is not in the initial HTML response, so the browser's preload scanner cannot find it — it is behind data-src, a CSS background, or client-side rendering that has to boot first.
• Priority. Only about 15 percent of eligible pages use fetchpriority="high" on the resource that defines their LCP. Meanwhile plenty of sites put loading="lazy" on the hero image, which asks the browser to confirm it is in the viewport before fetching — a delay you paid for deliberately.

Fix those first: a real <img src> in server-rendered HTML, fetchpriority="high", no loading="lazy" above the fold. Then look at server response time, where a CDN serving your HTML — used by only about a third of document requests — is the largest lever most small sites have not pulled.

And then, yes, compress the image

Once the image is discoverable and prioritised, byte size is the remaining variable, and on mobile it is a real one. A hero photograph exported from a design tool at 2.4 MB will not arrive in 2.5 seconds on a median 4G connection no matter how early you request it. Modern formats and sane quality settings routinely cut that 60–80 percent with no visible difference at display size.

CLS: Mostly Solved, With Three Stubborn Causes

CLS is the metric most sites pass, though about a quarter still do not. The causes are well understood and cheap to fix.

Unsized images. Two-thirds of pages have at least one image without explicit width and height. Without them the image occupies zero height until it loads, then shoves everything below it down the page. Setting the attributes, or a CSS aspect-ratio, costs one line.

Ineligible back/forward cache. A page restored from the bfcache has its layout shifts eliminated entirely — the bfcache produced the largest single-year CLS improvement Chrome has recorded. Pages are commonly excluded by a no-store cache directive or a legacy unload listener; DevTools tells you which.

Layout-inducing animations. Pages animating any CSS property that can affect layout are 15 percent less likely to have good CLS, and those animating margin or border width hit "poor" at roughly twice the overall rate. Cookie banners sliding in from the edge are the classic case. Animate transform: translateY() instead of top and the shift disappears.

What Does Not Move the Score

Being specific about this saves more time than any optimisation on the list above.

Chasing a Lighthouse 100. It is a lab simulation and it cannot measure INP. A green lab score next to a failing field score is normal, not a bug.

Minifying what you already ship. Shaving 8 percent off a bundle that is 400 KB too large does not change how long the main thread is blocked. Deleting the bundle does.

Micro-optimising a metric you already pass. Going from 1.9 s to 1.6 s LCP earns nothing. The thresholds are pass/fail at the 75th percentile — no bonus for being fast, only a penalty for being slow.

Compressing images when the LCP element is text. Check what your LCP element actually is in PageSpeed Insights before spending a day in the media library. On text-led pages it is usually a heading, and the fix is TTFB and font loading.

Expecting a ranking jump. Page experience is a modest tiebreaker between comparable results, not a substitute for relevance. Returns show up in conversion and bounce rate long before position.

Where to Start on Monday

One sprint, in this order:

1. Pull the field data — Search Console's report or the CrUX panel in PageSpeed Insights — and identify the failing metric per template, not per URL.
2. If INP fails, profile the interaction users make most and find the long task behind it.
3. If LCP fails, confirm what the LCP element is, then check discoverability and fetchpriority before touching file sizes.
4. If CLS fails, set dimensions on every image and check bfcache eligibility. Both are usually a single afternoon.
5. Re-measure 28 days later — that is the window the score is calculated over, and anything sooner is noise.

Most sites do not need a rebuild. They need a hero image the browser can see in the HTML, a bundle with the dead third removed, and width attributes on their images.

If your field and lab data disagree and you would rather not spend a quarter working out why, our consultancy team does this diagnosis regularly — send us a URL and we will tell you which metric is costing you and what fixing it involves.

Frequently Asked Questions