Martin Bauer
e1c10f5408
A DevTools trace recorded on musicdolphin put the whole question beyond argument: ImageDecodeTask 29,939 ms x20 (~1.5 s each) Decode LazyPixelRef 3,924 ms x20 Decode Image 3,530 ms x22 Paint 99.7 ms Layout 77.3 ms all app JavaScript <400 ms across 22 seconds Image decoding is not the largest cost on that page, it is very nearly the only one. The covers should already have been small - the backend downscales to 640 px now - but the page was still decoding them at 1920, 1600, 1400 px, with deliveryType "cache-storage" on every one. The service worker caches cover art cache-first, keyed on URL, on the premise that it is "immutable per album id". The id did not change; the bytes did. So every client that had ever loaded a cover kept serving the 3000 px original from its own disk and never asked the backend for the new one. Renaming the cache is the retirement mechanism the worker already has - `activate` deletes every cache that is not one of the two current names - so COVERS becomes v2, with a note saying that changing how covers are produced means bumping it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>