What is Interaction to Next Paint (INP)?

What does Interaction to Next Paint measure?

Interaction to Next Paint measures how promptly a page can present a frame after a qualifying user interaction. It covers the delay before event handling, the handling work, and the wait for presentation. It does not measure every eventual network or business outcome, so diagnose the visible response separately from completion of the entire customer task.

• Google’s INP definition, accessed October 8, 2026, describes the metric’s use of interaction timing across a page visit.

  Mouse clicks, touch taps, and keyboard actions are relevant categories. Scrolling and hovering alone are not the same qualifying interactions, even though they can affect the customer’s experience.

• A service-booking button illustrates the distinction.

  The interface can quickly indicate that the request is being processed while a later operation completes. Prompt feedback tells the customer the action registered. It does not prove that the booking succeeded, and the interface must still communicate the eventual result accurately.

• The metric concerns responsiveness throughout the visit rather than only startup.

  A page can load visibly and later become sluggish when a menu, filter, or form performs extensive work. Inspect the actual interaction and its timing rather than assuming that a fast initial load establishes responsive controls.

• A useful diagnosis connects a slow frame with its cause.

  The event handler may be short while unrelated work prevents it from starting. Alternatively, the handler can finish but leave expensive rendering before the result appears. Those cases need different repairs, even when the customer sees the same apparent delay.

How should a good INP result be interpreted?

Interpret a good result using the documented field threshold and the relevant distribution of observed page visits. One responsive interaction in a local test cannot establish that the page is consistently responsive for real visitors. Keep device group, measurement scope, and interaction coverage visible when deciding whether a problem exists or a repair has improved the observed experience.

• Google’s INP guidance, accessed October 8, 2026, recommends 200 milliseconds or less at the 75th percentile of field page loads, separated across mobile and desktop.

  These are documented evaluation criteria, not observed timing data or a success claim for the service website being discussed.

• A visit usually reports its slowest qualifying interaction.

  Google’s INP definition, accessed October 8, 2026, excludes one highest interaction for every 50 interactions to handle outliers in longer visits. That per-visit calculation differs from the 75th-percentile field aggregation across visits. Neither value is the average latency of every button pressed.

• A percentile summary does not say that every visitor experienced the same result.

  Less responsive experiences can remain beyond the reported point. Device capability, page state, and the actions people choose can differ. Those variations need appropriate evidence rather than an unsupported claim that one score describes every customer.

Why can a page have no reported INP value?

A page can have no reported value when the visit contains no qualifying interaction or the available dataset cannot supply the relevant observation. That absence is not a perfect responsiveness result. Identify measurement coverage and the actual actions performed before claiming that a page is fast or that a laboratory tool failed to detect a problem.

• Google’s INP definition describes visits involving only reading, scrolling, or other unmeasured gestures.

  A crawler that retrieves a page without scripted interactions may also produce no meaningful INP observation. A page-load test alone therefore cannot establish how its controls respond when used.

• If a lab session never opens the menu or submits a test form, it has not measured those paths.

  Add representative controlled interactions where appropriate. Use the application’s safe test arrangement for transactional flows rather than creating real bookings merely to obtain a metric.

• Public field datasets can also lack sufficient information at the requested URL scope.

  An origin result may be available instead. Read that scope explicitly; do not attach the origin’s summary to a particular page as though its own visits were independently observed and reported at that level.

• Missing data calls for a limited conclusion.

  The page may be responsive, unresponsive, or simply unobserved in the relevant context. Suitable real-user instrumentation and targeted lab interactions can help resolve the uncertainty. Fabricating a timing or presenting an empty report as proof of success provides no useful diagnosis.

How should field evidence locate the slow interaction?

Field evidence should locate the interaction type, page state, and relevant timing where the measurement arrangement supports that attribution. A high aggregate value establishes a symptom within its scope, but it does not identify the responsible control automatically. Use contextual observations to choose a reproduction case instead of optimizing whichever button is easiest to find.

• Google’s INP optimization guide recommends starting with real-user evidence where available.

  PageSpeed Insights can expose qualifying public field summaries, while suitable site-owned measurement can supply additional interaction context. Neither source should be described as providing details it does not actually contain.

• An advice page’s navigation menu can differ from a booking page’s validation flow.

  Grouping both into an unexplained site-wide average can obscure the problem. Inspect the page or template and the actual action associated with slow observations where that evidence exists, then reproduce the relevant state in the laboratory.

• Timing relative to loading also matters.

  A menu click during startup can contend with script evaluation. The same click later may respond promptly. A control used after a large filter operation can encounter different background work. Preserve that state instead of testing only a quiet page after all activity ends.

