Google’s 2026 Core Web Vitals update didn’t change what counts as a good score — it changed the plumbing underneath Interaction to Next Paint, refining how sustained interaction latency gets measured on input-heavy pages, and it started aggregating performance across an entire domain rather than judging each page in isolation. A site can have plenty of individually fast pages and still take a ranking hit, because a meaningful share of poor-performing URLs now drags the whole domain’s score down. Field data from real Chrome users also carries more weight than lab data, evaluated at the 75th percentile — so a page that feels fast in a controlled test can still fail if a quarter of real visitors experience it as sluggish.
The practical risk is that teams keep monitoring INP the way they always have — one page at a time, mostly from lab tools — and miss both the site-wide aggregation effect and the shift toward field data. A handful of genuinely slow templates (a product listing page, a checkout step, a comment thread) can now suppress rankings on pages that never had a performance problem of their own, and nothing in a single-page Lighthouse report will surface that.
Data Points to Track
- INP at the 75th percentile, per template/page type: not an average, and not per individual page — grouped by the templates that share layout and interaction patterns, since that’s how the aggregate scoring behaves
- Pass/fail rate across the full URL set: the percentage of indexed pages falling into “Poor” or “Needs Improvement” for INP, tracked as a single domain-wide number
- Interaction type breakdown: INP split by the interaction that triggered it (tap, key press, click) and by element type, to localise which components are driving slow responses
- Field vs. lab delta: the gap between Chrome UX Report field data and your own Lighthouse/synthetic lab measurements for the same pages, to catch cases where lab testing is misleadingly optimistic
- Long task and input-delay contributors: JavaScript execution blocking the main thread during the interaction window, tagged by the script or component responsible
Setup Steps
- Pull Core Web Vitals field data from Search Console and CrUX rather than relying on lab-only Lighthouse runs, since field data now carries more ranking weight and is measured at the 75th percentile of real users.
- Group pages by template, not URL, when computing pass/fail rates — the site-wide aggregate is what’s being scored, so a slow checkout template affects every page on that template, not just one.
- Instrument real-user INP measurement (via the Event Timing API or your analytics SDK’s built-in Web Vitals support) so you have your own first-party field data, not just what CrUX eventually surfaces.
- Set an alert threshold on the domain-wide “Poor + Needs Improvement” percentage, since crossing roughly 25% of URLs is where the aggregate penalty is understood to kick in.
- Profile long tasks on the specific interactions flagged as slow, using browser performance traces to attribute delay to a script, a re-render, or a layout thrash rather than guessing at the cause.
Actionable Insights
Because scoring now aggregates across the domain, the highest-leverage fix is usually the single worst-performing template, not the page with the worst individual score — improving one shared component (a product grid, a navigation menu, a comment widget) can move the pass rate for every page built on it. Widening field-vs-lab deltas are worth investigating on their own: they usually mean your lab testing environment doesn’t reflect the device and network conditions of your real user base, which means every optimisation validated only in the lab is flying blind on actual impact.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert