A React page is server-rendered with `renderToPipeableStream`, but its content is fetched inside `useEffect`. What does the HTML the server sends actually contain, and what does that cost you?

## What server rendering actually executes On the server, React runs the render phase and nothing else. It calls your component functions, collects the elements they return, and serialises the result to an HTML stream. There is no DOM to commit to, no browser to paint, and no lifetime after the response is written — so there is no commit phase, and passive and layout effects are never invoked. `useState` initialisers, `useMemo` factories and the component body all run; `useEffect` bodies and their cleanups do not. That single fact determines the whole answer. Any data that only arrives via an effect cannot be in server-rendered HTML, by construction. ## The timeline the user actually experiences 1. The server streams HTML containing a skeleton, because that is what the component renders with `data === null`. 2. The browser paints the skeleton — fast, and misleading. 3. The JS bundle downloads and parses. 4. `hydrateRoot` attaches React to the existing markup and commits. 5. Effects run; the request finally leaves the browser. 6. The response arrives, state updates, the real content replaces the skeleton. Steps 3 to 6 are entirely serial and happen after the server has already done work. On a slow connection the gap between the first paint and useful content can be several seconds. ## What it costs **Perceived performance.** The skeleton usually is not the largest contentful paint candidate you want; LCP lands on the real content, which is now several steps away. You get an early first paint that measures well on naive metrics and badly on the ones that reflect user experience. **Layout stability.** Replacing a placeholder with content of a different size shifts the page, hurting cumulative layout shift, unless you reserve exact dimensions. **Indexability and previews.** Search crawlers that execute JavaScript may still index the page, but on a delay and with no guarantee. Link-preview and social-card bots generally do not execute JavaScript at all, so they see the skeleton — which is why an otherwise fine app produces empty previews when shared. **Wasted server work.** You are paying for server rendering and getting only a shell out of it. That is a legitimate argument for either fixing the data path or dropping SSR for that route. ## Getting data into the server-rendered HTML The requirement is to have the data *before or during* render rather than after commit. Three shapes do that: - **A server component** is an async function component that runs only on the server and can `await` during render. Its output is already resolved when the HTML is produced, so the markup contains real content and no client effect is involved. - **A route loader** resolves the route's data before the matched components render, then renders with data in hand. - **A render-time resource read**, where the component reads a promise created outside it and the framework suspends until it settles, so the streamed output waits for real data rather than committing an empty state. In all three, `Suspense` is what makes it non-blocking: `renderToPipeableStream` streams the shell immediately and sends the slow subtree's HTML later when it resolves, so a slow query delays only its own boundary. That is the structural difference from effect fetching — the loading state is expressed as a boundary in the tree rather than as a boolean the component reached only after committing empty. ```jsx <Suspense fallback={<Skeleton />}> <SlowSection /> </Suspense> ``` ## The compromise you will be asked about A long-standing middle path is for the server to fetch the data, embed it in the HTML as a serialised payload, and have the client seed its initial state from it so no effect fetch is needed on first load. It works and is worth naming, but be honest about the cost: you maintain the serialisation format, the payload inflates the document, and you must keep the server's fetch and the client's refetch semantics in sync. It is the reason the ecosystem moved toward fetching during render instead.