Combien de millisecondes séparent une réponse générée à l’edge d’une page reconstruite de façon incrémentale ? Pour un site de documentation technique consommant un WordPress headless, avec une audience répartie sur cinq continents, la question n’était pas anecdotique : les retours utilisateurs signalaient une lenteur perçue nettement plus marquée depuis l’Asie du Sud-Est et l’Amérique du Sud que depuis l’Europe, où le serveur d’origine et la région de déploiement principale étaient hébergés.
Les deux architectures comparées
La première approche, l’ISR (Incremental Static Regeneration) de Next.js, génère les pages statiquement à la demande puis les met en cache sur un CDN, avec une région de déploiement principale unique pour l’exécution de la fonction de régénération. La seconde, un rendu entièrement délégué à Cloudflare Workers, exécute la logique de rendu directement dans plus de 300 emplacements edge répartis mondialement, sans région principale unique.
Le protocole de mesure
Le test a mesuré le temps de réponse pour une même page de documentation, depuis six régions géographiques distinctes, avec mise en cache froide (première visite) et mise en cache chaude (visites suivantes), sur une période de deux semaines représentative du trafic réel du site.
| Région de mesure | Latence moyenne ISR (cache chaud) | Latence moyenne edge Workers (cache chaud) |
|---|---|---|
| Europe de l’Ouest (proche de l’origine) | 32 ms | 29 ms |
| Amérique du Nord | 85 ms | 34 ms |
| Amérique du Sud | 168 ms | 41 ms |
| Asie du Sud-Est | 210 ms | 38 ms |
| Océanie | 195 ms | 44 ms |
Pourquoi un tel écart en cache chaud
La surprise du test tient au fait que ces mesures portent sur du contenu déjà en cache, un scénario où l’on pourrait s’attendre à une latence comparable quelle que soit l’architecture sous-jacente. En réalité, l’ISR dépend d’un CDN générique pour la distribution du contenu déjà généré, dont la couverture géographique et l’efficacité de mise en cache varient nettement selon les régions, alors que l’architecture Cloudflare Workers bénéficie nativement de la même infrastructure edge que le réseau Cloudflare pour la distribution, sans étape intermédiaire supplémentaire.
Ce que l’architecture edge Workers a coûté en complexité
Ce gain de latence n’est pas gratuit en termes d’ingénierie. Le rendu sur Cloudflare Workers impose des contraintes strictes : pas d’API Node.js complète disponible, taille de bundle limitée, et une réécriture partielle de la logique de récupération des données WordPress pour tenir compte de l’environnement d’exécution Workers, plus restreint qu’un environnement Node.js classique.
- Réécriture des appels à l’API REST WordPress pour utiliser l’API
fetchnative compatible Workers. - Abandon de certaines dépendances Node.js incompatibles, remplacées par des équivalents plus légers.
- Mise en place d’un cache Workers KV pour éviter de solliciter l’origine WordPress à chaque requête edge.
Un gain de latence mesuré en dizaines voire centaines de millisecondes n’a de sens que rapporté au coût d’ingénierie qu’il impose : sur un site où l’audience mondiale n’existe pas encore, ce chantier resterait un investissement prématuré.
Verdict
Pour ce site de documentation à audience réellement mondiale, le gain de latence justifiait largement l’effort de migration vers Cloudflare Workers, avec un écart particulièrement flagrant pour les visiteurs les plus éloignés du serveur d’origine. Sur un projet dont l’audience reste concentrée dans une seule région géographique, proche du serveur d’origine, l’ISR reste un choix pertinent, nettement plus simple à opérer et suffisant pour offrir une latence acceptable à l’écrasante majorité des visiteurs.
