Interaction to Next Paint (INP) measures responsiveness when a user interacts with a page. It has been a Core Web Vital since March 2024, when it replaced FID, as Google's launch post explains. A fast initial load does not prove that searching, filtering, or submitting a form remains responsive.
Google Search Central recommends good Core Web Vitals as part of page experience. Its guidance uses 2.5 seconds for LCP, 200 milliseconds for INP, and 0.1 for CLS. Use your own field measurements to prioritize work rather than assume a universal 2026 ranking change or a fixed percentage regression.
Match the measurement to the interaction
A lab test runs under controlled conditions and is useful for diagnosis. It does not represent every user, device or interaction. Compare lab measurements with field data rather than treating a green homepage audit as complete responsiveness coverage.
Search Console groups similar URLs and reports the 75th percentile of each metric over the last 28 days. A group’s overall status follows its worst metric; this is not a count of sessions passing all three metrics simultaneously. Aggregated field data can lag a recent change.
The two instruments you actually need
You need two things running, not one audit run occasionally.
Instrument one: field performance and production telemetry. Use CrUX, Search Console or your own real-user instrumentation for field INP. The TestVibe .NET telemetry agent reports server/process metrics and application errors; it does not automatically measure browser INP or JavaScript exceptions. The telemetry and monitoring guide explains that integration.
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, generate and verify selected journeys, then run them in representative browser configurations through automations. Drafts can be visible before generation completes. A functional assertion can pass despite a slow interaction, so add an explicit performance budget or dedicated measurement. Artifacts depend on run configuration and retention.
Field measurements, server telemetry and synthetic checks answer different questions. Compare them around the same release and time window.
INP is a coverage problem
Interaction-heavy surfaces such as search, exports and settings deserve deliberate measurement. Search Console grouping can expose shared problems, but do not assume every untested page is slow.
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 interaction coverage. Drive search, filters, forms, and other interaction-heavy surfaces, not just initial page loads.
- Schedule real-browser runs on every surface, with explicit performance checks where needed; functional coverage alone is not a latency gate.
- 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 after changes. Compare field data with your own baseline and use traces to locate slow interactions.
Keep interaction performance under continuous measurement: know the important surfaces, watch real-user data, and drive representative journeys before release.
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.