- Ya
- 19 Agosti 2026, 18:10 UTC
- Mwandishi
- Kamo
- Ahadi ya
- e414d05
MinIO returns object bytes exactly as stored — it does not negotiate Content-Encoding — and the two theme IngressRoutes carried `strip-hsts` and `cors` but no compression. So everything text-shaped on theme.kamocrm.com went out uncompressed, on every cold request, to every site embedding it. The chat widget is the worst case and the reason this surfaced: 145 KB of JavaScript, no Content-Encoding, embedded on customers' own pages, where it is reported against *their* Lighthouse score rather than ours. The theme config.json every app fetches at boot, the SVG logos and the HLS playlists are all in the same position. Deliberately `includedContentTypes` rather than reusing the cluster-wide `compress` middleware's bare `compress: {}`. This host is overwhelmingly already-compressed binary — WebP backgrounds, JPEG posters, MP4, and MPEG-TS segments measured in hundreds of megabytes — and running those through gzip spends CPU per request to produce output no smaller than its input. The list names only the types that actually shrink; everything else is passed through untouched. `kubectl diff` against live before pushing: no pre-existing drift on either route (`strip-hsts` and `cors` match the repo exactly), so the only changes are the new middleware and the two references to it. Also raises the HLS playlists from max-age=300. That was far shorter than its own stated reasoning required — the comment asks only that a re-encode become visible without waiting out a year — and low enough to be reported as an inefficient cache policy against every page embedding the reel. A re-encode is a deliberate act that happens a handful of times a year (the .source-sha256 marker no-ops every other run), so an hour of propagation costs nothing anyone will notice, and the added stale-while-revalidate answers a returning player from cache immediately for the day after that. Segments stay immutable and loop.mp4 stays at 300s, since the MediaMTX init container reads it on restart. That last part only takes effect on the next actual re-encode, since the job no-ops while the source hash matches; the live playlists keep their current headers until then.