Indice
I tuoi file di traduzione stanno silenziosamente rallentando i tempi di caricamento delle pagine. Un'app internazionalizzata tipica con oltre 500 chiavi genera bundle di traduzioni di 400‑800KB per lingua. Moltiplicalo per 15 lingue e stai servendo 6‑12MB di traduzioni, la maggior parte delle quali gli utenti non vedranno mai.
Questa guida spiega perché succede, come la suddivisione per namespace risolve il problema e quali pattern di implementazione possono ridurre il payload di traduzione del 90‑97%.
Il costo nascosto dei file di traduzione monolitici
La maggior parte delle configurazioni i18n inizia in modo semplice: un file translations.json per lingua. Funziona bene con 50 chiavi, ma le applicazioni reali crescono rapidamente.
Con più lingue il problema si moltiplica: un'app con 500 chiavi e 15 lingue significa che il CDN serve centinaia di KB di traduzioni prima ancora che l'utente veda contenuto.
Cosa sono i namespace i18n?
I namespace sono gruppi logici di traduzioni, spesso organizzati per pagina o funzionalità. Librerie come i18next, react‑intl e Better i18n li supportano.
Strategie per dividere i file
File CDN per namespace
Pubblicare ogni namespace come file separato riduce drasticamente il payload caricato da ogni pagina.
Query parameter per namespace
Il server restituisce solo i namespace richiesti.
Code splitting a build time
Framework come Next.js o Vite possono dividere le traduzioni durante la build.
Conclusione
Per applicazioni con molte lingue e centinaia di chiavi, il caricamento per namespace riduce drasticamente il traffico CDN e migliora le performance.
