Martin Bauer
83d16e0058
Search was still stalling for seconds a keystroke. A trace across five keystrokes said the renderer main thread was blocked for 9.4 s in a single task with *zero* V8 samples inside it - no JavaScript ran at all. What ran instead, on the worker pool during those same 9.4 s: ImageDecodeTask 7.6 s, RasterTask 1.7 s, and only 229 ms of actual "Decode Image". The main thread was waiting on cover bytes, not computing anything. Two causes, and the first one was mine. The stale-while-revalidate handler added earlier today made every cover do a Cache Storage read *plus* a network fetch *plus* a cache write, all serialised through one worker thread. Measured with Network.setBypassServiceWorker: worst keystroke 5580 ms through the worker against 461 ms without it. So covers no longer go through the worker at all. That costs nothing here: this worker only registers on localhost or over HTTPS, which on this setup is the kiosk on the device itself, where the backend is the same machine and a cache lookup is strictly more work than asking for the file. The shell caching, which is what makes it installable, stays. The second is that decode cost goes with pixel count, and 640 px was headroom for a tablet at devicePixelRatio 2 that nobody had asked for. A browse grid paints a card 132 px wide; the largest any screen asks for is 340. At 384 px, typing "conni" over 343 albums, keydown to painted, three runs: before 3735, 270, 5580, 88, 57 ms after 873, 75, 17, 24, 26 ms `shrink_cover` never scales art up, so dropping the limit cannot be applied by re-reading the cache - only by going back to the original art. _INDEX_VERSION 6 does that: the index is discarded and every album is scanned again through store_cover. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>