Quick answer: Almost every website publishes one speed number, and almost none of them say where that number came from. Ours said 0.36 seconds. When we measured it properly, we got 0.0197 seconds when the page was cached and 0.4765 seconds when it was not — and the 0.36 was neither of those. The number was not wrong when we published it. It was true for exactly one day, from one machine, in one cache state. This post is about what a speed score actually measures, the mistake we made with ours, and the three questions you can answer in about ten minutes on a site you already own.
If you have ever looked at a score out of 100 on PageSpeed Insights, wondered why the same site scores differently twice in one afternoon, or paid someone to “fix” a speed number that was never broken — this one is for you.
Our homepage advertises a performance figure: Page load time (median TTFB) 0.36s, with a note that we are under a 0.5s ninety-day target. It is on the page right now. You can read it on our homepage if you want to check.
That number is a measurement, not a decoration. It was taken, it was real, and for a while it was accurate. But it was taken once, on one day, and — this is the part we got wrong — it was never labelled with which measurement it was. There is more than one perfectly respectable way to time a page, and they disagree by an order of magnitude.
Tools like PageSpeed Insights run what is called a lab test. A computer loads your page under controlled, simulated conditions: a throttled connection meant to imitate a mid-range phone, a fixed location, a cold cache, one single visit. Then it grades the load.
That is useful for engineers. A controlled test lets you compare before and after a change. But it is not a measurement of your real visitors. Your real visitors arrive on different phones, different networks, in different towns, many of them with your pages already cached from a previous visit. None of that is in the lab number. Google’s own documentation separates the two: the lab test is diagnostic data, while the field data collected from real Chrome users over 28 days is what actually represents your visitors [2].
The deeper problem is that the two are usually collapsed into a single number on a single page. Time to first byte is not page load time, and neither one is a Core Web Vitals score. Google defines the Core Web Vitals set as LCP, INP and CLS [2], and Time to First Byte is the foundation underneath them — the time before the server starts answering [1]. Publish one figure and you have published a claim about a metric you never named.
Here is what our own site measured this morning, using the same method every day for four days. We timed the same page two ways: with a cache buster on every request (so the edge could not serve a stored copy — the uncached population) and with no buster at all (so the edge served a stored copy — the cached population).
Here is what that looks like when you measure the two populations separately instead of averaging them together:
Same site. Same server. Same page. Same morning. A factor of roughly 24 between the two medians.
Which one is “your” speed? If you are selling a hosting plan, the cached number is a fair proxy for a returning visitor and a poor one for a first-time visitor. If you are running a paid ad, the uncached number is closer to what a stranger experiences. If you are diagnosing a specific slow page, you want the uncached number and a look at where the time goes. You cannot answer any of those questions with one number that does not say which population it came from.
1. It changes between runs. Run the same test on the same unchanged page three times and you can get three different scores. Server load, network conditions, and which third-party scripts happened to respond slowly all move the result. A number that wobbles ten points on its own is not a measurement — it is a sample.
2. It tests a cold cache; your regulars have a warm one. The lab test visits like a stranger, every time. Repeat visitors — often the ones closest to buying — load a much faster version of your site from their browser cache. The score grades the stranger’s worst case and calls it your speed.
3. It tests from somewhere your customers are not. The test runs from a data center that may be on the other side of the country from your visitors. Distance is time. A site hosted and delivered close to Central Washington customers can feel fast here and still score poorly in a test run from far away.
4. It grades what it can see, not what matters. The score has little to say about whether the page feels responsive once it loads — whether buttons react, whether the layout jumps around while someone is trying to read. Those are separate metrics, and a page can score well while still feeling broken. Lighthouse, the engine underneath most of these scores, reports performance, accessibility, best-practices and SEO as separate audits precisely because they do not move together [5].
5. It can be gamed, and the game costs you. There are tricks that inflate a lab score — deferring everything, stripping scripts the test does not like — that do nothing for real visitors, or actively hurt them. Chasing 100 is how owners end up paying to make a number prettier while the actual site gets worse.
We monitor our own site’s speed, because it would be embarrassing not to. One morning the reported number moved — a lot — and nothing on the site had changed. No new plugins, no new pages, no deploy. Same site, same server, wildly different verdict.
What moved was the measurement, not the site. Our server’s own response time did not budge once across four days of measurements — it sat in the same 0.33 to 0.67 second band whether the page was fast or slow. What changed was the path between the machine doing the measuring and the edge serving the request: our connection time dropped from roughly 118 milliseconds to about 3, on every one of our own sites at once, while a control site hosted elsewhere did not move.
Here is the whole arc, measured the same way every morning:
Nothing in that list is a fix we made. We changed no code. We removed no plugin. The origin was never the problem and never changed — only the path to it did.
For two days we published explanations of what we thought had happened, and we were wrong twice: first that the edge had changed its routing, then that the route level had changed. We only got it right on the third day, when we looked at a property we had been ignoring.
Two rules came out of it, and they are free:
If we had reacted the way most owners react — panic, hire someone, rip out features, chase the score back up — we would have spent real money fixing a problem that did not exist, and possibly broken things that were working. The correct response to a moving number is to check whether the site actually changed before you change the site.
Field data. PageSpeed Insights also shows data from real visitors over the past 28 days (the Core Web Vitals assessment). That is slower to update, but it is the truth: real phones, real networks, real people. If your field data is passing, a bad lab run is weather, not climate.
Time to first byte. How fast your server starts answering. This is the foundation everything else sits on, and it is mostly a hosting quality question — which is exactly why it is worth measuring against a control site rather than against your own last result. A slow TTFB cannot be plugin-fixed away [1].
The three vitals that matter. LCP (how fast the main content appears), INP (how fast the page reacts when someone taps or clicks), and CLS (whether things jump around while loading). Passing all three, measured from real users, beats a vanity score every time.
Your own phone, on cellular, away from your office Wi-Fi. Load your site the way a customer in a parking lot in Moses Lake would. If it feels fast and works, that is data. If it feels slow, no green score should talk you out of believing your own eyes.
Pick a page you own — your homepage, or your most important landing page — and answer these. If you can answer all three, you already know more about your site than most score badges tell you.
When the field data says there is a real problem, the fixes are unglamorous: decent hosting with a fast first response, caching set up correctly so repeat visits are instant, images sized for the web instead of uploaded straight from a camera, third-party scripts (chat widgets, trackers, embeds) audited and cut down to the ones earning their keep, and a plugin list that gets reviewed instead of growing forever. None of that is a score trick. All of it shows up in how the site feels to the person holding the phone.
And when you do publish a performance number, publish it properly: say which population it came from, say when you measured it, and say how you measured it. A number with those three details attached is worth ten times a bare one — because a reader can tell whether it applies to them. Ours will carry that labelling from now on, including the 0.36s we have been publishing without it.
This is the hundredth consecutive morning of our daily audit. Same dashboard, same cron, same 09:00 UTC read, every day — which is the only reason the four-day arc above is something we can show instead of something we vaguely remember.
The audit pattern is the deliverable. A number on a webpage is a snapshot; a system that measures the same thing the same way every single day is what tells you whether the snapshot means anything. It is also how we caught the other thing this month — our blog index was a hardcoded list rather than a real archive, so six published articles, including our best-performing one, were invisible to anyone browsing our own site. Google had them indexed. Our own index did not. Same bug class as the speed number: a thing that looks automated and isn’t.
If you want a straight answer about how fast your site actually is — from real-visitor data, not a single lab run — that is a check we run for local businesses all the time. Get in touch and we will tell you what the numbers really say, including when the answer is “your site is fine.” If you want to read more of how we work, start with the Learning Center or the studio blog.
Gorden Web Design & Computer Repair ·
223 W 3rd Ave, Moses Lake, WA 98837 · (509) 230-4576 · Mon-Fri 9:00am-5:00pm