Core Web Vitals in 2026: LCP, INP and CLS without the jargon
Three acronyms decide a chunk of how Google ranks you and how your site feels to use. Here is what LCP, INP and CLS really measure — and, for each, the change that moves the number most.
Core Web Vitals are three numbers Google measures on real visits: how fast the main content appears (LCP, good is ≤ 2.5s), how quickly the page reacts to a tap (INP, good is ≤ 200ms), and how much the layout jumps while loading (CLS, good is ≤ 0.1). You are graded at the 75th percentile, so three out of four visits have to be good — not just yours on a fast laptop.
Google has a lot of ranking signals and most of them you cannot measure. Core Web Vitals are the rare exception: three concrete numbers, collected from real Chrome users, that you can watch and improve. They are worth understanding because they sit at the intersection of two things you care about — search rankings, and visitors not getting annoyed.
They are also, more than any other performance metric, a thing people spend months optimising in the wrong order. So this piece is organised around what actually moves each number, roughly ranked.
What counts as good in 2026
| Metric | Measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP | When the biggest element finishes rendering | ≤ 2.5s | 2.5–4s | > 4s |
| INP | Lag from an interaction to the next visual update | ≤ 200ms | 200–500ms | > 500ms |
| CLS | How much visible content shifts unexpectedly | ≤ 0.1 | 0.1–0.25 | > 0.25 |
Two things about that table trip people up. The thresholds are measured at the 75th percentile of real visits over a rolling 28-day window — so a quarter of your visitors can have a bad time and you still pass, but you cannot pass by testing on your own machine. And a URL only gets its own data once it has enough traffic; smaller pages inherit an assessment from a group of similar URLs on your origin, which is why fixing one slow template can move pages you never touched.
LCP: getting the big thing on screen
LCP is almost always your hero image, your headline block, or the main banner. It is the metric most sites fail, and it is also the most fixable, because the causes are boring and mechanical.
What moves it most
In rough order of how much difference they make on a typical site:
- Serve the LCP image properly. Right format (AVIF or WebP), right dimensions for the display size, from an edge server near the visitor. This single change moves more sites from red to green than everything else combined.
- Make the browser discover it early. An image referenced by CSS, or lazy-loaded, or injected by JavaScript, gets found late. Put it in the HTML as a plain img tag, and never set
loading="lazy"on the element that is your LCP. - Cut time to first byte. LCP cannot start until the HTML arrives. If TTFB is 800ms you have spent a third of your budget before rendering begins.
- Stop render-blocking resources. Every synchronous stylesheet and script in the head delays the paint.
Check which element Chrome actually considers your LCP before optimising anything — DevTools shows it in the Performance panel. People routinely spend a week optimising a hero image that was never the LCP element.
INP: making the page respond
INP replaced FID in March 2024 and it is a much harder metric to pass. FID only measured the delay before the first interaction was handled. INP measures the whole thing — input delay, your event handler running, and the browser actually painting the result — across every interaction on the page, and reports roughly the worst one.
The cause is nearly always the same: too much JavaScript occupying the main thread. While a long task is running, the browser cannot respond to anything. The visitor taps a menu, nothing happens for 400 milliseconds, they tap again, and now you have two menu opens queued.
What moves it most
Break up long tasks — anything over 50ms — so the browser gets a chance to respond between them. Defer third-party scripts that do not need to run during load; analytics, chat widgets and tag managers are the usual offenders and they are usually easy to postpone. Avoid doing expensive work synchronously inside an event handler, and if a click triggers something heavy, paint an acknowledgement first and do the work after.
INP is the one metric a CDN cannot fix for you. The edge can deliver your JavaScript bundle in 15 milliseconds; the browser still has to parse and execute it. If your INP is red, the work is in your code, not your delivery.
CLS: making the page hold still
Layout shift is the one that makes you tap the wrong button because an ad loaded and shoved everything down. It is measured as a score rather than a time, combining how much of the viewport moved with how far it moved.
The fixes are unglamorous and reliably effective. Set explicit width and height attributes on every image so the browser reserves the space before the file arrives. Give ad slots and embeds a fixed minimum height. Load web fonts with font-display: swap and a metrics-matched fallback so text does not reflow when the real font lands. And never inject a banner, cookie notice or promo bar above content that has already rendered — put it in the HTML from the start, or overlay it.
Where people waste their time
Three things that feel productive and move nothing:
Chasing a Lighthouse score. Lighthouse is a lab test on a simulated device. Google ranks on field data from real visitors. A 100 in Lighthouse and a failing CWV assessment is an entirely normal combination, and when they disagree, field data is the one that counts.
Optimising all three at once. The metrics are independent and the fixes are unrelated. Find the one in the red, fix that, re-measure. Usually it is LCP.
Re-measuring the next morning. The assessment is a 28-day rolling window. A fix deployed today shows up gradually over the following month. Use a real-user monitoring script if you want faster feedback than that — it will show you the change within hours, even though the official assessment lags.
Common questions
What are Core Web Vitals?
Core Web Vitals are three metrics Google uses to measure the user experience of a page: Largest Contentful Paint (how long until the main content renders), Interaction to Next Paint (how quickly the page responds to clicks and taps), and Cumulative Layout Shift (how much the layout moves unexpectedly while loading). They are collected from real Chrome visits and used as a ranking signal.
What is a good LCP score?
2.5 seconds or less, measured at the 75th percentile of real visits. Between 2.5 and 4 seconds needs improvement, and above 4 seconds is rated poor. The most effective fix for most sites is serving the largest image in a modern format at the displayed size from a CDN edge near the visitor, and making sure the browser can discover that image early in the HTML.
What replaced First Input Delay?
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. INP is stricter: FID only measured the delay before the first interaction began processing, whereas INP measures the full time from an interaction to the next visual update, across all interactions on the page, and reports close to the worst one.
Does a CDN improve Core Web Vitals?
It improves LCP substantially and CLS slightly, but not INP. A CDN cuts the network time to deliver your HTML and your largest image, and can convert and resize that image automatically, which is the main lever on LCP. INP depends on how much JavaScript runs in the browser, which delivery speed does not change.
How long do Core Web Vitals take to update after a fix?
The assessment in Search Console uses a 28-day rolling window of field data, so a fix deployed today improves the reported score gradually over the following four weeks rather than immediately. Real-user monitoring on your own site will show the improvement within hours if you need faster confirmation that a change worked.
Why does my Lighthouse score not match Search Console?
Lighthouse runs a single simulated test on a throttled connection in a lab, while Search Console reports field data aggregated from real Chrome users on real devices and networks. They routinely disagree. Field data is what Google ranks on, so treat Lighthouse as a debugging tool for finding problems rather than a scoreboard.
If you take one thing away: find your worst metric, fix the single biggest cause of it, and wait a month. Core Web Vitals reward patience much more than they reward effort, and the sites that score well are usually not the ones that tried hardest — they are the ones that fixed the right thing once.
See how NordicCDN does this for your site:
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
