Unjamming the Chrome Releases Blog

For the second time in a row, a post by cr0w on Mastodon regarding the Chrome release blog appearing to not render anything resulted in me firing up lynx to show a sub-second load and render, then finally doing something a bit more tangible about the situation.

The 81-Second Wall

The Google Blogger pages load an ancient copy of jQuery (1.11.3, from 2015) synchronously in the <head>, alongside a 53KB widgets.js Blogger framework. Then, posts like this one — https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html — stuff 433 CVE entries into the DOM — 670KB of HTML, 5,045 nodes. The Blogger WidgetManager processes all of that against the DOM using jQuery’s notoriously slow selector engine, and the main thread stays locked for 81 seconds. Nothing else runs. Not even the HTTP request for the DoubleClick tracking pixel queued behind it (because ofc there’s a DoubleClick tracking pixel).

The Safari Navigation Timing API numbers make it embarrassingly concrete:

responseEnd: 143ms
domInteractive: 231ms
domContentLoaded: 81,280ms

That’s 81 seconds between “DOM is ready” and “page is loaded.” All burning prescious CPU cycles with zero network activity during that window.

Why This Matters (Again)

This is the second time I’ve felt compelled to dig into this particular mess. The Chrome Releases page is a real/tangible operational resource — security teams, vulnerability managers, and researchers (somewhat, at least) depend on it for CVE data. When it’s broken, it creates a bottleneck for people who have real jobs to do.

The 433 CVE entries choking the page are exactly what people came to read. But they’re baked into the HTML as rendered text, not exposed as structured data anywhere. So even when the page eventually loads, you’re still scraping HTML to get at anything useful.

unjam

unjam solves that problem. It’s a small CLI that connects to a Blogger page and extracts structured data — both the widget configuration from the _WidgetManager._SetDataContext inline script and the CVE entries from Chrome Release posts — without touching a browser at all.

It’s a single Deno binary for macOS, Linux, and Windows. No dependencies, no configuration overhead, just download and run:

unjam --cve https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html

[
  {
    "issueId": "506558270",
    "issueUrl": "https://issues.chromium.org/issues/506558270",
    "severity": "Critical",
    "cveId": "CVE-2026-13774",
    "description": "Use after free in Extensions.",
    "reporter": "Google",
    "reportedOn": "2026-04-26"
  },
  {
    "issueId": "511766407",
    "issueUrl": "https://issues.chromium.org/issues/511766407",
    "severity": "Critical",
    "cveId": "CVE-2026-13775",
    "description": "Use after free in GPU.",
    "reporter": "Google",
    "reportedOn": "2026-05-10"
  },
  …
]

Getting CVE data from one of these posts used to mean waiting 81 seconds for a browser tab to finish wrestling with jQuery, then hand-scraping HTML. Now it takes about a second and returns clean JSON. The --cve flag parses each entry into structured fields — CVE ID, severity, description, issue tracker URL, reporter, and date reported — ready to pipe into jq, load into a database, or feed into whatever vulnerability management pipeline you’re running.

The tool also handles the general case: any Blogger page carrying the _WidgetManager._SetDataContext inline script can be unwedged with the default mode, which converts the JavaScript object literal into proper JSON. That turned out to be useful enough to bake in as default functionality.

The project’s at https://git.sr.ht/~hrbrmstr/unjam and has pre-built binaries for popular platforms.

I don’t expect this page to stay broken forever…I mean, someone at Google will eventually update the template (right, Anakin? right? Anakin?), and may even quietly drop the DoubleClick pixel (LOL) — but until then, unjam fills the gap cleanly.

rud.is