Core Web Vitals in 2026: What Actually Moves the Number

Core Web Vitals move when three things change: a faster-loading hero image, less JavaScript blocking clicks and taps, and layout that stops shifting. A high lab score alone rarely moves the number Google uses, since that number comes from real visitor data.

What are the three Core Web Vitals and their thresholds?

These three numbers cover three separate frustrations: waiting for the page to show up, waiting for a tap to register, and content jumping around while you try to read it.

Google scores a page against these thresholds using field data from the Chrome UX Report. That means real visits, at the 75th percentile, over the last 28 days. A page passes only when all three metrics are good at once.

INP is the newest of the three. It replaced FID (First Input Delay) as an official Core Web Vital in March 2024. It measures the full response to an interaction: the delay, the processing time and the next paint.

Why does my lab test score differ from what Google reports?

A Lighthouse or PageSpeed Insights lab test loads your page as a simulated mid-range phone on a slow connection. It is consistent and repeatable, and it shows a worst-case scenario. It also cannot measure INP at all: its closest lab proxy is Total Blocking Time, a related but different number. Small sites often get no field data from Google at all, since Chrome only reports on pages with enough real traffic.

The gap between the two numbers comes down to three things. The lab test deliberately simulates worse conditions than most visits. Real visitors are often on wi-fi or a fast mobile connection, and part of the page may already be cached from an earlier visit. Field data also only exists for sites with enough traffic, so a small business site is more likely to have no field score to check at all.

We measured this gap directly across 231 Czech small-business websites. The median lab LCP was 8.7 seconds. The median field LCP, from real visitors, was 1.9 seconds. The lab test still has a purpose here. It shows what a visitor on an older phone and a weak connection goes through, a real case, just slower than the average visit.

What moves LCP (loading speed)?

LCP is the moment a visitor sees that the page has actually loaded, usually when the hero image or the main heading appears. In order of impact:

1. Size and format of the hero image. Serve it as WebP or AVIF, sized to the dimensions it actually displays at.
2. Loading priority. The hero image should load with high priority, and never be marked lazy.
3. Server response time. A slow first byte delays everything that follows it.
4. Render-blocking CSS and web fonts. Anything that has to finish loading before the browser can paint the page pushes LCP back.

What moves INP (responsiveness)?

INP is what a visitor feels as lag: the gap between tapping a button and seeing anything happen on screen. In order of impact:

1. Less JavaScript running on the page. Every script the browser has to parse and execute competes with the visitor’s tap or click.
2. Fewer third-party scripts. Chat widgets, tracking pixels and tag managers each add their own delay, often outside your control.
3. Splitting long tasks. Breaking up work that blocks the main thread lets the browser respond to input in between chunks.

What moves CLS (visual stability)?

CLS is what makes a visitor tap the wrong thing, when text or an image loads late and pushes a button out from under their finger. In order of impact:

1. Width and height on images and video, so the browser reserves the right amount of space before they load.
2. Reserved space for embeds and cookie banners, so they do not push content down after it has already rendered.
3. Font loading that does not reflow text, so swapping in a web font does not resize the line it sits on.

What does not move the number?

Chasing a perfect 100 Lighthouse score is the most common trap. The lab test is synthetic. A page can score 100 in the lab while real visitors still see a slow or unstable page, across a range of devices and connections. Optimizing Total Blocking Time in isolation has the same problem: it correlates with INP, but Lighthouse never actually measures INP itself. The only score that matters for search is the field data from real visits, and a small site may need to grow its traffic before Google can report one at all.

What did fixing this look like for us?

We rebuilt Fabrika Sumy, a textile group’s site, as a fully static build. Its load time went from 4.2 seconds to 0.8 seconds.

If you want to see where your own site loses time, our free website audit checks the same things this article covers. What a sub-second load does to visitors and search traffic, with the research behind it, is in what a sub-second load does to conversion. How we build sites that pass Core Web Vitals from launch is on the website development page. We run through the same checklist above on every rebuild, before launch.

Frequently asked questions about Core Web Vitals

What is a good Core Web Vitals score in 2026?

A page passes when LCP is 2.5 seconds or under, INP is 200 milliseconds or under, and CLS is 0.1 or under. All three are measured from real visits over the last 28 days.

What replaced FID as a Core Web Vital?

INP (Interaction to Next Paint) replaced FID in March 2024. It measures the full time to respond to an interaction: the delay, the processing and the next paint.

Why does PageSpeed Insights show a worse score than what I experience?

PageSpeed Insights runs a lab test on a simulated mid-range phone and a slow connection, on purpose. Real visitors, especially on wi-fi or a fast connection, often see a faster page than the lab test reports.

Do I need a 100 Lighthouse score?

No. The lab score is a diagnostic tool. Google grades your site on field data instead. Focus on the checklist for LCP, INP and CLS, then check your field data once your site has enough traffic for Google to report it. A lower lab score with good field numbers still passes the assessment.