Interaction to Next Paint (INP)
The responsiveness Core Web Vital — and the newest one: it replaced First Input Delay (FID) as a Core Web Vital in March 2024. Where FID measured only the input delay of the first interaction, INP observes latency across all interactions over the page’s whole lifecycle (every click, tap, keypress) and reports a representative high value. Rationale: per web.dev, ~90% of a user’s time on a page is spent after it loads, so ongoing responsiveness matters more than first-paint speed.
Thresholds (field, CrUX)
- Good: ≤ 200 ms
- Needs improvement: 201–500 ms
- Poor: > 500 ms
Three phases
An interaction’s latency decomposes into:
- Input delay — waiting for event handlers to begin (often blocked by other JS).
- Processing duration — running all the event callbacks.
- Presentation delay — time until the browser paints the next frame.
Why it belongs in a page-weight wiki
INP is the metric that makes the wiki’s JS critique sharper: page-weight showed JS is the largest-and-growing request type (~613 KB, per web-almanac-page-weight-2024), and INP is where that JS is felt — “JavaScript is the primary driver of interactivity,” so a heavy main thread inflates input delay and processing time directly. It reframes the wiki’s bytes thesis: cutting bundle-size helps not only load (LCP) but responsiveness (INP). It also reinforces the lab-vs-field caveat — INP is a field (CrUX) metric, hard to fully capture in a lab run since it needs real interactions. A clean partial answer to the open question “does the 14 KB floor matter for interactive apps?”: for apps, the binding constraint shifts from transfer bytes toward main-thread execution, which is exactly what INP measures.
Related
core-web-vitals · page-weight · bundle-size · web-almanac-page-weight-2024 · lighthouse · squint