Comment diviser les gros fichiers de traduction : Chargement par namespace pour des apps plus rapides
Vos fichiers de traduction tuent silencieusement vos temps de chargement. Une application internationalisée typique avec plus de 500 clés génère des...
Table des matières
Vos fichiers de traduction tuent silencieusement vos temps de chargement. Une application internationalisée typique avec plus de 500 clés génère des bundles de traduction de 400-800 Ko par langue. Multipliez cela par 15 langues et vous servez 6-12 Mo de traductions — dont la plupart ne sont jamais vues par les utilisateurs.
Ce guide couvre pourquoi cela se produit, comment le découpage par namespace le résout, et les patterns d'implémentation pratiques qui réduisent les charges de traduction de 90-97%.
Le coût caché des fichiers de traduction monolithiques
La plupart des configurations i18n commencent simplement : un fichier translations.json par locale. Cela fonctionne bien à 50 clés. Mais les apps en production grandissent vite :
| Échelle | Clés | Taille (gzip) | Impact |
|---|---|---|---|
| Petite app | 50 | ~2 Ko | Négligeable |
| App moyenne | 500 | ~18 Ko | Notable en 3G |
| Grande app | 2 000 | ~70 Ko | Significatif |
| Entreprise | 5 000+ | ~200 Ko | Goulot critique |
Exemple réel : Notre propre landing page chez Better i18n a atteint 699 clés dans 59 namespaces. Le translations.json anglais faisait 478 Ko. La traduction hindi 841 Ko. Chaque visiteur téléchargeait le fichier entier — même pour la page tarifs seule (14 clés, ~2 Ko nécessaires).
Que sont les namespaces i18n ?
Les namespaces sont des groupes logiques dans vos traductions — organisés par page, fonctionnalité ou domaine :
{
"hero": {
"title": "Expédiez vos traductions plus vite",
"subtitle": "Localisation pilotée par l'IA pour les apps modernes"
},
"pricing": {
"title": "Tarification simple et transparente",
"monthly": "Mensuel",
"yearly": "Annuel"
}
}
Des bibliothèques comme i18next, react-intl et Better i18n supportent les namespaces. L'utilisation typique est useTranslations("pricing") — vous indiquez déjà au SDK quel namespace vous avez besoin.
Trois stratégies de découpage
Stratégie 1 : Fichiers CDN par namespace
Avant : /en/translations.json → 478 Ko (59 namespaces)
Après : /en/hero.json → 1,2 Ko, /en/pricing.json → 2,1 Ko, ...
Quand une page a besoin de hero + pricing + footer :
- Avant : 478 Ko → Après : 4,1 Ko (99% de réduction)
Stratégie 2 : Paramètre de requête namespace
GET /en/translations.json?ns=hero,pricing,footer
← Retourne uniquement les namespaces demandés (~4 Ko)
Stratégie 3 : Code splitting au build
const i18nConfig = {
resourceLoader: (language, namespace) =>
import(`./locales/${language}/${namespace}.json`),
};
Benchmarks de performance
| Métrique | Avant | Après | Amélioration |
|---|---|---|---|
| Charge traduction | 478 Ko | 12 Ko | 97,5% plus léger |
| Time to First Byte | 180ms | 45ms | 75% plus rapide |
| Bande passante CDN/mois | 48 Go | 2,1 Go | 95,6% de moins |
| Taux de cache hit | 62% | 94% | +32 points |
Conclusion
Les gros fichiers de traduction sont un problème de performance résolvable. Pour les apps servant 15+ langues avec 500+ clés, ce changement peut réduire les charges de traduction de 90-97% et la bande passante CDN de 95%.