Core Web Vitals in 2026: What They Are and Why They Still Matter

Core Web Vitals are three measurements of how a page feels to a real visitor: how fast the main content appears (LCP), how fast it reacts to a tap (INP), and whether it jumps around while loading (CLS). In 2026 they still feed Google’s ranking systems and still decide whether visitors stay.

Quick links

• What are Core Web Vitals in 2026?
• What do LCP, INP and CLS actually measure?
• Do Core Web Vitals still affect rankings?
• Why do they matter beyond rankings?
• How do you check your Core Web Vitals?
• What does a site with good vitals look like?
• FAQ

What are Core Web Vitals in 2026?

They are the subset of Google’s page experience signals that it has decided every site owner should track: one for loading, one for responsiveness, one for visual stability.

The set has changed once. Interaction to Next Paint replaced First Input Delay as the responsiveness metric when it became a stable Core Web Vital in 2024, and it has stayed that way since. If you read an older guide that talks about FID, it is out of date.

One detail trips people up. Google does not judge a single visit. It looks at the 75th percentile of page loads, split by mobile and desktop. So a page passes when three out of four real visits are good, not when your own laptop on office wifi says so.

What do LCP, INP and CLS actually measure?

Each metric answers one question a visitor would ask, and each has a number that counts as good. The targets below come from Google’s own Core Web Vitals documentation.

Largest Contentful Paint (LCP): is it loaded yet?

LCP is the time until the largest visible thing on the page has rendered. Usually that is the hero image, a big heading or a block of text. Good is 2.5 seconds or less.

It is the metric most sites fail first, and the usual causes are dull ones:

• An oversized hero image that was never compressed
• A slow server response before anything can start
• Scripts and stylesheets that block rendering
• Fonts that hold the text back until they arrive

Interaction to Next Paint (INP): does it respond when I tap?

INP measures how long the page takes to visibly react after a click, tap or key press, across the whole visit rather than just the first interaction. Good is 200 milliseconds or less.

This is where heavy JavaScript gets found out. A page can look loaded and still feel stuck because the browser is busy running scripts when someone presses the menu button. Tag managers, chat widgets, sliders and page-builder bloat are the usual suspects.

Cumulative Layout Shift (CLS): does it stay put?

CLS scores how much visible content moves unexpectedly while the page loads. It has no unit, just a score. Good is 0.1 or less.

You know the failure: you go to tap a link, an advert or cookie banner loads above it, the page lurches down, and you tap the wrong thing. The fix is almost always reserving space. Images without set dimensions, late-loading embeds and injected banners cause most of it.

Do Core Web Vitals still affect rankings?

Yes, but modestly. Google says good vitals align with what its core ranking systems seek to reward and recommends them for success in Search. It does not say how much weight they carry, and I would be suspicious of anyone who claims to know.

My read, from the sites we build and audit, is simple. Content relevance wins. A fast page with nothing useful on it will not outrank a useful page that is a bit slow. But where two pages are competing on roughly equal content, the one that loads quickly and behaves itself has the edge, and a site that fails badly on all three is leaving that edge to its competitors.

There is a newer reason to care too. AI answer engines mostly read the raw HTML a server sends back. A site that is slow to respond or leans on JavaScript to show its content tends to be the same site that fails LCP and INP. Fixing one usually helps the other, which is a point we make in our post on auditing your site for AI search.

Why do they matter beyond rankings?

Because visitors do not read your Search Console report. They just leave.

A slow, jumpy page loses people before they have read a word, and every visitor lost at that point is one you paid to attract through search, ads or a referral. For a lead generation site, that is the cheapest conversion improvement available: nothing about the offer changes, more people simply stay to see it.

It also shows up in places that are easy to miss:

1. Paid traffic. Clicks that bounce off a slow landing page are money gone.
2. Mobile visitors. They are usually on weaker connections and less powerful devices, and mobile is where most sites fail.
3. Trust. A page that shifts under your thumb feels careless, whatever it says.

If your site already feels sluggish, start with our guide to why your website is so slow. It covers the causes in more detail than there is room for here.

How do you check your Core Web Vitals?

Start with real-user data, then use lab tests to find the cause. Doing it the other way round is the most common mistake.

Google’s PageSpeed Insights documentation explains the split. Field data comes from the Chrome User Experience Report, which collects results from real Chrome users over a trailing 28-day window. Lab data comes from Lighthouse, which loads your page once in a simulated environment. The two can disagree, and when they do, the field data is the one Google cares about.

A sensible order of work:

1. Open the Core Web Vitals report in Google Search Console. It groups your URLs into good, needs improvement and poor, so you see patterns instead of single pages.
2. Run your homepage and two or three key landing pages through PageSpeed Insights. Read the field data first, and check mobile before desktop.
3. Use the Lighthouse results underneath to find the specific cause: the image, the script, the missing dimensions.
4. Fix one thing, then wait. Field data takes weeks to catch up, so do not panic when the numbers lag behind your work.

One caveat. Low-traffic pages may not have enough field data to report at all. In that case PageSpeed Insights falls back to site-wide data or shows nothing, and lab tests are what you have.

What does a site with good vitals look like?

Usually a boring one. Good vitals rarely come from clever tuning. They come from not adding weight in the first place.

Sites that pass comfortably tend to share a few traits:

• Pages are rendered ahead of time and served as plain HTML, so the server has little to do
• JavaScript is added only where something genuinely needs it
• Images are properly sized, compressed and given fixed dimensions
• Third-party scripts are rare and justified one by one

That is the argument for a lean stack, and the reason we build marketing sites on Astro, which ships very little JavaScript by default. Our piece on Astro SEO goes through how that plays out in practice. A plugin-heavy WordPress install can pass too, but it takes constant discipline to stop it creeping back to a fail.

I would not chase a perfect score. Passing all three at the 75th percentile is the target, and anything beyond that has sharply diminishing returns compared with writing something worth reading.