Lab data will tell you it is fine

You have a number now: an INP for the stop button, taken in your own browser, under throttling, written into MEASUREMENTS.md. Suppose it was 480ms. Poor, by the threshold.

Now run Lighthouse against the same page. Performance: 96. Green ring, no responsiveness warnings, LCP and CLS both fine. Two instruments, same page, contradictory verdicts — and the one that looks more official, that produces a shareable artifact with a number in a circle, is the one that is wrong about your users.

This is not a bug and not a calibration problem. Lighthouse’s default performance score does not contain INP at all. It cannot disagree with your measurement, because it never took one.

What the Lighthouse performance score is actually made of

Chrome’s own performance scoring documentation gives the composition for Lighthouse 10:

• Total Blocking Time — 30%
• Largest Contentful Paint — 25%
• Cumulative Layout Shift — 25%
• First Contentful Paint — 10%
• Speed Index — 10%

Five metrics. INP is not among them, and does not appear anywhere on that page. Four of the five are load-time metrics; the fifth, Total Blocking Time, is the responsiveness stand-in, and the same page describes it as measuring “how much time a page is blocked from responding to user inputs.”

Read that definition against a stream. TBT is computed over the page load window — it is a load metric wearing responsiveness vocabulary. Your stream begins after that window has closed, in response to a prompt the user typed, on a page Lighthouse has already finished scoring. Thirty percent of your score is a proxy for a property of a period of time in which your streaming code has not run.

Lighthouse is not incapable — it is being asked the wrong question

Be precise about the accusation, because the imprecise version is easy to refute. Lighthouse can measure INP. Chrome’s INP tool support post (17 May 2022) states that the timespan mode report “now includes INP and an audit to help diagnose any responsiveness issues.” Timespan mode records while you interact, rather than analysing a cold page load, and the user-flows article describes navigation mode as the standard behaviour of analysing “the cold load of a page.”

So the real statement is narrower and more useful: the thing everyone runs — navigation mode, the big score, the number in CI — does not include INP, and the mode that does include it is one nobody runs by default because it requires someone to sit there and interact. Your 96 is not a lie. It is a correct answer to “how did this page load,” being read as an answer to “how does this page respond.”

Why a lab test cannot fix this by trying harder

The obvious response is to automate the interaction — script a click on the stop button, run it in CI, get a lab INP. Worth doing, and it still will not substitute for field data. web.dev’s lab-versus-field article puts the limit plainly: “Lab tests, even those that support script user behavior, cannot accurately predict when users will choose to interact with a page.”

When is the whole game for a streaming surface. A scripted click at token 5, while the transcript is short and the main thread is merely busy, produces a completely different number from a real user’s click at token 900, when the DOM is large, forty markdown blocks have been re-parsed, and memory pressure has started to bite. You get to choose the moment in the lab. Your users choose it in the field, and they choose it precisely when they are most annoyed, which correlates with the stream having been going on the longest.

The same article names two specific holes in TBT as an INP proxy: it does not consider tap delay, and it does not consider user behaviour — so a page can have poor INP while showing good TBT. That is not a hypothetical for you. That is the exact shape of your failure.

What field data is, and what it costs to get

Field data means measurements from real users on real devices. There are two ways to get it, and they are not interchangeable.

CrUX: free, public, and not yours to shape

The Chrome User Experience Report is, in Google’s description, a dataset reflecting “how real-world Chrome users experience popular destinations on the web.” The lab-versus-field article describes it as a distribution of performance metrics from real Chrome users over a 28-day period, with field scores taken at the 75th percentile — the same percentile the thresholds are defined at.

Two eligibility filters decide whether you get any data at all, and both matter for the kind of work you are heading into. CrUX’s methodology page lists the user-side criteria: the user must have usage statistic reporting enabled, be syncing their browser history, have no sync passphrase set, and be on desktop Chrome (Windows, macOS, ChromeOS or Linux) or Android Chrome. No Safari. No Firefox. No signed-out users. No one with a sync passphrase.

And on the site side, the CrUX overview states that origins and pages must be “publicly discoverable and there must be a large enough number of visitors in order to create a statistically significant dataset.” That sentence removes most of the surfaces you are about to build. An agentic panel inside an authenticated B2B application is not publicly discoverable. It will never appear in CrUX, at any traffic volume.

RUM: yours, and the only option that works behind a login

Real user monitoring means you collect it yourself — the onINP call from the previous lesson, reporting to an endpoint instead of the console. It works on authenticated pages, it works in every browser that implements the underlying Event Timing API, it can carry your own dimensions (which host product, which model, how long the stream ran), and it is the only field instrument available for most of what you are going to ship.

The costs are real and worth stating rather than glossing. You are adding a beacon to somebody else’s page, which is a privacy and payload conversation with the host team before it is a technical one. Browser coverage is not uniform — the Event Timing API only reached Baseline in December 2025, so your dataset skews toward recently updated browsers. And you need enough sessions for a 75th percentile to mean anything; a p75 computed over eleven sessions is a decoration.

What this does not cover

Knowing that INP is the number and that it has to come from the field tells you nothing about which part of your code is spending it. The profiling lesson does that: recording a trace while the stream is running, reading the interactions track to find the phase, then the flame chart to find the function, with CPU throttling set so the failure is reproducible on hardware far too fast to feel it unaided.

Standing up a real RUM pipeline — a beacon endpoint, sampling, dimensions, alerting on a p75 regression — is deliberately out of scope here. This course stops at the number and the method that produces it. What lands in the budget reference is a threshold and how it is measured, not the telemetry plumbing that would carry it in production.