Next.js Discord

Discord Forum

SSG Build Error

Answered
Brown bear posted this in #help-forum
Open in Discord
Brown bearOP
I'm getting a build out of memory error in an SSG page. Why does this occur and is there a way to fix it?

Code:
export const dynamicParams = false;
export const revalidate = false;

type Props = {
  params: { addressSlug: string };
  searchParams: { [key: string]: string | string[] | undefined };
};

export async function generateStaticParams(): Promise<Props['params'][]> {
  const addressSlugs = (await db.property.findMany({
    // Limit ISR to only California addresses due to vercel build error memory, for now.
    where: { address: { state: 'CA' }, addressSlug: { not: null } },
    select: { addressSlug: true }
  })) as { addressSlug: string }[];

  return addressSlugs;
}

export default async function Page({
  params: { addressSlug }
}: Props) {
  const decodedAddressSlug = decodeURIComponent(addressSlug);

  return (
    <div>test<div/>
  );
}
Answered by joulev
you are trying to build 2.2 million pages during the build time. no build servers can handle that much load
View full answer

55 Replies

Answer
do something to make generateStaticParams return less than 2.2 million items
export const dynamicParams = true; (or just remove this export altogether), and only return, say, 100 most important items in generateStaticParams()
@joulev you are trying to build 2.2 million pages during the build time. no build servers can handle that much load
Brown bearOP
The reason I am building the 2.2 million pages is not for speed, but for SEO. If I do not get the pages registered, they will not be viewable when searched. Is there a better way to achieve this then?
Korat
ssr
@Brown bear The reason I am building the 2.2 million pages is not for speed, but for SEO. If I do not get the pages registered, they will not be viewable when searched. Is there a better way to achieve this then?
Vercel doesn’t send build data to google or whatever after the build completes. Generating 2.2m pages or 0 pages during the build time have no difference for SEO except for performance. Just ensure you have a sitemap with all the entities, valid links pointing to those pages, so on and so forth, then SEO is good.

Assuming each page takes 100ms to generate, which is astronomically unrealistic, 2.2m pages would still take 220k seconds. Are you really willing to wait 2.5 days for each build to complete, assuming you have a build machine sufficiently equipped to perform such a feat? Do you think sites like Facebook really wait for days and weeks to build all their pages for SEO? No right?
Brown bearOP
Makes sense, thanks. Will try to generate a sitemap with vercel. Hopefully that works out 🙂
@Brown bear But I do not think it is entirely unrealistic to generate all of those pages with the right architecture. If it were not for the cost of coding such a system, it could be cheaper to generate all of those pages, rather than server render at runtime. Building essentially renders every page. And if each page is viewed more than once a day, it would ultimately require less total page generation
If you do dynamicParams = true (ISR), it will always be rendered the optimal number of times, since non-prepared pages are rendered once during runtime and cached thereafter.

Users only visit 100k pages => only those 100k pages are built, once for each

Users visit all 2.2m pages => all those pages are built, once for each

Users visit all 2.2m pages, at least two visits per page => still only 2.2m generations, one for each page

No architectural system can get you something that can build 2.2m pages, each of them depending on an external source (e.g. a database), in a reasonable amount of time.
Total page generation for ISR is always less than or equal to the total number of possible pages
Brown bearOP
With ISR, will it build and store the page when requested at runtime? such that requests thereafter will retrieve the same page?
With an infinite revalidation time
Yes
Brown bearOP
That's nice. How much of the page is cached though? It all seems like magic to me. My page requests data and sends it to a react client component. Until what point does it stop the cache?
For a page that’s not built at build time but built at runtime as part of ISR, then from the second request to the page, it behaves exactly like a page that is built at build time
Brown bearOP
Yep, but how does the page even server side rendered? With nextjs, how am I supposed to know what exactly is being built and what is not?
Since client components are partially rendered on server too
With ISR, how am I supposed to know the performance gain if I don't know what is server side rendered
ISR is dynamic for the first request and static thereafter. Static here = pages that are generated at the build time (generateStaticParams)
Brown bearOP
Yes I understand ISR and SSG. But what is even being generated at build time? Is it the props from API call being sent to the client component, or API call and part of client component being prerendered?
I am under the assumption that ISR does the same thing as SSR, just with the page cached after the first time being sent
No I don’t have an answer for that, caching shenanigan is a complex topic that no one can answer fully. You can check the nextjs source to see what static and dynamic truly mean, though is it really that important?
Brown bearOP
Nope it isn't, I was just curious if ISR really gives much benefit.
From what it seems, the answer is maybe
It says that the url limit is 50,000 per sitemap. In the example, is it generating a sitemap per item in the returned array?
@Brown bear Nope it isn't, I was just curious if ISR really gives much benefit.
All you need to know is: ISR = on-demand generateStaticParams
That’s pretty much it
Brown bearOP
Oh wow the example is quite misleading. It returns an array of 3 ids but it ends up building 3 sitemaps with ids from 1-150,000. They should really change up the variable names...
Anyways I got my questions answered. Thank you very much @joulev for helping me out.
@joulev you are trying to build 2.2 million pages during the build time. no build servers can handle that much load
Brown bearOP
100,000 pages with a 26min build time amazing
looks like I'm going to wait a very long time every build 🙂
how about only generating 100 pages? that will change it to some 1-2 minutes
i don't see why you need to generate 100,000 pages in one go either, same reason that i don't see why you need to generate 2.2m pages in one go
you can add a page to the sitemap without building it in advance during the build time
fyi you have 6k minutes of build time per month for the free plan, and 24k mins per month for the pro plan (https://vercel.com/pricing). which means, for the free plan, you have 20 mins on average everyday – well enough for a typical project, but far too insufficient for the madness known as generation of 100,000 pages
and all builds will timeout after 60 minutes, regardless of how many pages you try to generate
Brown bearOP
Well it raises my site performance from 77 to 99
I'd say its worth it
6k minutes is for sure enough
still 230 builds a month
we'll see how sustainable this is
@joulev how about only generating 100 pages? that will change it to some 1-2 minutes
Brown bearOP
well then that defeats the purpose
might as well generate 0
@Brown bear Well it raises my site performance from 77 to 99
well whatever, your choice, i won't comment. just fyi amazon lighthouse score is 45
now that i have made my points, i won't be commenting on this matter. you will be entirely on your own
What is the difference between placing it in different routes SEO-wise?
Is there a difference
@joulev i suppose yes: <https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap#generating-multiple-sitemaps>
Brown bearOP
are the sitemaps generated at runtime?
For some reason they give this error
@Brown bear are the sitemaps generated at runtime?
1. Open a new post
2. Sorry I don’t know