Interaction to Next Paint (INP)

Technical Deep Dive & Specifications

What Interactions Count Toward INP?

The Event Timing API tracks discrete user interactions requiring JavaScript event dispatch and UI rendering:

+-------------------------------------------------------------------------------+
|                           INP INTERACTION ELIGIBILITY                         |
+-------------------------------------------------------------------------------+
|  ELIGIBLE FOR INP:                                                            |
|    ├── Mouse clicking a button, link, or custom interactive widget            |
|    ├── Tapping on a mobile touchscreen element                                |
|    └── Pressing keys inside a text input, textarea, or keyboard-navigated UI  |
|                                                                               |
|  EXCLUDED FROM INP:                                                           |
|    ├── Scrolling or swiping a long feed (handled by GPU compositor thread)    |
|    ├── Mouse hover / pointer movements across screen elements                 |
|    └── Pinching, zooming, or OS window resizing                              |
+-------------------------------------------------------------------------------+

The 3 Sub-Parts of Interaction Latency

An interaction begins the microsecond the user physically touches hardware and concludes only when the browser paints the resulting pixels to the screen. This journey is divided into three sequential sub-parts:

User Action                                                                      Display Updated
(Finger Tap)                                                                     (Pixels Rendered)
    │                                                                                   ▲
    ▼                                                                                   │
┌───────────────────────┬───────────────────────────────┬───────────────────────────────┐
│   1. INPUT DELAY      │    2. PROCESSING DURATION     │    3. PRESENTATION DELAY      │
│ (Wait on Main Thread) │ (Execute JavaScript Handlers) │ (Style + Layout + Paint + GPU)│
└───────────────────────┴───────────────────────────────┴───────────────────────────────┘

1. Input Delay ($T_{\text{input}}$)

The time between the physical user action and when the browser's main thread is actually free to begin executing the first registered event handler callback.

• Root Cause: Long-running tasks, heavy garbage collection, or background third-party analytics running on the main thread when the user interacts.

2. Processing Duration ($T_{\text{process}}$)

The cumulative execution time spent running all synchronous JavaScript event listener callbacks associated with that interaction (pointerdown $\rightarrow$ pointerup $\rightarrow$ click).

• Root Cause: Complex client-side algorithms, synchronous DOM queries, large array filtering, or heavy state management updates.

3. Presentation Delay ($T_{\text{present}}$)

The time between when JavaScript execution finishes and when the browser calculates style recalculation, layout reflow, rasterization, and commits the composite frame to the GPU display buffer.

• Root Cause: Massive DOM size, recalculating styles across thousands of nodes, forced synchronous layouts, or complex CSS filter repaints.

$$\text{Total Interaction Latency} = T_{\text{input}} + T_{\text{process}} + T_{\text{present}}$$

The Session-Level INP Calculation Algorithm

How does the browser pick a single INP number for a session with hundreds of clicks?

1. Low-Interaction Sessions ($< 50$ interactions): $$\text{Session INP} = \max(\text{All Interaction Latencies})$$ The absolute highest latency observed during the visit is the INP.

2. High-Interaction Sessions ($\ge 50$ interactions): To prevent unusual, single-frame OS hardware hiccups from skewing telemetry, the algorithm discards 1 outlier per every 50 interactions. $$\text{INP Value} = 98\text{th Percentile of Interactions}$$

   • For example, if a user performs $100$ interactions, the worst $1$ is ignored, and the $2\text{nd}$ worst interaction becomes the reported INP.

Total Interactions: 100
[ 12ms, 15ms, 18ms, ... 180ms, 195ms ]  [ 210ms (98th % - INP) ]  [ 950ms (Discarded Outlier) ]
                                                    ▲
                                                    │
                                           REPORTED SESSION INP

💻 Interactive Code Playground

Starter Code

Line-by-Line Code Breakdown

• Lines 55–60 (slow-btn handler): Uses a synchronous while loop to hold the main thread hostage for $250\text{ ms}$, creating an immediate $250\text{ ms}+$ Processing Duration bottleneck.
• Lines 63–87 (PerformanceObserver): Observes entries of type 'event'.
• Line 66 (if (!entry.interactionId) continue;): Filters specifically for interactions assigned an interactionId by the Chromium engine (distinguishing key/pointer events from passive lifecycle events).
• Lines 68–71 (Sub-part arithmetic):
  • inputDelay = entry.processingStart - entry.startTime
  • processingTime = entry.processingEnd - entry.processingStart
  • presentationDelay = entry.startTime + entry.duration - entry.processingEnd
• Line 87 (durationThreshold: 16): Captures all interactions exceeding $16\text{ ms}$ (one display refresh frame).

Expected Browser Render Output

[Interaction Captured: pointerdown]
• Target Node: <BUTTON> (ID: #slow-btn)
• Total Duration: 268.4 ms (FAIL >200ms)
  ├── 1. Input Delay: 2.1 ms
  ├── 2. Processing Time: 251.2 ms
  └── 3. Presentation Delay: 15.1 ms