nextjs - 💡(How to fix) Fix Next.js 16 + Turbopack: basePath causes 10-20x slower renders on subsequent requests [1 comments, 2 participants]

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 24.6.0
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 22.21.1
  npm: 10.9.2
  pnpm: 10.12.1
Runtime Versions:
  React: 19.2.3
  Next.js: 16.1.1

Which area(s) are affected?

Turbopack

Link to reproduction

Reproduction steps below (no public repo yet)

Describe the Bug

When using basePath in Next.js 16 with Turbopack (default), subsequent page requests take 10-20x longer to render than the first request.

Without basePath (FAST):

GET /core-features/auto-negotiations 200 in 422ms (compile: 13ms, render: 409ms)
GET /core-features/auto-negotiations 200 in 79ms (compile: 12ms, render: 67ms)
GET /core-features/auto-negotiations 200 in 80ms (compile: 10ms, render: 70ms)
GET /core-features/auto-negotiations 200 in 55ms (compile: 6ms, render: 49ms)

With basePath: '/docs' (SLOW):

GET /core-features/auto-negotiations 200 in 1761ms (compile: 1110ms, render: 651ms)
GET /core-features/auto-negotiations 200 in 8.8s (compile: 1055ms, render: 7.8s)

The pattern is consistent:

• First request: ~500-650ms render
• Second+ requests: 7-19 seconds render (10-30x slower)

Minimal reproduction

1. Create a Next.js 16 app with Turbopack (default)
2. Add basePath: '/docs' to next.config.mjs
3. Run npm run dev
4. Load any page twice
5. Observe the massive slowdown on the second request

next.config.mjs

/** @type {import('next').NextConfig} */
const config = {
  reactStrictMode: true,
  basePath: '/docs',  // This causes the slowdown
  output: 'standalone',
};

export default config;

Workaround

Disable basePath in development:

const config = {
  basePath: process.env.NODE_ENV === 'production' ? '/docs' : undefined,
};

Expected Behavior

Subsequent requests should be faster than or equal to the first request (due to caching), not 10-20x slower.

Additional context

• This does NOT occur when basePath is removed
• The slowdown is in the "render" phase, not compile
• Tested with fumadocs-mdx but the issue reproduces on the homepage which uses minimal components
• Console.log timing showed that actual code execution (like source.getPages()) takes <1ms - the slowdown is elsewhere in the render pipeline