Combien de temps WordPress passe-t-il, à chaque requête, à simplement charger les traductions de l’interface et des extensions actives ? Sur un site multilingue chargé de plugins volumineux comme WooCommerce ou un constructeur de pages, la réponse surprend souvent : plusieurs dizaines de millisecondes, avant même que la moindre requête vers la base de données ne soit exécutée.
Ce coût, invisible dans la plupart des profils de performance qui se concentrent sur les requêtes SQL, mérite d’être compris en détail, car il grandit avec chaque extension traduite installée, et il existe une solution que peu de développeurs connaissent encore.
Comment WordPress charge une traduction
Historiquement, WordPress s’appuie sur le format Gettext binaire .mo. Ce fichier contient l’ensemble des chaînes originales et traduites d’un domaine de texte donné. À chaque requête, la fonction load_textdomain() ouvre ce fichier, le parse depuis sa structure binaire, puis construit en mémoire un objet MO contenant toutes les paires de traduction, via la classe MO du répertoire wp-includes/pomo.
Ce parsing n’est pas gratuit. Un fichier .mo de traduction française pour une extension e-commerce complète peut dépasser plusieurs milliers d’entrées. Le décodage binaire de ce volume, répété à chaque requête PHP puisque rien n’est persistant entre deux exécutions sans cache d’opcode dédié aux données, ajoute un coût mesurable au démarrage de chaque page.
Ce qui change avec le format .l10n.php
Depuis WordPress 6.5, le cœur sait charger un format alternatif : .l10n.php. Il ne s’agit plus d’un fichier binaire à parser, mais d’un fichier PHP qui retourne directement un tableau associatif des traductions, exécuté nativement par le moteur PHP et bénéficiant directement du cache d’opcode d’OPcache comme n’importe quel autre script.
<?php
return array(
'domain' => 'mon-plugin',
'plural-forms' => 'nplurals=2; plural=(n > 1);',
'messages' => array(
'Add to cart' => 'Ajouter au panier',
'Checkout' => 'Commander',
),
);Cette structure, une fois compilée en bytecode par OPcache, ne nécessite plus aucun parsing binaire répété : le tableau est prêt à l’emploi dès le premier appel, et les requêtes suivantes bénéficient du cache d’opcode du fichier PHP, exactement comme pour n’importe quel autre script du thème ou d’une extension.
Comment produire ce format
Le format .l10n.php se génère automatiquement à partir d’un fichier .mo existant grâce à WP-CLI :
wp i18n make-php languages/Cette commande parcourt le répertoire de langues et produit, pour chaque fichier .mo, un fichier .l10n.php correspondant. WordPress détecte automatiquement la présence de ce format alternatif et le privilégie par rapport au binaire, sans configuration supplémentaire à écrire dans le thème ou l’extension.
Où le gain se fait sentir
- Sur des sites multilingues qui chargent plusieurs domaines de texte à chaque requête (thème, extensions, cœur).
- Sur des extensions volumineuses dont le fichier de traduction dépasse plusieurs centaines de kilo-octets.
- Sur des serveurs où OPcache est correctement configuré avec une mémoire suffisante, condition indispensable pour que le gain se matérialise.
À l’inverse, sur un petit site avec seulement quelques extensions légèrement traduites, la différence reste marginale et ne justifie pas nécessairement une migration systématique du parc de fichiers de langue.
Une nuance sur la maintenance des traductions
Le format .l10n.php doit être régénéré à chaque mise à jour du fichier .mo source, sans quoi la traduction affichée devient obsolète : contrairement au binaire, WordPress ne recompile pas automatiquement l’un à partir de l’autre à la volée. Un processus de déploiement qui met à jour des fichiers de langue doit donc intégrer l’étape wp i18n make-php après chaque changement, pour ne jamais servir une version périmée du texte traduit.
Sur nos projets, nous avons intégré cette commande directement dans le script de déploiement, juste après la synchronisation des fichiers de langue : le coût de génération est négligeable, et l’oubli devient impossible.
Pour aller plus loin
Le passage au format précompilé ne change rien au comportement fonctionnel des traductions : les mêmes chaînes, les mêmes règles de pluriel, le même domaine de texte. Seule la mécanique de chargement change, au bénéfice du temps de démarrage. Sur un site chargé de plugins traduits, cette optimisation, pourtant simple à mettre en œuvre, reste l’une des plus sous-exploitées du cœur récent de WordPress.
