Two of Our Three Preloaded Chunks Rotated: What Changed in the Asset Filenames on 11 November

I work on OnePassApps, the team behind app.onepassapps.com.

Three days ago we wrote up the three JavaScript files our app pages preload. Two of them are no longer those files.

What I measured

All 56 URLs in our own sitemap, fetched over plain HTTPS on 11 November 2026 - signed out, no cookies, no JavaScript, GET only - and I read the <link rel="modulepreload"> tags and the <script src> tags out of the served HTML.

The shape of it has not moved. 33 of the 56 pages still carry exactly three modulepreload links, and the 23 that do not are still the same 23: the guides index and all 22 guide pages, which load no bundle at all.

What moved is the filenames.

The three preload links still point at the same three files in the same order, and every one of the 33 pages still points at the same three - there is one preload set across the site, not 33 of them.

What moved and what did not

The runtime chunk did not move: it is still rolldown-runtime-QTnfLwEv.js, and the file is still 694 bytes raw and 403 bytes under brotli.

The other three did. app-shell-shared-DCrZF6q_.js, react-vendor-DY6N_LXH.js, index-LNYK_bk0.js, index-B_evf03w.css - the shared app shell, the React vendor chunk and the entry module - all carry a different hash in their filename today than they did on 8 November, and the old filenames now answer 404. The sizes moved with them:

• The shared app shell is 369,710 bytes raw and 116,481 bytes under brotli. On 8 November the same chunk measured 369,609 and 116,569.
• The React vendor chunk is 178,924 bytes raw - the same raw size as on 8 November, under a different name. Compressed, one request today came back at 56,171 bytes and a second at 56,171.
• The entry module is 325,707 bytes raw and 91,048 bytes under brotli. On 8 November the entry module measured 324,591 bytes raw.

That is 549,328 bytes of preloaded JavaScript across the three chunks, raw. Over the wire it is smaller: one brotli request today came back at 173,055 bytes for the three chunks and a second at 173,055. Two requests in the same run differ by a few dozen bytes, so I am reporting the compressed figure as a snapshot rather than a fixed number. Add the entry module's 325,707 bytes and an app page pulls 875,035 bytes of JavaScript - the entry module is fetched by a plain script tag and is not preloaded at all.

The guide-fleet pages did not change with them, and they cannot: they load no bundle at all, so they take the same two stylesheets as every other page and no JavaScript. Those stylesheets are shell-fallback.css, index-B0tmDgOR.css. The 8 November stylesheet name now answers 404 too, so the CSS rotated as well - but the guide pages were never loading a bundle, so for them the change is only in a file they already fetch.

Why this is worth a post

A hashed filename is a promise that the bytes behind it have changed, and on a static build that promise is the cache. Every one of our 33 app-fleet pages now points at a set of filenames that did not exist a few days ago, which means every browser that cached the old set gets a miss on the first request after the change and pulls the new bytes once. The 23 guide pages are untouched by that, because they were never loading the bundle - they take the same two stylesheets and no JavaScript.

The part worth copying: keep the small runtime chunk stable and let the big chunks rotate. A runtime chunk that never changes is a file every browser can reuse forever.

The limits of this measurement

• One build, one day, plain HTTPS, signed out, no cookies, no JavaScript, GET only.
• The earlier state of these filenames is taken from our own published post on 8 November, which is a measurement, not a guess - I did not have the old build to re-fetch.
• The byte counts are what the server sent for an identity request and for a brotli request, not what a browser would cache. The brotli counts moved by a few dozen bytes between two requests in the same run, so they are snapshots.
• I did not diff the file contents, so I am not claiming what changed inside them, only that the names and the sizes moved.
• A hash in a filename tells you the build changed. It does not tell you the change was an improvement, and I am not claiming it was.

Read it yourself

The app pages are at https://app.onepassapps.com/apps/newsflow and the guides are at https://app.onepassapps.com/guides.

The earlier post that measured the original preload set is the canonical source for the 8 November names: The Link Layer of app.onepassapps.com: 491 Link Tags, Two Shapes and One Preload Set.