FastTool All tools

BLOG

Core Web Vitals 2026: The INP 150ms Ranking Filter Survival Guide

April 17, 2026 · 18 min read

Three weeks after Google's March 27 core update, a publisher I track dropped from position 4 to position 11 for their main commercial query. Their content didn't change. Their backlinks didn't change. What changed was their mobile INP, which had been hovering at 240ms for months, the same 240ms that used to pass CWV cleanly under the old 200ms "needs improvement" threshold. Overnight, the threshold moved. Their pages didn't. The rankings followed.

If you've watched traffic dip since April, this is probably why. Google's March 2026 core update made two changes that together turn Core Web Vitals from a tiebreaker into a genuine ranking filter: INP's "good" threshold dropped from 200ms to 150ms, and CWV is now evaluated at the domain level instead of page-by-page. Sites that were coasting on decent averages are now being judged by their worst pages. Here's what actually changed, why it hurts, and what to do about it.

What Changed in the March 2026 Update

The March 27, 2026 Google Core Update shipped three CWV changes that compound:

  1. INP "good" threshold dropped to 150ms (from 200ms). "Needs improvement" is now 150-500ms. "Poor" stays at 500ms+.
  2. Site-level aggregation. Google now computes a domain-wide CWV score by aggregating page-level scores weighted by traffic share. A handful of slow pages that get most of your traffic can tank the whole domain's score.
  3. Equalized weighting. LCP, INP, and CLS now carry equal weight as ranking signals. Previously LCP had more influence; a poor INP was penalized less. Not anymore.

The numbers from the first month of tracking are ugly. Over 55% of tracked sites reported noticeable ranking changes within days of rollout. Sites with INP in the new "needs improvement" band (150-500ms) saw an average position loss of 0.8 places on competitive queries. Sites in the "poor" band (500ms+) lost 2-4 positions.

The threshold change hit mobile harder than desktop because mobile INP is typically 2-3x worse than desktop INP on the same site. A site at 180ms desktop / 280ms mobile passed cleanly before March 27. After, it's in the "needs improvement" bucket on both, which the new aggregation model treats as a global penalty.

INP Explained (Actually Explained)

Interaction to Next Paint replaced First Input Delay in March 2024, and two years later most sites still don't understand what it measures. INP is the time between a user interacting (tap, click, key press) and the next visual update the browser actually paints to the screen.

FID only measured the delay before the browser could start processing the input. INP measures the full round-trip: input delay + processing time + rendering + painting. It's a better metric because users don't care when processing starts, they care when the screen updates.

INP is also harder to game. You can't "fix" INP by loading a blank page first. If your button click takes 400ms to process and paint, INP is 400ms no matter what else you do. The only way to reduce INP is to make the work genuinely faster.

The measurement is per-interaction, and INP reports the worst interaction on the page (with a small fudge factor for pages with many interactions, where Google uses the 98th percentile instead of the absolute max). A page with 99 fast clicks and one 800ms click gets judged by the 800ms click. This punishes occasional hiccups in a way FID didn't.

The Three Metrics and Where They Actually Break

Metric Good (2026) Needs Improvement Poor Root Cause When It Fails
LCP ≤ 2.0s 2.0-4.0s > 4.0s Slow hero image, blocking CSS/fonts, slow TTFB
INP ≤ 150ms 150-500ms > 500ms Long JS tasks, third-party scripts, heavy event handlers
CLS ≤ 0.1 0.1-0.25 > 0.25 Images without dimensions, dynamically injected content, web fonts

LCP also tightened in 2026 (was 2.5s, now 2.0s) but it got less attention because most sites that cared about LCP had already optimized it. INP is the new battleground.

To check where your site sits today, plug your URL into our page speed estimator. It pulls CrUX field data (what Google actually uses) alongside lab-simulated metrics, so you can see both the reality and the diagnostics.

How to Actually Fix INP

INP is not one thing. It's a composite of input delay, processing time, and presentation delay. Fixing it means profiling which phase is slow and attacking that phase specifically. The typical culprits, in rough order of frequency:

1. Third-Party Scripts That Block the Main Thread

Analytics, tag managers, ad networks, chat widgets, A/B testing scripts, marketing pixels. Each one runs JavaScript on your main thread, and every millisecond of main-thread work adds to INP when a user interacts during that window.

Audit every third-party script on your site. For each one, ask: does the business genuinely need this? If yes, can it be async, deferred, or moved to a web worker via Partytown? If no, remove it. The biggest INP wins I've seen came from removing five or six "we might use this data someday" scripts that nobody was actually looking at.

2. Long JavaScript Tasks

