Start with a reproducible visitor interaction and its timing breakdown. Reduce the confirmed blocking or rendering work, then verify the complete task and later field results.
If a menu, filter or form feels unresponsive, investigate the interaction itself. Interaction to Next Paint, or INP, concerns how promptly the browser can show a visual response after a click, tap or key press. A fast initial download does not establish that those later actions work well.
This guide explains how to turn an INP warning into a reproducible task, identify which part of the response is delayed and verify a focused repair. It uses official documentation checked on 13 October 2026. The examples are hypothetical; no website performance, traffic or improvement was measured for this article.
Understand what the number represents
The official INP definition covers qualifying interactions throughout a page visit. It usually reflects the slowest interaction, with an outlier adjustment on visits containing many interactions. It is not the average button response, and scrolling or hovering alone does not contribute a qualifying interaction.
For field assessment at the 75th percentile, split by mobile and desktop, an INP of 200 milliseconds or less is good; more than 200 through 500 milliseconds needs improvement; more than 500 milliseconds is poor. These are responsiveness categories, not guaranteed business outcomes or search positions.
The metric stops at the next visual response, rather than waiting for every later effect of an action. A form can show a prompt progress state while a server request is pending. That may be responsive, but the eventual request must still succeed. A frozen button and a slow delivery process are different defects and can occur together.
Read field and laboratory results separately
PageSpeed Insights documentation distinguishes real-user data from Lighthouse’s simulated diagnostics. Its field results represent a trailing 28-day period. Check whether the panel describes the exact URL or the wider origin, and whether you are viewing mobile or desktop.
A good laboratory performance score does not establish that every real reader has a good INP. The test may not have opened the menu, typed into search or used the filter that people encounter later. Conversely, yesterday’s code repair does not immediately replace all experiences in a trailing field-data window.
Total Blocking Time is a laboratory measure of blocking during a defined loading interval. It can help expose work that threatens responsiveness, but it is not an alternative name for INP. Record which measure you actually have rather than describing a low TBT as a measured INP pass.
Do not mistake missing data for a clean bill of health
The Chrome UX Report methodology requires eligible experiences and sufficient popularity; the exact minimum visitor count is not published. Its population does not include every browser or device. A new or lightly visited page may lack field data even when it has an obvious interaction problem.
In that situation, use a recorded visitor journey as a diagnostic starting point. Label the result as a local observation under stated conditions. Do not invent a field percentile or acquire traffic merely to make a report appear.
Browser instrumentation also has limits. Mozilla’s PerformanceEventTiming reference lists the API as newly available across current browsers since December 2025, with older-browser limitations. Its default reporting threshold also means that not every short event appears. A missing entry is not proof of universal responsiveness; check support and collection settings before comparing systems.
Write a task that somebody else can reproduce
For a fictional course website, “the mobile lesson menu is slow” is too broad. A useful task says: open a particular public lesson at the narrow layout, wait for the initial content, tap the lesson-list button once, choose a chapter, close the list, then repeat while the page is still loading.
Record the page address, viewport, device or emulation, browser version, login state, consent state and whether resources were already cached. Note whether the first action differs from later attempts. Those details help distinguish a startup backlog from an expensive menu operation.
- Include the task people actually need: navigation, article search, accordion details or a genuine form-validation step.
- Test a keyboard path as well as a pointer path when the control supports both.
- Keep the chosen consent and login conditions consistent between comparison runs.
- Use safe test data and avoid real purchases, messages or irreversible actions.
Our mobile navigation guide covers menu behaviour and access. Responsiveness testing adds timing evidence; it does not replace those functional checks.
Record the interaction, not just the page load
Chrome’s Performance features reference documents an Interactions track. Start a recording, perform the written task, stop it and select the relevant interaction. Inspect its input delay, processing time and presentation delay, then examine the nearby main-thread work.
Take a short recording with a clear sequence rather than a long, unexplained trace. A trace containing many unrelated actions is harder to interpret. Record visible behaviour too: did the menu appear, did focus move sensibly, and did a second tap accidentally reverse the first?
The runtime-performance tutorial explains recording and CPU throttling. Emulation can help expose expensive work, but it is not a complete substitute for a representative phone. Keep test settings consistent and compare multiple attempts; one unusually quiet recording should not decide the repair.
Use the delay breakdown to choose the next investigation
The INP optimization guide divides an interaction into input delay, handler processing and the delay before the resulting frame is presented. The following worksheet translates those stages into questions for a site owner and maintainer.
| Stage dominating the trace | Question to investigate | Useful evidence |
|---|---|---|
| Before handlers start | What was keeping the main thread busy when the reader acted? | Tasks already running at the input time |
| While handlers run | What work does this gesture trigger, including additional listeners? | Call stacks and functions associated with the action |
| Before the next frame | What styling, layout or rendering is needed to show the result? | Rendering activity after event processing |
Do not blame a component just because its name appears somewhere in the trace. Identify the relevant interval, the actual call path and a reproducible before/after difference. A plugin can participate in a page without causing the observed delay.
Reduce unnecessary work before adding another optimizer
web.dev’s long-task guidance describes main-thread tasks over 50 milliseconds as long tasks. Reducing unnecessary work and splitting suitable jobs can let the browser attend to input between them. A developer must preserve job ordering and state; breaking one operation into asynchronous pieces can introduce new functional bugs.
For the course example, ask whether opening a short lesson list also rebuilds a large hidden index or runs unrelated widgets. Remove work the task does not require, or move nonessential work to an appropriate later point. This is a code and dependency decision, not a reason to enable every available optimization switch.
Present a truthful progress state when a necessary operation takes time. A spinner that never appears until after the expensive work does not help the initial response. A prompt spinner that conceals a failed operation is also inadequate. Verify the feedback and the final result independently.
Investigate expensive layout and oversized page structures
Layout-thrashing guidance explains how repeatedly changing styles and then reading geometry can force synchronous layout. Have the maintainer inspect the relevant code and, where appropriate, group reads before writes. A universal CSS snippet cannot repair an arbitrary interaction handler.
The DOM-size guide also connects large page structures with styling and rendering work. Inspect what the interaction affects rather than assuming that a particular node count always makes a page slow. Simplifying redundant wrappers or unnecessary rendered content can help; removing meaningful content or accessible controls merely to reduce a count can harm the reader.
If the trace points toward a plugin, use a protected test copy and a single controlled change. Follow the plugin audit workflow to preserve dependencies and data. Keep a rollback and retest the feature that the plugin supplies.
Confirm the repair without moving the problem elsewhere
- Repeat the same recorded journey under the same conditions.
- Compare the relevant interaction and its delay stages across several attempts.
- Test the first interaction during loading and ordinary later interactions.
- Check narrow and wide layouts, keyboard access and actual task completion.
- Review related controls for errors introduced by changed script or layout behaviour.
- Record the release date and review subsequent field data when available.
Keep the evidence modest: “this menu responded sooner in these recordings” is more defensible than “all users now pass Core Web Vitals.” A field assessment also includes other metrics and real-user variation.
For a generally slow site, start with the broader WordPress diagnosis. Use this INP workflow when the specific question is why a real action waits before the browser can respond. Fixing that reader task is the goal; a report colour is evidence to interpret, not the whole product.
Sources and verification
Editorial review 2026-10-13. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- web.dev: Interaction to Next PaintChecked Qualifying click/tap/keyboard interactions across a visit, longest-interaction model with outlier adjustment, current 200/500ms categories and next-paint scope.
Limits: No field measurement performed. Not all eventual asynchronous task completion is measured; categories do not establish search or business outcomes. - Google: About PageSpeed InsightsChecked Distinct CrUX field and Lighthouse lab results, trailing 28-day field period, URL/origin and mobile/desktop interpretation.
Limits: No report run and no assumption that a loading score measures all interactions or immediately reflects a new release. - web.dev: Total Blocking TimeChecked Lab blocking measure over a defined interval and relationship to INP as a potential diagnostic proxy, not a replacement.
Limits: No TBT values collected and no implication that a low result proves good real-user INP. - Chrome: CrUX methodologyChecked Eligibility, undisclosed minimum popularity, and a population that does not represent every browser/platform.
Limits: No traffic estimate inferred from absent data; local tests are not field percentiles. - Mozilla: PerformanceEventTimingChecked Newly available Baseline 2025 status since December 2025, older-browser caveat and default event duration reporting threshold.
Limits: Checked current documentation rather than repeating historical limited-availability labels. No custom telemetry installed and no guarantee of identical collection across tools. - Chrome: Performance features referenceChecked Interaction recordings, track selection, input/processing/presentation breakdown and nearby timeline inspection.
Limits: UI can vary by browser version. No trace recorded or exact culprit inferred from a script name. - Chrome: Analyze runtime performanceChecked Manual runtime recordings and controlled CPU-throttling diagnosis.
Limits: The tutorial uses older UI examples; emulation is not a full representative-device test or a universal slowdown prescription. - web.dev: Optimize Interaction to Next PaintChecked Field context, realistic local journeys, and the three interaction-delay stages used to direct investigation.
Limits: The diagnostic worksheet and fictional course journey are editorial synthesis; no maintainer implementation or INP repair was tested. - web.dev: Optimize long tasksChecked Main-thread long tasks over 50ms, blocking and splitting suitable work to allow scheduling opportunities.
Limits: No paste-in scheduling recipe; ordering, state and functional correctness require implementation-specific review. - web.dev: Avoid layout thrashingChecked Forced synchronous layout from interleaved geometry reads/style writes and grouping reads before writes where appropriate.
Limits: No universal CSS or handler fix derived, and no supplied script modified. - web.dev: DOM size and interactivityChecked Relationship of page structure, affected elements and style/layout work during interaction; simplify redundant structure based on profiling.
Limits: No absolute node-count performance guarantee and no recommendation to remove meaningful or accessible content.