Speed monitoring that names the file to remove
Everyone can tell you a page is slow. The useful answer is which of the forty files on it is the reason, and that one has to be read out of the page rather than scored.
What we measure, and what we borrow
This is the one place on this site where the honest answer is that most of the measurement is not ours. The three official metrics come from real browsers, and there is no way to produce them from outside a page. Pretending otherwise would be the easiest claim here to disprove, so the split is stated rather than blurred.
| Reading | Where it comes from | What it is good for |
|---|---|---|
| LCP, INP, CLS | Chrome UX Report, real visitors | Knowing whether the problem is real for people, not just for a test machine. |
| Time to first byte | Measured on every check | Separating a slow server from a heavy page, which are repaired in different places. |
| The causes | Read from the page already downloaded | Knowing which file to change, which no score contains. |
The field data and its deliberate absence without a key are in src/Vitals.php, the causes read from the page in src/Check/Vitals.php, read on 3 August 2026.
No key, no invented number
The field measurement needs a free API key. Without one, the screen shows no LCP rather than an estimate, and that is a decision rather than a limitation. A plausible number in the place where a measurement belongs is worse than an empty space, because nobody checks the space and everybody acts on the number.
What keeps working without a key is the part that tells you what to change: the first byte, and the causes read out of the page. That is already enough to act, which is why the key is optional and not a paywall.
The causes cost no extra request
The availability check has already downloaded the page and, for the layout check, its stylesheets. So the weight of every render-blocking file is known without asking for anything again, and looking for the usual regressions is a matter of reading what is already in hand: an image at the top of the page marked to load lazily, an image without dimensions, a font without a display rule.
That last group is worth naming because they are the ones that come back. They are not mistakes anyone makes once: they arrive with a plugin update, a theme change, or an image uploaded through a different route, months after the page was signed off.
Where the others land on this
If what you want is a thorough performance report, a dedicated tool will beat this comfortably, and several of them are free. They run the page in a real browser, profile the scripts and follow the whole waterfall, which is a different exercise from watching for a regression every day.
The difference here is frequency and place. Speed sits in the same queue as the outages, on the sites you already watch, and it surfaces when a number moves rather than when you remember to run an audit. If you audit every site monthly and act on it, this adds little.
Questions about measuring speed from outside
Do you measure Core Web Vitals yourselves?
No, and nobody honestly can from outside. LCP, INP and CLS come from real Chrome browsers, aggregated by Google in the Chrome UX Report, and there is no calculation that replaces them. We read that report rather than invent a number. Without an API key, which is free and takes two minutes, you get no LCP at all rather than a fabricated one.
What if the site has too little traffic to be in that report?
Then the report says so, and the screen says which source answered. A page with no field data falls back to the origin-level figures where they exist. "Not enough traffic to be measured" is an answer rather than a failure, and printing it is more useful than showing a confident number built on nothing.
If the score comes from Google, what does this add?
The part a score never contains: which file. A score tells you the page is slow; it does not tell you that one stylesheet is 180 kB and blocks rendering, or that the image at the top of the page is marked to load lazily, which delays the very thing the measurement is timing. Those are read out of the page we already downloaded for the availability check, so they cost no extra request.
Does this replace a full performance audit?
It does not, and it is not trying to. An audit runs the page in a browser, follows the whole waterfall and profiles the scripts. This watches, every day, for the four or five regressions that actually happen in production after a deployment: a file that grew, an image that lost its dimensions, a font that lost its display rule. Different job, different frequency.
Why is time to first byte reported separately from the rest?
Because it is the one number that is entirely yours, and the only one that cannot be fixed in the page. Nothing can be painted before the first byte arrives, so it is the floor under every other measurement: a page with a slow server cannot be made fast by removing an image, and knowing which of the two you are looking at saves an afternoon.
See the first byte on a real address
The free check measures the response time and reads the page, so you get the number and the reason in the same answer. One address, no account.