Any JS task running longer than 50ms blocks user interactions while it runs. Chrome DevTools' Performance panel shows them as long orange bars labeled "Task." Common culprits: React component trees re-rendering unnecessarily, data transformations on large arrays in an event handler, and animation libraries that do too much work per frame.

Fixes, from easiest to hardest:

  • Break long tasks into chunks with await scheduler.yield() or setTimeout(..., 0) to let the browser breathe.
  • Use requestIdleCallback for non-urgent work like analytics payload construction.
  • Move heavy computation to a Web Worker so the main thread stays free.
  • Virtualize long lists so you only render visible items.
  • Memoize expensive React computations with useMemo and useCallback.

3. Unoptimized Event Handlers

A click handler that queries the DOM, recomputes layout, and dispatches three Redux actions synchronously is a 200ms INP waiting to happen. Split synchronous event handling into "immediate feedback" and "deferred work":

// BAD: does everything synchronously
button.addEventListener('click', () => {
  updateUI();
  saveToServer();     // network call
  logAnalytics();     // another network call
  recomputeLayout();  // expensive DOM work
});

// GOOD: paint first, then defer
button.addEventListener('click', () => {
  updateUI();  // visible change immediately
  requestIdleCallback(() => {
    saveToServer();
    logAnalytics();
    recomputeLayout();
  });
});

That single pattern (paint immediately, defer everything else) is responsible for maybe 40% of the INP wins I've seen on React apps in the last six months.

4. Hydration and SSR Costs

If you ship a React/Vue/Next.js app, the initial hydration pass can take hundreds of milliseconds on mid-tier phones. If a user interacts during hydration, INP is whatever the delay happens to be.

Partial hydration (React Server Components, Qwik, Astro islands) fixes this by only hydrating interactive components. Static islands stay static. The interactive parts ship as small, targeted bundles. The INP gains are usually dramatic.

5. Font Loading That Blocks Paint

A webfont that loads after the first paint can cause layout thrash as text reflows. Use font-display: optional or swap to show fallback text immediately, and preload critical fonts in the HTML head.

How to Actually Fix LCP

LCP at 2.0s is aggressive. You have roughly one network round-trip plus one render to nail it. The fixes:

  • Compress the hero image. A 300KB JPEG should be 30-60KB in WebP or AVIF at the same visual quality. Our image compressor and AVIF converter handle the conversion in-browser.
  • Use responsive images. Don't ship a 2000px-wide hero to a 400px-wide phone. srcset and sizes let the browser pick the right size.
  • Preload the LCP image. <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> tells the browser to start downloading it alongside the HTML.
  • Inline critical CSS. Any CSS needed to render the LCP element should be in the HTML, not in an external stylesheet that the browser has to fetch.
  • Upgrade hosting. A TTFB of 800ms makes 2.0s LCP mathematically impossible. Cloudflare, Vercel, Fastly, and similar CDNs typically hit TTFB under 200ms globally.

How to Actually Fix CLS

CLS is the easiest metric to fix because the causes are mechanical:

  1. Every image needs explicit width and height attributes (or aspect-ratio CSS). Without dimensions, the browser reserves 0px until the image loads, then shoves everything down. Audit your HTML. Every single <img> should declare dimensions.
  2. Reserve space for ads, embeds, and iframes before they load. A 300x250 ad slot should be a 300x250 empty div that the ad fills.
  3. Avoid inserting content above existing content. If a newsletter banner needs to appear at the top of the page after load, animate it in from above the viewport instead of pushing the existing content down.
  4. Use font-display: optional on webfonts to avoid reflow when the font swaps.

Site-Level Aggregation: Why Your Slow Pages Are Now Everyone's Problem

The site-level scoring change is the one most people missed, and it's the one that hurts most. Under the old system, if your product pages passed CWV but your blog was slow, only the blog suffered. Under the new system, Google computes a weighted average across all indexed URLs and applies the resulting score as a site-wide modifier.

The weighting is traffic-share based. A page that gets 10% of your total impressions contributes 10% to your site score. Low-traffic pages barely count, but high-traffic pages can carry or crater you.

Two tactical implications:

  • Audit your top 20 pages first. Pull Search Console impression data, sort descending, and fix CWV on the top 20. That's probably 60-80% of your weighted score.
  • Noindex your slow zombie pages. If you have 500 archive pages that nobody visits but that all load slowly, they still contribute to the aggregate (weighted by their traffic share, which is tiny). Noindex or canonicalize them to prevent them from dragging the average.

Measurement: Lab vs Field Data

Lab tools (PageSpeed Insights lab scores, Lighthouse, WebPageTest) run your site in a simulated environment. They're reproducible and useful for diagnosis, but they're not what Google uses.

