Degraded pages-directory build performance in next.js@v13.2.5-canary.26 and higher (13.3, 13.4) (2-7x slower)

[klaasman]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6000
Binaries:
  Node: 18.15.0
  npm: 9.5.0
  Yarn: 1.22.19
  pnpm: 8.6.0
Relevant packages:
  next: 13.4.6-canary.0
  eslint-config-next: 13.4.5
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3

Which area(s) of Next.js are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue or a replay of the bug

https://github.com/klaasman/nextjs-build-performance-issue

To Reproduce

1. Clone repo
2. Run npm install - this will install next@v13.2.4
3. Run rm -rf .next to remove the build cache (if any)
4. Run npm run build - measure the build duration
5. Run npm install next@v13.2.5-canary.26
6. Run rm -rf .next to remove the build cache
7. Run npm run build - measure the build duration

The second build will/should be significantly slower.

Describe the Bug

I've ran into significant build performance issues since upgrading next.js from v13.2.4 to v13.3.0 or higher. The build duration of a project I'm working on became easily 2-3x slower after the upgrade. Building on vercel usually takes about 10 minutes, but after the upgrade it was 25-30 minutes.

After a lot of digging I was able to narrow it down to the v13.2.5-canary.26 release.

Luckily, it is easy to reproduce the issue with the attached repo. The repo even shows a 2-7x slower build compared to v13.2.4.

Steps to reproduce

This repo contains a simple next.js project with a pages-directory containing 200 pages (/pages/number/[number].tsx) which fake a 1 second delay before rendering the page. Not sure if this is relevant, but it helps to make the issue more visible.

1. Clone this repo
2. Run npm install - this will install next@v13.2.4
3. Run rm -rf .next to remove the build cache (if any)
4. Run npm run build - measure the build duration
5. Run npm install next@v13.2.5-canary.26
6. Run rm -rf .next to remove the build cache
7. Run npm run build - measure the build duration

The second build will/should be significantly slower.
See below for my results in finding the offending release. Note that I cleared the .next dir after each build.

Results

• 0m30s for next@v13.2.4
  ~30 seconds is the expected duration
• 0m31s for next@v13.2.5-canary.14
• 0m30s for next@v13.2.5-canary.22
• 0m31s for next@v13.2.5-canary.24
• 0m31s for next@v13.2.5-canary.25
• 3m30s for next@v13.2.5-canary.26
  ⚠️ this is where the build duration starts to degrade (next@v13.2.5-canary.26 release notes)
• 3m34s for next@v13.2.5-canary.28
• 3m33s for next@v13.2.5-canary.29
• 3m23s for next@v13.3.4
  maybe it got fixed somewhere in the v13.3.x range, but 13.3.4 doesnt show any improvement
• 1m01s for next@v13.4.5
  good improvement in next's latest release(s), but still 2x slower than v13.2.4
• 1m02s for next@13.4.6-canary.0

Expected Behavior

Pages directory build performance in v13.3.x and higher should not become 2-7x slower compared to next@v13.2.4

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

vercel

[HamAndRock]

I assume it's also related to #45508

[sannajammeh]

Also related to #50555 . Canary.26 seemed to introduce the issues

[ijjk]

Hi, this has been updated in v13.4.6-canary.3 of Next.js, please update and give it a try!

[klaasman]

Fantastic, I can confirm this resolved the issue - thanks! Do you have an ETA for v13.4.6?

[wadehammes]

Can also confirm this fixed build times for me on Vercel. Thanks @ijjk!

[ijjk]

Hi, the above patch is now available in v13.4.6!

[Enngage]

Hey @ijjk, we face the opposite problem as our builds are significantly slower in v13.4.6. We are initializing data from external systems, which takes some time (think 20 seconds). We want to leverage caching with some semaphores to ensure that this initialization happens only once.

However, each component where we attempt to use our data keeps hitting external systems simultaneously. This overloads our servers and is extremely slow because we can't reuse the cache. We can sort of workaround this by storing data in FS (or Redis or something similar) and using process.env to handle semaphores but surely there is a better way of doing this?

We have a similar issue during development as well as each change keeps flushing the memory cache. The documentation states that data should be fetched at 'component' level (https://nextjs.org/docs/app/building-your-application/data-fetching#fetching-data-at-the-component-level) but doing so is extremely inefficient if the "initialization" is slow because you can't use memory cache to store the result and each component triggers data reload all over again. We could use a similar approach as above, but there are many pitfalls there as well.

Do you maybe have some recommendations as to how to approach this? Ideally, we would add some sort of "bootstrap" call that gets called only once before all the build happens so we can pre-load all necessary data. Same with the dev & hot reload enabled.

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.