WordPress 6.5, sorti en avril 2024, a introduit un nouveau format de fichier de traduction : le .l10n.php, généré à côté du .mo classique et chargé en priorité par le cœur quand il est disponible. L’idée est simple : un fichier PHP qui retourne directement un tableau de traductions se charge plus vite qu’un format binaire qu’il faut d’abord parser avec MO::import_from_file().
Sur un site institutionnel décliné en dix langues, avec plusieurs milliers de chaînes traduites par langue (thème, plugins, contenu du cœur), la question méritait une mesure plutôt qu’une intuition. Voici ce que la comparaison a montré, protocole et limites compris.
Le protocole de mesure
Le site tourne sur WordPress 6.6 avec PHP 8.2 et OPcache activé. Pour isoler l’effet du format de traduction, deux versions du même environnement ont été comparées : l’une avec uniquement des fichiers .mo (renommage temporaire des fichiers .l10n.php pour forcer le repli), l’autre avec les deux formats présents, comme en configuration normale. Le point mesuré est le temps cumulé passé dans les fonctions de chargement de domaine de texte, via load_textdomain(), sur une requête de page d’accueil chargeant successivement les dix locales à tour de rôle (dix passages, moyenne retenue).
- Dix langues actives, entre 1 800 et 3 200 chaînes traduites par langue selon la locale.
- OPcache activé dans les deux scénarios, pour ne pas mesurer un effet de cache de bytecode plutôt qu’un effet de format.
- Dix passages par scénario, moyenne et écart-type relevés.
Le résultat chiffré
Le temps cumulé de chargement des chaînes traduites passe d’une moyenne de 41 millisecondes avec uniquement des fichiers .mo à 29 millisecondes avec les fichiers .l10n.php disponibles, soit un gain d’environ 30 % sur ce poste précis. Rapporté au temps de génération total de la page, qui tourne autour de 180 millisecondes sur ce site, le gain absolu reste modeste, de l’ordre de quelques pour cent du temps total. Sur un site à forte densité de traductions comme celui-ci, l’effet est cependant mesurable et cohérent d’un passage à l’autre, avec un écart-type resserré.
| Scénario | Temps moyen de chargement des chaînes | Écart-type |
|---|---|---|
| Fichiers .mo uniquement | 41 ms | 3,1 ms |
| Fichiers .l10n.php disponibles | 29 ms | 2,4 ms |
L’explication technique tient à la nature du format. Un fichier .mo est un format binaire structuré qu’il faut lire et parser à chaque appel non mis en cache, via la classe MO du cœur. Un fichier .l10n.php est un fichier PHP qui retourne directement un tableau associatif : PHP le charge comme n’importe quel script, et OPcache met en cache son bytecode compilé exactement comme pour n’importe quel autre fichier PHP du site. Le gain observé vient largement de cette synergie avec OPcache, pas seulement du format en lui-même.
Ce que ce gain ne couvre pas
Ce format ne concerne que les chaînes chargées côté PHP via les fonctions habituelles (__(), _e(), _x()…). Les chaînes destinées au JavaScript, exposées via wp_set_script_translations() et consommées côté client par les fonctions de l’API i18n de Gutenberg, suivent un chemin de chargement distinct et ne bénéficient d’aucune accélération liée à ce nouveau format. Sur ce site, la majorité des chaînes JavaScript proviennent de blocs personnalisés et représentent un volume nettement inférieur aux chaînes PHP, ce qui limite l’impact de cette limitation sur le résultat global, sans l’annuler pour autant.
La génération du fichier .l10n.php
Le fichier n’est pas généré automatiquement par le cœur à partir d’un simple .mo existant : il doit être produit au moment de la construction des paquets de traduction, typiquement via WP-CLI :
wp i18n make-php languages/site-fr_FR.mo languages/
Sur ce projet, cette commande a été intégrée à l’étape de déploiement qui régénère les paquets de langue à chaque mise à jour de contenu traduit, pour que les deux formats restent synchronisés. Un piège rencontré en cours de route : oublier de régénérer le .l10n.php après une mise à jour du .mo laisse le cœur charger une version périmée des traductions, puisque le format PHP est prioritaire quand il existe. La commande wp i18n make-php doit donc systématiquement suivre toute régénération du .mo, jamais s’exécuter seule sur un ancien fichier source.
Sur un site à dix langues, ce genre de gain ne se voit pas à l’œil nu en naviguant : il se mesure, et il justifie qu’on l’intègre au pipeline de build plutôt que de le considérer comme un détail d’implémentation du cœur.
Faut-il s’en préoccuper sur un site à faible nombre de langues
Sur un site bilingue avec quelques centaines de chaînes traduites, l’effet mesuré serait probablement dans la marge d’erreur de la mesure elle-même : le format de traduction n’est qu’un facteur parmi d’autres sur le temps de génération d’une page, et son poids relatif croît avec le nombre de langues actives et le volume de chaînes par langue. C’est un facteur qui compte surtout quand plusieurs conditions se cumulent : nombreuses langues actives, volume important de chaînes par langue et trafic suffisant pour que quelques millisecondes économisées par requête se traduisent en charge serveur globale réduite.
En résumé
Sur ce site à dix langues, le format .l10n.php introduit avec WordPress 6.5 réduit d’environ 30 % le temps de chargement des chaînes traduites côté PHP, grâce à sa compatibilité native avec OPcache. Le gain reste circonscrit aux chaînes PHP et ne concerne pas le JavaScript. La condition pour en profiter est simple mais facile à oublier : générer systématiquement le fichier avec wp i18n make-php à chaque mise à jour des traductions, sous peine de servir des chaînes périmées.
