09/02/2026
Measure it in a real browser
Three cases from one project where a confident number turned out to describe something other than the thing being measured. All three were found the same way: by going and looking directly instead of trusting the report.
Three measurements worth distrusting
A render delay that did not exist
Reported at 2,061ms by a simulated network model; the real browser showed no gap to explain at all.
A library ignoring the font it was given
Output with the site typeface embedded was statistically identical to output with nothing embedded.
A contrast failure that was a misreading
A 2.84:1 result on live text, from testing the light-theme color against the dark background.
A render delay that did not exist
PageSpeed Insights reported a 2,061ms element render delay on a page's largest contentful paint. That is a large number and it points somewhere specific — the element was found early and painted late, so something was blocking the paint.
Opening the same page in a real browser with the performance panel recording showed first contentful paint and largest contentful paint at the same millisecond. There was no gap to explain.
The reason is that PageSpeed's mobile scores come from a simulated network model rather than a real throttled load. The simulation is genuinely useful for comparing runs, and it does not describe what a browser did. The real cost on that page was a render-blocking stylesheet, which measured 476ms directly and was fixed by inlining it.
The practical rule: treat a lab score as a signal that something is worth investigating, and never as the description of what happened.
A library that ignored the font it was given
Generating social cards meant drawing text in the site's own typeface. The
short route is an SVG rendered through sharp, which is already a
dependency on most image pipelines.
The first render looked plausible. Text appeared, in a sans-serif, at the right size. The suspicious part was that embedding the site's actual woff2 as a data URI produced output with identical statistics to the version that had not embedded anything.
Rendering the same string four ways settled it:
sans-serif 59.866
SiteFont + @font-face 59.866
NoSuchFontXYZ 59.866
serif 59.866
Four different font declarations, including one naming a font that does not
exist, produced byte-identical images. The renderer ignores
font-family entirely and draws everything in one built-in face. No
error, no warning, and output that looks correct until you compare it with
something.
The cards are now rendered in a real headless browser, which loads the site's self-hosted font because it is a browser and that is what browsers do.
A contrast failure that was a misreading
The third case is the one worth admitting to, because the error was in the measurement rather than the tool.
Checking color contrast across a set of section colors turned up one at 2.84:1 against a dark background — a clear WCAG failure on live text. It was reported as a real bug.
It was not. The value being tested was the light-theme color; the dark theme redefines that token, and the actual dark value scores 6.77:1. Every color in the set passed, and the stated ratios in the stylesheet's own comment had been right all along.
The failure mode there is subtle: the calculation was correct, the threshold was correct, and the input was quietly from the wrong place. A measurement is only as good as its knowledge of what it is measuring — and a number that is computed correctly from the wrong value looks exactly like a number computed correctly from the right one.
What the three have in common
In each case a number was produced by something trustworthy and described something other than the question being asked. A simulation rather than a load. A default font rather than the requested one. One theme's value rather than the other's.
None of these is caught by being more careful with the tool. They are caught by checking the result against the thing itself — the browser's own timeline, two renders compared, the stylesheet block that actually applies.