- Ya
- 19 Agosti 2026, 18:34 UTC
- Mwandishi
- Kamo
- Ahadi ya
- a7436b2
Every background on the homepage was being downloaded TWICE. The components rendered the local `/img/bg/N.webp`, then an effect resolved the org's theme path on mount and replaced the source — so the browser fetched both. On the deployed site that measured 95.8 KB for the local bg/2 plus 100.7 KB for the themed one on a single section, and 21.4 + 21.9 KB on the hero. It was not even the same picture. bg/1 and bg/3 differ between the local copy and the theme bucket by an RMSE of 0.27 — different photographs, not re-encodes. So the hero's LCP element, preloaded at high priority, was thrown away after hydration and replaced with a different image the reader then watched appear. The themed URL is now what the server renders. Resolving it needs a hostname, and a server component cannot read one without `headers()` — which opts every route out of static rendering, the most expensive mistake this codebase has made — so the canonical host is a constant, run through `getThemePath` itself so the two cannot drift. Components still re-resolve on mount and only re-point when the live host differs, which is what keeps white-label tenants working, and the local files stay as the `onError` fallback. The video poster is sized to the aperture rather than the device pixel ratio. It was fetching 750px of image for a 369px panel; it is a placeholder a video paints over within a second or two, so retina detail there is spent on something nobody looks at long enough to judge. 26.4 KB originally, 9.3 KB last round, 4.1 KB now. ACCESSIBILITY — and this one is a trap worth naming. The brand tokens are not ours: `--color-primary*` are overwritten at runtime by the org's theme stylesheet, and the values the live theme actually serves are near-black greens. Against the #0f1f14 canvas they measure 1.15:1, 1.79:1 and 2.84:1, all far under the 4.5:1 body text needs. The built-in defaults are fine at 5.68:1 and 7.02:1 — which is exactly why this cannot be seen in development. The failure arrives with a stylesheet fetched from another host, after hydration, in production only. A fixed replacement colour would defeat the point of a white-label theme, and a fixed blend toward white cannot promise anything for an arbitrary input. So `--color-accent-on-canvas` is computed: take the theme's own colour and lift it toward white only as far as it takes to clear the threshold. A brand colour that already passes is returned untouched, so a carefully chosen theme is left exactly as its author set it. Unit-tested against the live theme's three greens, pure black, an `rgb()`-form value and an unparseable one — every case lands at or above 4.51:1, the passing colour is left alone, and an unreadable value leaves the stylesheet's own colour in place rather than guessing. The preview banner's text sits on an animated red gradient, where the worst stop is what has to pass rather than the average. Measured over #cc1111: the day count was 3.35:1 at 0.7 alpha (white crosses 4.5 at 0.86, so 0.88), the changelog link 4.27:1 (#ffe8e8 gives 4.91), and the "|" divider 1.50:1 — that pink cannot clear the line at any alpha, and it is decorative punctuation, so it is aria-hidden. Hiding it from the accessibility tree is the honest fix; a colour that merely looked readable would not be. Two non-composited animations, both of which the compositor should have owned: `.hero-bg` was transitioning `filter` on layers that are `opacity: 0` — blur and grayscale animated where nothing can see them, on a full-viewport layer that is also the LCP candidate. And the progress bar's highlight looped `background-position` forever on a fixed element at the top of every page; it is a translated pseudo-element now, which looks identical and stays off the main thread. `background-position` was the single largest contributor to that audit's count.