INP vs FID: The New Core Web Vital You Need to Optimize

In March 2024, Google made a significant change to Core Web Vitals: INP (Interaction to Next Paint) officially replaced FID (First Input Delay) as one of the three core metrics. This wasn't just a rename—it represents a fundamental shift in how we measure and think about page interactivity.

The Problem with FID

FID (First Input Delay) measured the delay between a user's first interaction with a page and the browser's response. On paper, this sounds reasonable—users expect immediate feedback when they click or tap.

In practice, FID had several limitations:

• Only first interaction: FID ignored all subsequent interactions. A page could be sluggish after the first click and still score well.
• Many pages had no FID: If users didn't interact before leaving (common on informational pages), no FID was recorded.
• Didn't capture full interaction: FID measured only input delay, not the actual processing time or time to visual update.

As web applications became more interactive—with dynamic content, infinite scroll, and complex UI—FID became increasingly inadequate as a measure of responsiveness.

What Is INP?

INP (Interaction to Next Paint) addresses these limitations by measuring responsiveness across all interactions throughout the page's lifecycle.

What counts as an interaction?

• Clicks (mouse)
• Taps (touchscreen)
• Key presses

Scrolling and hovering are not considered interactions for INP purposes.

What does INP measure?

For each interaction, INP measures the time from when the user initiates the interaction to when the browser paints the visual response. This includes:

1. Input delay: Time waiting for the main thread to be free
2. Processing time: Time to run event handlers
3. Presentation delay: Time to render and paint the result

INP then reports a single value representative of your page's overall responsiveness. For pages with many interactions, it's approximately the worst interaction (ignoring outliers).

INP Thresholds

Google defines three tiers for INP:

• Good: 200 milliseconds or less
• Needs Improvement: 200 to 500 milliseconds
• Poor: More than 500 milliseconds

These thresholds are stricter than FID's (which was 100ms for "good"). This reflects user expectations: we expect instant feedback from every interaction, not just the first one.

Why INP Is a Better Metric

INP provides a more accurate picture of real-world responsiveness because:

• It captures the full interaction lifecycle, not just input delay
• It measures all interactions, catching problems that occur after initial load
• It's more likely to have data (most pages have at least one interaction)
• It better reflects modern web application usage patterns

For developers, this means you can no longer optimize just for first load. Your page needs to remain responsive throughout the user's session.

What Causes Poor INP?

The primary cause of poor INP is JavaScript blocking the main thread. When JavaScript runs, the browser can't respond to user input until that code completes.

Long Tasks

A "long task" in browser terms is any JavaScript execution that takes more than 50 milliseconds. During this time, the page is essentially frozen—clicks, taps, and key presses are queued but not processed.

Common sources of long tasks:

• Large JavaScript bundles executing on page load
• Complex event handlers that do too much work
• Third-party scripts (analytics, ads, chat widgets)
• Framework hydration (React, Vue, Angular)
• Expensive DOM operations (layout thrashing)

Third-Party Scripts

Third-party scripts are a common culprit. Analytics, advertising, social widgets, and chat tools all compete for main thread time. Each one might seem harmless individually, but together they can create significant blocking.

Heavy Event Handlers

Sometimes the problem isn't background JavaScript, but the handler for the interaction itself. If clicking a button triggers complex calculations, large DOM updates, or synchronous network requests, the response will be slow.

How to Improve INP

1. Break Up Long Tasks

The most effective fix for INP is breaking long JavaScript operations into smaller chunks, allowing the browser to respond to user input between them.

Techniques include:

• Using setTimeout(fn, 0) to yield to the main thread
• Using requestIdleCallback() for non-urgent work
• The new scheduler.yield() API (where available)
• Breaking loops into smaller batches

2. Reduce JavaScript Size

Less JavaScript means less to parse and execute:

• Use code splitting to load only what's needed
• Remove unused dependencies
• Tree-shake dead code
• Consider lighter alternatives (e.g., Preact instead of React)

3. Defer Non-Essential Scripts

Load third-party scripts after the page is interactive:

• Add defer or async to script tags
• Load analytics and ads after critical content
• Lazy-load chat widgets until user engagement

4. Use Web Workers

Move heavy computations off the main thread entirely using Web Workers. They run in a separate thread and can't block user interactions.

Good candidates for Web Workers:

• Data processing and parsing
• Complex calculations
• Image processing

5. Optimize Event Handlers

Make your interaction handlers fast:

• Show immediate visual feedback (loading spinners, button state changes)
• Defer heavy work until after the UI update
• Debounce or throttle frequently-fired events
• Avoid synchronous layout reads followed by writes (layout thrashing)

Measuring INP

You can measure INP through:

• PageSpeed Insights: Shows real-user INP data from the Chrome User Experience Report
• Chrome DevTools Performance Panel: Shows individual interaction timings
• Web Vitals Chrome Extension: Real-time INP display while browsing
• Web Vitals JavaScript Library: Measure real users in production

For ongoing monitoring, use tools like Google Search Console (for aggregate data) or specialized monitoring platforms that track INP continuously.

Key Differences: INP vs FID Summary

Aspect	FID (Old)	INP (New)
Interactions measured	First only	All interactions
What's measured	Input delay only	Full interaction latency
Good threshold	≤ 100ms	≤ 200ms
Pages with data	Only if user interacted	Most pages

Conclusion

The switch from FID to INP reflects how the web has evolved. Modern sites are interactive applications, not static documents, and our metrics need to reflect that.

If you've been optimizing for FID, you may find that your INP scores are different—often worse. The good news is that INP optimization follows clear patterns: reduce JavaScript, break up long tasks, and ensure your event handlers are efficient.

Start by measuring your current INP, identify the problematic interactions, and work through the optimization techniques above. Your users—and your Core Web Vitals scores—will thank you.