vendredi 25 septembre 2026

À propos

Contact

Performance

Un CDN régional pour l’Asie : la latence WordPress mesurée avant et après

Un site multilingue vendant en Europe et en Asie souffrait d'un TTFB de plus de 2 secondes depuis Tokyo. Mesures avant et après un point de présence régional.

Par Clément Hadrot • 18 juin 2021 • 4 min de lecture • Aucun commentaire
Un CDN régional pour l'Asie : la latence WordPress mesurée avant et après

Un fabricant français d’accessoires de photographie vendait depuis plusieurs années en Europe avec un WordPress WooCommerce hébergé à Paris, avant d’ouvrir une nouvelle zone de vente en Asie, portée par une distribution via des revendeurs à Tokyo et Singapour. Les premiers retours clients dans cette zone évoquaient un site « lent à charger », sans plus de précision. Les outils de test habituels, lancés depuis l’Europe, ne montraient pourtant rien d’anormal.

La cause s’est révélée évidente une fois le test effectué depuis le bon endroit : un serveur d’origine unique à Paris, sans CDN à point de présence proche de l’Asie, imposait à chaque requête un aller-retour réseau de plusieurs dizaines de milliers de kilomètres avant même que WordPress ne commence à générer la page.

Mesurer depuis le bon endroit

Les outils de test synthétique habituels, lancés depuis des serveurs situés en Europe ou aux États-Unis, ne reproduisent pas l’expérience réelle d’un visiteur situé en Asie. Le test a donc été refait avec WebPageTest, en sélectionnant explicitement un point de mesure à Tokyo. Le résultat était sans appel : un TTFB de 2,1 secondes en moyenne sur cinq mesures, contre environ 200 millisecondes depuis un point de mesure parisien pour la même page.

Une partie de cet écart s’explique par la latence physique du réseau : le temps qu’un paquet met à parcourir la distance Tokyo-Paris et retour dépasse déjà 250 à 300 millisecondes incompressibles, avant même de compter l’établissement de la connexion TLS, qui ajoute plusieurs allers-retours supplémentaires sur une connexion non réutilisée.

Ce qu’un CDN régional change concrètement

Le choix ne portait volontairement pas sur la comparaison entre différents fournisseurs de CDN, déjà largement traitée par ailleurs, mais sur l’ajout d’un point de présence proche des visiteurs asiatiques pour les ressources statiques et, via une configuration de cache de page en périphérie, pour le HTML des pages les plus consultées.

L'essentiel à retenir : La distance géographique au serveur d'origine explique une grande part du TTFB ; Un point de présence régional réduit le trajet réseau, pas le temps de génération ; Le gain se mesure en centaines de millisecondes, pas en pourcentage

La configuration mise en place

Trois éléments ont été combinés pour réduire ce TTFB régional :

  • Activation du point de présence CDN le plus proche du trafic asiatique pour les fichiers statiques : images produits, CSS, JavaScript.
  • Mise en cache en périphérie des pages de catalogue et de fiche produit, servies directement depuis le point de présence régional sans repasser par Paris, avec une purge automatique déclenchée à chaque modification de contenu.
  • Passage en TLS avec reprise de session activée côté serveur d’origine, pour réduire le coût de l’établissement de connexion sur les requêtes qui devaient malgré tout atteindre Paris.

La mise en cache en périphérie du HTML a demandé une vérification préalable : les pages de fiche produit affichaient un contenu identique pour tous les visiteurs non connectés, ce qui rendait cette mise en cache sans risque. Les pages de panier et de compte client, en revanche, sont restées explicitement exclues du cache CDN, avec un en-tête Cache-Control: no-store renvoyé par WordPress sur ces routes.

Les résultats mesurés

Après mise en place, le même test WebPageTest depuis Tokyo donnait un TTFB moyen de 380 millisecondes pour les pages de catalogue servies depuis le cache régional, contre 2,1 secondes initialement. Les pages non couvertes par le cache de périphérie, comme le tunnel de commande, restaient proches de leur temps initial, ce qui confirme que le gain provient bien de l’évitement du trajet long vers Paris, pas d’une amélioration du temps de génération côté serveur d’origine.

Type de pageTTFB avantTTFB après
Page catalogue (cache CDN)2,1 s380 ms
Fiche produit (cache CDN)1,9 s410 ms
Tunnel de commande (non caché)2,0 s1,7 s

Pour aller plus loin

Ce cas ne traite pas le choix entre les différents CDN du marché, une décision qui dépend fortement du budget et des zones déjà couvertes par l’hébergeur existant. Il illustre surtout l’importance de tester la performance depuis l’endroit réel où se trouvent les visiteurs concernés, plutôt que de se fier à une mesure unique effectuée depuis le pays du siège de l’entreprise.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi