Core Web Vitals 2026: the one threshold most sites fail
LCP under 2.5s, INP under 200ms, CLS under 0.1. Fewer than half of sites pass all three, and INP is where nearly everyone loses. Here is what actually fixes it.
Key takeaways
- The thresholds are LCP under 2.5s, INP under 200ms and CLS under 0.1; about 47% of sites pass all three.
- INP is the most commonly failed metric because it requires JavaScript architecture changes, not asset compression.
- An element that animates in from zero opacity cannot be the LCP candidate at all; animate transform instead.
- Core Web Vitals act as a tiebreaker in search, but the stronger argument for the work is conversion and bounce rate.
Core Web Vitals are Google's three field measurements of user experience: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. Roughly 47 percent of sites pass all three at once. INP is the one most teams fail, because fixing it requires changing how JavaScript is architected rather than compressing an image.
- 2.5s
- Largest Contentful Paint threshold for a good rating
- 200ms
- Interaction to Next Paint threshold for a good rating
- 0.1
- Cumulative Layout Shift threshold for a good rating
- 47%
- of sites pass all three thresholds simultaneously
How much do they affect rankings
Less than vendors claim and more than sceptics allow. Pages ranking first are around 10 percent more likely to pass the thresholds than pages ranking ninth, which is a correlation rather than a mechanism. The honest description is that Core Web Vitals behave as a tiebreaker. Where two pages have comparable content and authority, the faster and more stable one wins. Where content quality differs sharply, speed will not rescue the weaker page.
The business case is stronger than the ranking case. Sites passing all three thresholds report materially lower bounce rates, and every percentage point of abandonment on a commercial page has a price you can calculate. Argue the work on conversion and treat the ranking benefit as a bonus.
Why INP is the hard one
LCP is largely a delivery problem: serve the hero image efficiently, avoid render-blocking resources, do not hide the main element behind a script. There is a specific trap worth naming, because it is common and silent. If your hero element animates in from zero opacity, it is not eligible to be the Largest Contentful Paint at all, and the field data may report no LCP candidate rather than a slow one. Animate transform, not opacity, on anything that could be your largest element.
INP measures how long the page takes to paint a response after a user interacts. It exposes long tasks on the main thread: heavy hydration, oversized event handlers, third-party tags, and layout work triggered by every keystroke. The fixes are architectural. Break long tasks up, defer non-critical hydration, move work off the main thread, and remove tag-manager payloads that nobody has audited in two years.
A practical order of work
- Read field data, not lab data. The Chrome User Experience Report is what Google uses. A perfect Lighthouse score on your laptop proves very little about a mid-range Android phone on a congested network.
- Fix mobile first. Mobile pass rates trail desktop by several percentage points, and mobile is what gets crawled.
- Audit third-party scripts before optimising your own code. It is common to find that a single unused tag accounts for the majority of main-thread blocking.
- Reserve space for anything that loads late. Images without dimensions, injected banners and web fonts swapping mid-render are the three usual causes of layout shift.
When to stop
Passing is the goal, not winning. Once a page is comfortably inside all three thresholds in field data, further optimisation buys you very little in search and starts costing engineering time better spent on content or conversion. Measure, cross the line, then move on.
Core Web Vitals will not win you a ranking you did not otherwise deserve. They will lose you one you did.