• Collect only appropriate diagnostic information.

  The useful evidence is the interaction and responsible work, not customers’ private form contents. Measurement design should identify the performance issue without publishing sensitive inputs or claiming firsthand findings when no such observations were collected for the website.

How can a slow interaction be reproduced in the laboratory?

Reproduce a slow interaction by matching the relevant page state and action as closely as the available evidence allows, then recording the event and rendering trace. A general page-load run is insufficient. Note the tested device conditions and sequence, because a control can respond differently during startup, after data changes, or on a less capable environment.

• Google’s optimization guide recommends testing common flows when field attribution is unavailable and interacting during loading where relevant.

  Those tests can identify plausible issues, but they do not prove how often real customers experience them. Keep diagnostic reproduction separate from population-level conclusions.

• Open the actual public route and perform the relevant controlled action.

  Record whether earlier steps are needed to reach the state. For a filter, that can include an existing selection or expanded result set. For a menu, direct entry during startup can differ from returning after the interface is fully initialized.

• Inspect the trace around the interaction rather than only reading its final value.

  Identify when input arrived, when callbacks began, when they ended, and when the next frame could appear. The sequence can reveal work outside the handler that still blocks the customer-visible response.

• Repeat where needed to establish the mechanism rather than cherry-pick a favorable run.

  Record changes in conditions that explain variation. A slower simulated device can help expose blocking work, but its value should not be presented as an observed real-customer metric unless suitable field evidence supports that interpretation.

How do input delay, processing time, and presentation delay differ?

These phases distinguish waiting to begin the interaction, executing its callbacks, and presenting the following frame. Diagnose the phase that contains the observed delay before selecting a technique. An expensive handler, unrelated startup task, and large rendering update can all produce sluggish feedback while requiring different implementation changes to make the actual interface responsive.

What should be investigated when input delay is large?

A large input delay calls for investigation of work occupying the main thread before the interaction can begin. The responsible task may not belong to the clicked control. Startup script evaluation, data handling, timers, and overlapping actions can contend with input, so inspect the preceding trace instead of rewriting the event handler without evidence.

• Google’s input-delay guidance explains that fetched scripts still require parsing, compilation, and execution.

  Finishing a network download does not make that work disappear. A visible page can therefore remain busy with startup tasks while a customer already attempts to use its menu or form.

• Review unnecessary startup work and dependency boundaries.

  A reporting feature may initialize before it is needed. A large optional component may run during a simple navigation action. Determine which work is essential at that moment rather than removing every third-party or application script indiscriminately and breaking required behavior.

• Check repeated actions where the interface appeared unresponsive.

  Several clicks can queue work and produce an unexpected final state once processing catches up. The immediate feedback and action-handling policy both matter. Do not treat customer repetition as the underlying cause without examining why the first action appeared to do nothing.

• After a targeted change, test the originally busy state.

  Waiting until all tasks finish can conceal the condition the repair should address. Confirm that essential startup behavior remains correct and that input begins promptly under comparable conditions. The result needs timing evidence rather than a declaration that the bundle became smaller.

How can event handlers provide prompt feedback without skipping required work?

An event handler can provide prompt feedback by performing the work needed for the next visible state first and deferring appropriate noncritical work. Preserve correctness and required ordering. A status indicator should communicate the actual operation, not falsely announce success before validation or submission finishes, and delayed work must still complete safely for the customer task.

• Google’s callback-optimization guidance discusses breaking work into tasks and allowing rendering after necessary visual updates.

  The point is to avoid blocking the next frame with unrelated work. It is not a universal instruction to insert timers randomly or postpone essential validation without understanding the flow.

• An illustrative booking action can show that processing started while a network request continues.

  The final confirmation appears only after the application’s result is known. This separates immediate acknowledgement from eventual completion. A spinner that masks a failed request indefinitely does not represent a complete usable interaction.

• Review side effects and state changes before splitting a handler.

  A later task may depend on data that changes after another interaction. Preserve required values and ordering through the implementation’s actual state model. A shorter handler can introduce race conditions if deferred work assumes the interface remained unchanged.

• Test completion, failure, and repeated-use paths after the change.

  The control should remain understandable and the final result accurate. The immediate timing can improve while later work still fails, so record those as separate observations rather than claiming the customer task was repaired solely because feedback appeared sooner.

Why can layout work make the next frame late?

Layout work can make the next frame late when an interaction triggers expensive style calculation, geometry updates, or forced synchronous layout. Inspect the trace and the changed document region. The processing and presentation phases can both be affected, so distinguish JavaScript execution from browser rendering work before choosing a repair for the visible delay.

