WPML

Diagnostic 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, interface publique au ralenti, délais d’attente 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 l’origine de la lenteur

    • Interface publique lente, interface d’administration normale : probablement la configuration de la mise en cache de la page entière 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 uniquement pour 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 les Journaux pour savoir quel journal correspond à 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 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 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.
    • Processeur (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

    WordPress sans cache d’objet charge de nombreux paramètres de WPML depuis 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 entière

    Un cache de page entière (WP Rocket, W3 Total Cache, cache de périphérie du fournisseur d’hébergement) est le plus grand gain de performances 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 par répertoire, la langue par sous-domaine ou la langue par 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 les 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 lourdes 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 bridage sortant de votre hébergeur), et non du site. Si le propre cache de WPML est en cause, les outils de dépannage sécurisés incluent Vider le cache dans WPML. Lorsque l’analyse des performances nécessite l’intervention du Support, rassemblez ce que vous avez trouvé via Partager les informations de débogage avec le support.