Zero of 445 audits report render-blocking resources. Of the ones we re-read, 78% still block the render

A field that thinned instead of emptying

Every audit we run stores what PageSpeed Insights said was worth fixing: a handful of named audits, each with an estimated saving. For as long as we had been running audits those records looked the same, and then they started getting shorter. No field went empty, no request failed, no error was logged. The records simply carried less.

That is the failure mode worth naming, because it is the one nothing catches. A pipeline that breaks announces itself. A pipeline that keeps working on a narrower slice of the truth returns a page with fewer problems on it, which is indistinguishable from a page with fewer problems.

What changed at the other end

Lighthouse 13 replaced the Opportunities and Diagnostics sections with Insights. The announcement was explicit about what that would cost anyone reading the JSON: after this time, the old audit data will no longer be available. Some audits were renamed, some were merged, and, in Google’s own words, “in some cases advice from many audits is consolidated into a single insight, and we have retired some advice.”

The six keys we had been reading map onto that reorganisation in three different ways:

Classic audit	What it became
render-blocking-resources	render-blocking-insight
modern-image-formats, uses-responsive-images	folded into image-delivery-insight
uses-text-compression	folded into document-latency-insight
prioritize-lcp-image	folded into lcp-discovery-insight
offscreen-images	retired, with no successor

Only the first is a rename. Three are merges, where several old audits now arrive as one insight, and one is a deletion on the grounds that the advice stopped mattering: “Offscreen images are already deprioritized by the browser so while lazy loading helps reduce bandwidth, it is unlikely to have an impact on what Lighthouse measures.”

One response, counted twice

Our selector accepted an audit if its details.type was opportunity. That was never a statement about what mattered on the page; it was a statement about how Lighthouse packaged its output, and we had written it down as though the two were the same thing.

On one mobile response from our base, eight audits reported a saving. The old rule returned two of them — unused-javascript and unused-css-rules, which kept the old packaging. The six it discarded:

Audit	Reported saving	Why it was invisible
render-blocking-insight	LCP 900 ms, FCP 900 ms	details.type is table
cache-insight	LCP 750 ms	table
layout-shifts	CLS 0.058	table
long-tasks, bootup-time, mainthread-work-breakdown	TBT 600 ms	table

Nothing here was missing from the response. It arrived, in full, and was dropped on the way into storage — by us.

What the base looked like mid-migration

We changed the rule to something that does not encode a version of Lighthouse: an audit is a hint if it reports a saving anywhere — the old overallSavings fields, or the new metricSavings, which reports estimated time per metric instead of one aggregate number.

On 2026-08-19 the base held both readings at once, because re-measurement had only reached part of it:

	Audits	Median hints carrying a saving
Read with the old selector	335	2
Re-read by saving	110	9

Both columns describe Lighthouse 13 responses. The only difference between them is which of our own two selectors wrote the record, so the jump from 2 to 9 is not a finding about sites at all. It is the size of what we were throwing away.

And in those 110 records, render-blocking-insight appears 86 times — 78%. The audit whose classic key appears zero times in our entire base is present, under its new name, on nearly four out of five sites we have looked at again.

Why the zero says nothing about the pages

The honest reading of “0 of 445” is narrow, and worth stating precisely: our storage no longer holds a single record written before the migration. Rolling re-measurement overwrote them. So the zero is not the moment a problem vanished from the web — it is the shape of an archive that was rebuilt during a rename, and it would look identical whether those pages block the render or not. The 86 out of 110 is what tells us which of the two it is.

We publish this the same way we publish the rest of our misses, because a measuring tool reporting its own blind spot is the only kind of report on that subject anyone ever gets. The data did not go missing. It went unread, in a system whose entire purpose is producing numbers we ask people to trust.

If you parse PageSpeed yourself

Three things we would do differently, in order of how much they would have saved us.

Select on the substance, not on the container. “Has a reported saving” survives a rename; details.type === 'opportunity' is a claim about the current major version that your code never rechecks. Every list of audit IDs hardcoded anywhere is the same bet with the same expiry.

Store the raw response, or accept that your history is unrepairable. We kept our parse and discarded the original, so the 335 older records cannot be re-read — only re-measured. That is a cheap decision to reverse today and an impossible one to reverse afterwards.

Alert on hints getting thinner, not on hints going missing. Nine against two is what the same responses yield under two readings, and no check on “is the field there” can see a gap of that shape — the field is there in both. A threshold on the median number of hints per audit can, and it is one line.