How do you decide where to place <Suspense> boundaries across a React page, and what goes wrong at each extreme — one boundary around everything versus a boundary around every component?

## The question behind the question An interviewer asking this is not testing whether you know the `fallback` prop. They are testing whether you can reason about perceived performance and visual stability under uncertainty, because boundary placement has no single right answer — it depends on the shape of the page and on what the user is trying to do. ## Start from the layout, not the data The most useful reframe: a `<Suspense>` boundary is a **hole in the layout that can be filled by a placeholder**. So the first test is geometric. Draw the boundary around a region that occupies a predictable box — a card, a panel, a table body, a right-hand rail. A same-sized skeleton swaps into that box and nothing around it moves. Boundaries around content with unknown or content-driven height are where layout shift comes from. Whatever the placeholder's height, it is not the content's height, and everything below jumps when the real content lands. The mitigations are the ordinary ones — reserve a fixed height, use a skeleton that reproduces the real content's rows and spacing, place the boundary at a section that has its own scroll container — but the structural fix is choosing a different boundary. ## Then apply the data test The second test is independence. Two regions whose data always arrives at the same time gain nothing from separate boundaries: they will reveal at the same moment anyway, and you have paid for two skeleton designs and two more places for a mismatch to creep in. Two regions with materially different latency — a cheap header versus an expensive aggregation — do benefit, because the cheap one stops waiting on the expensive one. This is also where grouping becomes a deliberate act. If three cards belong to one visual row, putting them under a single boundary makes them appear together, which usually looks intentional; giving each its own boundary makes them pop in one at a time, which usually looks like a bug even though it is strictly faster. ## The failure at each extreme **One boundary at the root.** Every suspension anywhere in the app replaces the entire screen. Perceived load time collapses to the slowest thing on the page, and a slow widget in a corner is indistinguishable from a slow page. Worse, on updates the whole app blanks, so any re-suspend is maximally disruptive. This is the state most codebases start in, and pushing boundaries downward is the highest-value change available. **A boundary around every component.** Each individual wait is minimal, but the composite experience is worse: a mosaic of placeholders resolving in unpredictable order, several reflows as differently-sized content lands, and no moment where the page "arrives". There is also a real maintenance cost — every boundary is a fallback someone must design and keep in sync with the content it replaces. The right answer is almost always in the middle: a handful of boundaries aligned with the page's visual regions. ## Priority: what should the user see first Boundaries let you rank the page. Content the user came for should be outside a boundary if it can be, or inside the boundary that resolves first; peripheral content — recommendations, activity feeds, analytics widgets — belongs behind its own boundary so it never gates anything. A useful discipline is to ask what the minimum useful screen is, and make sure nothing optional can prevent it from rendering. ## Update behaviour is part of the placement decision For each boundary, decide what happens on an *update*, not just a first load. If the region's stale content is still meaningful, drive the update through a transition so the boundary keeps showing it instead of flashing back to the fallback. If stale content would mislead — a balance, a permission state, a different entity entirely — let the fallback show, and rely on tight placement so the fallback covers a panel rather than the page. ## Ownership and consistency At scale the interesting problem is not any single boundary but who is allowed to declare one. If shared components ship their own internal boundaries, page authors get sensible defaults but lose the ability to coarsen a reveal, and page-level fallbacks may never appear because a descendant boundary caught everything first. If only pages declare boundaries, the shared components are more composable but every page author re-solves the same problem. Either policy works; having no policy is what produces pages that each load in a visually different way. I would pair the policy with a small shared skeleton vocabulary, so placeholders across the product look like the same product. ## How I would answer in one breath Boundaries follow the layout; group content that arrives together; keep optional content from gating essential content; make the fallback the same shape as what it replaces; and decide per region whether updates show the fallback or hold stale content behind a transition.