Analyse des performances de WPML – interface d’administration lente, délais d’attente du tableau de bord de traduction, ralentissements de l’interface publique
Les problèmes de performances de WPML (pages de l’interface d’administration lentes, interface publique qui rame, délais d’attente du Tableau de bord de traduction) s’expliquent presque toujours par quelques facteurs courants. Cette page les passe en revue dans l’ordre à vérifier, avant de supposer que le problème vient de WPML lui-même.
-
Confirmez d’où vient la lenteur
- Interface publique lente, interface d’administration normale → probablement une configuration de mise en cache de page complète ou une extension lourde sur l’interface publique.
- Interface d’administration lente, interface publique normale → probablement une surcharge du chargement automatique de
wp_options, une extension lourde réservée à l’interface d’administration, ou un serveur sous-dimensionné. - Le Tableau de bord de traduction en particulier est lent → probablement un grand nombre d’articles dans la requête du tableau de bord et un manque de mémoire PHP ou de temps d’exécution.
- Opérations de traduction lentes → probablement un problème de connectivité avec les services de traduction ; vérifiez le Journal de communication dans WPML > Support (consultez Journaux pour savoir quel journal correspond à quel symptôme).
-
Vérifiez les ressources du serveur
Ouvrez WPML > Support. Le panneau d’avertissement en haut signale une mémoire PHP inférieure aux 256 Mo recommandés par WPML. Les sites avec des catalogues plus importants ont besoin de 512 Mo ou plus.
Autres symptômes liés aux ressources du serveur :
- Requêtes de base de données lentes. Les sites importants avec de nombreuses traductions bénéficient d’un serveur de base de données sur SSD, d’un
innodb_buffer_pool_sizesuffisant et d’index sur la tablewp_icl_translations(ceux-ci sont ajoutés par WPML ; il est rare d’avoir besoin d’une intervention manuelle). - Temps d’exécution PHP. Si
max_execution_timeest inférieur à 60 secondes et que le Tableau de bord expire, augmentez-le. - Processeur (CPU). Les plans d’hébergement mutualisé ont souvent des limites de CPU strictes ; vérifiez auprès de votre hébergeur si vous êtes bridé.
- Requêtes de base de données lentes. Les sites importants avec de nombreuses traductions bénéficient d’un serveur de base de données sur SSD, d’un
-
Cache d’objets
Sans cache d’objets, WordPress charge un grand nombre de paramètres de WPML depuis la base de données à chaque requête. Ajoutez Redis ou Memcached comme cache d’objets (la plupart des hébergeurs WordPress infogérés le proposent ; sinon, les extensions Redis Object Cache ou WP Redis permettent de l’activer).
L’amélioration est généralement considérable. Les paramètres qui nécessitaient auparavant des requêtes dans la base de données sont servis depuis la mémoire.
-
Mise en cache de page complète
Une mise en cache de page complète (WP Rocket, W3 Total Cache, cache périphérique du fournisseur d’hébergement) est le gain de performances le plus important pour la vitesse de l’interface publique.
Si vous en avez déjà une mais que les pages semblent toujours lentes, vérifiez si votre cache gère correctement les URL par langue. La structure d’URL de WPML (qu’il s’agisse de la langue par répertoire, par sous-domaine ou par domaine) nécessite que le cache varie en fonction de l’URL. La plupart des caches le font automatiquement, mais il vaut la peine de vérifier que la version française n’est pas servie à partir du cache anglais ou vice versa.
-
Extensions en conflit ou lentes
Les sites accumulent les extensions ; certaines sont bien conçues et d’autres non. Pour trouver une extension lente :
- Installez Query Monitor (une extension de débogage).
- Rechargez une page lente.
- Regardez Requêtes par composant. L’extension avec les requêtes les plus lourdes est la suspecte.
Si une extension est en cause, remplacez-la ou désactivez la fonctionnalité qui provoque la lenteur.
-
Services de traduction lents, pas le site
Si les travaux de traduction semblent lents mais que le site lui-même fonctionne bien, le goulot d’étranglement se situe entre votre site et l’infrastructure de traduction de WPML.
Vérifiez WPML > Support > Journal de communication. Le journal affiche la latence de chaque appel d’API. Si des appels individuels prennent plusieurs secondes, le problème vient de la connectivité (chemin réseau, DNS ou limitation sortante de votre fournisseur d’hébergement), et non du site. Si le propre cache de WPML est en cause, les outils de dépannage sans risque incluent Vider le cache dans WPML. Lorsque l’analyse des performances nécessite l’intervention du Support, regroupez ce que vous avez trouvé via le Partage d’informations de débogage avec le Support.