INP optimization 2026 — exact code patterns, measurement, real fixes that get sites under 200ms. From an agency that ships them. Free 30-min audit.

INP (Interaction to Next Paint) measures how long your page takes to visibly respond after a user clicks, taps, or types. It replaced FID as a Core Web Vital in March 2024. Google considers INP under 200ms “good,” 200-500ms “needs improvement,” and over 500ms “poor.” In 2026, ~38% of mobile sites fail INP — meaning fixing it is one of the fastest SEO wins available. Most failures come from three patterns: heavy third-party scripts (analytics, chat widgets, A/B testing), unoptimized React/Vue hydration, and synchronous DOM reads/writes (“layout thrashing”).

We’ve shipped INP fixes on 4 client sites in the last 12 months. Median INP went from 312ms to 168ms. Below is the exact playbook.

The 80/20 of INP Fixes

If you only do three things:

1. Defer or delete third-party scripts. Chat widgets, analytics tags, A/B testing — these are usually 60-80% of INP cost.
2. Break long JavaScript tasks into chunks under 50ms using `scheduler.yield()` or `setTimeout`.
3. Eliminate forced synchronous layouts. Batch all DOM reads, then batch all writes. No interleaving.

That’s the bulk of it. Everything below is detail.

What INP Actually Measures

INP captures the longest interaction latency from a user session, made up of three phases:

Per Google’s web.dev INP guide, the input delay phase is the most common bottleneck. Translation: a user clicks, the main thread is busy with something else (usually third-party JS), and the click sits in queue.

Step 1: Measure Real INP

Don’t trust Lighthouse scores alone. Lighthouse uses synthetic interactions and underreports real INP.

Real-user INP sources:

• Chrome User Experience Report (CrUX) — actual field data, free, see PageSpeed Insights
• Google Search Console Core Web Vitals report — your own real users
• DebugBear, SpeedCurve, or Calibre — paid RUM tools with INP attribution

For lab debugging: open Chrome DevTools → Performance tab → click “Start profiling and reload page” → interact → look at the Interactions track.

Step 2: Identify the Killers

In our cohort of 4 sites we fixed, the INP killers ranked:

If you’re on WordPress with Elementor or Divi, that single switch (to Astra/GeneratePress + Gutenberg) often cuts INP in half. See our Wix vs WordPress 2026 comparison for theme advice.

Step 3: Fix Patterns

Fix 1: Defer Third-Party Scripts

The single highest-impact change. Use `loading=”lazy”` for iframes, `defer` for non-critical scripts, and Partytown to offload analytics to a web worker.

“`html “`

Real result from one client: GA4 + Intercom + Hotjar moved to Partytown cut INP from 287ms to 142ms.

Fix 2: Break Up Long Tasks

Use the new `scheduler.yield()` API (Chrome 129+, Edge 129+) or `setTimeout` fallback:

“`javascript async function processItems(items) { for (const item of items) { doExpensiveWork(item); if (scheduler && scheduler.yield) { await scheduler.yield(); } else { await new Promise(r => setTimeout(r, 0)); } } } “`

This lets the browser handle pending interactions between chunks. Critical for any task over 50ms.

Fix 3: Avoid Layout Thrashing

Bad pattern (forces synchronous layout multiple times):

“`javascript elements.forEach(el => { const w = el.offsetWidth; // read el.style.width = (w + 10) + ‘px’; // write — invalidates layout }); “`

Good pattern (batched):

“`javascript const widths = elements.map(el => el.offsetWidth); // all reads first elements.forEach((el, i) => el.style.width = (widths[i] + 10) + ‘px’); // then writes “`

Per Paul Lewis’s classic post on layout thrashing, this single pattern is responsible for ~30% of INP issues on dynamic dashboards.

Fix 4: Reduce React/Vue Hydration Cost

Server-side rendering with full client-side hydration is expensive. In 2026:

• Use selective hydration / islands (Astro, Qwik, React Server Components)
• Defer non-critical hydration with `useDeferredValue` or dynamic imports
• Avoid huge initial bundles — code-split aggressively

