next-intl middleware extremely slow with large number of locales (~140+)

[lxup]

Description

When using createMiddleware(routing) with a large number of locales (100+), the next-intl middleware becomes extremely slow even in a minimal setup.

With ~140 locales in routing.locales, the middleware takes ~120–180 ms per request.
With only a few locales (<5), it runs in ~1–3 ms.

This slowdown happens:

• before any dictionary loading
• without any additional middleware logic
• in both dev and production builds
• with or without other integrations (Supabase, Auth.js, etc.)

This suggests that locale negotiation or internal matching scales linearly with the number of locales. Because only prefix detection + cookie + Accept-Language is needed, the middleware should not degrade significantly with a larger locale list.

This makes next-intl difficult to use in multilingual applications that support many regional variants (e.g. fr-FR, de-CH, en-GB, etc.).

Verifications

• I've verified that the problem I'm experiencing isn't covered in the docs.
• I've searched for similar, existing issues on GitHub and Stack Overflow.
• I've compared my app to a working example to look for differences.

Mandatory reproduction URL

https://github.com/lxup/next-intl-middleware-slow-repro

Reproduction description

Steps to reproduce:

1. Open the reproduction repository.
2. Notice that supportedLocales contains ~140 generated locales.
3. Start the dev server or run a production build.
4. Load any page and check the console output in the server logs.

Observed:

• The line Intl middleware took: XXX ms consistently reports ~150 ms.
• Reducing the locale list to 3 items makes the middleware drop to ~1–2 ms.

Expected behaviour

The next-intl middleware should remain performant regardless of the number of supported locales.

Locale negotiation should be fast because it normally involves:

1. Detecting a prefix
2. Reading a cookie
3. Optionally parsing Accept-Language

None of these operations require scanning every locale or performing heavy operations.

Expected:

• Middleware execution time should remain close to ~1 ms even with many locales (100+).
• Locale negotiation should not scale linearly with the number of locales.
• Apps supporting many regional locales should not suffer a 100–150 ms overhead per request.

[amannn]

Interesting, thanks for sharing this! I see the same results on my machine with your reproduction. Not sure off the top of my head what causes this.

Would you by chance be interested in profiling this to diagnose where exactly the time is spent?

[lxup]

I managed to isolate the issue. It turns out the bottleneck wasn't the link generation, but the syncCookie logic—specifically the unconditional call to getAcceptLanguageLocale.

1. Profiling Analysis

I added performance timings to middleware.tsx and syncCookie.tsx. With ~140 locales, here is the breakdown:
Middleware Top-level:

[next-intl-timing] start:0ms, prepare:0ms, resolveLocale:0ms, logic:1ms, syncCookie:130ms, alternateLinks:1ms, total:132ms

Inside syncCookie:

[syncCookie-timing] getAcceptLanguageLocale: 131ms
[syncCookie-timing] total: 132ms

The issue is that getAcceptLanguageLocale (which performs the expensive negotiation/matching) is called on every request, regardless of whether it's actually needed to decide on the cookie update.

2. The Fix

I refactored syncCookie to check the existing cookie status before attempting to negotiate the locale from headers. We only need to run the expensive getAcceptLanguageLocale if no cookie is present.

Here is the optimized implementation:

export default function syncCookie<
  // ... generics
>(
  request: NextRequest,
  response: NextResponse,
  locale: Locale,
  routing: /* ... */,
  domain?: DomainConfig<AppLocales>
) {
  if (!routing.localeCookie) return;

  const {name, ...rest} = routing.localeCookie;
  const hasLocaleCookie = request.cookies.has(name);
  const hasOutdatedCookie =
    hasLocaleCookie && request.cookies.get(name)?.value !== locale;

  // Optimization: Check cookie status first to avoid expensive header parsing
  if (hasOutdatedCookie) {
    response.cookies.set(name, locale, {
      path: request.nextUrl.basePath || undefined,
      ...rest
    });
  } else if (!hasLocaleCookie) {
    // Only pay the performance cost if we absolutely need to derive from headers
    const acceptLanguageLocale = getAcceptLanguageLocale(
      request.headers,
      domain?.locales || routing.locales,
      routing.defaultLocale
    );
    
    if (acceptLanguageLocale !== locale) {
      response.cookies.set(name, locale, {
        path: request.nextUrl.basePath || undefined,
        ...rest
      });
    }
  }
}

3. Results

After applying this change, the performance impact is massive. The middleware overhead dropped from ~132ms to ~3ms with the same dataset (140 locales):

[next-intl-timing] start:0ms, prepare:0ms, resolveLocale:0ms, logic:1ms, syncCookie:1ms, alternateLinks:1ms, total:3ms

I've prepared a fix. I will open a PR shortly so you can review the changes!

[amannn]

Damn that's super impressive, thank you so much for digging into this @lxup! ❤️

Let me have a look at your PR …