How to Fix Core Web Vitals in 2026 (INP Is the One That Beats You)

Core Web Vitals are the part of technical SEO where teams most often believe they have fixed something they have not. The score looks green in a lab tool, the work feels done, and the field data in Search Console stays red for another month. The reason is almost always the same: the metric most sites fail is INP, and INP does not respond to the kind of fix that works on the other two.

This is the fixing guide. It assumes you already know that performance is a ranking signal and that you should diagnose before you fix, which is covered in our technical SEO foundations guide. Here the job is narrower and deeper: how to actually move each of the three numbers, with most of the weight on the one that beats people.

The thresholds, stated correctly, and the figure that is wrong

The three Core Web Vitals and their “good” thresholds are LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1. All three are assessed at the 75th percentile of real page loads, and all three have to pass for a page to earn an overall good assessment. It is pass or fail: two good and one poor is a fail.

One number you will see in older guides is wrong. The “good” LCP threshold is 2.5 seconds, not 2.0. There is no 2-second standard, and a guide quoting one is out of date. The thresholds themselves have not been tightened since they were set, so anyone telling you the bar moved in 2026 is mistaken about the headline numbers, whatever else may have changed in the tooling.

The other thing the old guides get wrong is the metric itself. INP replaced First Input Delay in March 2024. FID measured only the delay before the browser started processing your first interaction, and it was easy to pass. INP measures the full latency of every interaction across the whole visit and reports the worst one. If a guide still talks about FID, it is describing a metric Google retired, and the advice attached to it will not help your INP.

Why field data beats your test machine every time

Core Web Vitals are scored on field data, the experience of real users, collected by the Chrome User Experience Report over a rolling 28-day window. They are not scored on a lab test. This single fact explains most of the confusion around the metrics.

The score is taken at the 75th percentile, which means 75 percent of real visits have to hit “good” for the page to pass. Picture the fourth-slowest user out of every four: a mid-range Android phone on a patchy connection with your scripts competing for a slower processor. That user is who you are being measured against, not you on a fast laptop on office wifi. A Lighthouse score of 95 on your machine and a red CrUX result in Search Console are not a contradiction. They are measuring two different things, and only one of them counts for ranking.

Two consequences follow. The first is the reporting lag: because the window is 28 days of rolling field data, a fix you deploy today takes roughly four to six weeks to dominate the data and show up in Search Console. Set that expectation with stakeholders before you ship, or the fix will look like it failed. The second is the grouping effect. Google assesses performance at the level of URL groups, and a URL without enough of its own field data inherits its group’s or the whole origin’s scores. So a shared header, a sitewide script or one shifting element in a common template can hold down pages you never touched. Fixing a single page while the template around it stays slow does not move the reported number.

LCP: the loading fix, in order of impact

Largest Contentful Paint measures how long the largest visible element, usually the hero image or a headline block, takes to render. It is a loading problem, and the fixes are about getting that element on screen faster, in rough order of impact:

• Preload the LCP image so the browser fetches it early instead of discovering it late.
• Inline the critical CSS the above-the-fold content needs, so rendering is not blocked waiting for a stylesheet.
• Preconnect to the origins that serve render-critical resources, so the connection is already open when they are requested.
• Server-render the page where you can, so meaningful content arrives in the initial HTML rather than after JavaScript runs.
• Compress and correctly size the hero image, and serve it in a modern format, so it is not a megabyte where it could be eighty kilobytes.

One thing that sits underneath LCP and is worth checking first: time to first byte. If your server is slow to respond, your LCP has a floor it cannot beat no matter how well you optimise everything after it. A slow TTFB is an LCP problem wearing a different hat.

CLS: the stability fix, mostly about reserved space

Cumulative Layout Shift measures how much the page jumps around as it loads. Almost every fix is a version of the same idea: tell the browser how much space something will take before it arrives, so nothing has to move when it does.

• Set explicit width and height attributes on every image, video, iframe and ad slot, so the browser reserves the space before the asset loads.
• Use font-display: swap and reserve space for late-loading content, so a web font or a lazy component does not shove the layout when it appears.
• Give dynamic inserts, banners, cookie notices, embeds, a reserved slot rather than letting them push content down on arrival.

The trap here is the same grouping effect from earlier. One ad slot that loads without reserved space in a shared header will shift the layout on every page that header appears on, and drag the whole URL group’s CLS down with it. A layout-shift problem is rarely confined to the page you noticed it on.

INP: the responsiveness fix, and why it is structural

Here is the metric that beats most sites, and the reason it is harder than the other two. INP measures responsiveness: the time from a user interacting, a click, a tap, a key press, to the browser painting the next frame in response. An interaction has three phases, and naming them tells you where to look:

• Input delay: the wait before your event handler even starts, usually because the main thread is busy running other JavaScript.
• Processing time: how long your event handler itself takes to run.
• Presentation delay: the time from your handler finishing to the browser painting the result.

The root cause behind nearly all bad INP is the same: long JavaScript tasks holding the main thread while the user is trying to interact with the page. A task that runs for more than 50 milliseconds blocks the thread, and while it runs the browser cannot respond to input. This is why INP is structural. You cannot compress an image or open a connection to fix it. You have to change how your JavaScript occupies the main thread.

LCP and CLS are problems of resources arriving in the wrong order. INP is a problem of your own code refusing to get out of the user’s way. That is why a plugin fixes the first two and only architecture fixes the third.

