TL;DR: Google's 2026 Core Web Vitals update refined how Interaction to Next Paint (INP) is measured, added soft-navigation support to CrUX for single-page apps, and demoted Time to First Byte (TTFB) to a pure diagnostic. LCP and CLS thresholds didn't move — INP's measurement did, and that's where most "already fixed it" sites are quietly failing.
Here's the part that catches teams off guard: nothing about the headline thresholds changed. Good LCP is still under 2.5 seconds, good CLS is still under 0.1, good INP is still under 200 milliseconds. What changed is how the data gets collected underneath those numbers — so a site that passed in January can fail in October with no code changes, because the measurement got sharper, not because the site got slower. Teams building production sites with standards-compliant web development practices weather this kind of shift better, since they were never relying on measurement blind spots to begin with.
Three things changed, and only one touches your thresholds directly. First, Google refined the INP measurement methodology to attribute latency more precisely across input delay, processing time, and presentation delay, instead of bucketing slow interactions coarsely. Second, the Chrome User Experience Report (CrUX) — the field-data pipeline behind PageSpeed Insights and Search Console — added soft-navigation support: single-page apps that update the URL and DOM without a full page load now get per-view-transition INP and LCP data instead of one misleading session-long average. Third, TTFB was moved out of the ranking-adjacent "Core Web Vitals" grouping and reclassified as a diagnostic metric — still reported, but no longer weighed by the page-experience signal directly.
None of this is cosmetic: the soft-navigation change alone explains why some SPA-heavy teams saw field-data INP shift overnight with no deploy — they were finally measured per-interaction instead of per-session.
INP reached full parity with LCP and CLS in 2024, and by 2026 it's the metric most sites fail first, since it's caused by application code rather than network or asset weight. The cause is almost always the same: a long task on the main thread blocks the browser from responding to input, painting a frame, or both. Interaction to Next Paint measures the full span from a tap or keypress to the next visual update — input delay, then processing time, then presentation delay — and any segment can blow the budget.
The fix is breaking up long tasks so the browser can breathe. scheduler.yield() exists for exactly this: it hands control back at a checkpoint, lets pending input and rendering happen, then resumes where it left off.
async function processLargeDataset(items) {
for (const item of items) {
handleItem(item);
// yield after every item, or batch N items per yield
if ('scheduler' in window && 'yield' in scheduler) {
await scheduler.yield();
}
}
}In frameworks, the equivalent instinct is marking non-urgent state updates as interruptible. React's useTransition does this: it lets an urgent update (a keystroke showing up in an input) render immediately while a related, expensive re-render (filtering a 10,000-row table) happens without blocking it:
const [isPending, startTransition] = useTransition();
function handleChange(value) {
setQuery(value); // urgent: keep the input responsive
startTransition(() => {
setFilteredResults(filter(data, value)); // can wait a beat
});
}Both solve the same problem: stop treating the main thread as something you own exclusively for the duration of a task.
LCP's threshold hasn't moved — under 2.5 seconds is still good — and the causes haven't changed much either, which is a little embarrassing given how well-documented the fixes are: a hero image discovered only after a render-blocking stylesheet finishes parsing; a web font that delays text rendering because it's not preloaded; render-blocking scripts in the document head; and server response time eating into the budget before client-side optimization gets a chance to help.
<link rel="preload" as="image" href="hero.webp" fetchpriority="high"> — rather than hoping the browser's scheduler guesses right.font-display: optional or swap on web fonts so text doesn't sit invisible.defer or load them after the LCP element is in the DOM.Cumulative Layout Shift punishes unexpected movement — it doesn't penalize changes the user caused (expanding an accordion), only ones that shift content they weren't touching. Teams who think they've fixed CLS usually fixed the obvious case — images without dimensions — and got blindsided by three quieter sources: ads or embeds injected after initial render without reserved space; web fonts loading without font-display set, causing a reflow when the real font swaps in; and video or iframes that, like images, need explicit width/height or aspect-ratio to reserve their box before the asset arrives.
A layout shift only counts against CLS if it happens without the user expecting it — space needs to be reserved before content arrives, not adjusted after.
The fix is uniform across all three: reserve the box before the content loads, reserve a minimum-height container for ad slots even when nothing has loaded yet, and treat font loading as a layout concern, not just a typography one.
TTFB still matters for user experience — a slow one delays everything downstream, including LCP — but as of 2026 it's explicitly a diagnostic signal rather than a weighted Core Web Vital. A site with slow TTFB but passing LCP, INP, and CLS doesn't get flagged by the report at all. Chase it when it's dragging LCP past 2.5 seconds; ignore it once the three graded metrics already pass.
Field data (Real User Monitoring, from the Chrome User Experience Report) and lab data (Lighthouse, PageSpeed Insights on demand) answer different questions, and conflating them is the most common measurement mistake. Field data reflects what real visitors on real devices and networks experienced over the past 28 days — it's what the page-experience signal uses, and the only data that reflects your actual device mix. Lab data is a single simulated run — useful for debugging before shipping, but it can pass while field data fails, since it skips the low-end phone on a congested network a slice of your traffic uses.
For INP, the DevTools Performance panel is the practical debugging tool: record an interaction and it shows input delay, processing time, and presentation delay, plus the long tasks responsible. That's a diagnosis tool, though — the pass/fail number for search is still the field data in CrUX and Search Console.
Given limited time, this order moves the needle for most sites:
scheduler.yield() or framework-level transitions.Yes — INP replaced First Input Delay as the third Core Web Vital in March 2024 and carries equal weight with LCP and CLS. The 2026 update refined how it's measured, not its standing.
Unchanged: 200ms or less is "good," up to 500ms "needs improvement," above that "poor." What changed is measurement precision, not the pass/fail line.
No. Under 0.1 is still good, 0.1–0.25 needs improvement, above 0.25 is poor. CLS wasn't part of the 2026 update.
Not directly — TTFB is diagnostic, not a graded Core Web Vital. It can still hurt indirectly by delaying LCP.
Breaking up the longest main-thread tasks with scheduler.yield() — one unyielded long task is the most common root cause of a failing score.
Yes — 2026 added soft-navigation support to CrUX, so SPA route changes get their own INP and LCP measurements per view, instead of one session-long average.
Trust PageSpeed Insights' field-data tab (and Search Console) for pass/fail decisions — that's real-user data. Trust DevTools for diagnosing why an interaction is slow; it's a lab tool, not a substitute for field data.
Core Web Vitals in 2026 reward the same discipline they always have: don't block the main thread, don't make the browser guess what's coming next, don't shift content the user didn't ask to move. The methodology got sharper — the sites coasting on measurement blind spots are the ones that need to re-measure first.