outputFileTracing increases export build time by 1.5-2x

[lnewson]

Link to the code that reproduces this issue

https://github.com/lnewson/nextjs-reproduction

To Reproduce

1. Run yarn build and take note of the time (~5s for me)
2. Edit next.config.ts and change outputFileTracing to true (or just delete it)
3. Run yarn build and take note of the time (~8s for me)
4. Attempt to exclude all files from being traced by adding the following and run yarn build, but note it makes little to no difference.

  experimental: {
    outputFileTracingExcludes: {
      '**/*': ['./**/*'],
    },
  },

Current vs. Expected behavior

We've not long upgraded to Next.js 14 and logging this issue per the following warning added in Next.js 14:

⚠ Disabling outputFileTracing will not be an option in the next major version. Please report any issues you may be experiencing to https://github.com/vercel/next.js/issues

The expected behaviour would be that the file tracing can either be disabled still or that having it enabled does not drastically reduce export build performance. Ideally for export builds, as I cannot see a reason for it in that case, it would be good if it didn't run at all.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000
  Available memory (MB): 65536
  Available CPU cores: 10
Binaries:
  Node: 20.11.1
  npm: 10.2.4
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.4.3
Next.js Config:
  output: export

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

Performance, Upstream

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

next build (local)

Additional context

For our use case we are just using Next.js as a static site generator and then hosting the generated output using a webserver. So having the file tracing done does not help us in anyway I'm aware of and I'm not sure it even makes sense for it to be running in export mode?

In our production system the file tracing performance issue is much worse (~2000 mdx pages). Build times go from ~6mins to ~10-12mins (these run on linux/ubuntu AWS EC2 instances).

This issue also occurred throughout various versions of Next.js 13. I also tested this using Next.js 14.1.4 as an early upgrade PoC. I'm not sure if it ever didn't cause an issue with export performance as we've only used Next 13.2 or higher.

I've left all dependencies in package.json in case that helps to debug issues (excluding 2 internal only ones as those cannot be included).

Note: I've made each build clear any caches to reproduce the issue more clearly. Having a cache does not impact the file tracing time though in testing and in fact just makes the proportions worse as the webpack build part takes less time.

[lnewson]

This is potentially related to #60754 but that one was about windows and didn't use export mode.

[TheThirdRace]

This is potentially related to #60754 but that one was about windows and didn't use export mode.

This is definitely related; I saw the same type of results on my side using Windows and the WSL2.

outputFileTracing	build time
false	8s
true	16s

The build is twice as long with the file tracing enabled. I don't know what justified the need to change the original method or its removal, but the file tracing issue hits hard for build times.