- Shipped
- August 20, 2026 at 2:23 PM UTC
- Author
- Kamo
- Commit
- 8399936
Chasing "make fewer HTTP requests" found two real things, and the second is much larger than the audit that led to it. THE HLS BRANCH NOBODY WAS TAKING. HeroStage picks native HLS when the element reports it can play the type, with a comment framing that as the Safari case. It is not: **************** returns "maybe" in Chrome, on desktop AND on Android. So Chrome never reached the hls.js branch, and none of its tuning — start level, level cap, buffer limits — has ever applied to it. Only Firefox, which answers "", was using hls.js at all. That mattered because the native player offers no quality API, so its own ABR climbed to the 720p rung for a 369 px aperture. Measured on an emulated Moto G: 8 media requests, 5,353 KB inside fifteen seconds, on a phone, for a muted decorative loop. A narrow viewport is handed the 540p rendition playlist directly now — the only way to cap native playback is to give it a playlist without a higher rung in it. That costs adaptive switching within the reel, which is the deliberate trade: it is decoration, and its slowest visitors (Save-Data, 2G/3G) are already excluded before any of this runs. media: 8 requests / 5,353 KB -> 6 requests / 3,143 KB (-41%) The hls.js config is fixed too, for the Firefox path that does use it. `startLevel` read `narrow ? 2 : 1` with a comment calling 2 "the bottom rung" — hls.js sorts levels ascending ("sort levels from lowest to highest"), so 2 is the TOP rung and phones were starting on 720p there as well. `capLevelToPlayerSize` is now desktop only: it measures in DEVICE pixels, so 412 px at DPR 2.625 reads as ~1080 and authorises 720p anyway, and cap-level-controller reassigns `autoLevelCapping` on a timer, silently overwriting any manual cap set beside it. Narrow viewports get an explicit cap derived from the manifest instead, plus a 10-second forward and back buffer so a 66-second loop is not pulled down whole. AN 85 KB FAVICON. The theme bucket's favicon.svg is the full logo traced to 669 paths — 219 KB raw, 84 KB over the wire — and browsers prefer an SVG icon when one is offered. The PNG beside it is the same mark at 4.9 KB. The SVG link is gone; it was the heaviest request on the page after the video. On the advice itself: combining scripts and stylesheets is HTTP/1.1 guidance and this site is served over h2, where requests are multiplexed on one connection and merging bundles would cost cache granularity and code splitting for no gain. The waste above was real and is fixed; the remaining counts are 23 code-split chunks and 15 <Link> prefetches, and the prefetches are what make navigation instant. Diagnosed with Chrome over the debugging protocol, including an isolated hls.js page to prove the cap logic worked before concluding the app was not reaching it.