Martin Bauer
3fea56d4e1
Shrinking the covers changed nothing on the device, twice over, because two layers were independently serving the old bytes and each had the same wrong premise written into its comment: that a cover is "content-addressed by album id". The id addresses which album the art belongs to. The bytes behind the URL change whenever the art is reprocessed. The backend sent `public, max-age=604800`, so every browser that had loaded the page in the previous week kept decoding the 3000px original out of its own disk cache without asking. It now sends `no-cache`, which does not mean "do not store" but "revalidate before reusing" - the file stays cached and the usual answer is a 304. The service worker cached covers cache-first on a URL that never changes, which means a client could serve a stale cover for ever; bumping the cache name fixed today's covers and would have had to be done again for the next batch. It now does stale-while-revalidate: the cached copy is returned immediately, so a grid of album art still never waits on the network, and a fresh copy is fetched behind the page for next time. Neither layer needs a version bump when art is reprocessed again. The revalidation is off the paint path entirely, which is what makes `no-cache` affordable here: the service worker answers first, the network call happens behind it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>