You own a Next.js App Router route whose main data takes roughly two seconds. How do you decide between streaming a skeleton with loading.tsx and letting the response block until the data is ready?

## Frame the decision, not the feature Streaming is cheap to switch on in the App Router — a `loading.tsx` file, or a `<Suspense>` around a subtree — which is exactly why it gets applied reflexively. The judgment being tested is whether you know what you are trading away, because the mechanism is a reordering of when bytes arrive and nothing more. Total server work, total transfer, and time-to-complete are unchanged. ## Axis 1 — does the shell have value? Ask what the user can read or do while the slow region is pending. - **Rich shell**: a dashboard whose nav, header and summary cards are fast while one analytics panel is slow. Streaming is clearly right; the page becomes usable in a couple of hundred milliseconds. - **Empty shell**: a search results page whose entire content is the slow query. Streaming produces a header and a shimmer. The user waits the same two seconds and now watches a placeholder pretending to be progress. Sometimes that is still preferable — it proves the app is alive — but it is a much weaker case, and a rich fallback (last-known results, cached partial data) usually beats an empty one. ## Axis 2 — what the response can no longer do This is the axis candidates most often miss. The moment the first chunk is flushed, the response has committed: its status line and headers are already on the wire. Anything the framework decides later, deep inside a slow subtree, cannot retroactively turn the response into a different status or a redirect — it has to be expressed inside the streamed markup instead. Practical consequences: - A route that must reliably answer with a not-found or a redirect based on the slow data is a poor streaming candidate; resolve that decision **above** the boundary, where the response is still uncommitted, then stream the rest. - Errors that occur after the shell is out surface through the nearest error boundary in the UI rather than as a failed request. Monitoring that watches only HTTP status will report these routes as healthy while users see error UI, so instrumentation has to move client-side or into the render itself. ## Axis 3 — is streaming answering the right question? Before optimizing *when* the bytes arrive, ask whether the two seconds are necessary at all. Common findings: the query is uncached and identical for every visitor; several awaits run sequentially that could run concurrently; the data changes hourly and the route never needed to be rendered per request. Each of those is a larger win than any boundary placement, and a candidate who reaches for `<Suspense>` before checking them is optimizing the symptom. There is also a coupling worth naming out loud: streaming is a property of a per-request render. Deciding to stream implicitly asserts that this route renders per request, which is a rendering-mode decision that should be made deliberately rather than inherited from a `loading.tsx` someone added. ## Axis 4 — the cost of the skeleton itself Skeletons are not free: - **Layout stability.** A fallback whose dimensions differ from the real content shoves the page around when the chunk lands. Fallbacks should be sized like what they replace. - **Perceived jank.** Many independent boundaries mean many independent reveals; a page that assembles in six visible steps can feel worse than one that appears once. - **Maintenance.** Every skeleton is a second, unversioned copy of a layout that drifts from the real component over time. ## Axis 5 — measurement and the honest metric Streaming improves first byte and first paint, and typically the largest-contentful paint when the largest element is in the shell. It does not improve time-to-interactive-with-real-data, and it can make a naive "page load complete" metric look worse because the response stays open longer. Decide up front which metric the team is optimizing and make sure the dashboard reflects the user's experience, not just the one number that moved. ## How I would actually answer "Two seconds is a symptom; I want to know why first. If the query can be cached or parallelized, that is the fix. If it genuinely must be slow per request, I stream — but only if the shell is useful without it, and only after confirming this route does not need to decide its status or destination from that data. Then I size the fallback like the content, keep the number of boundaries small enough that the page assembles in one or two visible steps, and make sure errors after the flush are still visible in monitoring."