Sending INP as an event
Interaction to Next Paint (INP) is a Core Web Vitals metric for responsiveness: it reflects the latency of interactions across the page's life, reporting a representative worst interaction. You capture it from the Event Timing API (or web-vitals) and send it as an event with the value as a parameter. INP replaced First Input Delay as the responsiveness Web Vital; it is a documented signal you report under your own event name.
How INP is captured
INP draws on the Event Timing API, which exposes interaction latencies; the web-vitals library aggregates them and reports a representative value (web.dev). Rather than the first interaction (the older FID), INP considers interactions throughout the visit and surfaces a near-worst-case latency. You then send that number as an event parameter alongside the page identifier.
Why INP replaced FID
First Input Delay only measured the delay before the first interaction's handler began. INP captures full interaction latency — input delay, processing, and presentation — across all interactions, so it better reflects sustained responsiveness. Aggregating field INP by template highlights pages with heavy handlers or main-thread contention. Treat published INP thresholds as current, revisable guidance, not a fixed fact to assert.
- Built on the Event Timing API
- Considers many interactions, not just the first (unlike FID)
- Captures input delay, processing, and presentation time
How it appears in analytics and logs
High INP on a page means interactions feel sluggish — long event handlers or main-thread work delay the next paint after a tap, click, or keypress.
Diagnostic use case
Measure real-user responsiveness per template by capturing interaction latencies and sending a representative INP value as an event parameter.
What WebmasterID can help detect
WebmasterID can record field INP as a first-party performance event keyed to a page or template, with no cookies and no per-visitor profiling.
Common mistakes
- Assuming INP equals the old FID.
- Reporting lab INP as representative of real users.
- Citing a threshold as permanent rather than current guidance.
Privacy and accuracy notes
INP is an interaction-latency number tied to a page, not a person. Send the value and page context only; never attach identity to the timing.
Related pages
- Sending LCP as an event
Largest Contentful Paint (LCP) is a Core Web Vitals metric for perceived load speed: the render time of the largest content element in the viewport. To analyse it per page you capture LCP via PerformanceObserver (or the web-vitals library) and send it as an event with the value as a parameter. It is a real performance signal, not a GA4-named event, so the event name and parameter are yours to define.
- Sending CLS as an event
Cumulative Layout Shift (CLS) is a Core Web Vitals metric for visual stability: the sum of unexpected layout-shift scores during the page's life, bucketed into session windows. You capture it from the layout-shift PerformanceObserver entries (or web-vitals) and send it as an event with the score as a parameter. It is a genuine UX signal, defined by a documented formula, that you report under your own event name.
- Tracking Core Web Vitals as events
Core Web Vitals — Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift — are field performance metrics you can record as analytics events. Google's open-source web-vitals JavaScript library measures them in real browsers and hands you a value and an id you can send as a custom GA4 event. This page covers what each metric means and how to model it as an event without any personal data.
- Website observability
Record real-user responsiveness per template.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.