Field Notes · Web
Core Web Vitals 2026: INP Guide
The era of "make it load fast" is over; the metric that still moves the needle is the one that measures what happens after your page has loaded.
For years, Core Web Vitals were a story about loading. Compress the images, cache the assets, push the largest element into view inside two and a half seconds, and you passed. That story is now incomplete. The vital that catches most sites out in 2026 does not measure how quickly a page appears. It measures whether the page actually responds when a real person taps, clicks, or types after it has loaded.
Interaction to Next Paint, or INP, replaced First Input Delay as a Core Web Vital on 12 March 2024. It is a different kind of problem to the ones the loading-speed era trained us to solve. INP is a main-thread and JavaScript problem, not an image-and-caching problem, which is precisely why so many sites that sailed through the LCP era are quietly failing now. This guide covers what the three current vitals actually are, why INP is harder, where rankings genuinely come into it, and what to fix first.
What are the three Core Web Vitals in 2026, and what counts as good?
There are three Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). To be rated good, a page must hit LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, all assessed at the 75th percentile of real page views. The set has been stable since INP arrived; according to web.dev's primary documentation, no new vital has been added since.
Each metric has three bands. Knowing the full range matters, because the gap between good and poor is where most real sites actually live:
- LCP (loading): good is 2.5s or under, needs improvement is 2.5s to 4.0s, poor is above 4.0s.
- INP (responsiveness): good is 200ms or under, needs improvement is 200ms to 500ms, poor is above 500ms.
- CLS (visual stability): good is 0.1 or under, needs improvement is 0.1 to 0.25, poor is above 0.25.
One nuance trips people up. A page is rated good for a metric only when at least 75% of real-user visits meet that good threshold, and all three metrics must pass for an overall pass. You are not being graded on your average visit. You are being graded on whether three quarters of your visitors had a good one.
Why did INP replace FID, and why is it harder?
INP replaced FID because FID only ever looked at the first interaction, and only at part of it. First Input Delay measured the input delay of a visitor's very first tap or click, the waiting time before the browser could begin processing it. INP measures the full latency, from input to the next painted frame, across every interaction for the entire life of the page. It exposes problems FID structurally could not see.
That single change in scope is what makes INP hard. A page could keep its first interaction snappy and still grind to a halt on the tenth, when more scripts had loaded, more handlers had attached, and the main thread was congested. FID waved that page through. INP does not. For each interaction, INP takes the single longest duration among the group of event handlers driving it, and then reports approximately the worst interaction on the page, using around the 98th percentile to discount freak outliers on pages with many interactions.
This is also why INP is, fundamentally, a field metric. It needs real interactions to exist at all, which is why standard Lighthouse lab tests cannot measure it the way they measure loading. You cannot fake a thousand real users clicking around. You can only watch what happens when they do.
What actually causes poor INP?
Poor INP is almost always caused by a busy main thread. When the browser is occupied running JavaScript, it cannot process the interaction a user just triggered or paint the frame that responds to it. The visitor taps, and nothing happens, because the thread that should answer them is busy doing something else.
The specific culprit web.dev names is the long task. Any task that occupies the main thread for longer than 50 milliseconds is classed as a long task, and long tasks block the thread from handling pending interactions and painting frames. That is the core mechanism behind sluggish responsiveness. The usual sources are familiar to anyone who has profiled a modern site:
- Heavy JavaScript execution that monopolises the main thread in long, unbroken chunks.
- Large, deeply nested DOM trees that make every style and layout recalculation expensive.
- Third-party scripts, tag managers, and analytics that quietly stack work onto the thread after load.
- Event handlers that do too much synchronously before yielding control back to the browser.
This is the deeper reason JavaScript-heavy sites, single-page applications, and tag-laden pages tend to struggle. It is a tendency, not a law Google has written down, but the pattern is consistent: pages that quietly passed FID now fail INP because the very thing that made them feel modern, all that client-side scripting, is what congests the thread.
Field data or lab data: which one actually counts?
Field data is the one that counts for rankings. Google's page-experience signal uses the Chrome User Experience Report (CrUX), which collects metrics from real Chrome users over a rolling 28-day window and reports them at the 75th percentile. Lab data from a tool like Lighthouse is a single synthetic test on controlled hardware and network, and it does not feed rankings at all.
This distinction quietly wrecks a lot of well-meaning optimisation work. A site can score 95 or higher in a local Lighthouse run and still be rated poor in the field, because the lab cannot replicate the cheap Android phone on a congested mobile network that represents a real slice of your audience. A gap of roughly 10 to 15 points between a local Lighthouse score and PageSpeed Insights is entirely normal, precisely because PageSpeed Insights overlays real CrUX field data on top of the lab result.
How much do Core Web Vitals actually affect rankings?
Less than the industry sometimes implies, and Google says so plainly. Core Web Vitals are used by Google's ranking systems, but, in Google's own words, in a limited way. Google's documentation states directly that trying to achieve a perfect score purely for SEO may not be the best use of your time, and that a relevant, genuinely helpful page can outrank one with a better page experience.
The honest framing is that Core Web Vitals behave more like a tiebreaker than a lever. When your content is already competitive with the other results, good responsiveness and stability can help you edge ahead. When your content is not competitive, no amount of millisecond-shaving will rescue it. Google has never published a weighting, so anyone quoting you a precise percentage for Core Web Vitals as a ranking factor is inventing it. Treat it as lightweight, treat it as a tiebreaker, and prioritise accordingly.
What should you fix first?
Fix the thing your real users actually feel, in the order that yields the most responsiveness for the least effort. Because INP is a main-thread problem, the highest-value work is almost always about how and when your JavaScript runs. The documented optimisation techniques from web.dev, in a sensible priority order, are:
- Break up long tasks so no single piece of work hogs the main thread past 50 milliseconds.
- Yield to the main thread between chunks of work, so the browser can answer pending interactions.
- Code-split and lazy-load JavaScript so you ship only what each page needs, when it needs it.
- Defer non-critical scripts, including third-party tags, so they stop competing with interactions.
- Move heavy computation off the main thread entirely by using Web Workers.
- Use optimistic or progressive UI updates so the interface responds immediately while work continues behind it.
Underpinning all of this: measure in the field, not just the lab. Watch CrUX and real-user monitoring at the 75th percentile, because that is the data Google uses and the only place INP truly exists. A green Lighthouse score is a useful diagnostic. It is not the scoreboard.
The performance conversation has moved from "load fast" to "stay responsive", and most sites have not caught up. Get the thresholds right, measure in the field, fix the main thread, and treat Core Web Vitals as the tiebreaker they are rather than the magic lever they are not. That last part, the unglamorous main-thread and JavaScript work that actually moves INP in real-user data, is exactly the kind of performance engineering DarkHorse does: numbers, not narratives.
Questions people ask
Is INP just FID with a new name?
No. FID measured only the input delay of a visitor's first interaction, while INP measures the full input-to-next-paint latency across every interaction for the entire page lifecycle. That wider scope means INP exposes responsiveness problems FID structurally could not detect. It is a genuinely harder metric, not a rebrand.
Does a 100 Lighthouse score mean I pass Core Web Vitals?
No. Lighthouse produces lab data from a single synthetic test, and lab data does not feed Google's rankings. Google uses real-user field data from CrUX at the 75th percentile, so a page can score 95 or higher in the lab and still be rated poor in the field. Lighthouse cannot even measure INP in the standard way, because INP needs real interactions.
Will maxing out Core Web Vitals rocket my rankings?
Almost certainly not. Google states that Core Web Vitals are used in a limited way and that chasing a perfect score purely for SEO may waste your time. They act closer to a tiebreaker among comparable results than a primary ranking lever, so relevant, helpful content beats a fast but thin page every time.
What is the single most common cause of poor INP?
A main thread blocked by long tasks. Any task that runs longer than 50 milliseconds prevents the browser from processing pending interactions and painting the frame that responds to them. Heavy JavaScript, large DOM trees, and stacked third-party scripts are the usual sources, which is why JavaScript-heavy sites and single-page applications tend to struggle most.