For years Largest Contentful Paint got all the attention, because it was the easy one to see and the easy one to fix. Interaction to Next Paint — the lag between a user's tap and the next frame the page paints back — got less, because it only shows up when a real person interacts with a real page under real conditions. That's a problem, because INP is the Core Web Vital your users are most likely failing. Across origins, about 78% pass LCP and 84% pass CLS, but only 72% pass INP. It's the weakest of the three and the hardest to catch in a lab.
The 2026 Core Web Vitals update didn't reshape the ranking math as much as the headlines suggested — Core Web Vitals remain a page-experience signal, the published thresholds didn't move, and the update didn't hand INP new ranking weight. What it did do was tighten how INP is measured: the methodology now better captures sustained interaction latency on input-heavy pages, and sites that re-measured after the change saw their p75 INP land 18 to 25 percent worse than their late-2025 baseline — without a single line of code changing. The finish line didn't move; the stopwatch got honest.
Lab numbers lie about interaction
Most teams answer a Core Web Vitals scare by opening Lighthouse, running it against the homepage, getting a green score, and calling it handled. Lighthouse is a synthetic lab test on one page from one machine. It cannot simulate a distracted user hammering a button while the main thread is busy hydrating — which is exactly the condition that produces a bad INP. Google grades on field data, not lab data, and the two routinely disagree.
Field data also arrives late. Search Console rolls real-user sessions up into URL groups, and a group shows green only when at least 75% of its real-user sessions hit "Good" on all three metrics, measured over a trailing window counted in weeks. By the time a regression accumulates enough sessions to clear that window and surface in Search Console, it has been live for a while. Waiting for the field number to move is waiting to find out you already shipped the problem.
The two instruments you actually need
You need two things running, not one audit run occasionally.
Instrument one: production telemetry. TestVibe telemetry captures production JavaScript errors with context and charts server-side vitals — CPU, memory, active sessions, GC heap — over time, right next to your test results. It will not hand you a field INP number; the authoritative field measurement still comes from the Chrome UX Report and Search Console. What it catches is the wreckage that rides along with a heavy front end: a component that throws under load, a bundle whose memory climbs run over run, a server pinned at its CPU ceiling while latency drifts up. Errors are grouped and persisted, so you can review what fired during a run long after it finished, and a captured error opens straight into a Debug-with-AI flow. The telemetry and monitoring guide walks through wiring the agent in with one package and one line at startup.
Instrument two: scheduled synthetic runs against real browsers. This is the main event. The code changes that wreck INP and LCP are behavioral — a newly added blocking third-party script, a component that now hydrates on the critical path, a lazy-load that quietly stopped being lazy. None of those are visible to a protocol-level check. They surface when a real Chromium instance walks the actual journey and the interaction that used to be instant now stalls, or the assertion times out waiting on a page that's busy doing render work. In TestVibe you describe the flow in plain language, the generated Playwright test is verified against a live run of your app before you ever see it, and it runs in an isolated cloud sandbox with the screenshot, video, and trace attached when it fails. Schedule those runs with automations so every meaningful surface gets driven nightly, and use multi-browser and multi-viewport configurations so a desktop-only regression doesn't hide behind a mobile pass.
The division of labor is clean. Telemetry watches production and catches what you didn't test. Synthetic runs catch the regression in the build, before production ever sees it. Monitoring and testing are the same loop — each one feeds the other, and neither closes the gap alone.
INP is a coverage problem
The pages that fail INP are almost never the ones you re-test. They're the interaction-heavy surfaces nobody thinks about: the admin panel, the export screen, the account-settings deep-link, the legacy report that predates the current front-end framework and still ships jQuery from another era. And because Search Console grades URL groups on 75% of real sessions, a cluster of slow, interaction-heavy pages can keep an entire group out of the green — so the surface you forgot about doesn't just fail on its own, it holds back the ones next to it.
Which turns the question from "is the homepage fast" into "what is every surface in my app, and which ones is nobody driving." That's a coverage question, and it's the one teams are worst at answering. TestVibe's coverage mapping reads your source, infers the route-grounded areas your app is actually made of, and lines your existing tests up against them, so the surfaces with nothing watching them rise to the top. Walk that map, find the interaction-heavy areas with nothing next to them, and point a scheduled run at each one. The forgotten pages are the ones that hurt you, precisely because they're forgotten.
The playbook, condensed
- Prioritize INP coverage. It's the vital most sites fail — 72% pass, against 78% for LCP and 84% for CLS. Drive your interaction-heavy surfaces synthetically, not just your landing pages.
- Schedule real-browser runs on every surface, so the code change that slows an interaction fails a test before it reaches users.
- Wire telemetry into production for the errors and capacity problems that accompany a heavy front end — and read them next to your test results, not in a separate tab.
- Re-measure INP under the tightened methodology. Sites that re-measured saw p75 land 18–25% worse than their late-2025 baseline, worst on listing pages, search results, and dashboards. Yesterday's green is not today's green.
The 2026 update didn't rewrite how Google ranks you. It tightened the bar and put a spotlight on the vital your app is most likely failing — the one a lab run on your best page will never show you. The discipline that keeps interaction fast is coverage and continuous measurement: know your whole surface, watch it from production, and drive it synthetically before it ships.
Want scheduled real-browser runs across every surface plus telemetry next to your results, instead of one Lighthouse pass on the page you remember? Get early access, or read the telemetry and monitoring guide to see how the agent wires in.