Interaction to Next Paint
also called INP
Definition
How long a page takes to respond visibly after a visitor interacts with it.
How it's calculated
Read from the product's weighted summary measure, which is already expressed in SECONDS, the semantic layer divides the underlying millisecond measurement by a thousand before exposing it, and the product renders that value unchanged with a seconds suffix. There is no further conversion anywhere: the display projection only rounds to two decimal places, and grading is applied to the same seconds value, bucketing at 0.2 and 0.5 seconds.
Scope, grain and dimensions
- Grain
- One number per date range, optionally split by device, or one row per page.
- Dimensions
- page · device
- Required filters
- date_range
- Aggregation
- The headline is the weighted summary measure read without a page dimension; page-level values are used only for distributions and worst-page evidence.
- Metric type
- score · seconds
Data sources
Where you'll see this
Named reports that normally include this metric.
Skills and analyses that use it
Skills carry the judgment; the analysis verbs do the reading.
Analysis verbs
site_health_cwv_check
Method rungs and levers
This sits on the bottom rung: if it reads badly, every measurement above it is unreliable.
levers L1 Technical & crawl health
Ask Quattr
- "What is our INP?" Simulate this →
- "Are pages responsive to interaction?" Simulate this →
How to read it
Responsiveness rather than load speed. Read it against the 0.2 and 0.5 second bands, the standard Core Web Vitals thresholds, expressed in the same seconds the value arrives in, and read the grade beside the number. The threshold VALUES are recorded in code as pending confirmation for this product specifically, this vital most of all, with a note that observed pages have tended to land in the poor band.
Caveats, freshness and failure modes
Seconds, end to end. The value is not a Lighthouse sub-score and is not milliseconds: a reading of 0.62 is 0.62 seconds, and multiplying or dividing it by a hundred anywhere is a hundredfold error. An earlier version of this product treated the same value as an internal hundredths-of-a-second score and labelled the result milliseconds; that is the bug the current scale replaces.
The grading thresholds are the standard Core Web Vitals bands and are flagged in code as pending product-specific confirmation, this vital most of all.
These are lab measurements, not field data from real visitors.
Collection cadence varies by site and by page.
In trend mode the per-bucket values are returned ungraded, the good, needs-improvement and poor bands are not applied to a time series.
- Freshness
- varies by site, priority URLs can run nightly; most pages far less often. The collection date rides on the card rather than being assumed.
Common failure modes
- Rescaling the value before grading or quoting it, it is already in the unit the thresholds are expressed in.
- Reporting it in milliseconds, which invites a hundredfold slip in either direction.
- Reading a poor grade as a confirmed product problem when the thresholds are still pending confirmation.
Not the same as
The confusions that cause the most wrong decisions.
Interaction to Next Paint Vital grade Compare definitions →
The number is a weighted average; the grade is the band it lands in. Score and verdict stay separate on every vital.
Watch this metric read in a real run
All runs →
Related metrics and workflows
Verification
A definition is the smallest part of this.
The measurement matters because something acts on it. Here is the rest of the showcase, in the order most people find useful.