Core Web Vitals: how to optimise LCP, INP and CLS

Core Web Vitals measure three things: how fast the main content loads, with an LCP target under 2.5 seconds; how responsive the page is to interactions, with an INP under 200 milliseconds; and visual stability, with a CLS under 0.1. They are calculated from real visits, at the 75th percentile, over a rolling twenty-eight days. They are not the most powerful ranking levers, but they are among the few you control from end to end.

What are Core Web Vitals? The three metrics and their thresholds

What each one measures, in one sentence

LCP, for Largest Contentful Paint, is the moment the largest visible element is rendered, usually a cover image or a large heading. INP, for Interaction to Next Paint, measures the delay between a visitor’s action and the visible response on screen, across the whole visit. CLS, for Cumulative Layout Shift, quantifies the content shifts that make people click the wrong thing.

Metric	Good	Needs improvement	Poor
LCP	≤ 2.5 s	≤ 4 s	> 4 s
INP	≤ 200 ms	≤ 500 ms	> 500 ms
CLS	≤ 0.1	≤ 0.25	> 0.25

Field data vs lab data

This is the distinction behind most of the confusion. The scores shown by an audit tool come from a simulation, run on one machine, once. The Core Web Vitals that count come from the Chrome User Experience Report, fed by your real visitors’ visits, on their own phones and connections. A site can score 98 out of 100 in the lab and stay in the red in the field, simply because half its audience browses on a mid-range phone.

Check your LCP, INP and CLS in three numbers

Note your three values from Search Console or PageSpeed Insights, enter them below, and the tool tells you where you stand and where to start.

How to optimise LCP: find the culprit element, then serve it faster

Identify the LCP element

Before fixing anything, you need to know which element is being measured. Chrome DevTools names it explicitly in the Performance panel, and PageSpeed Insights identifies it in its diagnostics. Nine times out of ten, it is the cover image or the heading block at the top of the page. Optimising anything else will not change the score, however much time you spend on it.

Fixes in order of return on effort

• Serve the cover image in a modern format, properly sized, and certainly not 2,000 pixels wide and scaled down by the browser.
• Preload it and give it fetch priority, rather than letting it wait its turn behind the scripts.
• Never lazy-load the image at the top of the page: it is the most expensive mistake, and it often comes from a plugin switched on without any configuration.
• Remove whatever blocks rendering, especially fonts and stylesheets loaded from another domain.
• Check server response time: if the first byte arrives after one second, no image optimisation will make up the delay.

How to optimise INP: the metric that replaced FID

Why the March 2024 switch hurt

Until March 2024, the responsiveness metric was FID, which only measured the delay before the first interaction was handled. It was a lenient measure: many sites scored brilliantly while being a pain to use. INP measures every interaction during the visit and keeps the worst ones. On the day of the switch, perfectly green sites turned orange without a single line of code changing.

Break up long tasks

A poor INP almost always comes from JavaScript hogging the main thread. The approach is the same everywhere: record a session in the Performance panel, spot the tasks that exceed fifty milliseconds, and see what triggers them. The usual culprits are third-party scripts, especially analytics tools, consent banners and chat widgets, along with animations recalculated on every scroll.

The fixes range from simple to structural: defer what is not needed for the first render, load widgets only when the visitor gets close to them, split heavy processing into chunks that hand control back to the browser, and simply remove the scripts nobody looks at any more. On many sites, removing two forgotten tools does more than three days of redesign.

How to improve your CLS score: remove layout shifts

CLS is the easiest of the three to fix, because its causes are few and well known. Images without declared dimensions reserve zero pixels and then push the text down. Ad slots and third-party embeds do the same, only worse, because their height varies. Custom fonts cause a shift when they replace the fallback font, if the two do not have comparable metrics. Finally, banners inserted at the top of the page after loading move everything below them.

The remedies are mechanical: declare width and height on every image and iframe, reserve space for blocks that arrive later, tune how fonts load, and display banners as overlays rather than above the content. Half a day is enough on most sites.

Are Core Web Vitals a ranking factor, and how much do they weigh?

Let us be clear: on a competitive query, a slow page with excellent content will rank above a fast page with mediocre content. Core Web Vitals act as one signal among many others, and Google has said so repeatedly. Their value lies elsewhere, and it is twofold. They break ties between comparable pages, which happens more often than people think. And they have a direct effect on conversion rate, regardless of any ranking: a checkout that responds badly loses orders that search had brought in.

That is why I handle them alongside the rest of the technical work, as part of a technical SEO audit, and not as a separate project run to turn a dashboard green.

Core Web Vitals mistakes to avoid

• Optimising the lab score instead of the field data, which is the only data Google uses.
• Measuring the home page and inferring the state of the whole site: category and checkout pages are the ones that make money.
• Stacking performance plugins, which end up tripping over each other and adding the weight they claim to remove.
• Turning on lazy loading everywhere, including the cover image.
• Judging a change on the same day: field data is smoothed over twenty-eight days, so you have to wait before drawing conclusions.