What are Core Web Vitals, and how do you read them?

When someone says a website “feels slow”, they rarely mean just one thing. The important part may take a while to appear, a button may not react when tapped, or the text may jump just as you start reading. Those are three different annoyances with three different causes, and Google measures them separately.

Core Web Vitals are those three measurements. Google uses them as a ranking signal, but their practical value lies elsewhere: they turn what a visitor feels into numbers and let you decide what to fix first.

The three metrics, in plain language

LCP (Largest Contentful Paint). How long the largest element of the first screen takes to render: usually the main image, a headline or a block of text. It answers the question “when did I see that the page was actually there?”.

INP (Interaction to Next Paint). How long the page takes to respond visibly when you tap, click or type. It considers every interaction during the visit and keeps one of the worst. In 2024 it replaced FID, which only measured the first interaction, and it is considerably stricter.

CLS (Cumulative Layout Shift). How much the content moves around while loading. It is not expressed in seconds but as a unitless score combining how much of the screen shifts and how far. It is the button that slips out from under your finger because a notice has just appeared above it.

Other metrics are useful for diagnosis, such as TTFB (how long the server takes to start responding) or FCP (the first thing painted), but they are not part of the assessment.

Which figures count as good?

Google publishes three bands for each metric:

Metric	Good	Needs improvement	Poor
LCP	up to 2.5 s	2.5 to 4 s	over 4 s
INP	up to 200 ms	200 to 500 ms	over 500 ms
CLS	up to 0.1	0.1 to 0.25	over 0.25

A page passes the assessment when all three sit in the good band. One failure is enough for a negative verdict. Mobile and desktop are assessed separately, and passing on desktop while failing on phones is common.

Why the 75th percentile and not the average?

The figures do not come from the average visit but from the 75th percentile: the value that three out of four visits do not exceed. If your LCP at p75 is 2.3 seconds, 75% of people saw the main content within 2.3 seconds.

An average would hide precisely the people having the worst time, usually those browsing on a basic phone with poor coverage. With p75, a quarter of your audience can have a bad experience without sinking the score, but half cannot. That is why what moves the result is rescuing the slow end, not speeding up people who were already fast.

Field data and lab data

This is where most of the confusion lies. There are two ways of measuring, and they produce different figures by design.

Field data. It comes from the Chrome UX Report (CrUX), a public dataset Google builds from real visits by Chrome users who share usage statistics. It is aggregated over a rolling 28-day window. This is what counts for the assessment.

Lab data. It comes from tools such as Lighthouse, the engine behind the 0 to 100 score in PageSpeed Insights. They load the page once, on a simulated device and network. They are repeatable and very useful for debugging, but they do not describe what your audience experiences.

Why they do not match

• The device. The simulation uses a fixed mobile profile; your audience uses whatever phone they own, sometimes a far humbler one.
• The network. The lab simulates a stable connection; out in the world there is patchy coverage and congested networks.
• Interaction. Lighthouse loads the page but never uses it, so it cannot measure INP. Instead it estimates how much the browser is blocked during loading (the Total Blocking Time). A slow response to taps only truly shows up in the field.
• What happens after loading. Cookie notices, chat widgets, ads or blocks that appear on scroll move real users’ CLS and often do not appear in a lab load.
• Time. The lab is a snapshot of now; the field summarises four weeks. A fix published yesterday already shows in Lighthouse and takes weeks to be fully reflected in CrUX.

A useful rule to keep your bearings: the lab helps you find the cause; the field tells you whether the problem exists and whether you have actually solved it.

What to do when a metric fails

Each metric has its usual suspects:

When LCP fails:

• The main image is too heavy or uses an old format. Compress it, serve it as WebP or AVIF, and at the size it is actually displayed; the guide to image formats and sizes covers how.
• That image is lazy-loaded (loading="lazy") even though it sits on the first screen. It should be requested as early as possible, even with fetchpriority="high".
• The server is slow to respond. If TTFB already uses up half the budget, no front-end optimisation will make up for it: you need caching, a CDN or better hosting.
• Fonts and stylesheets blocking the first render.

When INP fails:

• Too much JavaScript keeping the browser busy: marketing tags, chat widgets, third-party embeds. Reviewing whether all of them are still needed is usually the quickest win.
• Long tasks running right at the moment of a tap. Breaking them up lets the browser respond in between.

When CLS fails:

• Images, videos or iframes without width and height (or aspect-ratio), so no space is reserved for them.
• Notices, banners or ads that push content down instead of overlaying it or having space set aside.
• Web fonts that change the size of the text once they finish loading.

Start with mobile. It is almost always the one that fails, because the network and processor are weaker, and it is the one that counts when people search from their phones. If your site is not yet built for small screens, that is the first problem to tackle; we explain why in responsive design and why it matters.

How much do they weigh in rankings?

It is worth keeping this in proportion. Core Web Vitals are a real signal, but a light one next to relevance: a slow page that answers the search better will still rank above a fast one that does not. Where they do make a difference is between equally useful pages, and above all in what happens after the click: fewer people leaving, more forms completed, more readers reaching the end.

For the other ranking factors, the complete guide to search rankings gives the wider picture.

Checking yours

The Core Web Vitals checker queries Google’s CrUX report directly, so it shows field data rather than a simulation. Type your domain to see the whole origin, or a specific URL if it has enough traffic. You will see mobile and desktop side by side, the p75 for LCP, INP and CLS (with FCP and TTFB for support), how visits split between good, needs improvement and poor, and whether you pass the assessment.

If something comes up red, use Lighthouse to look for the cause in that specific metric, fix it, and check CrUX again a few weeks later, once the 28-day window has caught up with the change. If no data appears, that is not an error: your site does not yet have enough Chrome visits, and lab data is the only reference available.

---

Core Web Vitals do not reward a round score: they reward a page that shows up quickly, responds when touched and stays still. Looking at them with real data and per device is the most direct way to know what your audience is experiencing.