What are Core Web Vitals in 2026? LCP, INP and CLS

Three numbers decide whether Google calls a page fast: 2.5 seconds, 200 milliseconds and 0.1. Those are the “good” thresholds for Core Web Vitals, and if you run a website you’ll run into the term in Search Console, in PageSpeed Insights, and sooner or later in a cold email from someone selling speed audits.

Core Web Vitals turn “does this page feel fast and steady” into measurements. There are three of them, they’re collected from real visitors rather than a test on somebody’s laptop, and they feed into Google’s page experience signals in search. Below I cover what each one measures, how much I think they matter for rankings (less than the sales pitches say), and where people get them wrong. I’m writing from Singapore, on fibre, which is about the best case for judging page speed, and that comes back in the misconceptions section.

What it is

Core Web Vitals are three metrics that Google defines and documents on web.dev. Each one covers a different way a page can irritate a visitor.

• LCP (Largest Contentful Paint): how long until the biggest thing in view, usually a hero image or a headline block, has rendered. Good is 2.5 seconds or less.
• INP (Interaction to Next Paint): how long the page takes to visibly respond after a tap, click or key press. Good is 200 milliseconds or less.
• CLS (Cumulative Layout Shift): how much the visible content jumps around while the page loads. It’s a unitless score, and good is 0.1 or less.

Poor starts above 4 seconds for LCP, above 500 milliseconds for INP and above 0.25 for CLS. Between good and poor sits a “needs improvement” band.

INP is the newest of the three. It replaced First Input Delay (FID) on 12 March 2024. FID only measured the wait before the browser started handling a visitor’s first interaction, so a page could pass while feeling sluggish on every tap after that. INP looks at interactions across the whole visit and reports something close to the slowest one.

The “core” part means Google considers them relevant to every page. Other web vitals exist, like Time to First Byte and First Contentful Paint, but they aren’t part of the pass or fail assessment. As far as I know the set and the thresholds haven’t changed since the INP swap, but Google has changed the list before, so check the Core Web Vitals page on web.dev before you build a plan around the numbers here.

How it works

Google uses two kinds of data, and mixing them up causes most of the confusion.

Field data comes from real Chrome users who’ve opted in to sharing usage statistics. Google collects it into the Chrome User Experience Report, usually called CrUX, on a rolling 28-day window. For each metric it looks at the 75th percentile, meaning three quarters of visits need to hit the “good” number. A page passes the assessment when all three metrics are good at that percentile. Mobile and desktop are scored separately.

Lab data comes from a simulated page load in a tool like Lighthouse, with throttled network and CPU. It’s handy for debugging because you can rerun it as often as you like, but it isn’t what Google assesses. In its standard page-load test Lighthouse can’t measure INP at all, since nobody taps anything, so it reports Total Blocking Time as a rough stand-in.

Both show up in PageSpeed Insights. The real-user block at the top is CrUX. The score underneath is Lighthouse. Search Console has its own Core Web Vitals report that groups URLs behaving alike and marks each group good, needs improvement or poor. Low-traffic sites often have no field data at all, and for those pages the lab numbers are all you get.

What usually drags each number down:

• LCP: slow server response, oversized hero images, render-blocking CSS and JavaScript, and lazy-loading the hero image by mistake.
• INP: too much JavaScript hogging the main thread. Tag managers, chat widgets and ad scripts are the usual suspects.
• CLS: images and embeds with no reserved space, late-loading ads, web fonts swapping in, and banners injected above the content. Cookie consent banners are a common one. If you’re choosing a consent tool, The Privacy Wire is a better place for the privacy side of that decision than this site.

Heavy client-side JavaScript hits LCP and INP, and it also changes what Googlebot sees, which I went through in javascript rendering and the half Googlebot never sees.

Why it matters

Four reasons, roughly in the order I’d weight them.

First, it’s a search signal, but a small one. Google’s page experience documentation lists Core Web Vitals among the things its ranking systems look at, and says in the same breath that a good page experience doesn’t beat more relevant content. I treat it as a tiebreaker between pages that are otherwise close. I haven’t run a controlled test on how much it moves rankings, and I don’t know of anyone outside Google who has published clean data.

Second, visitors feel it. Nobody reads “CLS 0.31” but everybody has tapped the wrong button because an ad loaded and shoved the page down. A slow INP makes a menu or a form feel broken, and people leave pages that feel broken.

Third, money pages. If you sell anything or collect leads, the INP on your add-to-cart or submit button is the number I’d look at before any other. That’s my opinion, not a study.

Fourth, it’s public. Anyone’s field data is a paste into PageSpeed Insights away, including a competitor’s, provided the site has enough traffic to have any. If you’re weighing up a site to buy, it’s a ten-minute technical check to run alongside the work in auditing the link profile of a site you just bought.

Common misconceptions

Four wrong takes I see a lot, and what’s actually going on.

“A score of 100 in PageSpeed Insights means I pass.” The big score is a Lighthouse lab number. The assessment uses field data. You can score 95 in the lab and still fail INP with real users, and the reverse happens too.

“Fix Core Web Vitals and rankings will jump.” Usually they won’t. It’s a tiebreaker layered on top of relevance, links and everything else. If you have two pages competing for the same query, that will cost you more than 300 milliseconds of LCP. Here’s the bit you might argue with: on a small content site I’d sort out cannibalisation and broken internal links before touching an image compression plugin.

“FID is one of the three.” It was, until March 2024. Older guides and some dashboards may still list it, so a report that treats FID as current deserves a second look.

“It loads fast for me, so it’s fine.” Your pass or fail is set by the visit at the 75th percentile, not the typical one. A slow tail of mid-range Android phones on patchy connections can sink a site that feels instant on my Singapore fibre. If your readers are spread across Southeast Asia, trust PageSpeed Insights’ mobile test, which throttles the connection and CPU to mimic a mid-range phone, over whatever you see on your own machine.

Where to go from here

Three follow-ups, depending on what you found.

• If you haven’t picked a measurement tool yet, start with the best site speed testing tools in 2026. PageSpeed Insights and Search Console are free and enough for a first pass.
• To decide how much of your week this deserves, read technical SEO that actually matters.
• To see how Googlebot experiences your server rather than how visitors do, try the best log file analysis tools for SEO in 2026. Slow server responses hurt both crawling and LCP, so it’s a useful second angle.

The rest of the SEO explainers are in the blog index.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-09-26.