Combien coûte réellement chaque milliseconde gagnée sur un site qui vend aux quatre coins du monde ? Argo Smart Routing, l’option de Cloudflare facturée au gigaoctet de trafic, promet de router les requêtes vers l’origine par le chemin réseau le plus rapide plutôt que par le chemin géographiquement le plus court. Sur le papier, l’argument séduit. En pratique, il fallait le mesurer sur un cas réel avant de le recommander à un client qui hésitait à l’activer.
Le site en question est une boutique WooCommerce hébergée en France, avec une clientèle répartie entre l’Europe de l’Ouest et l’Asie du Sud-Est, en particulier Singapour et Hong Kong. L’objectif de ce comparatif était simple : quantifier le gain de TTFB apporté par Argo sur ces deux zones géographiques, et déterminer si le surcoût se justifie économiquement pour ce profil de trafic.
Protocole de mesure
Les tests ont été réalisés avec WebPageTest depuis quatre points de mesure : Paris, Londres, Singapour et Tokyo, sur cinquante requêtes successives par point et par configuration, en ciblant une page produit mise en cache par Cloudflare (donc hors temps de génération WordPress, pour isoler la seule variable réseau). Deux configurations ont été comparées sur le même compte Cloudflare : Argo désactivé, puis Argo activé, à 24 heures d’intervalle pour éviter les biais liés à la charge du réseau à un instant donné.
Les chiffres, zone par zone
Depuis Paris et Londres, la différence est marginale : 4 à 7 % de latence réseau en moins avec Argo, ce qui reste dans la marge d’erreur des mesures successives. La proximité géographique et la densité du réseau Cloudflare en Europe de l’Ouest font qu’un chemin déjà quasi optimal ne peut pas beaucoup s’améliorer.
Depuis Singapour, en revanche, l’écart devient significatif : 38 % de latence réseau en moins, soit un TTFB perçu réduit d’environ 210 ms sur cette route spécifique. Depuis Tokyo, le gain se situe autour de 29 %. Ces deux zones bénéficient du fait qu’Argo peut router le trafic par des chemins privés entre datacenters Cloudflare plutôt que de traverser un réseau public parfois congestionné entre l’Asie et l’Europe.
| Zone de test | TTFB sans Argo | TTFB avec Argo | Gain |
|---|---|---|---|
| Paris | 48 ms | 45 ms | 6 % |
| Londres | 61 ms | 57 ms | 7 % |
| Singapour | 552 ms | 342 ms | 38 % |
| Tokyo | 481 ms | 341 ms | 29 % |
Justifier le coût auprès d’un client
Argo est facturé en supplément du plan Cloudflare, au gigaoctet de trafic transféré, ce qui inquiète légitimement un client habitué à des coûts fixes. L’argument à lui présenter n’est pas « Argo rend le site plus rapide » de façon générale, mais la donnée segmentée : sur ce site précis, la part du trafic Asie représentait 18 % des sessions mais généraient un taux de rebond nettement plus élevé, corrélé à des temps de chargement supérieurs à la seconde. Réduire ce temps de 200 ms sur ce segment a un impact business mesurable, quand le même effort sur le trafic français n’en aurait presque aucun.
Ce qu’Argo ne fait pas
Il est utile de rappeler à un client ce qu’Argo n’apporte pas : il ne remplace pas le cache de page Cloudflare, qui reste une option séparée et gratuite sur le plan de base. Argo agit uniquement sur le trajet réseau entre l’edge Cloudflare et l’origine (ou entre deux edges Cloudflare), pas sur le temps de génération de la page côté WordPress. Un site avec un TTFB serveur déjà élevé (mauvais hébergement, absence de cache objet) ne sera pas sauvé par Argo : il faut d’abord traiter le temps de génération avant d’optimiser le transport réseau.
Ne facturez jamais Argo à un client sans lui montrer la carte de son trafic par zone géographique. C’est cette carte, pas une promesse générale, qui justifie la dépense.
Notre verdict
Sur ce projet, Argo Smart Routing a été activé uniquement après validation du gain mesuré, avec un suivi mensuel du coût réel engendré comparé au volume de trafic international. Le verdict : l’option se justifie clairement dès qu’une part significative du trafic vient de zones éloignées géographiquement de l’origine, et devient superflue sur un site à audience purement locale ou déjà servi par un edge proche. La mesure préalable, zone par zone, reste le seul argument recevable pour ce type de dépense récurrente.
