- Shipped
- August 20, 2026 at 3:12 PM UTC
- Author
- Kamo
- Commit
- e800c0f
Adds public/img/hero-still.webp — 1280x720, matching the aperture's 16/9 exactly — and makes it what the hero shows until someone presses play. This also fixes a bug the tap-to-play change introduced and I missed. The <video> element carried `opacity: reelWanted ? 1 : 0`, which was right while the reel started by itself: the element appeared once the gates opened, poster and all. With playback now gated on a tap, `reelWanted` stays false for every visitor who never presses it — so the element, and therefore its poster, was invisible for the entire visit and the aperture showed the skeleton pulse instead. It keys on the poster being ready now. The skeleton is correspondingly reduced to what it was always meant to be: the gap before the still arrives, rather than something waiting on `canplay`, which never fires under `preload="none"` until the reel is asked for. Three smaller changes follow from the still being content rather than a placeholder: · Local, not the theme bucket's kamo13-poster.jpg. For most visitors this frame is the hero for the whole visit, so it ships with the app. · Quality 50, not 30. Thirty was chosen for something a video painted over within a second; artefacts in this are artefacts in the page. Through the optimizer it is 1.5-3.7 KB of AVIF depending on the rung — the source is 22 KB of WebP. · No more idle gate. In-view still earns its keep, because on a narrow viewport this aperture sits below the fold under the copy column. Waiting for the main thread to go quiet on top of that was caution owed to the multi-megabyte video behind it; making a ~2 KB image arrive late now just means a longer look at nothing. Verified in Chrome: before the tap the poster is set, the element computes to opacity 1, the skeleton is absent and zero media requests have been made; after it, currentTime advances 1.1 -> 3.6 -> 8.6s with muted false. Console and DevTools Issues clean, 22 requests, all guards pass.