- Shipped
- August 19, 2026 at 3:49 PM UTC
- Author
- Kamo
- Commit
- a93eb8f
Every page except the homepage felt slow, which points straight at the (pages) subtree — and at something I put there. When 4fae924 added (pages)/loading.tsx every route was dynamic, and for a dynamic route Next prefetches no further than the nearest loading boundary, so that file was load-bearing: without it a <Link> prefetch returned nothing at all. Those routes are prerendered now. All but two. A static route's whole payload sits in the router cache before the click, so the boundary buys it nothing and leaves React a fallback it can flash mid-transition — 30 shimmering skeleton elements built, painted and torn down on the way into a page whose content was already in hand. The homepage sits outside (pages) and is where visitors start, so it never paid any of it. That is the asymmetry. The boundary now lives only on [kbSection], covering the two routes that genuinely render per request and would otherwise lose their prefetch. Measured on a production build: static-route prefetch payloads drop 37.5 KB -> 26 KB (the skeleton markup was riding in every one of them, and pages carry ~73 links), chunk references stay at 78 so prefetch is still complete, and /en/help-center still prefetches its boundary. Also memoises the footer. The (pages) layout is a client component, so it re-renders on every navigation and drags its children with it; SharedNavigation genuinely depends on the route, the footer does not, yet it rebuilt ~29 links and their motion wrappers on every page change. Includes the REVALIDATE_SECRET wiring: created as the kamomarketing-secrets Secret in the cluster (never committed, referenced by name), and the deploy job reads it from the cluster rather than duplicating it as a CI secret, so the two cannot drift.