Core Web Vitals INP Optimization: The Metric Most Sites Are Failing

There is a Core Web Vital that most sites are failing, and most SEOs are ignoring.

Interaction to Next Paint (INP) replaced First Input Delay (FID) as the responsiveness metric in March 2024. The threshold is strict: under 200 milliseconds to be considered "good."

Most sites that passed FID are failing INP. The metrics measure fundamentally different things.

Why INP Matters More Than FID

FID measured the delay before the browser started processing the first interaction. It did not measure how long the processing took or whether the page actually responded.

INP measures the complete picture: from when a user interacts (click, tap, key press) to when the browser renders the next frame. It captures the full perceived delay.

The difference in practice:

• FID: User clicks button, browser starts processing immediately. FID is good.
• INP: User clicks button, browser starts processing immediately, but processing takes 400ms, and the page does not visually respond until processing completes. INP is poor.

FID gave credit for starting fast. INP requires finishing fast.

What INP Actually Measures

INP observes all interactions during a page visit—clicks, taps, and key presses—and reports a value that nearly all interactions were beneath.

Specifically, it measures the longest interaction latency, with some statistical adjustment to account for outliers. If you have 100 interactions on a page and 99 are under 150ms but one takes 800ms, your INP will reflect that outlier.

The three phases of interaction latency:

1. Input delay: Time from user interaction to event handler running
2. Processing time: Time for the event handler code to execute
3. Presentation delay: Time for the browser to render the next frame

All three phases contribute to INP. A problem in any phase creates poor INP scores.

Diagnosing INP Problems

Start with data. Google Search Console shows Core Web Vitals by URL group. PageSpeed Insights and Chrome DevTools provide page-level analysis.

Step 1: Identify Problem Pages

In Search Console, navigate to Core Web Vitals report. Filter for "Poor" INP scores. Note which URL groups are affected—this helps identify patterns.

Step 2: Profile Specific Interactions

Use Chrome DevTools Performance panel:

1. Open the page
2. Start recording
3. Interact with the page as a user would
4. Stop recording and analyze the trace

Look for long tasks (over 50ms) on the main thread. These block responsiveness.

Step 3: Identify the Bottleneck Phase

Determine which phase is causing the problem:

• **High input delay:** JavaScript is blocking the main thread before your handler runs
• **High processing time:** Your event handler code is too slow
• **High presentation delay:** Rendering is expensive after state changes

Each requires different fixes.

Common INP Problems and Fixes

Problem 1: Third-Party JavaScript Blocking Main Thread

Tag managers, analytics scripts, chat widgets, consent banners, and personalization tools all execute JavaScript. When they run long tasks on the main thread, user interactions wait.

Diagnosis: In DevTools, filter the Performance trace by third-party domains. Look for long tasks from external scripts.

Solutions:

• **Defer non-critical scripts:** Load analytics and tracking after the page is interactive
• **Use web workers:** Move heavy processing off the main thread
• **Lazy load widgets:** Load chat and feedback widgets on user intent, not page load
• **Audit tag manager:** Remove tags you no longer use; consolidate redundant tags

Problem 2: Event Handlers Doing Too Much Work

Click handlers that trigger API calls, state updates, and re-renders can easily exceed 200ms.

Diagnosis: Profile the specific interaction. Measure how long your event handler code takes to execute.

Solutions:

• **Break up work:** Use requestIdleCallback or setTimeout to split work across frames
• **Optimize rendering:** Use React.memo, useMemo, or virtual DOM optimizations
• **Debounce inputs:** For search or filter inputs, debounce to reduce processing frequency
• **Show immediate feedback:** Update UI instantly, then fetch data; do not wait for data to update UI

Problem 3: Large DOM Updates

When interactions trigger large DOM changes, the browser spends time in layout and paint phases.

Diagnosis: In the Performance trace, look for long "Layout" or "Paint" entries after your event handler completes.

Solutions:

• **Virtualize long lists:** Only render visible items
• **Use CSS containment:** contain: content on independent sections reduces layout scope
• **Batch DOM updates:** Minimize layout thrashing from multiple read/write cycles
• **Avoid forced synchronous layouts:** Reading layout properties after writing triggers expensive recalculation

