Busca de Dados Paralela, Sequencial e por Fluxo

Server Components can fetch data sequentially (one waits for another) or in parallel (all at once). Choosing well dramatically affects load time.

Sometimes one request depends on another result, forcing order. This creates a waterfall and is slower.

Independent requests should start together. Initiate the promises, then await them with Promise.all.

An accidental waterfall happens when you await each fetch on its own line even though they are independent. Kick them off before awaiting.

You do not have to wait for everything. Wrap slow parts in Suspense so fast content streams to the user immediately.

The special loading.tsx file is automatically a Suspense boundary for the whole route segment, giving an instant loading state.

Place multiple Suspense boundaries so each section reveals as soon as its own data is ready, instead of blocking on the slowest one.

In RSC you can fetch data exactly where it is needed (in the component that uses it). React dedupes identical requests, so colocated fetches are fine.

Next.js memoizes fetch calls with the same URL/options within a single render pass, so calling it in multiple components does not hit the network twice.

You can start a fetch early (a preload function called before render) to overlap network time with rendering of other parts.

Default to parallel + colocated fetching; add Suspense boundaries around slow, independent sections; only go sequential when a real data dependency exists.

You learned to fetch in parallel with Promise.all, avoid accidental waterfalls, and use Suspense (including loading.tsx) to stream UI progressively. Next.js memoizes fetches, so colocated leaf fetching is efficient.