Qu'est-ce qu'un CDN (Content Delivery Network) ? Fonctionnement

Qu'est-ce qu'un CDN (Content Delivery Network) ?

Un réseau de diffusion de contenu (CDN) est un groupe de serveurs répartis sur de nombreux sites, qui conservent des copies de votre contenu et répondent à chaque requête depuis le site le plus proche du visiteur. Il raccourcit la distance parcourue par les données, soulage votre serveur et garde le contenu populaire disponible lors des pics.

Votre serveur reste la source de référence et s'appelle le serveur d'origine. Les serveurs du CDN placés devant lui sont les serveurs edge (de périphérie). MDN décrit l'idée de la même façon : des copies des données, servies par les serveurs les plus proches de chaque utilisateur.

Comment fonctionne un CDN

1. Le navigateur demande une URL de votre domaine, et le DNS l'oriente vers un serveur edge du CDN proche du visiteur.
2. L'edge consulte son cache. En cas de succès (hit), il répond tout de suite. En cas d'échec (miss), il récupère le fichier auprès de l'origine ou d'un cache intermédiaire, en garde une copie, puis répond.
3. Les visiteurs suivants de cette zone reçoivent la copie conservée jusqu'à son expiration (TTL) ou jusqu'à ce que vous la purgiez.

La part des requêtes servies depuis le cache est le taux de succès du cache (cache hit ratio), le chiffre qui dit si le CDN remplit son rôle. La même idée s'applique un niveau plus bas, avec le cache d'API.

Ce qu'il faut mettre en cache, et ce qu'il faut exclure

L'en-tête de réponse Cache-Control indique au CDN ce qu'il peut conserver et pendant combien de temps.

Attention aux noms : no-cache ne veut pas dire « ne pas stocker », mais « vérifier auprès de l'origine avant de réutiliser ». C'est no-store qui interdit le stockage. Toutes les directives figurent dans la référence MDN sur Cache-Control.

Pourquoi utiliser un CDN

• Latence réduite. La distance joue sur la latence, et un serveur edge proche est plus proche que votre origine pour la majeure partie du monde. C'est d'abord le temps jusqu'au premier octet qui s'améliore.
• Moins de charge sur l'origine. Chaque requête servie à l'edge est une requête que vos serveurs ne voient jamais : une infrastructure plus petite suffit pour le même trafic.
• Pics de trafic. Le contenu en cache continue d'être servi pendant que votre origine ferait sinon la queue.
• Résilience. Si un site edge a un problème, les requêtes peuvent être routées vers un autre. Les copies en cache peuvent continuer à répondre tant que l'origine est lente.
• Protection et options. Beaucoup de fournisseurs terminent le TLS, compressent les réponses et filtrent le trafic abusif à l'edge. Cela aide face aux attaques par saturation (voir comment arrêter les attaques DDoS), mais ne remplace pas la limitation de débit sur votre propre origine.

Erreurs courantes avec un CDN

• Fichiers périmés après un déploiement. Mettez un hash dans le nom des fichiers statiques pour qu'une nouvelle version ait une nouvelle URL, et ne purgez que les rares URL dont le nom ne peut pas changer, comme le HTML. Notre article sur l'invalidation du cache et les tests de performance (en anglais) va plus loin.
• Mettre en cache des réponses personnalisées. Oublier private sur une réponse propre à un utilisateur peut laisser un cache partagé la remettre à quelqu'un d'autre. MDN met précisément en garde contre cela.
• Une clé de cache trop précise. Si des cookies ou des paramètres aléatoires entrent dans la clé, le CDN stocke une copie par variante et le taux de succès s'effondre. Retirez tout ce qui ne change pas la réponse.
• Cache stampede. Quand un objet populaire expire, de nombreux edges interrogent l'origine en même temps. stale-while-revalidate ou une couche d'origin shield absorbe ce pic.
• Croire qu'un CDN est toujours plus rapide. MDN rappelle qu'un hôte tiers ajoute sa propre résolution DNS et sa propre connexion. Si votre public est à côté de l'origine, le gain peut être faible : mesurez-le.
• Ne jamais tester un échec de cache. Après une purge ou un déploiement, l'origine doit encaisser toute la charge pendant un moment.

CDN et edge computing

Un CDN stocke et sert du contenu. L'edge computing exécute votre code sur ces mêmes sites, par exemple pour réécrire une requête ou personnaliser une réponse près de l'utilisateur. Beaucoup de fournisseurs proposent les deux, mais seul le premier est un CDN au sens classique.

Comment tester et surveiller un CDN

• Lisez les en-têtes de réponse. L'en-tête Age indique depuis combien de temps l'objet est dans un cache proxy ; une valeur de 0 signifie en général qu'il vient de l'origine. La plupart des fournisseurs ajoutent aussi leur propre en-tête d'état du cache. L'outil gratuit curl Online envoie la même requête depuis six régions AWS et affiche statut, en-têtes et temps, pour comparer les sites edge.
• Suivez la vitesse par région. La surveillance de la vitesse des pages lance des audits Lighthouse planifiés depuis 25 régions cloud et montre si le CDN aide partout ou seulement près de votre origine. Suivez-la avec les Core Web Vitals.
• Testez au-delà du cache. Un test de charge sur une URL en cache mesure surtout le CDN. Testez aussi avec des requêtes qui contournent le cache pour voir ce que fait votre origine à froid. Notre article sur les emplacements edge dans les tests cloud (en anglais) explique pourquoi le lieu du test compte.

Questions fréquentes : CDN

Ai-je besoin d'un CDN pour un petit site ?

Si presque tous vos visiteurs sont dans une région proche de votre serveur, le gain est faible. Si vos visiteurs sont dispersés dans le monde, ou si vous voulez un tampon pour les pics de trafic, un CDN vaut le coup. Beaucoup de fournisseurs proposent une offre de départ gratuite ou peu chère.

Un CDN peut-il mettre en cache des réponses d'API ?

Oui, avec précaution. Les réponses GET en lecture seule, identiques pour tous, se mettent bien en cache. Les données personnelles, comme GET /me, doivent être marquées private ou no-store. Utilisez Cache-Control et Vary de façon réfléchie.

Comment vider le cache après un déploiement ?

Utilisez des noms de fichiers versionnés ou avec hash pour les fichiers statiques : chaque version a une nouvelle URL et il n'y a rien à vider. Pour les URL qui gardent leur nom, comme les pages HTML, appelez l'API de purge de votre fournisseur après le déploiement.

Comment savoir si une réponse vient du cache du CDN ?

Regardez les en-têtes de réponse. Un en-tête Age différent de 0 indique que l'objet vient d'un cache proxy, et la plupart des CDN ajoutent leur propre en-tête indiquant hit ou miss. Répétez la requête et comparez.

Un CDN protège-t-il contre les attaques DDoS ?

Il aide, car les attaques par saturation sont absorbées à l'edge avant d'atteindre votre origine. Il ne remplace ni la limitation de débit, ni un pare-feu applicatif, ni un plan contre les attaques de couche applicative sur les points d'accès dynamiques.

Un CDN a-t-il un effet sur le SEO ?

De façon indirecte. Un chargement plus rapide peut améliorer les Core Web Vitals, que Google recommande de soigner pour la recherche. Un cache mal configuré peut aussi servir d'anciens titres et balises meta ou bloquer les robots : vérifiez ce que le CDN renvoie à Googlebot.