#I'm compiling 20k pages, and it's only using a fraction of my CPU

30 messages · Page 1 of 1 (latest)

spark prism
#

I'm on the latest version of next.js (13.4?), and I've put together a benchmark to see how next.js would perform on my 20k page website.

I'm running next build, with the export option turned on. It only seems to be maybe a single CPU core. Is there a way I can speed this up further? I haven't added things like CSS or images to my test to optimize yet, so if there is no parallelization currently, I'm worried this will slow down too much.

I need static site generation. ISR isn't an option for me.

tender stratusBOT
#

🔎 This post has been indexed in our web forum and will be seen by search engines so other users can find it outside Discord

      🕵️ Your user profile is private by default and won't be visible to users outside Discord, if you want to be visible in the web forum you can add the "Public Profile" role in <id:customize>

      ✅ You can mark a message as the answer for your post with `Right click -> Apps -> Mark Solution`
      (if you don't see the option, try refreshing Discord with Ctrl + R)
brittle prawn
#

Check out these options

#

They aren’t documented

#

But there’s an option for experimental.cpus

#

But by default it should try to use all of them…

#

Maybe enable workerThreads

brittle prawn
#

One more thing you could do

#

Increase the heap size

#

So it utilizes more of your available memory

spark prism
brittle prawn
#

Take a look at the code I linked

#

Those are all the options available in your next config

#

So you would add the corresponding option to your next config

#

To enable it

#

But I think your biggest win here will be increasing the heap size

timid dune
#

I was wondering about how are you compiling 20k pages?

spark prism
#

So right now, it's just relatively simple .tsx pages. We're working on generating tests that are more complicated.

We're evaluating moving everything over to next.js.

brittle prawn
#

You mentioned that ISR isn't an optoin

#

does that include using the "fallback" strategy ?

#

the idea is that you only build a subset of all your popular pages during build-time

#

and the remaining pages will be built on demand when a user navigates to them

#

and then the newly built paged will be served for subsequent requests

spark prism
#

How can I choose what pages are built at buildtime?

brittle prawn
#

by using the fallback option

#

the ones without fallback enabled will be built

#

you need to define a getStaticPaths function which returns a list of all the page paths