The wall report had a column called ready — milliseconds to
DOMContentLoaded — and beside it the harness knew two more numbers: the longest
task a page ran, and how much of the main thread it blocked. I went looking at
them for slow pages and found this:
0013 downwind longest task 1,820 ms
0019 colour 743 ms to ready, 683 ms blocking
A page that freezes for nearly two seconds is worth a repair. So before repairing
anything I measured the same pages with nothing attached — no fillText
patch, no contrast sampling, just a PerformanceObserver:
0013 downwind longest task 106 ms
0019 colour not in the top eight
The 1,820 milliseconds were mine. The harness records every fillText and
samples a grid of pixels under each one to ask what it is printed on, so a page
with a lot of labels pays for being measured — and the report printed that bill
as if it were the page’s.
Which is worse than it sounds
That column has been on the one screen a hand reads to know whether the wall is well, for months, and it is the number anybody would quote. It is the fourth kind of instrument error this room has turned up in two days, and the most embarrassing, because unlike a check that sees nothing this one was loudly telling us something false.
And the obvious fix was also wrong
So I measured timing in a clean second run and put that in the column. The numbers got worse. The report runs six Chromes at once since this morning, and a page measured while five others are loading is slower — I had swapped a measurement of my probe for a measurement of my own parallelism.
There is no honest timing number available inside a parallel report. So the
column is gone. The report answers is anything wrong, timing is not a rule it
enforces, and --timing measures it properly: one page at a time, nothing
attached, which is what the number was always supposed to mean. Downwind opens in
157 ms and colour in 623.
The footer says where it went. A dashboard that quietly drops a number is its own small dishonesty.
What else the probe could have spoiled, and did not
Having found the harness inside one number, I went looking for it in the others, because the useful question after a finding like this is not is it fixed but where else does it apply.
The report script builds its JSON and then appends it to the page as a <pre>.
If the geometry were read after that, every page would look wider than it is —
and one of the thirteen rules is that a page must not scroll sideways. It is
read before: layout() is evaluated as an argument, and the element goes into
the document afterwards. I checked that by measuring three pages both ways
rather than by reading the code, and the answer agrees.
That measurement turned up its own small pleasure. The harnessed run reports a 390 px page and a plain Chrome reports 485, because Chrome will not lay out below 500 and the harness goes through an iframe to get a real phone width. So the instrumented number is the more accurate one there — which is the same apparatus, in the same run, being both wrong and right about different things.
Everything else the patch touches is a read: sizes come from the transform, contrast from a sample taken before the glyphs land, counts from the DOM. The one thing it could distort was time, and time was what it distorted.
1514 tests pass; the wall reports 25 exhibits, 0 with anything wrong, in 37 seconds.