FrontendHaltInteraction responsiveness and INP
Measure and fix how long the page takes to visually respond to input — input delay, handler work, and the next paint.
WHAT YOU WILL BE ABLE TO DO
Learning outcomes
- Explain interaction responsiveness and inp in plain language.
- Connect the behavior to the underlying browser or framework model.
- Implement the core pattern and reason through edge cases.
- Answer common follow-ups without relying on memorized phrases.
01Explain it simply
Interaction to Next Paint measures how long the page takes to visually respond after a user interaction — the delay before the handler runs, plus the handler itself, plus rendering the resulting frame. A high INP means the UI feels laggy even if the page loaded fast.
One-line definition: Measure and fix how long the page takes to visually respond to input — input delay, handler work, and the next paint.
02Mental model
INP reports roughly the worst interaction latency over the page's lifetime. It breaks into input delay (the main thread was busy when the event fired), processing time (your handler's synchronous work), and presentation delay (time to render the next frame, including layout and paint). Fixes target each: break up long tasks, keep handlers lean and defer non-urgent work, and avoid large synchronous DOM updates or layout thrash in the handler.
03Step by step
- Measure INP with field data from real users, then reproduce the worst interactions in a profile.
- Split long tasks so the main thread is free when input lands.
- In the handler, do only what's needed for immediate feedback; schedule the rest with a yield or later task.
- Avoid forcing synchronous layout inside handlers — reading layout after writing it.
- Use a framework's transition or deferred-update API so a large re-render doesn't block the interaction's paint.
- Re-measure the specific interaction, not just the page average.
04Working example
button.addEventListener("click", async () => { showSpinner(); // cheap: paints immediately await yieldToMain(); // let the browser render that frame const result = doExpensiveWork(); // now runs without blocking the click's paint render(result);});const yieldToMain = () => new Promise((r) => setTimeout(r, 0));The handler does the minimum for instant feedback (show a spinner), then yields so the browser can paint that frame, and only then runs the expensive work. Without the yield, the spinner and the expensive work are in one task and the user sees nothing until all of it finishes, inflating INP.
05Where it is used
- Diagnosing a UI that feels sluggish despite good load metrics
- Prioritizing which interactions to optimize using field data
- Justifying breaking up long tasks and deferring work in event handlers
- Choosing when to use a framework's deferred or transition rendering
06Common mistakes
- Optimizing average interaction time when INP is about the worst one
- Doing all the work synchronously in the handler so nothing paints until it's done
- Forced synchronous layout — writing to the DOM then immediately reading a layout property — inside a handler
- Assuming a fast Lighthouse score means good responsiveness; lab INP misses real interaction patterns
07Interview answer
Break INP into input delay, processing, and presentation delay, and map each to a fix. Stress it's the worst interaction, measured in the field, and that it's the event-loop cost model seen from the user's side.
A click handler shows a loading spinner and then does 300ms of synchronous work. Users report the spinner doesn't appear until the work is done. Why, and what's the fix?
The spinner update and the 300ms of work are in the same task, so the browser can't paint the spinner until the whole task finishes; yielding to the main thread after showing the spinner lets that frame paint before the expensive work runs.
DDConcept deep dives
Deep dive 1
INP is the event loop's cost model seen from the user's side
An interaction can't be handled while a task runs, the handler's synchronous work is itself a task, and the browser can only paint the result between tasks after microtasks drain. INP measures exactly that chain: input delay (thread busy), processing time (handler work), presentation delay (style, layout, paint of the next frame). Every INP fix is really a scheduling fix — shorten tasks, defer work, avoid synchronous layout.
- Input delay comes from a long task occupying the thread when the interaction fires.
- Presentation delay grows when the handler triggers a large synchronous re-render or full-page layout.
- The same run-to-completion rules from the event loop explain every part of the breakdown.
Deep dive 2
Optimize the worst interaction, measured in the field
INP approximates the worst interaction latency over the page's lifetime, because that's what makes a UI feel unreliable — the average hides the one stall users remember. And it must come from real users: lab tools test a handful of interactions on one device profile and miss the slow-device, background-loaded, unusual-interaction cases that actually drive a bad score. Field data attributes INP to specific elements and events so you know what to fix.
- A page that's instant 98% of the time and stalls twice still has poor INP.
- Chrome UX Report or a RUM tool is the authoritative source; Lighthouse INP is a lab estimate.
- Reproduce the field-flagged interaction in the profiler to see where the time goes.
Deep dive 3
Split the handler: immediate feedback now, expensive work later
The pattern that fixes most INP problems is separating the interaction into the minimum needed for visual acknowledgement — a pressed state, a spinner — done and painted immediately, then a yield to the main thread, then the expensive work as a later task. A framework's transition or deferred-update API does the same for large re-renders: render a light response first, process the heavy update without blocking that paint.
- If the handler and the expensive work are one task, nothing paints until both finish.
- Yielding after the feedback lets the browser render that frame before continuing.
- Move DOM-free computation to a Web Worker; DOM and render work must stay on the main thread.
QAInterview questions and model answers
Attempt each answer aloud before opening it. The model answer shows the depth and precision expected in an interview; it is not a script to memorize.
Intermediate · Conceptual · 1 min · Question 1What does Interaction to Next Paint measure?Open model answer
Model answer
The time from a user interaction (click, tap, key press) to the next frame the browser paints reflecting that interaction. It captures input delay before the handler runs, the handler's own processing time, and the presentation delay to render the resulting frame.
Open question page →Intermediate · Conceptual · 1 min · Question 2Why does INP report the worst interaction rather than the average?Open model answer
Model answer
Users remember the janky interaction, not the smooth ones. A page that responds instantly ninety-eight times and stalls for half a second twice feels unreliable, and an average would hide that. INP approximates the worst-case experience over the page's lifetime.
Open question page →Intermediate · Conceptual · 1 min · Question 3What is input delay and what causes it?Open model answer
Model answer
It's the gap between the interaction happening and the event handler starting to run, caused by the main thread being busy with another task — a long render, parsing, a timer callback — that must finish first. Breaking up long tasks is the fix.
Open question page →Advanced · Conceptual · 1 min · Question 4What is presentation delay in the INP breakdown?Open model answer
Model answer
After the handler runs, the browser still has to run style, layout, paint, and compositing to show the result. A handler that triggers a huge synchronous re-render or a layout of the whole page inflates this phase even if the handler's own logic was fast.
Open question page →Advanced · Conceptual · 1 min · Question 5How do you keep an event handler from inflating INP?Open model answer
Model answer
Do only the work needed for immediate visual feedback synchronously, then yield to the main thread so that frame can paint, then run the rest as a separate task. Also avoid forced synchronous layout — writing to the DOM then reading a layout property in the same handler.
Open question page →Advanced · Conceptual · 1 min · Question 6How can a framework's transition or deferred-update API help INP?Open model answer
Model answer
It lets you mark a large state update as non-urgent, so the framework renders an immediate lightweight response to the interaction first and processes the expensive update without blocking that first paint. The interaction feels instant while the heavy work happens after.
Open question page →Intermediate · Conceptual · 1 min · Question 7Why can a good Lighthouse score coexist with poor real-world INP?Open model answer
Model answer
Lighthouse measures a simulated load and a limited set of interactions in a lab. Real users trigger interactions Lighthouse never tests, on slower devices, with more background work, so field data (from the Chrome UX Report or a RUM tool) is the authoritative INP source.
Open question page →Intermediate · Conceptual · 1 min · Question 8What's the relationship between INP and the event loop?Open model answer
Model answer
INP is essentially the event loop's main-thread cost model observed from the user's side: input can't be handled while a task runs, microtasks and rendering are scheduled around tasks, and long tasks delay both the handler and the paint. Understanding task scheduling is understanding INP.
Open question page →Advanced · Conceptual · 1 min · Question 9How do you find which interactions are hurting INP?Open model answer
Model answer
Field tools attribute INP to specific elements and event types. Then reproduce that interaction with the performance panel recording, look for the long task around the interaction, and inspect whether the cost is in the handler, a resulting render, or layout.
Open question page →Intermediate · Conceptual · 1 min · Question 10Does moving work to a Web Worker help INP?Open model answer
Model answer
It can, for pure computation that doesn't need the DOM, because it frees the main thread so the handler and paint aren't blocked. It doesn't help if the expensive part is DOM manipulation or rendering, which must stay on the main thread.
Open question page →SCScenario questions
Scenario 1
A data-heavy table lets users click a column header to sort. On a mid-range phone, the header shows no visual feedback for roughly 400ms after each click, and field data shows INP around 450ms attributed to that interaction.
- Record the interaction in the performance panel and locate the long task.
- Separate the immediate feedback (header active state) from the sort and re-render.
- Paint the feedback, yield, then run the sort.
- Mark the table re-render as a non-urgent transition if the framework supports it.
- Re-measure that specific interaction in the field.
Reveal worked answer
The click handler is sorting thousands of rows and re-rendering the whole table synchronously, so nothing paints — not even the header's pressed state — until all of it finishes, which is the 400ms. I'd split it: update the header's active state and paint that immediately, yield to the main thread, then do the sort. If the framework has a transition API I'd wrap the table re-render in it so the expensive update doesn't block the interaction's first paint. Then I'd confirm with field data that INP for the sort interaction drops back under the good threshold.