Couverture CDN et TTFB : pourquoi la distance ralentit encore votre site
La promesse d’un CDN est séduisante et surtout vraie : placez votre contenu sur un réseau de serveurs partout dans le monde, et chaque visiteur est servi depuis un point proche, donc la distance cesse de compter. Les équipes ajoutent un CDN, voient leurs temps de chargement d’assets chuter, et supposent le problème de distance résolu. Puis elles vérifient leur Time to First Byte et il est toujours élevé - parfois autant qu’avant. Le CDN n’a pas échoué. Il ne fait juste pas la chose qu’elles supposaient. Voici la distinction qui éclaire tout.
Deux choses différentes voyagent vers votre visiteur
Quand un navigateur charge une page, il récupère deux types de contenu catégoriquement différents, et un CDN les traite différemment :
- Les assets statiques — images, fichiers CSS, JavaScript, polices. Ils sont identiques pour chaque visiteur, donc un CDN peut les copier vers des points périphériques du monde entier et les servir depuis le plus proche. C’est ce qu’un CDN fait brillamment par défaut.
- Le document HTML — la page elle-même. Sur beaucoup de sites, il est généré à chaque requête (WordPress interrogeant une base, une appli rendue par utilisateur), ce qui est par défaut marqué non cachable - le CDN transmet donc la requête à votre serveur d’origine, où qu’il soit.
Le Time to First Byte mesure cette réponse du document - la première chose qui arrive, avant tout asset. Et si le document vient d’une origine lointaine, votre TTFB paie tout le coût de distance même avec un CDN devant vos assets.
Pourquoi « j’ai un CDN » ne corrige pas le TTFB
Imaginez un visiteur à Montréal et un serveur d’origine à Francfort, avec un CDN entre les deux :
| Requête | Servie depuis | Coût de distance |
|---|---|---|
| Image d’en-tête (statique) | Point CDN près de Montréal | Faible - point proche |
| Feuille de style (statique) | Point CDN près de Montréal | Faible - point proche |
| La page HTML (dynamique) | Origine à Francfort | Élevé - aller-retour transatlantique |
Les images et le CSS arrivent d’à côté. La page elle-même - celle dont l’arrivée est mesurée par le TTFB - traverse encore un océan. Le visiteur voit donc des assets rapides attachés à un premier octet lent, et le tableau de bord du CDN affiche d’excellents chiffres d’assets pendant que les données terrain montrent un mauvais TTFB. Les deux sont vrais. Ils mesurent des choses différentes.
Le correctif : amener le document en périphérie aussi
Résoudre le TTFB, c’est rendre le document lui-même servable depuis la périphérie, pas seulement les assets. Il y a deux voies :
- Mettre le HTML en cache en périphérie. Si une page est identique pour tout le monde, le CDN peut être configuré pour mettre en cache et servir le document depuis les points périphériques aussi - pas seulement les assets. Cela exige que la page soit réellement cachable, ce que les pages dynamiques par requête ne sont souvent pas sans configuration soignée.
- Rendre le site statique dès le départ. Une architecture statique-first pré-rend chaque page en fichier HTML au moment du build. Comme il n’y a pas de génération par requête, le document est trivialement cachable et peut être servi depuis la périphérie partout - le CDN traite vos pages exactement comme vos images. C’est la voie la plus propre vers un TTFB bas quel que soit l’emplacement du visiteur.
La différence est architecturale : un site dynamique lutte pour rendre ses documents servables en périphérie ; un site statique l’est par nature.
Couverture périphérique : tous les CDN ne couvrent pas votre audience également
Il y a un second facteur, plus subtil : où se trouvent réellement les points périphériques. « CDN mondial » sonne exhaustif, mais ce qui compte, c’est la densité de couverture dans la région de votre audience. Un réseau à des centaines de points concentrés aux États-Unis et en Europe peut quand même laisser des utilisateurs d’un marché vaste et moins densément servi être routés vers un point lointain.
Cela compte le plus pour les marchés géographiquement vastes. Un pays étalé sur des milliers de kilomètres - avec des utilisateurs dans les grandes villes et dans des régions rurales et éloignées - n’est bien servi que par un CDN à couverture réelle sur cette étendue, pas juste un point dans la plus grande ville. Pour évaluer un CDN, la question utile n’est pas « combien d’emplacements a-t-il dans le monde » mais « à quelle distance est le point le plus proche de mes vrais visiteurs ».
Une checklist pratique
- Séparez les deux chiffres. Vérifiez les temps de chargement d’assets et le TTFB du document indépendamment - un CDN peut rendre l’un excellent et laisser l’autre mauvais.
- Découvrez si votre HTML est mis en cache en périphérie ou récupéré depuis l’origine. Si chaque requête de page atteint votre origine, c’est votre plafond de TTFB.
- Préférez des pages statiques ou cachables en périphérie pour que le document bénéficie de la périphérie, pas seulement les assets.
- Évaluez la couverture là où sont vos utilisateurs, pas le nombre d’emplacements mondiaux.
Voyez où en est réellement votre TTFB
Notre outil gratuit mesure directement le TTFB réel de votre document - le chiffre qu’une configuration CDN limitée aux assets ne corrigera pas. S’il est élevé malgré un CDN, vous venez de trouver la raison pour laquelle votre performance en données terrain traîne derrière vos tests synthétiques.
Vérifiez le TTFB de votre site →
Envie d’un site rapide partout ?
Nous construisons des sites statique-first dont les pages - pas seulement les assets - sont servables depuis la périphérie, pour que le TTFB reste bas qu’un visiteur soit dans une grande ville ou une région éloignée. Si la distance ralentit encore la réponse de votre document, c’est exactement le problème que nous corrigeons.
Obtenez un audit technique gratuit →
Publié par l’Équipe Ingénierie Runkexpert. Dernière mise à jour le 26/07/2026.