renderToString returns the fallback before React.lazy's own microtask can run

The expensive part, per the author's write-up on dev.to, was that the obvious theory survived the obvious experiment. Resolve every page's dynamic import up front, await all of them, then render: identical 12.6kB output, still green ^[6]. At that point the module is loaded, awaited and resolved before render starts, which rules out the tidy explanation that it is not loaded yet ^[6].

React.lazy never asks whether the module is available. It keeps its own status field, and only its own initialiser advances it ^[7]. On the first render it sees Uninitialized, calls your loader, takes back a promise, marks the component Pending, attaches a .then to write the result in, and suspends ^[8]. An already-resolved promise still does not invoke that .then synchronously; it schedules a microtask that runs once the current synchronous execution finishes ^[9]. renderToString finishes nothing mid-render. It runs top to bottom, never yields, sees Pending, writes the fallback and returns, all before the callback that would have marked the component Resolved gets a turn ^[10]. The exit code was accurate as far as it went: renderToString did return a string.

So the thing to check before assuming this transfers is which renderer your build script calls, not the React version. Under renderToPipeableStream the same lazy components are fine, because a streaming renderer can wait; under renderToString, that status belongs to React's initialiser alone, and your code never gets a turn to write it ^[11].

The fix stops delegating that state. Loaded is a plain variable the .then assigns, preload is memoised with `pending ??= load()`, and the component calls `use(preload())` only when Loaded is still null ^[12]. That leaves two states with no microtask between them. Loaded set, and rendering is an ordinary synchronous function call that never suspends, which is the path the build takes every time; Loaded null, and use() suspends exactly as lazy would, which is what you want when a browser navigates to a page it has not fetched ^[13].

What you buy is a registry you now maintain. Every route pushes its own preload into the list the build awaits ^[12], and a route nobody registers will not fail loudly: it takes the null branch during the build, suspends, and writes a fallback into a green run ^[13][10]. That is the same failure with a smaller blast radius, and this time the variable is yours, so a build script can read it.

Seventeen files, one byte count ^[1][4]. Seventeen times 12.6kB is 214.2kB of HTML written without a page body in any of it ^[14]. In my context the check worth adding is not a byte floor, because the next footer edit lifts the floor and the assertion quietly starts passing again; it is a per-route string that only that page's body can produce, checked against the file written for that path ^[1].