- Ya
- 26 Agosti 2026, 02:30 UTC
- Mwandishi
- kamo
- Ahadi ya
- c36c532
getRequestConfig runs per request, and for any non-English member it called mergeWithFallback over the entire 23,252-key catalogue every time — rebuilding a result that cannot change until the next deploy. Measured on a desktop CPU: 8-25 ms depending on the locale, ~16 ms on average, of single-threaded work sitting in front of the response. A pod is slower than a desktop, and this lands on TTFB for every page load by every member who is not reading English. Cached per locale for the life of the process. The English path is untouched — it already returned the base catalogue without merging. Two things make this cheaper than it looks. It is bounded by construction: isLocale() gates the key before it reaches the map, so there is at most one entry per supported locale, 21 of them. And a cached catalogue is mostly free — mergeWithFallback copies string REFERENCES rather than strings, so what is retained is an object spine over strings the import cache already holds. Six merged copies were not distinguishable from zero in a heap measurement across separate processes. The English fallback for a missing locale file is cached too, deliberately. Locale files ship inside the image, so one that is absent at the first request is absent for the whole life of the process; re-reading the failure per request bought nothing. Safe to share because nothing mutates it: the only consumer of getMessages() is app/layout.tsx, which reads it and hands it to NextIntlClientProvider. Verified: tsc --noEmit clean over i18n/ and app/layout.tsx with their transitive imports.