Problem 4: Main Thread Competition

Multiple things competing for the main thread—animations, scroll handlers, background sync—delay interaction processing.

Diagnosis: Look at the full Performance trace. What else is running when the interaction occurs?

Solutions:

• **Use CSS animations:** CSS transforms are GPU-accelerated and do not block main thread
• **Throttle scroll handlers:** Process on animation frame, not every scroll event
• **Prioritize user interactions:** Use scheduler.postTask to prioritize interaction handlers over background work

Framework-Specific Optimizations

React

• Use React 18's concurrent features for non-blocking rendering
• Implement useDeferredValue for expensive computations
• Wrap lists in memo() to prevent unnecessary re-renders
• Use Suspense boundaries to progressively render

Next.js

• Use Server Components to reduce client-side JavaScript
• Implement dynamic imports for heavy components
• Configure proper code splitting
• Use the App Router for automatic component-level streaming

Vue

• Use v-once for static content
• Implement keep-alive for cached components
• Use shallowRef for large objects
• Lazy load route components

WordPress

• Audit and remove unnecessary plugins
• Use asset optimization plugins (Autoptimize, WP Rocket)
• Consider headless WordPress with modern frontend
• Implement caching aggressively

Measuring Success

INP improvement requires ongoing measurement.

Lab Tools:

• PageSpeed Insights (single page, synthetic)
• Chrome DevTools Performance panel (interaction profiling)
• Lighthouse (automated auditing)

Field Tools:

• Google Search Console Core Web Vitals report (aggregated real user data)
• Chrome User Experience Report (CrUX) (anonymized real user data)
• Web Vitals library (custom real user monitoring)

Tracking INP Over Time:

Implement the web-vitals JavaScript library to collect INP data from real users. Send this data to your analytics platform. Track percentiles (p75, p95) over time. Monitor by device type—mobile often differs significantly from desktop.

The SEO Impact

Core Web Vitals are a ranking factor, but context matters.

When CWV matters most:

• Competitive niches where content quality is similar
• Pages competing for top 3 positions
• Mobile search (where performance is more variable)

When CWV matters less:

• Unique content that nothing else matches
• Queries with limited competition
• Branded searches

"Whilst Core Web Vitals are not the only ranking factor, they matter significantly in competitive niches where content quality is similar across competing pages."

The practical advice: fix INP problems because they hurt user experience, which affects engagement and conversion. The SEO benefit is real but secondary.

Implementation Priority

If you are failing INP, here is the priority order for fixes:

1. Audit third-party scripts: Highest impact, often lowest effort
2. Lazy load non-critical features: Chat widgets, feedback tools, heavy embeds
3. Optimize event handlers: Profile and improve the slowest interactions
4. Reduce JavaScript payload: Code splitting, tree shaking, modern bundles
5. Improve rendering performance: Virtual lists, CSS containment, layout optimization

Most sites can achieve passing INP scores by addressing items 1 and 2 alone. Go deeper only if quick wins do not solve the problem.

FAQ

What INP score should I target?

Under 200ms for at least 75% of interactions. Aim for under 150ms if possible. Anything over 500ms is considered poor and may impact rankings.

Is INP more important than LCP and CLS?

All three Core Web Vitals matter, but INP affects perceived performance most directly. A site can load fast (good LCP) and stay stable (good CLS) but still feel sluggish if interactions are slow (poor INP).

Do all interactions affect INP?

INP tracks clicks, taps, and key presses. Scrolling and hovering are not included. Only one INP value is reported per page—typically the longest interaction latency.

Can I fix INP with server-side rendering?

SSR helps with initial load performance and reduces client-side JavaScript, which indirectly helps INP. But SSR does not directly fix interaction responsiveness—that requires client-side optimization.

How long does it take for INP improvements to reflect in Search Console?

Search Console data is based on the past 28 days of real user data. After deploying fixes, expect 2-4 weeks before improvements fully reflect in the report.

Should I prioritize INP over content improvements?

If your INP is poor (over 500ms), fix it first—it creates a terrible user experience. If INP is "needs improvement" (200-500ms), content improvements likely have higher ROI. Context matters.