Design Suspense boundaries that don't collapse into one big spinner

You are designing where Suspense boundaries go on a data-heavy page, so the page reveals content progressively instead of either waterfalling requests or blocking everything behind one top-level spinner.

PAGE
A creator profile page: header with avatar and follow button, a stats row, a paginated grid of posts, and a "similar creators" rail below the fold.

DATA DEPENDENCIES
Profile header needs a fast /profile call; stats row needs a separate, usually slower /stats call; posts grid needs /posts?page=1, independent of the others; similar creators needs a slow recommendation call.

FETCHING APPROACH
TanStack Query hooks with suspense: true, called from route-level loader components.

NON-CRITICAL SECTIONS
The "similar creators" rail — nice to have, but nobody visits this page to see it.

DESIGN RULES
Start every request as early as possible — as close to the route or component entry point as the fetching approach allows — even when the component that renders the result sits deep in the tree behind its own Suspense boundary. Never gate the start of a fetch behind the boundary that will display its result; that ordering is what turns Suspense into a self-inflicted waterfall. Use one Suspense boundary per independently-loading region of the UI, not one boundary per component — group things that should visually appear together and can tolerate loading together into the same boundary. Never put a slow, non-critical section such as comments, related items, or a sidebar widget in the same boundary as the primary content; an unrelated slow request should never delay what the user actually came to the page for. Name a fallback for every boundary that matches the shape of what it is replacing — a skeleton with the right layout and approximate dimensions, not a generic centered spinner — so the loading state does not cause a visible layout jump when real content arrives. Call out any place where two sibling boundaries would race in a way that produces a confusing partial layout — one section rendering above another that hasn't loaded yet in an order that looks broken rather than intentional — and resolve it by grouping them into one boundary instead of leaving the race in place. Pair every data-fetching Suspense boundary with an error boundary scoped immediately around it, not shared broadly across unrelated boundaries — a rejected promise inside a Suspense boundary propagates as a thrown error that the nearest error boundary must catch, and without one scoped to just that region, a single failed request can crash the whole page instead of degrading only its own section. Keep the key prop on a boundary's contents stable across re-renders that should not restart it — an accidentally changing key remounts the subtree and re-triggers its fallback even though the underlying data never actually became unavailable.

OUTPUT FORMAT
1. A tree diagram, text is fine, showing where each Suspense boundary sits and exactly what is inside it.
2. For each boundary: what triggers its fallback, and a description of what the fallback should look like.
3. Any request-waterfall risk you found in the original data-fetching approach and how the boundary placement avoids or fixes it.
4. Anything from the non-critical sections list you deliberately isolated into its own boundary and why grouping it with primary content would have been the wrong call.