Purpose of generateStaticParams in next js, and is it worth it?

[baranelitez]

Summary

I've been reading the next.js docs, and there are two things that puzzle me about the generateStaticParams.

#1: 1st thing that puzzles me is the paragraph at https://nextjs.org/docs/app/building-your-application/routing/dynamic-routes#generating-static-params .

The primary benefit of the generateStaticParams function is its smart retrieval of data. If content is fetched within the generateStaticParams function using a fetch request, the requests are automatically memoized. This means a fetch request with the same arguments across multiple generateStaticParams, Layouts, and Pages will only be made once, which decreases build times.

So the primary benefit is that generateStaticParams helps other occurences of generateStaticParams, making them faster? That makes me think that it's a no brainer NOT to use generateStaticParams at all, which nullifies the build time impact completely.

---

#2 I understand that it also generates the route before a request has been made as well. But that's what makes me wonder.. I'll try explaining with an example:

Case 1: For our blog posts, we don't use SSG (generateStaticParams):

As far as I know, once a dynamic route like /blog/posts/[slug] is hit, the content is generated at request time, stored in the "Full Route Cache" which is persistent, and then sent to the visitor's browser. Any visits from now on, whether it be 5 mins later or a month, will be sent from this cache. Negating the need for a re-render on server.

Case 2: We do use SSG (generateStaticParams):
All the possible routes are generated at build time and stored at the "Full Route Cache", and any requests to them will be delivered from that cache, negating the need for a re-render on server.

Now let's say in Case 1, we had all of our blog posts visited by previous visitors. And that will cause every rendered blogpost page to be stored in the "Full Route Cache", which effectively brings it to the same state with Case 2.

So in the end, all generateStaticParams can do for us is just making the first ever request a little bit faster. But in return, we lost the ability to run revalidation on those routes. <-- I'm not sure about that one

---

the TLDR version of my questions are:

1. The primary benefit to generateStaticParams is said to be faster generation times. The alternative is not generating these pages AT ALL, which definitely results in faster build time. Am I missing a point?
2. Disregarding the FIRST EVER visit to a route (let's say all our blog pages have taken a visit), Is there any runtime performance difference between if we use generateStaticParams or not ?

---

I might have some errors in my understanding of the concepts. If so, I apologize and would appreciate some enlightenment!

Additional information

No response

Example

No response

[icyJoseph]

The primary benefit to generateStaticParams is said to be faster generation times. The alternative is not generating these pages AT ALL, which definitely results in faster build time. Am I missing a point?

Yeah that's kind of odd.

I think, getStaticPaths, sums it up best. You can pre-render a bunch of pages upfront, and then decide whether or not you want this to be a closed set, or not.

If its a closed set, you can serve both the content, and 404's such for non existing content, right away. No on-demand needed.

If its an open set, then you can render an "important" sub set, by some heuristic, and then leave it open for on-demand generation of less "important" pages.

In both cases, you can also allow for revalidation, and have 404's have its own time to be cached as well, so that is new content does appear, it'll take over the 404.

getStaticPaths was more explicit about it.

I think this section of the migration, can help you: https://nextjs.org/docs/app/building-your-application/upgrading/app-router-migration#dynamic-paths-getstaticpaths to correlate both getStaticPaths and generateStaticParams, to actually gain insight into whats the problem the framework is trying to solve with them.

Having written all of this now, I think the claim, faster generation times, while certainly true, it is a bit of a catch-22. Since in App Router, you fetch the data where you need it. And there's no way to pass data from generateStaticParams to the page, you'd have to call the same data endpoint in both. At this point, your first reaction would be, that you are both being inefficient, and potentially even having diverging data if your data changes very frequently, but since the call to your data made at generateStaticParams, or fetch during render, at some point, would be cached, then you'd escape those two issues. 🤷

[baranelitez]

thanks for the answer! for me it appears as if it's just a "migration stepping stone" for people who were used to writing getStaticPaths/Props in case they want to write it still out of habit.

can you also confirm my second question? I assume there's no runtime performance difference between a GSP'd page, and a page that has been hit by anyone at least once. Am I right?

[icyJoseph]

can you also confirm my second question? I assume there's no runtime performance difference between a GSP'd page, and a page that has been hit by anyone at least once. Am I right?

I mean, a pre-rendered page has HTML, etc, which can be cached CDN level, whereas your counter example, still has to hit the server, do a quick pass rendering (using fetch cache, etc), and then serving the content. That can translate to very noticeable delays.