The stopwatch test

Performance scores are useful the way a thermometer is useful. They give you a number, the number moves in the right direction when things improve, and you can put it in a dashboard. They are also a proxy, and after a while teams start optimising the proxy.

I have watched a site go from 71 to 96 on a well-known audit tool while getting measurably slower for the people using it. Nobody cheated. The work was real. It was simply aimed at the metric rather than at the experience, and the metric was a weighted average of five lab measurements taken on a simulated device on a simulated network.

The test

Pick up a phone. Not the newest one — the one in the drawer, three years old, on cellular rather than the office network. Open the page. Count out loud until you can read the first sentence of the actual content.

That is the number. It is not precise, it does not go in a dashboard, and it is the truest signal you will get all week, because it contains every factor the lab quietly excluded: the cold cache, the real DNS lookup, the CPU throttling because the phone is warm, the ad blocker, the captive portal, the fact that your reader is on a train.

Do it before you start work and after you finish. If the count did not go down, whatever you did was not a performance improvement, whatever the score says.

Three numbers worth keeping

The stopwatch tells you whether things got better. When they did not, you need to know where the time went, and for that three measurements do most of the work.

• Time to first byte. How long before the server said anything. This is DNS, connection, TLS, and your application's own thinking time. If it is bad, nothing you do in the browser will save you.
• First contentful paint. When something — anything — appeared. The gap between this and TTFB is what your document is doing to itself: blocking stylesheets, blocking scripts, fonts, layout.
• Time until it is readable. Nobody standardised this one, which is exactly why it matters. It is the stopwatch number, and it is the only one your reader experiences.

Two of the three you can capture without a service:

curl -s -o /dev/null \
  -w 'dns %{time_namelookup}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n' \
  https://example.com/

Lab data lies consistently, field data lies randomly

Both are worth having. A lab run is reproducible, so it is good for catching regressions: same device profile, same network shape, same page, run it on every deploy and alert when it moves. It cannot tell you what your users experience, because it is not your users.

Field data — timings collected from real sessions — can. It is noisy, it needs volume before the percentiles mean anything, and you should read the 75th and 95th rather than the median, because the median is the reader who was going to be fine anyway. The slow tail is where people give up.

The habit

None of this requires a budget. Keep the old phone charged. Run the curl one-liner in the deploy log. Once a month, load the site somewhere with bad signal and try to use it in a hurry. Write the number down.

A score tells you how you did against a rubric. The stopwatch tells you how long someone waited.