The common assumption is that a poor INP score means most interactions on your site are slow. When the median is good but the 75th percentile fails, that assumption is wrong. It means the majority of interactions are fine, but a specific subset of interactions — or a specific subset of users — experiences significantly worse responsiveness. This long-tail pattern requires a different diagnostic approach than broad INP failure. Instead of optimizing the general interaction pipeline, you need to identify which interactions, on which pages, for which user segments produce the outlier durations that drag the 75th percentile past the 200ms threshold.
Why the 75th Percentile Exposes Problems the Median Hides
CrUX evaluates INP at the 75th percentile, meaning 75% of observed interaction experiences must fall under 200ms for a “good” assessment. When the median (50th percentile) is under 200ms but the 75th percentile exceeds it, between 25% and 50% of all observed interactions exceed the threshold. This distribution shape points to a bimodal pattern: one population of fast interactions and a distinct second population of slow interactions.
The bimodal pattern emerges from several structural causes. Different interaction types on the same page have vastly different processing costs — a navigation click completes in 30ms while a faceted filter toggle takes 350ms. Different pages within the same origin have different interaction complexity — the homepage is responsive while the product comparison page is sluggish. Different user populations experience different hardware constraints — users on flagship devices complete the same interaction in 100ms that takes 400ms on a budget Android device.
INP itself uses a near-worst-case selection: for pages with 50 or more interactions, it reports the 98th percentile interaction duration (excluding the absolute worst as an outlier). CrUX then evaluates this per-page INP value at the 75th percentile across all page views. The combination means the reported INP reflects the worst interaction for 75% of sessions. If 30% of sessions involve a particular slow interaction that other sessions do not trigger, that interaction defines the CrUX INP even though 70% of sessions are unaffected.
Understanding this percentile stacking is essential for correct diagnosis. A “poor INP” at the 75th percentile does not mean the site is broadly unresponsive. It means a specific intersection of interaction type, page template, and user conditions produces durations that pull the distribution’s tail past the threshold.
Per-Interaction RUM Attribution and Interaction Type Segmentation
The web-vitals JavaScript library’s onINP callback with attribution provides the specific interaction that determined each page view’s INP score. The attribution data includes:
- The interaction target (the DOM element that received the event, reported as a CSS selector)
- The interaction event type (click, keydown, pointerdown)
- The timing breakdown: input delay, processing time, and presentation delay as separate values
- The Long Animation Frame (LoAF) entries that overlap the interaction, providing script attribution
Logging this data to an analytics pipeline for every page view creates the dataset needed for systematic diagnosis. The critical fields to capture alongside the INP attribution are: page URL or template identifier, navigator.deviceMemory, navigator.hardwareConcurrency, navigator.connection.effectiveType, and the timestamp relative to page load. This combination enables segmentation across all three dimensions that produce long-tail patterns: interaction type, page context, and user environment.
Without per-interaction attribution, diagnosis is guesswork. CrUX confirms the 75th percentile INP value but provides no information about which interactions or user segments are responsible. The attribution build of the web-vitals library is the bridge from aggregate metric confirmation to actionable root-cause identification.
The Chrome team’s documentation on Long Animation Frames (LoAF) provides additional script-level attribution. LoAF entries report which scripts executed during the interaction, how long each script ran, and whether third-party scripts contributed to the processing time. This granularity distinguishes first-party handler performance from third-party interference.
Query the RUM dataset to identify patterns in the outlier interactions. Two analytical cuts provide the highest diagnostic value:
By interaction target: Group all INP-contributing interactions by their target element selector. If 80% of outlier interactions (those exceeding 200ms) share the same target — a specific filter checkbox, a dropdown menu trigger, a search input, a modal open button — the problem is isolated to that component’s event handler. The processing time sub-component will dominate the total duration, confirming that the handler itself is the bottleneck.
By page template: Group outlier interactions by page URL pattern or template identifier. If outliers concentrate on specific page types (product listing pages, dashboard views, search results pages), the problem is architectural — the page’s overall DOM complexity, JavaScript payload, or framework rendering cost creates slow interactions across all interactive elements on that template. In this case, the processing time and presentation delay sub-components will both be elevated, because both the handler execution and the subsequent layout/paint operations are slow.
The distinction between these two patterns determines the optimization strategy. A component-specific problem requires refactoring one event handler. A template-level problem requires reducing the page’s DOM surface area, JavaScript execution cost, or framework rendering overhead. Applying the wrong fix — optimizing a single handler when the entire page is congested, or restructuring the page architecture when one handler is the sole culprit — wastes engineering effort without moving the metric.
A third pattern exists: outlier interactions are distributed across many targets and many pages but cluster on a specific subset of user sessions. This indicates an environment-driven long tail rather than a code-driven one, which requires the device and network segmentation described in the next step.
Step 3: Cross-Reference with Device and Network Segments
If the interaction type distribution is roughly uniform across fast and slow interaction populations, the differentiating factor is the user’s hardware and network environment, not the interaction itself. Segmenting the outlier dataset by navigator.deviceMemory and navigator.connection.effectiveType reveals whether the long tail is driven by device capability.
Mid-tier Android devices with 2-4GB RAM and Snapdragon 600-series or MediaTek Helio chipsets frequently show 2-3x longer processing times for identical event handlers compared to flagship devices. A filter handler that completes in 120ms on a Pixel 8 takes 350ms on a Samsung Galaxy A14. The handler code is identical; the hardware’s JavaScript execution speed differs by a factor sufficient to push the interaction past the 200ms threshold.
Network conditions compound device-tier effects when interactions trigger network requests (search suggestions, live filtering with server-side queries). A 150ms handler combined with a 200ms API round trip on a 3G connection produces a total INP of 350ms, while the same interaction on Wi-Fi completes in 200ms total.
When device tier is the primary long-tail driver, optimization must target execution efficiency specifically for the slow hardware. Reducing the number of DOM nodes mutated during the interaction, using virtual scrolling to limit rendering scope, breaking the handler into yielding segments with scheduler.yield(), and offloading computation to web workers are the techniques that compress the long tail. These optimizations may have minimal visible effect on fast devices where the interaction already passes but deliver significant reductions on the slow devices that define the 75th percentile.
Practical Limits of Long-Tail INP Optimization
Eliminating all outlier interactions is not feasible when the long tail is driven by genuine hardware diversity in the user base. A site serving users across a range from flagship to budget Android devices will always have a distribution where some percentage of interactions on the slowest hardware exceeds 200ms. The achievable goal is compressing the outlier distribution enough that the 75th percentile falls below the threshold, which may mean accepting that 10-15% of interactions on the slowest devices still exceed 200ms.
The strategies with the highest impact on long-tail compression include:
scheduler.yield() to break long handlers into chunks that allow the browser to paint between processing segments. This reduces the measured interaction duration because INP captures from input to next paint — if the first paint occurs after a fast initial processing chunk, the remaining work runs after the INP measurement window.
Virtual scrolling for any interaction that mutates a large list. Rendering only the visible viewport plus a buffer limits DOM mutations to 10-30 elements regardless of the total result set size. On mid-tier devices, this reduces processing and presentation delay by 40-60%.
Web worker offloading for computation-heavy operations like client-side filtering, sorting, and data transformation. Moving these operations off the main thread eliminates their contribution to processing time entirely.
AbortController for canceling superseded work when a user interacts faster than the handler completes. Rapid filter toggling should not accumulate processing for intermediate states.
These techniques are not mutually exclusive and typically deliver the largest improvement when combined. The monitoring feedback loop — deploying the optimization, observing the 75th percentile INP in RUM data over 2-4 weeks, and identifying the next set of outlier interactions — drives iterative improvement toward consistent compliance.
Does improving the median INP reliably pull down the 75th percentile score?
Not necessarily. When the 75th percentile is poor but the median is good, the problem concentrates in specific interactions, device segments, or page states that the median population does not encounter. Fixing the median experience addresses the common case, but the 75th percentile requires targeting the long-tail scenarios, such as slow interactions on low-end devices or complex UI states that only a subset of users triggers.
Can A/B testing frameworks inflate INP at the 75th percentile without affecting the median?
Yes. A/B testing scripts that evaluate experiment assignments during interaction handlers add processing time to every interaction. On fast devices, this overhead stays below the 200ms threshold. On slower devices at the 75th percentile, the same overhead pushes interactions past the threshold. Moving experiment evaluation to idle time or pre-computing assignments during page load eliminates this interaction-time cost.
Does the Long Animation Frames API help identify which specific interactions cause 75th percentile INP failures?
Yes. The Long Animation Frames (LoAF) API reports per-frame script attribution, including the source URL and function name of scripts executing during each frame. Correlating LoAF entries with INP attribution data from the web-vitals library identifies which scripts and handlers produce the longest interaction durations. Filtering this data to the 75th percentile segment reveals the specific code paths responsible for long-tail failures.