Field tools (Chrome User Experience Report, web-vitals JavaScript library) measure what real users actually experience. This is what Google uses for ranking. Field data lags by 28 days (CrUX reports rolling 28-day averages), which means CWV fixes don't move the needle until you've had a month of fast data.

The practical workflow:

  1. Lab-test to identify bottlenecks (PageSpeed Insights, Lighthouse, WebPageTest).
  2. Fix the bottlenecks.
  3. Ship to production.
  4. Instrument field measurement with web-vitals JS library to confirm users see the gains.
  5. Wait 28 days for CrUX to update before expecting ranking effects.

Search Console's Core Web Vitals report uses CrUX field data and shows you which URLs are passing and failing at each metric. It's the closest thing to "what Google sees" and it's free.

Real Cases: Three Sites, Three Fixes

Case 1: E-commerce Product Pages at 280ms INP

A mid-size DTC brand ran into the INP 150ms ceiling because their product pages embedded a "recently viewed" widget, a live chat, and a review carousel, all of which ran heavy JS on every page load. Their fix was to lazy-load all three components on scroll or interaction, not on page load. INP dropped from 280ms to 110ms. Rankings on commercial queries recovered over six weeks.

Case 2: Publisher at 320ms INP from Ad Networks

A news site had a healthy 1.8s LCP but 320ms INP because their ad network injected 11 third-party scripts per page. They audited their stack, consolidated to a single SSP with server-side bidding, and moved non-critical tracking scripts to Partytown. INP dropped to 140ms. Revenue per session stayed flat because the remaining ads filled better without competition, and rankings recovered.

Case 3: SaaS Landing Page at 210ms INP from Analytics Bloat

A B2B SaaS had four analytics providers, two A/B testing tools, a heatmap tool, and a session replay tool all running on their main landing page. INP was 210ms. They kept one analytics provider and one A/B testing tool, moved everything else behind consent gates or removed it. INP dropped to 95ms.

The pattern is clear: most INP problems are caused by third-party JavaScript, not by your own code. If you're over the threshold and haven't audited your third-party scripts, that's where to start.

Tools That Help

The Common Mistakes

A few patterns I keep seeing in CWV audits that almost always backfire:

  • Chasing the lab score, not the field score. Your PageSpeed Insights score can be 98 while your CrUX field INP is 400ms, because real users use mid-tier phones on patchy 4G and your lab runs on a simulated Motorola G4. Only field data counts.
  • Lazy-loading the LCP image. loading="lazy" on your hero image delays LCP by hundreds of milliseconds. Only lazy-load below-the-fold images.
  • Ignoring the 75th percentile. Google doesn't judge you by your median user. They judge you by the 75th percentile, which means your slowest 25% of sessions. If your p75 INP is 300ms and your p50 is 90ms, you're failing.
  • Optimizing after launch. CWV scores are 28-day rolling averages. Fixes take 4-8 weeks to propagate into ranking signals. Every week you delay is a week of ranking erosion.

Frequently Asked Questions

What is the new INP threshold?

150ms for "good" (down from 200ms). 150-500ms is "needs improvement". 500ms+ is "poor". Lab and field both use the same thresholds.

Is CWV now a site-level ranking factor?

Yes. Google aggregates page-level CWV into a traffic-weighted domain score and uses that as a ranking modifier. Individual page scores still matter, but a bad site-wide average hurts every page on the domain.

How big is the ranking impact?

Sites in "needs improvement" saw average drops of 0.8 positions. Sites in "poor" saw drops of 2-4 positions. The impact scales with query competitiveness and with how much your competitors beat you on CWV.

How do I measure INP?

PageSpeed Insights shows lab and field CWV for any URL. Search Console's Core Web Vitals report shows field data aggregated across your whole site. The web-vitals JavaScript library lets you collect per-user INP in your own analytics.

How long do CWV fixes take to show in rankings?

Field data updates on a 28-day rolling window. Expect 4-8 weeks after shipping fixes before ranking movements appear. Lab metrics update immediately but don't affect rankings directly.

Does CWV affect AdSense or ad revenue?

Not directly, but poor CWV reduces organic traffic, which reduces ad impressions. Fast sites also have better user engagement, which improves viewability and CPMs.

Further Reading

The March 2026 update raised the floor for what counts as "fast enough." Sites that were coasting on decent averages are now competing against sites that took performance seriously years ago. The good news: every site has some low-hanging fruit. Remove the scripts you don't need, compress the images you ship, split the long tasks, and you'll probably move from failing to passing in a month. The bad news: waiting doesn't help. The threshold already moved. The only question is how fast you catch up.