Why PageWeight's image and third-party checks were wrong for five weeks
On July 1, 2026, we fixed a bug where PageWeight's image-optimization and third-party-script sections were silently empty on every single scan — reporting a clean bill of health regardless of the actual page. The stranger part: the code that shipped with this bug was only five weeks old. The audit IDs it relied on had already stopped existing in Google's live API seven months before we wrote it.
What changed in the PageSpeed Insights API
Google's Lighthouse 13 (GA October 2025) replaced a set of standalone "byte efficiency" audits with consolidated insight audits. The old audit IDs — things like uses-webp-images, uses-optimized-images, and third-party-summary — stopped being returned by the API. According to PageSpeed Insights' own release notes, the change went live in the API on October 20, 2025.
Critically, this isn't a breaking change in the sense of an error or a 4xx response. The API still returns 200 OK with a full JSON payload — it just no longer contains the keys older integrations expect. Any code checking audits["uses-webp-images"] gets back nothing, which most parsing logic (including ours) interprets as "no issues found."
How PageWeight ended up already behind on day one
PageWeight's /analyze endpoint was written on May 29, 2026 — roughly seven months after Lighthouse 13's audit IDs had already gone live in production. The endpoint was new. The bug wasn't a regression that crept in over time; the code was already reading a shape of API response that hadn't existed since the previous October. It just happened to fail silently instead of loudly, so nothing about running it locally or in production surfaced the problem. Every scan for the next five weeks reported the image section as optimized and the third-party section as empty, independent of what the page actually contained.
The fix
Lighthouse 13's replacement audits, mapped from what we were reading before to what the API actually returns now:
| Old audit ID | Current audit ID | Notes |
|---|---|---|
uses-webp-images / uses-optimized-images |
image-delivery-insight |
Drop-in compatible item shape: wastedBytes / totalBytes / url |
third-party-summary |
third-parties-insight |
Field renamed: blockingTime → mainThreadTime |
render-blocking-resources |
render-blocking-insight |
|
uses-long-cache-ttl |
cache-insight |
|
dom-size |
dom-size-insight |
Three audits we were also reading — uses-text-compression, efficient-animated-content, and uses-rel-preconnect — have no equivalent in the new insight-based output. We dropped them rather than guess at a replacement.
How we verified it, not just patched and hoped
Before shipping the fix, we ran the same real URL through both the old and new parsing code side by side: the old code produced empty image and third-party sections, the new code produced fully populated ones. After deploying, we re-ran a real scan against a large, well-known site and confirmed the third-party section correctly listed its actual third-party scripts — output the old code was structurally incapable of producing, which ruled out any ambiguity about whether the fix had actually taken effect in production.
If you run your own PageSpeed Insights integration
If you have code — a CI check, an internal dashboard, a plugin, a monitoring script — that parses raw PSI or Lighthouse audit IDs and was written or last touched before this migration was on your radar, there's a real chance it's returning a clean report on categories it can no longer see. It won't error. It will just look fine. The only way to know is to run a page you know has real image or third-party bloat through it and check whether it still gets flagged.