Core Web Vitals Thresholds 2026: LCP, INP and CLS Limits, and What to Fix First

Google's official Core Web Vitals thresholds require that at least 75% of a site's page visits meet the "Good" standard across three key metrics: LCP, INP, and CLS. 

Most site owners never check this number, since Lighthouse (Google's automated page-speed test) only shows a single test run, not real visitor data.

That's the gap the best SEO agency in Bangladesh closes for clients, checking Search Console's field data first before touching a single line of code. Here's what each threshold actually looks like. 

Core Web Vitals Thresholds Breakdown

Here's how the three metrics break down, starting with loading speed.

Largest Contentful Paint (LCP) - measures loading performance.

• Good: ≤2.5 seconds
• Needs Improvement: 2.5 to 4.0 seconds
• Poor: >4.0 seconds

Interaction to Next Paint (INP) - measures page responsiveness.

• Good: ≤200 milliseconds
• Needs Improvement: 200 to 500 milliseconds
• Poor: >500 milliseconds

Cumulative Layout Shift (CLS) - measures visual stability.

• Good: ≤0.1
• Needs Improvement: 0.1 to 0.25
• Poor: >0.25

You can check your site's real-world numbers using PageSpeed Insights or the Search Console Core Web Vitals report. 

This guide breaks down what each metric measures, clears up a threshold myth going around right now, and gives you the exact fix order for each one based on what actually caps your score.

The Current Core Web Vitals Thresholds for 2026

The three thresholds have not moved. LCP stays at 2.5 seconds or under for a good score, INP stays at 200 milliseconds or under, and CLS stays at 0.1 or under. 

Google measures all three at the 75th percentile of real user visits collected through the Chrome User Experience Report, over a rolling 28-day window.

Metric	Good Threshold	Needs Improvement	Poor
LCP (Largest Contentful Paint)	≤2.5 seconds	2.5s–4.0s	>4.0s
INP (Interaction to Next Paint)	≤200 milliseconds	200ms–500ms	>500ms
CLS (Cumulative Layout Shift)	≤0.1	0.1–0.25	>0.25

The 75th percentile part matters more than most site owners realize. 

Your page only passes a metric when at least 75% of real visitor experiences meet the good threshold. It's not about your own device or your fastest test run.

This rule exists because Google cares about the majority of your visitors, not the best case. 

A site can load instantly for someone on fast fiber with a new phone, but if a quarter or more of your visitors face slow networks, older devices, or a server far from their location, the page still fails. 

Field data from real users beats lab scores from a controlled test every time, which is why field data vs lab data is the first thing to understand before you touch any code.

Did Google Change the Thresholds in 2026

No, Google did not change the Core Web Vitals thresholds in 2026. 

A claim that LCP dropped to 2.0 seconds has been circulating on some SEO blogs and social posts, but it does not match Google's own Search Central documentation, which still lists 2.5 seconds as the good LCP score.

This kind of myth usually spreads the same way. 

One site publishes a stats page with a wrong number. A dozen other sites copy that page without checking Google's actual documentation. 

The number gets repeated so many times it starts to sound official, even though nobody traced it back to a real source.

What did change in 2026 is measurement precision, not the headline numbers. 

INP tracking got more accurate, and Chrome 151 added better soft-navigation tracking for single-page applications, which finally gives JavaScript-heavy sites more reliable Core Web Vitals data. 

The thresholds themselves are exactly where they were: LCP at 2.5 seconds, INP at 200 milliseconds, CLS at 0.1, all measured at the 75th percentile.

If you read a claim about tightened thresholds anywhere else, check it against Google's Search Central page directly before you change anything on your site.

What Each Metric Is Actually Measuring

Each of the three metrics tracks a different part of the page experience, from how fast content shows up to how stable the page feels once it loads.

LCP measures how long it takes for the largest visible element to render on screen. 

This is usually a hero image, a main heading, or the key content above the fold that a visitor sees first and reads as "the page has loaded."

INP measures the worst interaction delay across the entire visit, not just the first click. 

It replaced First Input Delay on March 12, 2024, because FID only tracked the first interaction, while INP checks every click, tap, and keystroke during the session. 

That makes INP noticeably harder to pass than FID ever was.

CLS measures how much the layout jumps while the page loads or while someone interacts with it. 

This covers unexpected shifts, like an image pushing text down after it finally loads, or an ad injecting itself above content that was already sitting still.

Field Data vs Lab Data and Why Your Lighthouse Score Can Be Wrong

CrUX field data comes from real Chrome users browsing your actual site over a rolling 28-day window. 

This is the data Google uses for Core Web Vitals assessments in Search Console and for ranking. 

It reflects your real visitors across their actual devices, networks, and locations.

Lighthouse and PageSpeed Insights lab data runs a synthetic test on a simulated mid-range Android phone with throttled network conditions. 

It gives you a one-time snapshot under standardized, harsh conditions. That's useful for debugging, but it does not tell you what your real visitors experience.

This is exactly why a perfect 100 in Lighthouse can still fail in Search Console. 

The lab score comes from one synthetic load. The Search Console assessment comes from the 75th percentile of real visits over 28 days. 

A page can look flawless in the lab while carrying a 600ms INP in the field, and Lighthouse will never warn you about it.

Three places to check, each for a different job:

The Search Console Core Web Vitals report shows field data across your whole site, grouped by URL pattern and by mobile versus desktop. 

This is the source of truth for what Google actually sees when it evaluates your pages.

PageSpeed Insights shows both the lab score and the field data assessment in one place, which makes it handy for a combined check during an audit. 

If you're building out a full website auditing checklist, this tool belongs near the top of it.

Your own Real User Monitoring setup, using something like the web-vitals JavaScript library, shows improvements within days instead of waiting weeks for CrUX's rolling window to catch up.

What to Fix First by Metric in Priority Order

Fixing Core Web Vitals in the wrong order wastes time, because some fixes are capped by problems further upstream. 

Here's how to fix Core Web Vitals based on what actually blocks each score, not a flat checklist you tackle randomly.

LCP Fix Order

Server delays cap everything else on this list, so the order below matters as much as the fixes themselves.

Server response time comes first. 

This caps everything downstream. 

If your server takes 800 milliseconds to respond, no amount of image optimization will get your LCP into the good range. 

Fix this with a CDN that caches HTML at the edge, server-side caching for dynamic pages, faster hosting, or edge rendering where it's available. 

Shared hosting will not hold up in competitive niches.

Render-blocking CSS and JS come second. 

Remove or defer anything that stops the browser from painting. 

Inline critical CSS directly in the head for above-the-fold content, defer non-critical stylesheets, and move render-blocking scripts to defer or async. 

Keep critical CSS under 14KB so you don't create a new bottleneck while fixing the old one.

Hero image format and priority come third

It only comes after the first two are handled. 

Convert the LCP image to WebP or AVIF, which runs 40 to 60% smaller than JPEG at the same quality. 

Add fetchpriority="high" to the LCP image element. In documented tests, this single change alone improved LCP from 2.6s to 1.9s. 

Add a preload tag for the LCP image in the head, and never lazy-load it, since loading="lazy" on your hero image adds 200 to 500 milliseconds of delay. 

Serve correctly sized images using srcset and sizes with explicit width and height, which pairs well with a broader strategic use of images in SEO.

Pro Tip: If you only have time to fix one thing on LCP this week, check your TTFB first. Everything else is wasted effort if the server itself is slow.

INP Fix Order

Most sites fix the wrong layer first here, so work through these three in sequence rather than jumping straight to code changes.

Audit third-party scripts. 

This is the single biggest INP cost on most sites, and it's easy to miss because it's not your own code. 

Chat widgets, analytics tags, and A/B testing tools all fight for the main thread. Defer them until after the page becomes interactive, which alone often moves INP from red to green.

Break up long main-thread tasks. 

Any JavaScript task over 50 milliseconds blocks the main thread, so the browser can't respond to clicks or taps during that window. 

Use scheduler.yield() or setTimeout(fn, 0) to chop long tasks into smaller pieces and hand control back to the browser between them. 

Move expensive work to requestAnimationFrame or defer it with queueMicrotask.

Optimize event handlers last. 

Heavy React re-renders, synchronous API calls, and unoptimized global event listeners add to INP, but they're usually lower-impact than third-party scripts and long tasks. 

Use content-visibility: auto, Web Workers, and lightweight semantic HTML to cut down presentation delay.

CLS Fix Order

These fixes are the cheapest to implement and the easiest to get right the first time, so there's no excuse to skip them.

Image and video dimensions 

Missing width and height are the most common cause of layout shift. Explicit dimensions let the browser hold the exact box before the file finishes loading, so nothing jumps once it arrives.

Ad and embed containers come second. 

Reserve space for ads, iframes, and embedded content with fixed minimum heights in CSS before the content loads. 

Give every ad slot a fixed size so it holds its spot whether or not anything fills it.

Font-display strategy comes third. 

Use font-display: swap to reduce invisible text and stop layout shifts caused by font swapping.

Preload your primary font and match the fallback's metrics using size-adjust, so the swap doesn't resize the text underneath it. 

Never insert content above existing content unless it's a direct response to something the user did.

How to Check Where You Actually Stand Right Now

Checking your real status takes three steps, moving from the widest view down to the most detailed one.

Step 1: Open Search Console's Core Web Vitals report. 

Check mobile and desktop separately. Find which URL groups are marked "Poor" or "Needs Improvement," and note which specific metric is driving that status. 

This tells you which page templates are failing and where to spend your time.

Step 2: Run PageSpeed Insights on your representative URLs. 

Test your top three to five pages, meaning your homepage, top landing page, and highest-converting product or service page. 

Check whether the numbers are URL-level or origin-level before concluding. Note which metrics are red or orange in both the field data and lab data sections.

Step 3: Use Lighthouse and DevTools last, for debugging only. 

Chrome DevTools' Performance panel lets you record traces and pinpoint the exact element or script causing the failure. 

Lighthouse audits, filmstrips, and traces explain why a metric fails, whether that's render-blocking CSS, unsized ad slots, or a long JavaScript task, but only pull this tool out after you've confirmed the issue with field data.

Heads Up: CrUX's 28-day rolling window means fixes take weeks to show up, not days. 

Each day, the oldest day of data drops off and a new one enters, so you'll see gradual movement instead of a sudden jump. 

Expect first movement in 2 to 3 days, a visible trend by day 7, and a fully clean window by day 28. 

The assessment can flip earlier than 28 days if your improvement is large enough to pull the 75th percentile past the threshold on its own.

Why Core Web Vitals Still Matter for SEO in 2026

Core Web Vitals are part of Google's Page Experience signals, confirmed as ranking factors since 2021. 

Content quality and backlinks still carry the most weight, but Core Web Vitals act as a tiebreaker between pages that are otherwise close in relevance and authority. 

This connects directly to your broader on-page SEO factors, since page experience sits inside that same on-page category. 

Sites that pass all three metrics often rank better, especially in competitive niches where several pages are chasing the same keyword.

The effect goes beyond rankings too. 

Pages with LCP under 2.5 seconds see 15% lower bounce rates on average. Sites with INP under 200ms tend to hold higher engagement and longer sessions. 

CLS under 0.1 cuts down accidental clicks and makes the page feel more trustworthy. 

Over time, these small gains stack up into better organic performance and higher conversions, which is part of why on-page SEO carries real weight beyond just rankings.

Common Core Web Vitals Mistakes to Avoid

These are the same five issues we see over and over again, and every one of them is an easy fix once you know where to look.

Optimizing for Lighthouse instead of field data. 

Many teams chase a perfect Lighthouse score while ignoring the real user metrics that actually decide the outcome. 

Check Search Console's report first, then use Lighthouse only for debugging.

Lazy-loading the LCP image. 

Adding loading="lazy" to your hero image adds 200 to 500 milliseconds of delay and directly hurts LCP. Save lazy-loading for images below the fold only.

Ignoring third-party scripts for INP. 

Analytics tags, chat widgets, and tag managers frequently do more damage to INP than your own code does. Audit them and defer aggressively.

Skipping image dimensions. 

Missing width and height attributes is the most common cause of CLS on the web. Always set explicit dimensions or use CSS aspect-ratio.

Expecting instant results. 

CrUX's 28-day rolling window means full improvements take weeks to show up in Search Console. Use your own RUM setup if you want to track progress faster than that.

Checking Search Console field data before touching a single line of code matters, because that's the number Google actually scores you on. 

Core Web Vitals good score isn't about chasing a perfect Lighthouse run. It's about fixing the layer that caps everything else first, then working down the list in order.

Frequently Asked Questions

Did Google lower the LCP threshold to 2.0 seconds in 2026?

No, LCP stays at 2.5 seconds or less according to Google's own documentation.

Is INP a confirmed ranking factor?

Yes, INP has been an official Core Web Vitals ranking signal since it replaced FID in March 2024.

Can a page pass Lighthouse and still fail Core Web Vitals?

Yes, Lighthouse runs one lab test while Core Web Vitals scores come from real visitor data in the field.

How long after deploying a fix does Search Console update?

Expect first movement in 2 to 3 days, with a fully clean 28-day window by day 28.

Is Time to First Byte itself a Core Web Vitals metric?

No, TTFB isn't an official metric, but it directly caps how fast LCP can be.