i18n in next.config.js introduces significant latency in App Router

[Envoy49]

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/z3jmlt

To Reproduce

1. Navigate to provided link
2. Fork it
3. Start server by running pnpm dev

Current vs. Expected behavior

The combination of App Router with Pages Router seems to introduce large latency.
We migrated some of our page routes to app routes as being suggested by an official Next.JS guide(gradual migration) but this process wasn't smooth and we still couldn't go life due to the latency issues on App Router.
We have done profiling of pages routes vs app routes with the help of load tests and could identify that P95 and P90 latency are 10X higher on App Router compare to Pages Router.
See below screenshot.

I also created a sandbox environment to try and confirm if this behaviour can also be observed there and below on dev server I can see near similar results related to latency.
I got /test-app-router in the app folder and /test-pages-router in pages folder.
Results are below:

 ✓ Starting...
 ✓ Ready in 2.4s
Browserslist: caniuse-lite is outdated. Please run:
  npx update-browserslist-db@latest
  Why you should do it regularly: https://github.com/browserslist/update-db#readme
 ○ Compiling / ...
 ✓ Compiled / in 4.5s (544 modules)
 GET / 200 in 4728ms
 GET / 200 in 35ms
 ○ Compiling /test-app-router ...
 ✓ Compiled /test-app-router in 512ms (516 modules)
 GET /test-app-router 200 in 767ms
 ⚠ Fast Refresh had to perform a full reload. Read more: https://nextjs.org/docs/messages/fast-refresh-reload
 ○ Compiling /test-pages-router ...
 ✓ Compiled /test-pages-router in 1761ms (744 modules)
 GET /test-pages-router 200 in 1879ms
 ⚠ Fast Refresh had to perform a full reload. Read more: https://nextjs.org/docs/messages/fast-refresh-reload
 GET /test-pages-router 200 in 14ms
 GET /test-pages-router 200 in 10ms
 GET /test-app-router 200 in 95ms
 GET /test-app-router 200 in 25ms
 GET /test-pages-router 200 in 8ms
 GET /test-app-router 200 in 24ms
 GET /test-pages-router 200 in 7ms
 GET /test-app-router 200 in 19ms
 GET /test-pages-router 200 in 6ms
 GET /test-app-router 200 in 16ms
 ⚠ Fast Refresh had to perform a full reload. Read more: https://nextjs.org/docs/messages/fast-refresh-reload
 GET /test-pages-router 200 in 54ms
 GET /test-app-router 200 in 28ms
 GET /test-pages-router 200 in 7ms
 GET /test-app-router 200 in 25ms
 GET /test-pages-router 200 in 7ms
 GET /test-app-router 200 in 18ms
 GET /test-pages-router 200 in 6ms

After caching is stabilised in browser we can clearly see that app router is 3x times slower than pages router.
This behaviour is making gradually migration from pages router to app router impossible.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.6.0
  Available memory (MB): 16384
  Available CPU cores: 10
Binaries:
  Node: 20.11.0
  npm: 10.2.4
  Yarn: N/A
  pnpm: 9.6.0
Relevant Packages:
  next: 14.2.4 // There is a newer version (14.2.7) available, upgrade recommended!
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2

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

Not sure

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

next dev (local), next build (local), Other (Deployed)

Additional context

Our production app is running on Linux system.
Same behaviour can be observed both on Linux(prod), Darwin(local) and sandbox environment provided in the link.

[WinnyBunny]

Could it be because of how Page/App routers cache data? as far as I know caching methods differ between this two router system.

[Envoy49]

Could it be because of how Page/App routers cache data? as far as I know caching methods differ between this two router system.

I don't see how caching can be related to this problem.
If you look at the example I provided there is just a simple page with h1 tag.

[Envoy49]

removing this in next.config.js fixes the issue but I am not sure how this can affect the app router?

  i18n: {
    locales: ["en-AU"],
    defaultLocale: "en-AU",
  },

here is the difference before and after

✓ Compiled /test-app-router in 394ms (479 modules)
 GET /test-app-router 200 in 730ms
 GET /test-app-router 200 in 248ms
 GET /test-app-router 200 in 238ms
 ⚠ Found a change in next.config.js. Restarting the server to apply the changes...
Debugger listening on ws://127.0.0.1:9230/3d8a59f2-3443-43f0-9bac-a41e079edf18
For help, see: https://nodejs.org/en/docs/inspector
   the --inspect option was detected, the Next.js router server should be inspected at port 9230.
  ▲ Next.js 14.2.8
  - Local:        http://localhost:3000/
  - Environments: .env
  - Experiments (use with caution):
    · externalDir
    · outputFileTracingRoot

 ✓ Starting...
 ✓ Ready in 1567ms
 ✓ Compiled /test-app-router in 392ms (479 modules)
 GET /test-app-router 200 in 506ms
 GET /test-app-router 200 in 30ms
 GET /test-app-router 200 in 38ms
 GET /test-app-router 200 in 48ms

[samcx]

@Envoy49 How exactly are you testing latency? If testing locally via next dev, I can see there might be possibly additional latency since everything is being served via a local Node.js server. If testing in a Serverless Environment such as Vercel, your Next.js app is served independently (e.g., different Static pages, or different Functions by Next.js Page), so you likely won't see the same level of latency.

This is also interesting because technically, i18n is not supported in App Router. This config was created with Pages Router. So when you use a single next.config.js with the i18n config for both your App and Pages Router, I can for-see issues happening.