For simple sites, consider whether you need a JS framework at all. Static HTML + minimal JS produces sub-100ms INP almost free.

Fix 5: Optimize Cookie Consent

Cookie banners often inject blocking JS. Solutions:

• Use a lightweight CMP (Termly, CookieYes) over enterprise (OneTrust)
• Defer ad/analytics scripts until consent is given
• Render banner with CSS-first, JS-second pattern

Step 4: WordPress-Specific Fixes

Most failing INP scores in our cohort are on WordPress sites. The 4-step WP cleanup:

1. Audit plugins. Anything that adds a script in the head should justify its INP cost.
2. Drop the page builder. Switch to Gutenberg + a lightweight theme (Astra, GeneratePress, Kadence).
3. Cache aggressively. WP Rocket or LiteSpeed Cache. Defer JS, lazy-load images.
4. Move third-party scripts to Partytown via plugin or manual.

We took one client site from a 487ms INP to 178ms by doing exactly the above. Time invested: ~12 hours.

What Other INP Guides Get Wrong

Wrong: “INP is just about React/Vue performance.” Right: INP affects every site. Static WordPress sites with bad plugin choices fail INP just as often as React SPAs.

Wrong: “Use `requestIdleCallback` to defer work.” Right: `requestIdleCallback` doesn’t yield to user input. Use `scheduler.yield()` instead, which is purpose-built for INP.

Wrong: “Lazy-load everything.” Right: Lazy-loading critical content hurts LCP. Lazy-load below-the-fold images and scripts only.

Real Before/After Data

From our 4 client engagements (April 2025 to April 2026):

Median improvement: 144ms. All four crossed the 200ms “good” threshold.

For why this matters for AI Overview citations: see our Google AI Overviews ranking guide — Core Web Vitals are now a documented factor in citation eligibility.

Tools Stack

• Free: PageSpeed Insights, Chrome DevTools Performance tab, web-vitals JS library
• Cheap: DebugBear ($60-150/mo) — RUM with INP attribution
• Pro: SpeedCurve or Calibre ($120-400/mo) — full performance monitoring

For broader SEO measurement: best free keyword research tools 2026 and our website cost calculator for build-stage planning.

What to Do This Week

If you don’t know your INP: run your site through PageSpeed Insights, scroll to “Discover what your real users are experiencing.” That’s your real-world INP.

If you’re failing: do the 80/20 first. Audit third-party scripts (you’ll find 2-4 you can defer or kill), break long JS tasks, fix any layout thrashing in custom code.

If you want a fix scoped: book a free 30-min audit. We’ll run the diagnostic live and send you a prioritized fix list.

FAQ

What’s a good INP score in 2026? Under 200ms is “good” per Google. Under 100ms is excellent. Most failing sites cluster around 250-450ms.

Does INP affect SEO? Yes. INP is a confirmed Core Web Vital and a Google ranking signal. The impact is small individually but compounds with content quality. AI Overview citations also weight Core Web Vitals.

Will updating my CMS/theme fix INP? On WordPress with a page builder, yes — switching to Gutenberg + a lightweight theme often halves INP. On other platforms, theme alone rarely helps; the wins come from script audit and JS optimization.

Is React always bad for INP? No. React with selective hydration (RSC, Astro islands) or careful code-splitting achieves sub-150ms INP routinely. Naive client-side React with monolithic bundles is the problem.

How long does INP optimization take? 3-15 hours for most small-business sites. Complex SPAs or e-commerce can take 30-80 hours. ROI is usually positive within a quarter from improved CWV scores and conversion.

What’s the difference between INP and FID? INP measures *all* interactions on the page (worst-case observed). FID measured only the first input delay. INP is harder to game and reflects real-user pain better.

Sources:

• web.dev INP article
• LinkGraph INP Optimization Guide
• DebugBear INP Documentation
• web.dev How to Optimize INP
• Google PageSpeed Insights