Next.js Build Time Nearly Doubles After Integrating @sentry/nextjs

[dalnoki]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

^9

Framework Version

Next.js Version: 14.1.0

Link to Sentry event

No response

Reproduction Example/SDK Setup

No response

Steps to Reproduce

After integrating @sentry/nextjs into the customer's Next.js project, they noticed a significant increase in build times. The build time consistently jumps from about 21–22 seconds to ~47–60 seconds, despite excluding Sentry Replays. Additionally, it appears the build process is running on a single processor core, leading to slower performance.

Build Time Comparison:
With Sentry:
Install: ~10s
Build: ~47-60s
Without Sentry:
Install: ~7s
Build: ~21-22s

Sentry SDK Configuration:
sentry.client.config.js | sentry.edge.config.js | sentry.server.config.js

all three files are same as below

import * as Sentry from "@sentry/nextjs";

Sentry.init({
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,

// Define how likely traces are sampled. Adjust this value in production, or use tracesSampler for greater control.
tracesSampleRate: 1,

// Setting this option to true will print useful information to the console while you're setting up Sentry.
debug: false,
});

Calculated build time using following commands -
time npm install
time npm run build

Expected Result

Minimal or no impact on build time after integrating Sentry, or at least a smaller overhead compared to the observed near-doubling in build duration.

Actual Result

Build time increases by over 100% (from ~21–22 seconds to ~47–60 seconds).

[lforst]

Hi, we are aware of this. The reasons for increased build times are:

• Next.js is generating sourcemaps not ideally efficiency-wise (I believe due to webpack) eating a lot of memory and CPU. Here we cannot do anything from the SDK perspective. As a user, you could disable sourcemap generation but this will drastically reduce UX when using Sentry because you will not be able to see your original source code in issues.
• Sourcemap upload: We are uploading sourcemaps to Sentry a bit inefficiently and consume a lot of memory. We are in the process of fixing this and it has already improved a lot. I recommend using the most up to date version of the Next.js SDK and @sentry/cli subdependency.

[vernak2539]

Thanks @lforst, we're seeing this as well (sentry v8).

Totally understand the first point. Do you think using a different bundler, like rspack, will help with the issue? (we're not looking to disable sourcemap generation or the reasons you say). I've given it a try and not sure if it helps or not, but was hoping to confirm (I'll continue to look into it)

[lforst]

@vernak2539 I cannot recommend nor discourage switching bundlers tbh. I wouldn't. What I can recommend is updating to the latest SDK version (v9) because we had some improvements wrt memory consumption.