Qu'est-ce qu'un CDN : définition, rôle réel et limites
Un réseau de diffusion de contenu, ou CDN, est un ensemble de serveurs répartis en de nombreux endroits qui conservent des copies des mêmes données pour répondre au visiteur depuis le point le plus proche de lui. La définition de MDN tient en deux phrases ; ses conséquences sont plus longues, car un CDN change ce que le visiteur attend de l'origine et introduit une dépendance qui n'est pas sans contrepartie.
La définition, et ce qu'elle sous-entend
MDN décrit un CDN comme un groupe de serveurs répartis sur de nombreux emplacements, qui stockent des copies dupliquées des données afin que les serveurs répondent aux demandes selon celui qui est le plus proche du visiteur. Trois mots portent tout le mécanisme : répartition géographique, duplication, proximité. Un CDN n'est donc pas un hébergeur au sens courant, c'est une couche placée devant le serveur d'origine.
La même page rappelle l'usage le plus courant : servir les feuilles de style et les fichiers JavaScript de bibliothèques publiques. Elle ajoute que des sites entiers peuvent être servis depuis un CDN, en particulier les sites entièrement statiques composés de HTML, CSS et JavaScript. La portée réelle dépend donc du contenu : ce qui est identique pour tous se met en cache, ce qui est calculé pour un visiteur ne se met pas en cache.
Ce que le CDN fait entre le visiteur et l'origine
La première décision est une décision de routage : le nom du site résout vers une infrastructure qui choisit un point de présence, souvent par diffusion anycast ou par mesure de latence. La connexion se termine là, et non sur le serveur d'origine, ce qui raccourcit les échanges de poignée de main. Le point de présence peut ensuite servir une copie en cache, dont la fraîcheur est calculée selon la RFC 9111, sans que l'origine voie la requête.
Viennent ensuite la compression, la négociation de version et parfois la transformation d'image. Pour une ressource présente en cache, l'origine ne travaille pas du tout : c'est le gain le plus net et le plus facile à mesurer. Pour une ressource absente du cache — une page personnalisée, une recherche, un formulaire — le point de présence n'est qu'un relais vers l'origine, avec le trajet aller-retour en supplément.
Pourquoi la distance pèse autant
MDN le formule directement : la distance géographique affecte la latence proportionnellement. Avant le premier octet de contenu, plusieurs allers-retours ont lieu — résolution du nom, établissement de la connexion, négociation TLS — et chacun paie le trajet. Rapprocher l'extrémité de la connexion raccourcit chacun de ces échanges, ce qui compte davantage que le débit brut annoncé sur une offre commerciale.
C'est aussi la raison pour laquelle un CDN aide beaucoup un visiteur éloigné et peu un visiteur situé près de l'origine. Sur un site dont l'audience est concentrée dans une seule région, le bénéfice de proximité est faible ; sur un site lu depuis plusieurs continents, il est structurel. La question n'est donc pas « faut-il un CDN » mais « d'où ce site est-il lu ».
Les limites que MDN souligne aussi
La même page liste les inconvénients, et ils ne sont pas théoriques. Le premier est la dépendance : si le CDN tombe, est bloqué dans une région ou ferme définitivement, le site dysfonctionne. Le deuxième est la surface d'attaque : un CDN compromis peut servir du contenu malveillant à vos visiteurs, d'où l'intérêt des mécanismes d'intégrité de sous-ressource, qui vérifient l'empreinte d'un fichier chargé depuis un tiers.
Le troisième est contre-intuitif et vaut d'être répété : un CDN peut réduire la performance. Établir une connexion vers un site tiers ajoute des résolutions de noms et des négociations, et les navigateurs modernes ne partagent pas leur cache entre origines pour des raisons de vie privée. Le même fichier peut donc être téléchargé plusieurs fois au fil de la navigation, malgré la mise en cache annoncée.
Ce qu'un CDN ne répare pas
Un CDN ne corrige pas une origine lente. Si une page exige une requête de base de données coûteuse à chaque affichage, la mettre en cache est la seule réponse utile, et cette décision appartient au site, pas au réseau de diffusion. Les en-têtes de cache, les durées de vie et les règles de purge restent la responsabilité de l'application : sans eux, le CDN ne peut que relayer plus vite une réponse déjà produite.
Il ne répare pas non plus une page dont le contenu dépend du visiteur : panier, espace client, résultat de recherche. Ces réponses sortent du cache par construction, ou ne doivent jamais y entrer. La proportion de requêtes servies depuis le cache est donc l'indicateur qui décide si la couche apporte quelque chose, et il se mesure, il ne s'annonce pas.
Mesurer l'apport sans chiffres de vitrine
La méthode est simple et reproductible : relever le temps jusqu'au premier octet et le temps de chargement complet depuis plusieurs lieux, avant et après la mise en place, à heure comparable et sur les mêmes pages. Ajouter le taux de réponses servies depuis le cache, lu dans les en-têtes de réponse. Un gain annoncé sans mesure avant et après ne dit rien du site concerné, seulement du fournisseur qui l'annonce.
Il faut également regarder la stabilité, pas seulement la moyenne : un CDN qui accélère le cas courant et échoue sur les formulaires dégrade l'expérience réelle. Enfin, les journaux changent de forme et de lieu : les adresses visibles deviennent celles des points de présence, ce qui complique le comptage des visiteurs et l'analyse des incidents. Cette conséquence se prévoit avant, pas après.
Quand un CDN n'apporte rien
Trois situations rendent la couche inutile : une audience concentrée géographiquement, un site presque entièrement dynamique, et un volume de trafic trop faible pour que la proximité change quoi que ce soit. Dans ces cas, le coût se paie en complexité — une dépendance de plus, une configuration de cache à maintenir, des journaux déplacés — sans contrepartie mesurable.
La décision se prend donc sur des mesures, pas sur une intuition de modernité. Un site vitrine de quelques pages, lu depuis une seule région, gagne plus à alléger ses images et à réduire ses requêtes qu'à ajouter un intermédiaire. À l'inverse, une documentation statique lue dans le monde entier est le cas d'usage où la couche est la plus rentable.