Request Memoization in Next.js

I’ve been using Next.js for about two years, and it still amazes me both how elegant the framework is and how much it streamlines development. It wasn’t always straightforward—until I dove in, spent countless nights learning how caching and rendering strategies actually work under the hood. You see, it’s vital to understand why a framework was built in the first place, and how it works, before one can learn to use the appropriate tools required to solve a problem.

So, what can you expect from this series?

To be honest, I would like this blog to be a conversation between me and you, who is reading it. It took me some time to learn the concepts and it can only be helpful if you put your doubts and questions in the comments, or maybe even write to clarify my words on something if you think I may have made a mistake somewhere. With that out, let’s focus on the most basic thing that Next.js does, which is not even a Next.js feature but a React feature - Request Memoization.

Enter Request Memoization

Traditionally, we had to carefully choose where to declare our fetch calls (or axios requests) to avoid redundant network trips that degrade performance. Often that meant fetching data in a parent component and prop-drilling the result to children.

Request memoization solves this elegantly. If multiple parts of the component tree request the same resource during one render, React issues a single network request, caches the response in memory, and serves that same response to every caller.

In simple terms, it deduplicates identical requests you write—so you don’t have to micro-optimize where you call fetch().

What’s great is that you, as a developer, no longer have to worry about deciding where to put that fetch API in your codebase so as to not affect the performance of your application and making a potential unnecessary request. Write your data needs where they belong in the UI, and memoization handles the rest. Isn’t that awesome?

(During the initial request, the request is not memoized, so it’s a cache miss. The data is fetched from the data source, and stored in the Request memoization cache (RM Cache). For subsequent requests for the same data, the response is returned directly from the cache, thereby reducing the number of requests and load on the data source.)

However, there are few things that you need to keep in mind.

• Request memoization is not a NextJS feature. It’s a react specific feature.

• It’s scope is limited to the current render pass and is cleared once the rendering ends.

• Since it’s scope is limited to rendering of a component tree, request memoization is applicable to fetch APIs defined under pages, layouts, and server components. However, it’s not applicable to fetch requests defined under route handlers as that is not part of the component tree.

Well that’s it for this blog. In upcoming posts, we will be diving into Next.js rendering modes (SSG, ISR, SSR) and show how each interacts with the Data Cache, compare force-cache, no-cache, and revalidate settings with real-world examples, and demonstrate how Next.js’s full-route caching wraps around React’s request memoization for end-to-end performance.