• Google’s layout guidance within INP optimization describes layout thrashing: writing styles and then immediately reading geometry can force work earlier than otherwise needed.

  Repeated read-write cycles can compound that cost. Identify the actual access pattern rather than assuming every style change is a performance defect.

• Review whether measurements can be gathered before mutations and whether updates can be grouped safely.

  A component that changes many nodes individually may cause repeated work. A targeted update can be more appropriate than rebuilding a large region. The correct choice depends on the needed output and framework behavior, not one universal code pattern.

• Large result collections can increase rendering work after filters or expansions.

  Pagination or other suitable collection strategies can limit the amount displayed, but they also need accessible continuation and correct membership. Hiding necessary information merely to reduce work is not a complete interface solution.

• Retest layout and controls after the change.

  Cumulative Layout Shift measures a different stability concern. A faster update that moves controls unexpectedly can still harm the customer experience. Do not infer visual stability from a responsiveness improvement; inspect the affected layout under the relevant interaction.

How do large DOM updates and client-side HTML affect responsiveness?

Large DOM updates and client-side HTML can affect responsiveness because the browser must process the generated structure and render its result. A short data request does not establish a cheap visual update. Inspect the amount and timing of work performed after the response, especially when a filter or navigation action replaces a substantial document region.

• Google’s INP optimization guide discusses DOM size and client-generated HTML costs.

  Server-streamed markup and a large client-side insertion have different processing paths. This does not mean every client-rendered component is wrong; the issue is the observed work that blocks feedback in the relevant interaction.

• Check whether the update includes information outside the current task.

  A narrow selection change may rebuild an entire result view unnecessarily. A component can retain stable regions and update only what changed where the implementation supports that safely. Verify behavior rather than assuming a framework automatically minimizes every mutation.

• Offscreen rendering techniques can be considered with suitable testing.

  The optimization guide discusses content-visibility as one option. Its application needs review of the actual content and interaction requirements. Do not adopt it as a substitute for accurate navigation or assume it removes all layout work under every condition.

Why can embedded widgets make field and site-owned measurements disagree?

Embedded widgets can make measurements disagree because interactions inside frames contribute to the user’s page experience while a top-level measurement script may not have access to every frame’s contents. Identify the browsing context containing the slow action. A booking or video widget can be relevant even when the surrounding page’s own controls appear responsive.

• Google’s INP definition describes iframe interactions and limits of page-script access.

  Public field observations and a site-owned real-user arrangement may therefore have different visibility into those interactions. A difference does not automatically prove that either report is broken or that one metric should be discarded.

• An embedded booking control may use its own scripts and rendering context.

  Inspect where the event occurs and which thread or dependency is responsible. A trace focused only on the parent component can miss that work. Use available evidence appropriate to the actual widget rather than attributing every delay to the site’s navigation code.

• Third-party ownership can limit direct repair options.

  Confirm supported integration choices and the observed behavior before replacing the provider or making broad performance claims. A loading configuration, unnecessary embed, or alternative flow may be reviewable, but the right change depends on real functional requirements and available implementation control.

• Validate the customer path after any change.

  Removing a slow widget can also remove the only working booking route. Offer a suitable replacement where that decision is justified. A better parent-page number alone does not demonstrate that visitors can still complete the service task the embed originally supported.

How is INP different from loading metrics and server response time?

INP concerns responsiveness to qualifying actions, while loading metrics concern the arrival and display of the page’s content. Server response time describes another part of delivery. These signals can share causes but answer different questions, so a favorable value in one should not be treated as proof that the other experience is acceptable or fully diagnosed.

How should an INP repair be verified and reported?

Verify an INP repair by reproducing the relevant interaction under known conditions, checking which timing phase improved, and confirming the task still behaves correctly. Then review appropriate field evidence when available. A faster controlled action demonstrates its tested result, while population-level responsiveness and business outcomes require their own observations rather than assumptions from the code change.

• Google’s optimization guidance describes identifying slow actions, reproducing them, and addressing the responsible work.

  Keep the post-change comparison tied to that diagnosis. If conditions or page state changed, record the difference instead of attributing every favorable timing to the repair automatically.

• Illustrative repair, not client data.

  A service filter rebuilds a large result list before acknowledging a selection. The developer limits the immediate update to necessary feedback and makes the remaining work appropriately scheduled. The trace checks processing and presentation separately, while functional testing verifies correct membership and final state.

• Test repeated selections and failure conditions relevant to the actual flow.

  Deferred work must not overwrite a newer choice or leave a misleading pending indicator. The immediate frame and eventual result are both part of the usable interface, even though their measurement questions differ.

• Report the observed interaction, conditions, phase, and remaining limits.

  The useful conclusion is an evidence-based explanation of why feedback was delayed and what now changes in the verified customer path.