Comparez deux chemins de requête : dans le premier, un visiteur tape une URL, la requête traverse le réseau jusqu’au serveur, PHP se charge, WordPress détermine la langue via Polylang ou WPML, puis redirige ou affiche le bon contenu. Dans le second, un Worker Cloudflare répond en quelques millisecondes, avant même que la requête n’atteigne l’origine, et sert directement la bonne version linguistique en cache. La différence de latence se compte en dizaines, parfois en centaines de millisecondes, ce qui n’est pas négligeable sur un site à fort trafic international.
C’est cette promesse qui pousse certaines équipes techniques à déplacer la décision de langue hors de WordPress, directement au niveau du edge Cloudflare. L’idée séduit sur le papier. Elle mérite d’être confrontée à ce qu’elle complique réellement une fois en production.
Ce qu’un Worker peut faire avant WordPress
Un Cloudflare Worker s’exécute sur le réseau de périphérie, au plus près du visiteur, avant que la requête n’atteigne l’origine (le serveur qui héberge WordPress). Il peut lire l’en-tête Accept-Language, un cookie de préférence, ou l’en-tête CF-IPCountry fourni automatiquement par Cloudflare, et décider quelle version linguistique servir : réécriture d’URL vers /en/, redirection 302, ou simple ajout d’un en-tête consommé plus loin. Le code minimal ressemble à ceci :
export default {
async fetch(request) {
const country = request.headers.get("CF-IPCountry");
const url = new URL(request.url);
if (url.pathname === "/" && country === "DE") {
return Response.redirect(url.origin + "/de/", 302);
}
return fetch(request);
}
};
Associé au cache Cloudflare, ce mécanisme permet de servir une page HTML entièrement mise en cache au edge, sans jamais réveiller PHP, MySQL ni l’extension multilingue installée sur WordPress. Pour un site à fort trafic sur la page d’accueil, le gain est réel et mesurable dans les outils de suivi de performance.
Ce que ça déplace, sans le résoudre
Le piège principal est la duplication de la logique de langue. WordPress, via Polylang ou WPML, continue de gérer la structure des URLs, les traductions de contenu, les redirections de langue par défaut et les balises hreflang. Le Worker, lui, prend une décision de routage en amont, avec des informations plus pauvres (pays de l’IP, en-tête navigateur) que celles dont dispose WordPress une fois la requête traitée (préférence explicite enregistrée en base, rôle de l’utilisateur, contenu réellement traduit ou non). Si les deux systèmes ne sont pas alignés, on obtient des redirections contradictoires : le Worker envoie vers /de/ un visiteur allemand, mais la page allemande n’existe pas encore pour ce contenu précis, et WordPress la re-redirige vers la langue par défaut. Le visiteur subit alors deux redirections au lieu d’une, ce qui annule une bonne partie du gain de performance visé.
Les cas où le edge complique plus qu’il n’aide
Sur un site où le contenu n’est pas traduit dans toutes les langues pour toutes les pages — le cas le plus fréquent en pratique — le Worker ne peut pas savoir, sans appeler WordPress, si une traduction existe réellement pour l’URL demandée. Router en aveugle sur le pays de l’IP revient à ignorer le vrai état de la traduction. Deux solutions existent, toutes deux avec un coût : interroger une API légère exposée par WordPress pour connaître les traductions disponibles (ce qui réintroduit une latence), ou maintenir une liste statique des URLs traduites synchronisée à chaque publication (ce qui ajoute une étape au workflow éditorial et un risque d’oubli).
Le cas du visiteur qui change de langue manuellement
Autre angle mort fréquent : un visiteur qui choisit explicitement une langue différente de celle suggérée par son pays ou son navigateur doit voir ce choix respecté sur toutes les pages suivantes. Cela suppose que le Worker lise un cookie de préférence posé par WordPress et que ce cookie soit correctement propagé et priorisé au-dessus de la détection automatique. Oublier cette priorité conduit à des situations où un visiteur francophone basé en Allemagne se voit systématiquement renvoyé vers l’allemand malgré son choix explicite, une régression qui agace beaucoup plus qu’elle n’aide.
Architecture recommandée
Visiteur
└─ Cloudflare Worker (edge)
├─ Cookie de préférence présent ? → respecter, ne pas re-router
├─ Cache HIT pour cette langue/URL ? → servir directement, 0 PHP
└─ Cache MISS ou décision incertaine
└─ Laisser passer vers WordPress
└─ Polylang/WPML tranche définitivement
└─ Réponse mise en cache au edge pour la prochaine requête
Ce schéma limite le Worker à deux rôles simples et sûrs : accélérer les cas déjà connus (cache existant, cookie déjà posé) et laisser WordPress trancher les cas ambigus. C’est moins spectaculaire qu’un routage entièrement piloté par le edge, mais nettement plus fiable en production.
Notre verdict
Déplacer la décision de langue au edge apporte un gain de performance réel, mais seulement pour les requêtes dont la réponse est déjà connue avec certitude. Dès qu’il s’agit de décider quelle langue afficher pour une URL dont l’état de traduction n’est pas garanti, le Worker doit rester un accélérateur du cache existant, jamais l’autorité finale sur la langue. Confier cette autorité entièrement au edge, sans synchronisation fine avec l’extension multilingue installée sur WordPress, crée plus de redirections erronées que de gains mesurables.
