Un CDN conserve des copies de vos fichiers en de nombreux endroits et sert chaque visiteur depuis le plus proche. Cela supprime la distance, et la distance est bien réelle : une requête du Caire vers un serveur en Allemagne coûte environ 60 ms avant que quoi que ce soit ne soit calculé, et cela pour chaque fichier.

Ce qu'il corrige vraiment

  • La latence des fichiers statiques — images, CSS, JavaScript, polices — pour les visiteurs éloignés de votre serveur.
  • Les pics de bande passante, car l'origine sert chaque fichier une fois au lieu d'une fois par visiteur.
  • Un bouclier grossier mais efficace contre les déferlements de trafic.
  • La négociation TLS, qui se fait près du visiteur au lieu de traverser un océan.

Ce qu'il ne corrige pas

  • Une requête lente. Le HTML vient toujours de votre serveur, et il est toujours lent.
  • Une page qui ne peut pas être mise en cache parce qu'elle est propre au visiteur.
  • Une première visite sur un nœud froid, qui paie de toute façon le trajet complet.

Ce qu'il masque

C'est la partie qui coûte du temps aux gens. Avec un CDN devant, vos propres tests sont rapides parce que vous tombez à chaque fois sur une copie en cache, tandis qu'un client connecté sur une page non cachable reçoit la vraie réponse, la lente. Mesurez l'origine directement quand vous cherchez un goulet d'étranglement.

curl -sS -o /dev/null -w 'origin ttfb %{time_starttransfer}\
' \
     --resolve yourdomain.com:443:203.0.113.10 https://yourdomain.com/

Deux choses à régler dès le premier jour

  • La vraie adresse IP du visiteur. Tous vos journaux et toutes vos limites de débit voient le CDN tant que vous ne l'avez pas configuré — voir Cloudflare et la vraie adresse IP du visiteur.
  • La purge. Sachez vider un seul fichier et sachez tout vider, avant qu'un déploiement en ait besoin.
Ne mettez pas de CDN devant un panneau d'administration ni devant une API qui s'authentifie par en-tête. Y mettre du cache est une fuite de données, pas un gain de vitesse.