INP replaced FID — here's what changed
In March 2024, Interaction to Next Paint became a Core Web Vital, replacing First Input Delay. If you optimized for FID and thought you were done, INP is a harder test and many pages that passed FID now fail INP. It's worth understanding why.
FID only measured the delay before the browser started processing your first interaction. It ignored how long the processing took and ignored every interaction after the first. INP measures the full latency — from tap or click to the next frame painted — across all interactions during the visit, and reports roughly the worst one. So a button that takes 400ms of JavaScript to respond, or a filter that recalculates on every keystroke, now shows up where FID gave it a pass.
The threshold for a good score is 200 milliseconds at the 75th percentile; 200–500ms needs improvement, and above 500ms is poor.
Why interactions get slow
INP is almost always a main-thread problem. When you click, the browser needs to run your event handler, then recalculate styles and layout, then paint. If a long JavaScript task is already running — or your handler itself does too much — the paint is delayed and the user feels lag. The three common causes:
1. Long tasks blocking the main thread. A heavy script (analytics, a hydration pass, a big third-party widget) monopolizes the main thread, so even a trivial click has to wait its turn. Breaking long tasks into smaller chunks lets the browser respond to input between them:
async function processInChunks(items) {
for (let i = 0; i < items.length; i++) {
doWork(items[i]);
// Yield to the main thread so pending input can be handled
if (i % 50 === 0) await new Promise(r => setTimeout(r, 0));
}
}
2. Expensive event handlers. A handler that re-renders a large list, recalculates layout, or filters thousands of rows on every keystroke will blow past 200ms. Debounce input handlers, and move heavy computation off the critical path — or into a Web Worker if it's genuinely CPU-bound.
3. Large DOM and forced reflows. Reading a layout property (like offsetHeight) right after writing to the DOM forces a synchronous reflow. Batch your reads and writes, and keep the DOM size reasonable — the analyzer flags oversized DOM trees, which drag down both INP and rendering speed.
The framework angle
If you're on React, Vue, or another hydration-based framework, a big INP culprit is hydration itself — the JavaScript that makes server-rendered HTML interactive can occupy the main thread for hundreds of milliseconds right when users first try to interact. Mitigations: code-split so you ship less JavaScript, defer non-critical hydration, and avoid running expensive effects on mount. Reducing your JavaScript bundle is the same work that helps render-blocking resources and overall page speed, so the wins compound across all three Core Web Vitals.
How to measure INP
INP needs real interactions, so lab tools can only estimate it — you have to click around. In DevTools, the Performance panel now surfaces interaction latency, and the web-vitals JavaScript library reports INP live in the field with the specific element attributed. Search Console's Core Web Vitals report shows the field 75th-percentile number, updated on the usual rolling 28-day window. Test on a mid-range Android phone if you can; INP problems are far worse on slower CPUs than on a developer laptop.
FAQ
Q: What's the difference between INP and FID? A: FID measured only the input delay before processing began, for the first interaction only. INP measures the complete latency from interaction to the next paint, across all interactions on the page, and reports the worst. INP is stricter, so some pages that passed FID fail INP.
Q: What is a good INP score? A: 200 milliseconds or less at the 75th percentile of real interactions. Between 200 and 500ms needs improvement, and above 500ms is poor.
Q: Why is my INP fine in the lab but poor in the field? A: INP requires real user interactions, which lab tools can't fully simulate, and field data comes from slower devices than a developer machine. Test by interacting on a mid-range phone and trust the Search Console field number.
Q: Does reducing JavaScript improve INP? A: Usually, yes. Long JavaScript tasks blocking the main thread are the most common cause of poor INP. Shipping less JavaScript, code-splitting, breaking up long tasks, and deferring non-critical work all reduce interaction latency.