- Expédié
- 26 août 2026 à 02:30 UTC
- Auteur
- kamo
- Commite
- c36c532
getRequestConfig par demande, et pour tout membre non-anglais qu'il appelle fusionwithWithFallback sur l'ensemble du catalogue 23 252 clés à chaque fois - reconstruire un résultat qui ne peut pas changer avant le prochain déploiement. Mesuré sur un CPU de bureau: 8-25 ms en fonction sur la localité, 16 ms en moyenne, de travaux à un seul étalage en face de la réponse. Une dose est plus lente qu'un bureau, et cela atterrit sur TTFB pour chaque chargement de page par chaque membre qui ne lit pas l'anglais. Caché par local pour la durée du processus. Le chemin anglais n'est pas touché, il ont déjà renvoyé le catalogue de base sans fusion. Deux choses le rendent moins cher qu'il n'y paraît. Elle est délimitée par la construction: isLocale() portes la clé avant qu'elle n'atteigne la carte, donc il y a au plus une entrée par support Ensemble, 21 d'entre eux. Et un catalogue mis en cacheté est pour la plupart gratuit et fusionwithgwithAchallback copies Les catégories de cordes plutôt que les chaînes, donc ce qui est retenu est un obtiendre d'objet sur s'enchaîne déjà le cache d'importation. Six exemplaires fusionnés ne se sont pas distingués de zéro dans une mesure de tas à travers des processus distincts. La solution anglaise pour un fichier local manquant est également mise en cache, délibérément. Locale les fichiers expédient à l'intérieur de l'image, de sorte qu'un absent à la première demande est absent pour toute la durée du processus; relire l'échec par demande n'a rien acheté. Coffre-fort à partager parce que rien ne le mute: le seul consommateur de getMessages() est app/layout.tsx, qui le lit et le donne à NextIntlClientProvider. Vérifié: tsc --noEmit nettoie sur i18n/ et app/layout.tsx avec leurs importations en transit.