Retour au blog
Ingénierie

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...

Ali Osman Delismen12 min de lecture

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 :

ÉchelleClésTaille (gzip)Impact
Petite app50~2 KoNégligeable
App moyenne500~18 KoNotable en 3G
Grande app2 000~70 KoSignificatif
Entreprise5 000+~200 KoGoulot 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étriqueAvantAprèsAmélioration
Charge traduction478 Ko12 Ko97,5% plus léger
Time to First Byte180ms45ms75% plus rapide
Bande passante CDN/mois48 Go2,1 Go95,6% de moins
Taux de cache hit62%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%.

Commentaires

Loading comments...

Related

Articles similaires