WPML

Triage des performances de WPML – Interface d'administration lente, délais d'attente du Tableau de bord de traduction, latence de l'interface publique

Les problèmes de performances de WPML (pages de l'interface d'administration lentes, ralentissements de l'interface publique, délais d'attente dépassés du Tableau de bord de traduction) proviennent presque toujours de 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.

  1. Confirmez où se situe la lenteur

    • Interface publique lente, interface d'administration normale → probablement une configuration de cache de page complète ou une extension lourde sur l'interface publique.
    • Interface d'administration lente, interface publique normale → probablement un encombrement 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 est particulièrement lent → probablement un grand nombre d'articles dans la requête du tableau de bord et pas assez de mémoire PHP ou de temps d'exécution.
    • Opérations de traduction lentes → probablement la connectivité aux services de traduction ; vérifiez le Journal de communication dans WPMLSupport (consultez Journaux pour savoir quel journal répond à quel symptôme).

  2. Vérifiez les ressources du serveur

    Ouvrez WPMLSupport. Le panneau d’avertissements en haut signale une mémoire PHP inférieure aux 256 Mo recommandés par WPML. Les sites avec de plus grands catalogues 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 grands sites avec de nombreuses traductions bénéficient d'un serveur de base de données sur SSD, d'un innodb_buffer_pool_size suffisant et d'index sur la table wp_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_time est inférieur à 60 secondes et que le Tableau de bord expire, augmentez-le.
    • CPU. Les plans d'hébergement mutualisé ont souvent des limites de CPU agressives ; vérifiez auprès de votre hébergeur si vous êtes bridé.

  3. Cache d'objet

    Sans cache d'objet, WordPress charge de nombreux paramètres de WPML à partir de la base de données à chaque requête. Ajoutez Redis ou Memcached comme cache d'objet (la plupart des hébergeurs WordPress infogérés le proposent ; sinon, les extensions Redis Object Cache ou WP Redis l'activent).

    L'amélioration est généralement importante. Les paramètres qui nécessitaient auparavant des requêtes à la base de données sont servis depuis la mémoire.

  4. Cache de page complète

    Un 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à un 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 (que ce soit la langue en tant que répertoire, la langue en tant que sous-domaine ou la langue en tant que domaine) nécessite que le cache varie selon 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.

  5. Extensions conflictuelles ou lentes

    Les sites accumulent des extensions ; certaines sont bien conçues et d'autres non. Pour trouver une extension lente :

    1. Installez Query Monitor (une extension de débogage).
    2. Rechargez une page lente.
    3. Regardez Queries by Component. L'extension avec les requêtes les plus coûteuses est la suspecte.

    Si une extension est en cause, remplacez-la ou désactivez la fonctionnalité qui provoque la lenteur.

  6. Services de traduction lents, pas le site

    Si les tâches de traduction semblent lentes 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 WPMLSupportJournal de communication. Le journal montre 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 plutôt en cause, les outils de dépannage sans risque incluent Vider le cache dans WPML. Lorsque l’enquête sur les performances nécessite l’intervention du Support, regroupez ce que vous avez trouvé via Partager des informations de débogage avec le support.