Compilation performance regression when enabling canary features

[apostolos]

Link to the code that reproduces this issue

https://github.com/apostolos/next.js-repro-canary-regression

To Reproduce

1. Enable any experimental feature that switches to react canary (via next.config.ts)
2. Start the dev server and open http://localhost:3000
3. Refresh the page or change any part of the code and wait for HMR
4. Notice compilation time regression

Current vs. Expected behavior

When we don't have any experimental features enabled, page rendering & HMR speeds remain fast and consistent.

After enabling any experimental feature that requires canary react (PPR, viewTransition, taint, etc.), compilation speeds are majorly affected.

We notice anything between 3x to 5x slowdowns in webpack. Turbopack is even worse, sometimes reaching multi-second HMR compilation times in a medium-sized codebase.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:25 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6020
  Available memory (MB): 32768
  Available CPU cores: 12
Binaries:
  Node: 24.3.0
  npm: 11.4.2
  Yarn: 1.22.22
  pnpm: 9.15.9
Relevant Packages:
  next: 15.4.0-canary.114 // Latest available version is detected (15.4.0-canary.114).
  eslint-config-next: N/A
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.8.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Performance

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

We tested the reproduction in most of the latest canaries.

AFAICT, the biggest regression starts in v15.4.0-canary.98

React gets upgraded in #80804 from 197d6a04-20250424 to fa3feba6-20250623 with tons of Flight updates getting merged, so hard to tell what exactly is going on.

_NEXT-4612

[ztanner]

Hi @apostolos, thank you for the report.

A number of performance related improvements have landed in React that we've upstreamed into Next.js. Can you confirm that things appear to be better with the latest canaries?

[apostolos]

Yes! Things feel significantly better now.

From my non-scientific benchmark:
(cold full page rendering -> followed by full refreshes -> followed by HMRs)

STABLE

CANARY

Slowdown is now under 2x across the board. This maybe is expected ?? (we actually do use canary features like Activity, Taint, and Transitions in the canary version).

In any case, this is perfectly usable now. Many thanks!

Are more improvements coming later?

[ztanner]

Glad to hear it's faster 🙌

We're definitely always working to balance optimization with better dev tooling, so appreciate when you flag stuff like this so we can make sure it's addressed.

From the compilation side of the world, you can try the Turbopack tracing util to get insight on where the time is spent.

Going to close this as the underlying performance regression has been addressed, but don't hesitate to open a new issue if you encounter something else.

[apostolos]

@ztanner I tried tracing with weird results:

An HMR that supposedly is done in ~70-80ms ends up being served after 350-450ms:

Is that normal?

[github-actions]

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

[ztanner]

@ztanner I tried tracing with weird results:

An HMR that supposedly is done in ~70-80ms ends up being served after 350-450ms: Is that normal?

@apostolos apologies, I didn't see this. What you're seeing in that report is the time spent compiling. The delta you're seeing is likely overhead from rendering, which is going to be a mixture of your code and Next.js code. Next.js emits spans for the work it performs, which you can hook into with otel.