Core Web Vitals in 2024: Which Thresholds Actually Matter

Written by

in

Google has spent years telling us that page experience is a ranking factor, and every year the goalposts move a little. As of early 2024, three metrics carry the Core Web Vitals label, and only three. If your dashboard is still red on any of them, this is the order to fix them in.

The three metrics that count today

Largest Contentful Paint measures how long the biggest element above the fold takes to render. Google considers anything under 2.5 seconds good, 2.5 to 4 seconds in need of improvement, and above 4 seconds poor. First Input Delay measures the gap between a user’s first interaction and the browser starting to respond to it; the threshold is 100 milliseconds. Cumulative Layout Shift scores how much your content jumps around while loading, and the target is 0.1 or below.

Those three numbers, 2.5 seconds, 100 milliseconds and 0.1, are the whole scorecard. A page passes Core Web Vitals only if it is in the good band on all three, measured at the 75th percentile of real user traffic over a rolling 28 day window.

Why First Input Delay flatters almost everyone

Here is the uncomfortable part: roughly 96 percent of origins already pass FID. That is not because the web got fast. It is because FID only measures the delay before the browser starts processing the first input, not how long the page takes to actually do something useful. A page can register the click in 20 milliseconds and then freeze for two seconds while React reconciles, and FID will still report a perfect score.

Google is aware of this. An experimental metric called Interaction to Next Paint has been available in the Chrome User Experience Report since 2022, and it measures the full latency of an interaction rather than just the beginning of it. It is not part of Core Web Vitals, and Google has not committed to a date for making it one. Treat it as something to watch, not something to optimise for.

Where WordPress sites usually lose

On a typical WordPress install, LCP is the metric that fails, and the culprit is almost always an unoptimised hero image or a render blocking stylesheet in the head. Serving the hero as WebP and adding fetchpriority high to that single image often moves LCP by 800 milliseconds on its own.

CLS failures are usually ads, embeds or webfonts. Reserve the space with explicit width and height attributes, and use font-display swap with a matched fallback so the reflow is small when the real font arrives.

Measure with field data, not lab data

Lighthouse runs a simulated load on a throttled connection and gives you a number in ten seconds. It is useful for catching regressions in CI, and it is not what Google ranks on. Search Console reports field data from real Chrome users, and that is the source of truth. The two disagree constantly, and when they do, the field data wins.

Budget four to six weeks between a fix shipping and the Search Console report catching up, because the 28 day rolling window has to flush the old sessions out first.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *