Performances de WordPress multilingue : 7 façons de maintenir un site traduit rapidement

Résumez ce post avec : 9 min de lecture

ChatGPT Perplexité Grok Google IA

Un site WordPress multilingue reste rapide lorsque chaque version linguistique est traitée comme son propre ensemble de pages pouvant être mises en cache : donnez à chaque langue une URL distincte, assurez-vous que le cache de votre page et le CDN stockent chacun séparément, chargez les polices uniquement pour les scripts utilisés par une page et choisissez une méthode de traduction qui fournit du HTML terminé et traduit au lieu d'échanger du texte après le chargement de la page. Mesurez ensuite les Core Web Vitals par langue, car une page d'accueil rapide en anglais ne dit rien sur la page japonaise.

Principaux points à retenir

• Mesurez chaque langue séparément. Les “bons” seuils de Google sont LCP dans les 2,5 s, INP dans les 200 ms et CLS dans les 0,1, au 75e percentile des chargements de pages.
• URL spécifiques à la langue (/de/, /fr/) peut être mis en cache comme n'importe quelle autre page. La langue choisie par cookie ne le peut généralement pas.
• Effacez le cache des pages traduites lorsque les traductions changent, sinon les visiteurs verront du texte obsolète.
• Diviser les polices Web par script avec unicode-range, donc un visiteur allemand ne télécharge pas de glyphes japonais.
• Évitez les redirections linguistiques automatiques à chaque visite ; chaque redirection est un aller-retour supplémentaire avant que quoi que ce soit ne s'affiche.

Pourquoi les sites WordPress multilingues ralentissent

L'ajout de langues multiplie le nombre de pages sans changer votre serveur. Cinq langues sur un site de 200 pages signifient environ 1 000 URL à mettre en cache, à explorer et à conserver à jour. Les problèmes de performance proviennent généralement de l’un des cinq endroits suivants :

1. Cache raté. Les pages traduites ne sont pas mises en cache ou sont mises en cache sous la mauvaise clé.
2. Travaux de traduction sur demande. Les traductions sont recherchées ou générées pendant que le visiteur attend.
3. Échange côté client. La page se charge dans la langue d'origine, puis JavaScript remplace le texte, ce qui retarde le contenu final et peut modifier la mise en page.
4. Polices lourdes. L'ajout de chinois, de japonais, de coréen ou d'arabe ajoute des fichiers de polices volumineux.
5. Rediriger les sauts. La détection de langue qui redirige chaque première visite ajoute un aller-retour.

Chacun a une solution simple.

Étape 1 : mesure par langue

Google recommande d'obtenir de bons Core Web Vitals, qui, selon lui, “correspondent à ce que nos principaux systèmes de classement cherchent à récompenser” (Recherche Google Central). Les cibles:

Web.dev recommande de les juger au 75e percentile des chargements de pages, répartis par mobile et ordinateur de bureau (web.dev).

Comment mesurer par langue :

• Exécutez PageSpeed Insights sur la même page dans chaque langue (/pricing/, /de/pricing/, /ja/pricing/). Les différences pointent directement vers des problèmes spécifiques à la langue, tels que les polices ou le texte long, provoquant des changements de mise en page.
• Dans le rapport Core Web Vitals de Search Console, ouvrez les exemples d'URL dans chaque groupe de problèmes et notez quels dossiers de langue apparaissent.
• Testez depuis les régions que vous servez. Un site hébergé aux États-Unis aura une latence plus élevée pour les visiteurs en Asie, quelle que soit la langue.

Étape 2 : donnez à chaque langue sa propre URL pouvant être mise en cache

La mise en cache des pages est la plus grande victoire. Le manuel d'administration avancée de WordPress indique que les plugins de mise en cache servent les pages sous forme de fichiers statiques et “peuvent améliorer les performances plusieurs centaines de fois pour des pages assez statiques” (Ressources pour les développeurs WordPress).

Cela ne fonctionne que si chaque langue possède une URL distincte. Lorsque la langue est choisie par un cookie ou par les paramètres du navigateur et servie sur la même URL, un cache de pages stocke soit une langue pour tout le monde, soit doit être contourné. Google préfère également des URL distinctes pour le référencement : il recommande “des URL différentes pour chaque version linguistique d'une page plutôt que d'utiliser des cookies ou des paramètres de navigateur” (Recherche Google Central).

Liste de contrôle pour votre plugin de mise en cache :

• Mettre en cache les pages sous /de/, /fr/ et ainsi de suite, et vérifiez qu'aucun ne figure dans la liste d'exclusion.
• Si le plugin peut précharger le cache, incluez les URL traduites ; le préchargement à partir de votre plan de site est plus simple si le plan de site les répertorie.
• Ne faites pas varier le cache par un cookie de langue, sauf si vous n'avez pas d'autre choix.
• Purgez l'URL traduite lorsque sa traduction change, pas seulement lorsque le message original est modifié.

Étape 3 : diffuser du code HTML traduit, et non du texte échangé après le chargement

La manière dont votre outil de traduction produit une page traduite est aussi importante que la mise en cache.

• Traduction côté serveur génère le HTML traduit sur le serveur. Le visiteur reçoit la page terminée et un cache de pages peut la stocker.
• Traduction côté client envoie la page originale, puis JavaScript récupère les traductions et remplace le texte dans le navigateur. Cela fonctionne sur n'importe quelle plate-forme, mais le contenu traduit arrive plus tard et le texte traduit plus long peut déplacer des éléments après leur peinture, ce qui apparaît comme un changement de mise en page.

Sur WordPress, préférez une méthode côté serveur pour vos langues principales. Si un script côté client est votre seule option sur une partie du site, réservez de l'espace pour le texte qui grandit (boutons et menus notamment) et testez CLS dans chaque langue.

Étape 4 : diviser les polices par script

Les polices latines sont petites ; les polices CJK complètes (chinoises, japonaises, coréennes) peuvent être plusieurs fois plus grandes. Le chargement de chaque script sur chaque page gaspille de la bande passante.

Utilisez le @font-face unicode-range descripteur. MDN explique que si une page n'utilise aucun caractère dans la plage, “la police n'est pas téléchargée”, et que le descripteur existe pour qu'un site “avec de nombreuses localisations” puisse fournir des ressources de police distinctes pour chaque script (MDN).

@font-face {
  font-family: 'Brand Sans';
  src: url('/fonts/brand-latin.woff2') format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153;
  font-display: swap;
}
@font-face {
  font-family: 'Brand Sans';
  src: url('/fonts/brand-arabic.woff2') format('woff2');
  unicode-range: U+0600-06FF;
  font-display: swap;
}

Aussi:

• Auto-hébergez les fichiers WOFF2 et préchargez uniquement le fichier latin (ou script principal) utilisé au-dessus du pli.
• Envisagez d'utiliser une bonne police système pour les scripts que la police de votre marque ne couvre pas, au lieu d'une grande police Web.
• Utiliser font-display: swap le texte s'affiche donc immédiatement dans une police de secours.

Étape 5 : gardez les images et les scripts allégés dans toutes les langues

• Images localisées. Si vous remplacez les images par langue, compressez et dimensionnez chaque version comme l'original ; il est facile de télécharger une bannière non optimisée de 4 Mo pour un marché.
• Chargement paresseux. Ajouts WordPress loading="lazy" aux images par défaut ; assurez-vous que votre image de héros n'est pas chargée paresseusement, dans chaque modèle de langue.
• Scripts tiers. Les widgets de chat, les badges de paiement et les trackers spécifiques au marché s'additionnent. Chargez-les uniquement sur les langues ou les pages qui en ont besoin.

Étape 6 : évitez les redirections inutiles

Les redirections automatiques basées sur la langue du navigateur ajoutent un aller-retour avant le premier octet de la bonne page. Google déconseille également de rediriger les utilisateurs vers une version linguistique “en fonction de ce que vous pensez être la langue de l'utilisateur”, car cela peut empêcher les utilisateurs et les moteurs de recherche d'atteindre toutes les versions (Recherche Google Central).

Meilleures options :

• Laissez les gens choisir une langue avec un commutateur visible et créez des liens internes vers les URL traduites afin qu'ils restent dans leur langue.
• Si vous effectuez une redirection, faites-le uniquement lors de la première visite sur la page d'accueil et n'oubliez pas le choix.
• Pointez hreflang et les liens internes vers les URL finales, et non vers les URL qui redirigent.

Étape 7 : obtenez les bases directement sur le serveur

Les pages traduites ne changent pas les fondamentaux. Le manuel WordPress pointe vers la mise en cache, un CDN pour les fichiers statiques et le réglage du serveur comme principaux leviers :

• Maintenir PHP à jour et OPcache activé.
• Ajouter un cache d'objets persistant (Redis ou Memcached) si votre hébergeur le prend en charge, en particulier pour les sites WooCommerce ou les sites d'adhésion où la mise en cache pleine page est limitée.
• Utiliser un CDN pour les images, CSS et JS, et pour les pages complètes si votre configuration le permet, afin que les visiteurs éloignés de votre serveur les obtiennent à proximité.
• Gardez la liste des plugins courte. Chaque plugin actif s'exécute sur chaque requête non mise en cache, dans chaque langue.

Comment s'adapte le plugin WordPress ConveyThis

Le plugin ConveyThis traduit les pages sur le serveur et sert chaque langue sur son propre sous-dossier ou sous-domaine, de sorte que les pages traduites peuvent être mises en cache comme l'original. Il conserve un cache local de traductions pour chaque page et langue, de sorte que les demandes répétées n'attendent pas sur le service de traduction, et lorsque vous modifiez une traduction, il efface le cache de page dans les plugins de mise en cache populaires tels que WP Rocket, W3 Total Cache, WP Super Cache et WP Fastest Cache.

Autres paramètres à connaître :

• Exclure des pages ou des sections qui n'ont pas besoin de traduction, comme les zones de compte, pour que le travail de traduction reste là où cela compte.
• La redirection automatique par langue du navigateur est désactivée sauf si vous l'activez et utilise la langue du navigateur plutôt que les recherches IP ; voir redirection automatique.
• Les mots ne sont comptés que lorsque le contenu traduit est montré aux visiteurs ; les robots ne comptent pas.

Le Page d'intégration WordPress couvre l'installation et les paramètres, et plans et tarifs répertorie les limites de mots et de langues par plan. Pour traduire les chaînes de thèmes elles-mêmes, consultez notre guide sur traduire un thème WordPress.

Questions fréquemment posées

L’ajout de langues ralentit-il un site WordPress ?

Ce n'est pas obligatoire. Chaque langue ajoute des pages, et non un poids par page, à condition que les pages traduites soient mises en cache sur leurs propres URL et que les traductions soient appliquées sur le serveur. Les ralentissements proviennent généralement de pages traduites non mises en cache, d'échanges de texte côté client, de polices lourdes ou de redirections.

Les pages traduites doivent-elles être mises en cache séparément ?

Oui. Chaque langue doit avoir sa propre URL, et votre cache de page et votre CDN doivent stocker chaque URL séparément. Purger une page traduite lorsque sa traduction change.

Comment mesurer les performances pour chaque langue ?

Exécutez PageSpeed Insights sur la même page dans chaque langue et comparez, puis vérifiez quels dossiers de langue apparaissent dans le rapport Core Web Vitals de Search Console. Visez le LCP en 2,5 secondes, l'INP en dessous de 200 millisecondes et le CLS en dessous de 0,1.

Les sous-répertoires ou sous-domaines sont-ils plus rapides pour un site multilingue ?

Aucun des deux n’est intrinsèquement plus rapide. Les sous-répertoires partagent un hôte, un cache et une configuration CDN, ce qui est plus simple à gérer ; les sous-domaines peuvent être hébergés séparément si vous avez besoin de serveurs plus proches d'une région.

Comment puis-je empêcher les grandes polices de ralentir les pages traduites ?

Divisez les polices par script avec le descripteur de plage Unicode afin que les navigateurs téléchargent uniquement les polices des caractères utilisés par la page, servent WOFF2 et utilisent l'échange police-affichage.

Gardez-le rapide à mesure que vous grandissez

La rapidité et la qualité de la traduction dépendent toutes deux de la manière dont les pages traduites sont produites. Tu peux créer un compte ConveyThis, installez le plugin WordPress et mesurez vos pages traduites par rapport aux originaux.