A better solution that can work with both App and Pages Router is to use Middleware instead to handle Internationalization, which is supported equally in App and Pages Router.

[Envoy49]

Building thing and deploying to the branch which has its own domain. Lets call it pre production.
Creating load tests and calling all routes equally and I can see the latency. Plan application which has no code in it, only i18n in the config.

You are giving a suggestion but not sure if it is going to work or not and turning this from issue to discussion?
I am reporting this so you guys can investigate and try to reproduce.
I have no time or any will to do this myself and fix it for your platform.
And how could we know that a better solution is to use middleware when app router didn't exist?
Stop this nonsense

[zengxiangke]

I suspect this before. Now it is confirmed. Thanks a lot.

[kl13nt-tng]

Confirming that adding the locale configuration object in next.config.js on a blank project immediately pushes the average TTFB from ~10ms to 230+ms. We're using npm, not pnpm. So it's not a pnpm quirk at play.

[rafatairnz]

I can also confirm the above, as soon as I include i18n in any form/shape I can see the average TTFB going up 10x. Any one looking into this or know if it's nextjs version specific issue?
I'm on 14.2.26

[rafatairnz]

@leerob have you ever heard anything about this or have had anyone one come to you about it?

[annuaicoder]

This error happens because next/image requires you to explicitly allow external image domains.

To fix this, add "cdn.sanity.io" to your next.config.js like this:

// next.config.js
module.exports = {
  images: {
    domains: ['cdn.sanity.io'],
  },
};
Then restart your dev server.

This tells Next.js to trust images from Sanity’s CDN. You can read more here: https://nextjs.org/docs/api-reference/next/image#domains

Let me know if you’re still seeing issues after this change!

[rafatairnz]

The problem reported relates to i18n, including external image domains is likely related to something else.

[rafatairnz]

Sample here https://codesandbox.io/p/devbox/xvvg2r
It has been noted that dev mode is slower than prod and that's expected, but focus on perf times for having i18n and not having it.

• Navigate to /test1 and click the button to go to /test2 (First click after cold start usually takes considerably longer, you can click back and forward and then refresh the page)
• Keep navigating back and forward and you'll see times around 600ms between routes for this slow sandbox
• Now go to next.config.ts and remove the i18n config entirely, repeat the 1st step and notice how times drop by half (around 300ms)

Notes:
-router.push onClick of button was used intentionally for these example (has no noticeable perf disadvantages vs using Link)

The same experiment locally
Key takeaway here is that right after page load the navigation takes considerably longer when i18n is present.

with i18n

Screen.Recording.2025-06-03.at.10.55.16.AM.mov

without i18n

Screen.Recording.2025-06-03.at.10.56.53.AM.mov

[annuaicoder]

You're right — thanks for pointing that out. The external image domain config was unrelated to this specific issue, which is clearly tied to the i18n setup.

I checked the sandbox and can confirm the navigation is significantly slower with i18n enabled (around 600ms vs. 300ms without it). This seems to be due to the additional processing Next.js does for locale detection and routing.

Potential Solution:
If you don't need automatic locale detection or routing per locale, you can simplify your next.config.js like this:

// next.config.js
module.exports = {
i18n: {
locales: ['en'], // Use only one locale
defaultLocale: 'en',
localeDetection: false, // Turn off automatic detection
},
};
This retains the i18n structure (so it's future-proof if you add more locales later) but disables the overhead from detection logic.

Also, for projects that don't need i18n at all, removing the i18n block entirely will improve route transition speeds, especially in dev mode.

Let me know if tweaking the config this way improves performance for your case.

[rafatairnz]

For very simple apps that could work. But for more complex one (which is my case) there are several locales and we want the detection to happen.
The biggest question here is understanding what is causing it and if not something that can be solved "easily" then we explore other ways of implementing i18n for the project.

[annuaicoder]

That makes sense — thanks for clarifying. Since disabling locale detection isn't an option, the next step might be to profile where the slowdown is happening exactly. It could be related to how Next.js handles locale-aware routing or how pages are preloaded with different locale contexts.

You might try running your app with NODE_ENV=production and enabling Next.js’ trace output or profiling tools like Chrome DevTools or Web Vitals to pinpoint which part of the routing or middleware is adding the extra time.

If it turns out to be a limitation in Next.js’ built-in i18n, libraries like next-translate or react-intl might offer more control or better performance in complex setups.

Curious to hear what you find — we might be running into similar issues in the future.

[rafatairnz]

Browser profiling isn't too helpful, there's just ~500ms idle time that nothing happens and then the screen gets painted. So nextjs is doing something on the server-side before it can proceed to actually do anything on the browser.

profiling-data.30-05-2025.14-18-22.json

But yeah the idea is exploring other ways to implement i18n in case there is no solution for this specific issue

[annuaicoder]

Yeah, the slowdown is happening because when i18n is enabled — especially with automatic locale detection — Next.js adds extra logic during each route change. It checks the user's locale, rewrites the URL if needed, and sometimes loads different data or components based on the locale. That adds processing time, especially in dev mode where everything is less optimized.

One possible solution (without removing i18n) is to move locale detection to the edge using middleware, so it only runs once on initial load and not during client-side navigation. That can reduce the impact on every route change.

Also worth checking:

If your _middleware.js or server functions are locale-aware and slowing things down.

Whether you can lazy-load or cache translation files better.

If you're open to restructuring, libraries like next-intl or next-translate might give better performance in complex setups by handling i18n more efficiently at runtime.