- Shipped
- 20 Agosti 2026, 01:30 UTC
- Author
- Kamo
- Commit
- ae788a4
Two findings, both of which were doing something other than what the code said. THE BACKDROP WAS FETCHING THE 1920 CANDIDATE. 149 KB, for a decorative picture behind content on a 412px phone, with `sizes="(max-width: 768px) 50vw, 100vw"` sitting right there saying otherwise. The cause is a rule I added myself two commits ago: these sections carry `content-visibility: auto`, so when the browser comes to pick a source the subtree has not been laid out — a viewport percentage has nothing to resolve against, and it reaches for the largest candidate in the set. Absolute widths settle it. 640 on a phone, 1080 on a desktop, whatever the layout is doing: 153,011 bytes -> 24,181. Upscaling slightly is the right trade on this image — it is darkened to 60% under a radial black overlay, behind opaque content, and resolution shows far less on it than the compression banding that lowering quality would cause. THE PRECONNECT WAS BEING REPORTED AS UNUSED WHILE ALSO BEING ASKED FOR, which is what a credentials-mode mismatch looks like. The first thing the browser fetched from theme.kamocrm.com was HeroBackdrop's `config.json` — a cross-origin `fetch`, so a CORS request, and a socket opened without `crossorigin` cannot serve one. Adding a second hint would have opened a second connection to the same host to paper over it. The file is read on the server instead (app/lib/theme-config.ts, cached for an hour — it changes only when an org re-provisions its theme), and the count and play order arrive as props. The request is gone entirely for this site, the browser's first call to that origin is now the theme stylesheet, which is not CORS, and the existing hint is used by it. A genuine white-label host still re-resolves on the client, because the server cannot know a hostname it was not built for. CLUSTER RESOURCES — checked, and there is nothing to gain there. The pod idles at 10m CPU and 186Mi on a 48-core node sitting at 47% CPU and 53% memory, with requests of 50m/128Mi and no limits. Real TTFB measured from outside is 58-77 ms across five samples, with `x-nextjs-cache: HIT` and `x-nextjs-prerender: 1` — the page is served from a prerender, not computed per request. The 434 ms Lighthouse attributes to the document is 50,867 bytes crossing a throttled Slow 4G link, which no amount of CPU changes. The one thing worth correcting is the memory request, which sits below actual usage; that is a scheduling accuracy fix rather than a performance one, and is left for a deliberate change to the deployment rather than smuggled in here.