Design loading UI so one slow query doesn't block a whole page from painting

You are designing the loading UI for a specific page using route-level loading.tsx and granular Suspense boundaries, so the page streams in as each piece of data resolves rather than showing one full-page spinner until the single slowest fetch finishes.

PAGE DATA DEPENDENCIES
user profile header (fast, cached), order history table (medium), real-time inventory sync status (slow, external API)

SLOWEST DATA SOURCE
The inventory sync status — it calls a third-party API with roughly 2 seconds of typical latency

DATA FETCHING APPROACH
Async Server Components fetching directly, with each section as its own async function component

REQUIREMENTS
Use loading.tsx at the route segment level for the initial navigation fallback — this file automatically wraps the entire segment in a Suspense boundary, which is exactly why it should show a skeleton that roughly matches the eventual layout rather than a generic centered spinner, since it's the very first thing a visitor sees on that route. Identify which pieces of the page are genuinely independent of each other's data, meaning neither needs to wait on the other, and wrap each independent piece in its own Suspense boundary with its own fallback so each can resolve and stream in on its own schedule. The slowest data source named above must never be awaited at the top of the page component in a way that blocks everything else on the page from rendering — its fetch should start as early as possible, but nothing else on the page should be gated behind its resolution. Give each Suspense boundary a fallback that's sized and shaped like the real content it's replacing — a skeleton with matching approximate dimensions, not a generic centered spinner that causes a visible layout jump the moment the real content swaps in and claims a different amount of space. If a section legitimately needs to wait on another — a detail panel that needs to know which item was selected before it can fetch anything — don't force it into a parallel Suspense boundary alongside unrelated content just for the sake of consistency; nest it inside the boundary it genuinely depends on, or leave it sequential, and say so explicitly rather than parallelizing something that has a real, unavoidable data dependency. Note explicitly where this interacts with caching, since the two are easy to conflate: a Suspense boundary around a component changes only when the browser sees that component's result, not whether the underlying data is cached — caching is a separate decision made through the data-fetching approach itself, not something Suspense boundary placement affects one way or the other.

OUTPUT FORMAT
The page's Suspense structure as a component tree, described in text with fallback components sketched rather than fully styled, plus a one-line note on which sections are genuinely independent versus genuinely sequential and why each was placed the way it was.