Un client avec une audience répartie sur plusieurs continents se plaignait d’un temps de chargement très inégal selon la région du visiteur : rapide en Europe, nettement plus lent en Asie du Sud-Est, alors que le front tournait pourtant sur un serveur unique correctement dimensionné. Le problème n’était pas la puissance du serveur, mais sa localisation géographique unique : chaque visiteur lointain payait le prix de la latence réseau, avant même que le rendu ne commence.
Le déplacement du rendu vers l’edge avec Cloudflare Workers a résolu ce problème sans changer de continent d’hébergement pour l’origine WordPress elle-même.
Ce que « rendre à l’edge » signifie concrètement
Plutôt que d’exécuter la logique de rendu sur un serveur unique situé dans une seule région, le code s’exécute dans le point de présence le plus proche du visiteur, parmi plusieurs centaines répartis dans le monde. La requête HTTP du visiteur ne quitte jamais vraiment sa région pour obtenir une réponse déjà en cache, ce qui réduit drastiquement la latence perçue.
Architecture retenue
Visiteur (Tokyo)
→ Point de présence Cloudflare le plus proche
→ Cache KV local : contenu présent ? → réponse immédiate
→ Cache KV absent → appel à l'origine WordPress (Europe)
→ réponse mise en cache KV pour les prochains visiteurs de la région
L’origine WordPress, elle, reste hébergée à un seul endroit : ce n’est pas elle qui est distribuée, mais le cache des réponses qu’elle produit.
Stratégie de cache adoptée
- Chaque réponse mise en cache porte une clé qui inclut la route demandée et les paramètres de requête significatifs, jamais l’ensemble des en-têtes de la requête d’origine.
- Une durée de fraîcheur courte est acceptée pour le contenu très consulté, avec revalidation en arrière-plan pour ne jamais bloquer un visiteur en attente d’une origine lente.
- Le contenu jamais consulté dans une région donnée n’est simplement jamais présent dans le cache KV local de cette région, sans réplication systématique inutile.
Le rôle de l’origine unique dans ce schéma
Garder une origine WordPress unique simplifie considérablement la gestion du contenu : un seul back-office, une seule base de données, un seul point où publier. La distribution géographique ne porte que sur les réponses déjà calculées, jamais sur la logique de rédaction ou de modération du contenu, qui reste centralisée comme sur un projet WordPress classique.
Ce qui doit rester dynamique
Tout ce qui dépend du visiteur (un panier, une session authentifiée) ne peut évidemment pas être mis en cache globalement de cette façon. Sur ce projet, seules les pages de contenu éditorial public passaient par ce cache distribué ; les zones personnalisées continuaient d’appeler directement l’API à chaque visite, sans passer par le cache edge.
Le coût réel de ce type d’infrastructure
Contrairement à une intuition répandue, ce genre d’architecture ne coûte pas nécessairement plus cher qu’un serveur unique correctement dimensionné : la facturation dépend surtout du nombre de requêtes qui atteignent réellement le code exécuté à l’edge et du volume de lectures et d’écritures dans le cache distribué, pas d’un tarif par région géographique. Sur ce projet, le coût mensuel est resté comparable à celui de l’ancien serveur unique, pour une expérience nettement plus homogène d’un continent à l’autre.
Un piège rencontré avec l’invalidation
Purger un cache réparti dans plusieurs centaines de points de présence n’est pas instantané partout à la fois : une purge déclenchée à la publication d’un article peut mettre quelques secondes à se propager entièrement. Il a fallu accepter ce court délai de propagation plutôt que de viser une cohérence strictement immédiate, techniquement hors de portée d’une infrastructure aussi distribuée.
Sur ce projet, le vrai gain ne venait pas d’une origine plus rapide, mais du fait que la grande majorité des visiteurs ne touchait jamais l’origine du tout : ils étaient servis directement depuis le point de présence le plus proche.
Ce qu’on retient
Déplacer le rendu vers l’edge ne dispense pas d’héberger correctement l’origine WordPress elle-même, ce sujet reste distinct. Mais pour une audience géographiquement dispersée, cette architecture réduit la latence perçue de façon plus radicale que n’importe quelle optimisation appliquée à un serveur unique, aussi bien placé soit-il.
