Fetching in Server Components

"fetch requests are not cached by default and will block the page from rendering until the request is complete." — Next.js Documentation, "Fetching Data"

If you have used Next.js before version 15, read that sentence again, because it reverses something you almost certainly believe. For several years fetch in the App Router was cached by default — a decision that was well-intentioned, widely misunderstood, and the source of an entire genre of bug report titled some variant of "my data is stale and I do not know why". It is not the default any more. A fetch in a server component now goes to the network on every request unless you say otherwise.

That change makes this chapter's material simpler to reason about and easier to get wrong in a new way. Simpler, because a request now does what it appears to do. Wrong in a new way, because "goes to the network every time" combined with "blocks the page from rendering until complete" means an unremarkable-looking component can hold your entire page hostage to somebody else's API.

Part II established that a server component can query a database directly and that its code and credentials never reach the browser. This chapter is about doing that well: where to put a fetch, why you do not have to thread it through props, what the framework deduplicates for you and what it does not, and — the part that separates fast pages from slow ones — how to notice that you have written a waterfall.

Almost everything here reduces to one question asked repeatedly: does this request need to wait for that one? Where the answer is no and your code says yes, you have a waterfall. Where the answer is yes, you have a dependency, and the tool is not to eliminate it but to stop it blocking everything else.

Fetch where the data is used

The first instinct carried over from client-side React is to fetch high in the tree and pass the results down, because fetching in two places meant two requests. In a server render that instinct is unnecessary and mildly harmful.

Identical fetch requests are memoized during a server render pass. A GET with the same URL and the same options, called from five different components, executes once and shares the result — across server components, layouts, pages, generateStaticParams and generateViewport. So the component that needs the data can simply ask for it.

That trailing-slash row is not a contrived example; it is one of the two ways this silently stops working in practice. The other is a header or option added in one call site and not the others — an authorisation header, a next.tags array, a signal — which makes two calls that look identical in review into two distinct requests.

If you need to defeat memoization deliberately, the documented mechanism is to pass an AbortController signal, which makes the request unique.

Memoization only covers fetch. For an ORM query or a file read there is no URL to key on, and the equivalent tool is React's cache() from the previous part — wrap the function once and every call site shares the result.

Not cached, and blocking

Now the behaviour that has changed. A fetch in a server component is not cached by default and blocks rendering until it completes. Both halves matter, and the second is the one that shows up in your latency graphs.

That final distinction is worth holding onto, because both options make a page feel faster and they are answers to different questions. Caching removes the request. Streaming keeps the request and stops it blocking. Part IV is about the first; the fourth chapter of this part is about the second.

There is a development-only wrinkle that has confused a great many people, and it is documented: Next.js keeps an HMR cache for fetch responses in local development, and it applies even to cache: 'no-store', so an uncached request may not show fresh data between hot reloads. It clears on navigation or a full reload. If you are staring at a value that refuses to change while you edit, reload the page before you doubt your code.

The waterfall you did not mean to write

Here is the mistake that costs the most and looks the most innocent. Two awaits in a row are sequential, even when neither depends on the other.

Three hundred and ninety milliseconds against one hundred and eighty, for a change that moves two await keywords. And the sequential version is what you get by writing the obvious thing, which is why this is worth checking for deliberately rather than expecting to notice.

The tell in review is a run of const x = await … lines at the top of a component. Some of those may genuinely depend on each other. Most do not.

When sequential is genuinely required

Some requests really do depend on earlier ones — you cannot fetch an artist's playlists before you know the artist's id. That is a dependency, not a mistake, and the tool is different.

The problem is not that the second request happens late. It is that everything else on the page is waiting behind both. Wrapping the dependent part in <Suspense> lets the rest render immediately and the chain stream in when it resolves.

That last observation joins this chapter to Part I. loading.tsx wraps the page in a Suspense boundary automatically, so the layout renders instantly and the whole page streams. Finer control comes from placing <Suspense> yourself, closer to the slow thing — and the documentation now recommends exactly that, because a boundary near the uncached access is more precise than one at the segment.

There is a caveat carried over from Part I worth restating in this context: a layout that performs uncached or runtime data access does not fall back to a loading.tsx in its own segment, because loading sits below layout in the hierarchy. It blocks the navigation instead. Wrap the slow part of the layout in its own boundary, or move the fetch into the page.

Getting data to client components

The last piece. A client component cannot query a database, so the data has to come from a server component — and there are three ways to send it, suited to different situations.

The absent await is genuinely the crux, and it is invisible in review — a diff that adds one is a diff that turns a streaming page into a blocking one, with no other change and no warning.

For data driven by interaction rather than by rendering — a search box, an infinite list, a polling widget — a client-side data library like SWR or React Query remains entirely appropriate. That is the legitimate case from the previous part, and the boundary between it and the anti-pattern is the same test: is this data needed to render, or because something happened.

Common Mistakes

1. Assuming fetch is still cached by default. It is not, since Next.js 15. Every request goes to the network unless you cache it deliberately.

2. Forgetting that an uncached fetch blocks rendering. A slow third-party call holds the whole page until it returns, however small the component that made it.

3. Consecutive awaits for independent requests. A request starts when the function is called, not when it is awaited. Call them all, then Promise.all.

4. Breaking memoization by accident. A trailing slash, a cache-busting parameter, or a header added at one call site and not another makes two requests out of what looks like one.

5. Expecting memoization to apply in a Route Handler. It does not — route handlers are not part of the React component tree.

6. Expecting memoization to cover an ORM call. It only applies to fetch. Wrap other data functions in React's cache().

7. Reaching for caching to fix a slow personal request. Caching removes the request; only streaming keeps it and stops it blocking. Per-user data is a streaming problem.

8. Adding an await in front of a promise you meant to pass down. The Suspense fallback then never shows and the page blocks. The missing keyword is the feature.

9. Putting an uncached fetch in a layout and expecting loading.tsx to cover it. loading sits below layout, so the navigation blocks instead. Wrap it in its own boundary or move it to the page.

10. Debugging stale data in development without reloading. The HMR cache applies even to cache: 'no-store' and clears on navigation or a full reload.

Interview Corner

Summary

• fetch is not cached by default in current Next.js, and an uncached request blocks rendering until it completes.

• Identical fetch requests are memoized within a render pass, so fetch in the component that needs the data rather than drilling it down.

• The memo key is method, URL and options. A trailing slash, a query parameter or a header added at one call site makes a second request.

• Memoization is not a cache — it collapses duplicates within one request — and it does not apply in route handlers or to non-fetch calls. Use React's cache() for those.

• A request starts when you call the function, not when you await it, which is the whole of the parallelisation technique.

• Consecutive awaits are sequential even for independent data. Call them all, then Promise.all.

• Layouts and pages render in parallel by default; the waterfall is something you create inside a single component.

• A genuine dependency is not a waterfall. Do not flatten it — wrap it in <Suspense> so it stops blocking the rest of the page.

• Caching and streaming answer different questions. Caching removes the request; streaming keeps it and stops it blocking. Personal data is a streaming problem.

• To get data into a client component, pass the unresolved promise and read it with use(). Adding an await in the server component silently undoes the streaming.

Reading is only half of it. The next chapter turns to writing — how a form submission or a button click runs code on the server without an API route, what a Server Action actually is on the wire, and why the ergonomics of calling a function hide a public endpoint that has to defend itself. The next chapter is Server Actions.