The fixes are accordingly architectural:

• Break long tasks into smaller ones and yield to the main thread between them, using the scheduler.yield() API or manual task chunking, so the browser gets regular chances to handle input.
• Defer non-critical JavaScript so it is not all executing during load, when the main thread is busiest and interactions are most likely to be slow.
• Reduce DOM complexity, because a large DOM makes the rendering work after each interaction heavier.
• Audit third-party scripts hard. Chat widgets, faceted-search filters, personalisation tools and tag managers are common INP killers, and a single new widget can add a hundred-plus milliseconds of main-thread blocking to every page it loads on.

Because this is fundamentally a JavaScript problem, the deepest INP fixes overlap with how your site renders in the first place, which we cover in our guide to JavaScript SEO and the render gap. If client-side rendering is doing heavy work on the main thread, that is both a rendering problem and an INP problem, and the same fix helps both.

One measurement note that catches people out: Lighthouse cannot measure INP, because INP needs real interactions and Lighthouse does not interact with the page. The closest lab proxy is Total Blocking Time, which correlates with INP, but the real signal only ever comes from the field.

How to know if you actually passed

The single most common mistake is declaring victory on a green Lighthouse score. Lighthouse is a lab tool, useful for finding problems during development, but it is not what Google ranks on and it cannot even see your real INP. The only thing that confirms a pass is field data: the Core Web Vitals report in Search Console, or the field section of PageSpeed Insights, showing “good” at the 75th percentile.

Two disciplines make the difference between thinking you passed and knowing it. First, wait for the 28-day window before judging a fix, since the field data lags the deploy by weeks. Second, set an early-warning band: monitor your metrics against a threshold tighter than Google’s, so a regression from a new deploy or a newly added script shows up before it drags your field data back into the red. A site that only checks Core Web Vitals when rankings drop is always a month behind its own performance.

Worth knowing too: if a page or origin does not have enough Chrome field data, Google does not apply the Core Web Vitals signal to it at all. For lower-traffic sites that can mean the metric is not affecting your ranking either way, which is worth confirming before you invest heavily in it.

Where Core Web Vitals sits in the bigger picture

Keep the weight of this in proportion. Core Web Vitals is a tiebreaker. It is the signal that separates two pages of comparable content and authority, not a substitute for either. Passing it will not lift weak content over strong, and failing it will quietly cap otherwise-strong content in a competitive result. It earns its place as maintenance, not as a growth lever.

Which is exactly why it should not be the first thing you fix on a struggling page. If a page is not ranking, the question of whether it is even indexed and whether its content earns the position comes first, and that order of operations is the subject of our technical SEO foundations guide. Fix the foundations in the right sequence, and Core Web Vitals is the last, sharpening pass, not the place you start.

FAQs

What is a good INP score?

A good INP is 200 milliseconds or less, measured at the 75th percentile of real user interactions. Between 200 and 500 milliseconds needs improvement, and above 500 milliseconds is poor. The figure that matters is the field data in Search Console or the field section of PageSpeed Insights, not a lab tool, because INP can only be measured from real interactions.

Why is INP so hard to fix?

Because it is a JavaScript architecture problem, not a resource one. LCP and CLS are fixed by loading assets faster and reserving layout space, the kind of work a plugin or a few attributes can do. INP is caused by long JavaScript tasks blocking the main thread while a user is trying to interact, so fixing it means restructuring how your code runs: breaking up long tasks, deferring non-critical scripts, yielding to the main thread and auditing third-party widgets. That is development work, not configuration.

Did Google lower the LCP threshold to 2 seconds?

No. The good LCP threshold is 2.5 seconds and has not changed. There is no 2-second standard, and any guide quoting one is out of date. The three Core Web Vitals thresholds, LCP 2.5 seconds, INP 200 milliseconds, CLS 0.1, have stayed the same since they were set, even as the measurement tooling around them has evolved.

Why does my site pass on my laptop but fail in Search Console?

Because they measure different things. Your laptop running a lab tool like Lighthouse simulates one fast device on a good connection. Search Console reports field data: the experience of your real users at the 75th percentile, including people on mid-range phones and slower networks. Google ranks on the field data, not the lab score, so a green Lighthouse result alongside a red Search Console status is normal, and the field data is the one to trust.

How long do Core Web Vitals take to update after a fix?

Roughly four to six weeks. Google scores Core Web Vitals on a rolling 28-day window of field data, so a fix you deploy today only gradually comes to dominate that window before it shows as improved in Search Console. This is why a fix can look like it failed when it has simply not aged into the data yet, and why it pays to confirm the improvement in faster field-data sources before waiting on Search Console.

Are Core Web Vitals a ranking factor?

Yes, but a modest one. Google treats Core Web Vitals as part of page experience, a tiebreaker that separates pages of similar content and authority rather than a primary driver of rankings. Passing will not push weak content above strong, and failing will quietly cap strong content in competitive results. For pages without enough Chrome field data, the signal is not applied at all. Treat it as maintenance that protects good content, not as a growth lever on its own.

Last reviewed: June 2026

This article provides general information about Core Web Vitals and is not affiliated with or endorsed by Google. Core Web Vitals thresholds, tooling and measurement methodology change, and pass rates cited reflect Chrome User Experience Report data at the time of writing. Verify current thresholds and figures against Google’s own documentation before relying on them.