On March 12, 2024, Google replaced First Input Delay with Interaction to Next Paint as the third Core Web Vital. FID measured only the delay before the first input handler ran. INP measures the full latency of every interaction across the page lifetime, then reports the worst one. That swap is the biggest change to CWV since the program launched, and a lot of older guidance has not caught up.
The thresholds below are the ones Google actively uses to bucket pages today. A page is graded against the 75th percentile of real user experience over a 28-day rolling window — meaning 75% of visits must clear the "good" bar before the page itself counts as good. Get that mental model right and the rest of this falls into place.
The 2026 thresholds
| Metric | Good | Needs Improvement | Poor |
| LCP (Largest Contentful Paint) | ≤ 2.5s | ≤ 4.0s | > 4.0s |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | ≤ 0.25 | > 0.25 |
| INP (Interaction to Next Paint) | ≤ 200ms | ≤ 500ms | > 500ms |
These are the thresholds documented at web.dev/vitals and used by the Chrome User Experience Report. They have not moved since INP shipped in 2024.
LCP: the largest paint, not the last paint
Largest Contentful Paint marks when the biggest above-the-fold element finishes rendering. Usually that element is a hero image, a video poster, or a large block of text. The 2.5 second budget is measured from navigation start to that paint event, at the 75th percentile of users on your real traffic mix.
Google split LCP into four sub-parts to make diagnosis tractable: Time to First Byte, resource load delay, resource load duration, and element render delay. The first three are server- and network-bound. The fourth catches client-side blockers — render-blocking JavaScript, late-loaded fonts, hydration that delays paint. If your LCP is 3.8 seconds and TTFB is 1.9 of that, fixing your image CDN will not save you. Move the origin closer or cache the HTML at the edge.
The single highest-leverage fix for most sites is fetchpriority="high" on
the LCP image plus a preconnect to its origin. The second is removing
render-blocking script tags from <head>. The third is right-sizing the LCP
image — a 4 MB hero on a phone is the most common single cause of a poor
score.
CLS: 0.1 is tighter than it sounds
Cumulative Layout Shift measures unexpected layout movement throughout the page session, scored as the largest burst of shifts inside any 5-second window. The 0.1 cap is strict. A single late-loading banner that pushes the fold down can blow it on its own.
The fixes are unglamorous. Set explicit width and height on every image
and iframe so the browser reserves space before bytes arrive. Reserve slots
for ad units and embeds with min-height boxes. Load custom fonts with
font-display: optional or preload them so the swap does not reflow text.
Avoid injecting content above existing content after first paint — if a
cookie banner has to appear, anchor it with position: fixed instead of
pushing the document down.
INP: the metric that surfaces React sins
Interaction to Next Paint measures the time from a user input — tap, click, keypress — to the next frame that reflects the result. The clock includes input delay, event handler execution, and rendering. The 200ms budget is based on user research showing people perceive responses above that threshold as sluggish.
INP punishes long JavaScript tasks brutally. The common culprits: heavy
synchronous work in click handlers, oversized React re-renders triggered by
context changes, third-party tag managers firing on every interaction,
hydration that monopolizes the main thread for hundreds of milliseconds.
Break long tasks into chunks with scheduler.yield() or setTimeout(0). Use
useDeferredValue and useTransition to push non-urgent renders off the
critical path. Audit third-party scripts ruthlessly — Segment, Intercom, and
session replay tools are frequent INP killers.
Field data is the only data Google ranks on
Lighthouse runs in a simulated lab environment: throttled CPU, throttled network, single page load, no real users. PageSpeed Insights shows both lab scores and field data from CrUX when CrUX has enough samples. Search Console's Core Web Vitals report uses CrUX exclusively. Google's ranking signal uses CrUX exclusively.
If your Lighthouse score is 95 and your CrUX field data shows poor INP, the field data wins. Real users have older phones, weaker networks, browser extensions, and traffic patterns your lab test does not model. The 28-day rolling window also smooths out spikes — a bad deploy you fixed last week will linger in the data for almost a month.
Sites with low traffic do not appear in the public CrUX dataset at all. Below roughly 1,000 monthly visits per origin, you fall back to lab tooling plus your own RUM (real user monitoring) data. The web-vitals JavaScript library from Google ships exactly the same measurement code Chrome uses internally — install it, send the values to your analytics backend, and you get field data without waiting for CrUX to notice you.
The honest take on ranking impact
Core Web Vitals affect ranking. Google has confirmed this since 2021. The effect is real but small — Google's own statements call it a tiebreaker between pages of similar relevance, not a primary ranking factor. Content quality, topical authority, backlinks, and intent match all outweigh CWV by a wide margin in actual search results.
If your site loads in 6 seconds, fix it because users bounce, not because Google will rank you third instead of seventh. The performance work is worth doing on its own merit. The SEO upside is a bonus that mostly matters when you are competing against pages of equal substantive quality. Treat CWV as the UX hygiene metric it actually is, and your priorities sort themselves out.
Verify before shipping
The isitready.dev scanner pulls live CrUX field data for your origin alongside lab measurements, flags which metric is failing the 75th percentile threshold, and points at the specific page-level causes — render-blocking resources, oversized LCP images, layout-shifting embeds, long INP tasks. Run it before you assume a Lighthouse 100 means your real users are happy.