# Ce que coûtent vraiment WPML et Polylang en performance : mesures sur nos projets

> Un plugin multilingue n'est jamais neutre en performance. Nous avons mesuré l'impact réel de WPML et Polylang sur plusieurs sites comparables.

- Auteur : Clément Hadrot
- Publié le : 2024-04-04
- Mis à jour le : 2024-04-04
- Catégorie : Multilingue
- URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/performance-cout-plugins-multilingues-analyse/

## L’essentiel

- La duplication de contenu multiplie mécaniquement le volume de la base de données
- WPML ajoute davantage de requêtes que Polylang sur une page type
- Un cache correctement configuré absorbe la majorité du surcoût

Ajouter le multilingue à un site n'est jamais un choix neutre en performance, et c'est un sujet que les clients anticipent rarement au moment de choisir leur extension. Pour objectiver ce coût plutôt que se fier à des impressions, nous avons mené une série de mesures comparatives sur trois configurations équivalentes : un site sans multilingue, le même site avec Polylang activé, et le même site avec WPML activé, chacun en deux langues avec un volume de contenu identique.

Cet article présente la méthodologie et les résultats de ces mesures, ainsi que les leviers concrets pour absorber le surcoût observé sur un projet réel.

## Méthodologie de mesure

Le site de test reproduit un blog d'entreprise avec cinq cents articles, dix catégories, et un thème standard sans personnalisation lourde. Les mesures portent sur trois indicateurs : le nombre de requêtes SQL générées par le chargement d'une page d'article typique (mesuré via `Query Monitor`), le temps de réponse serveur (`Time To First Byte`) mesuré sur cent chargements successifs après réchauffement du cache, et la taille de la base de données MySQL après import du même volume de contenu dans chaque configuration.

Chaque test a été mené sur un environnement d'hébergement identique, avec l'objet cache PHP désactivé pour isoler l'effet propre du plugin multilingue, avant de mesurer à nouveau avec un cache d'objets persistant (Redis) activé, condition plus représentative d'un site en production.

## Résultats sans cache d'objets

| Configuration | Requêtes SQL / page | TTFB moyen | Taille base (Mo) |
| --- | --- | --- | --- |
| Sans multilingue | 38 | 210 ms | 42 |
| Polylang (2 langues) | 54 | 265 ms | 79 |
| WPML (2 langues) | 87 | 340 ms | 91 |

Le surcoût de requêtes SQL provient principalement des jointures supplémentaires nécessaires pour déterminer la langue courante et filtrer le contenu en conséquence, ainsi que des tables additionnelles interrogées à chaque affichage (`icl_translations` pour WPML, table de traduction interne pour Polylang). WPML génère davantage de requêtes que Polylang sur ce test, principalement en raison de son système de gestion de traduction plus riche (statuts de traduction, gestionnaire de tâches) qui reste actif même lorsqu'il n'est pas directement utilisé sur le rendu final de la page.

> L'essentiel à retenir : La duplication de contenu multiplie mécaniquement le volume de la base de données ; WPML ajoute davantage de requêtes que Polylang sur une page type ; Un cache correctement configuré absorbe la majorité du surcoût

## L'effet du cache : l'essentiel du surcoût disparaît

Une fois un cache d'objets persistant activé (Redis, dans notre test), les résultats se resserrent nettement : le TTFB moyen de la configuration WPML redescend à 225 ms, contre 195 ms pour Polylang et 180 ms pour le site sans multilingue. Le nombre de requêtes SQL par page chute également, la majorité des requêtes répétitives (résolution de langue, chargement des chaînes traduites) étant mises en cache d'une visite à l'autre pour un contenu identique.

Ce constat a une implication pratique importante : sur un site multilingue, un cache d'objets persistant n'est pas une simple optimisation de confort, c'est un prérequis de performance qui devient presque incontournable dès que le trafic dépasse un niveau modeste. Un hébergement mutualisé sans possibilité d'installer Redis ou Memcached expose mécaniquement un site multilingue WPML à des temps de réponse significativement dégradés par rapport à l'équivalent monolingue.

## L'impact du volume de base de données

Le doublement quasi mécanique du volume de contenu (chaque article existant en deux exemplaires, un par langue) se traduit par une base de données significativement plus lourde, avec des conséquences en cascade : des sauvegardes plus longues, un temps d'indexation plus important pour un moteur de recherche interne, et une empreinte mémoire plus élevée pour tout cache de requêtes qui tenterait de conserver l'ensemble des données en mémoire.

Sur un site de grande taille (plusieurs dizaines de milliers d'articles), ce facteur devient significatif dans le choix de l'hébergement : un site multilingue en quatre langues doit être dimensionné, en base de données, comme un site quatre fois plus volumineux que sa version monolingue équivalente, pas comme le même site avec « un peu plus de contenu ».

## Optimisations spécifiques recommandées

- Activer un cache d'objets persistant (Redis ou Memcached) dès l'ajout d'une extension multilingue, quelle que soit la taille actuelle du site.
- Sur WPML, désactiver les modules non utilisés (gestion de tâches de traduction avancée si aucune agence de traduction externe n'intervient) depuis **WPML → Réglages avancés**, chaque module actif ajoutant potentiellement ses propres requêtes.
- Vérifier qu'un cache de page complet (Varnish, cache statique du CDN) sert bien des versions distinctes par langue, sans quoi une page peut être servie en cache dans la mauvaise langue à certains visiteurs — un bug de performance qui devient un bug fonctionnel.
- Surveiller la taille de la base de données lors des sauvegardes automatiques, un site multilingue volumineux pouvant dépasser les quotas de certains hébergements mutualisés plus rapidement que prévu.

> Un chiffre qui revient souvent en revue de projet : sur nos sites multilingues correctement mis en cache, l'écart de temps de réponse perçu par l'utilisateur final devient négligeable par rapport au site monolingue équivalent. Le vrai risque de performance n'est donc pas le plugin lui-même, mais l'absence de cache adapté à son usage.

## Notre verdict

WPML et Polylang ont un coût de performance réel et mesurable, plus marqué pour WPML que pour Polylang sur une configuration comparable, principalement à cause de requêtes SQL supplémentaires et d'une base de données mécaniquement plus volumineuse. Ce coût reste cependant largement maîtrisable avec un cache d'objets persistant correctement configuré, qui absorbe l'essentiel de l'écart observé. La vraie question à se poser avant de choisir une extension multilingue n'est donc pas seulement fonctionnelle, mais aussi celle de l'infrastructure d'hébergement disponible pour l'accompagner.