CDN informatique : à quoi sert un réseau de diffusion

Un CDN, ou réseau de diffusion de contenu, est présenté partout comme la solution à la lenteur d’un site. C’est vrai pour une partie du problème seulement, et la partie qu’il ne traite pas est précisément celle que Google mesure le plus sévèrement. Voici ce qu’un CDN accélère réellement, ce qu’il ne peut pas accélérer, et comment le savoir avant de payer.

Le principe, en une phrase

Un CDN est un ensemble de serveurs répartis géographiquement, appelés points de présence, qui conservent une copie de vos fichiers et la servent depuis le point le plus proche du visiteur.

Le gain est donc d’abord un gain de distance, et la distance se paie en latence incompressible : dans une fibre, le signal parcourt environ 200 000 kilomètres par seconde. Un visiteur situé à 5 000 kilomètres de votre serveur subit une cinquantaine de millisecondes d’aller-retour avant même que le serveur ait commencé à travailler. Rapprocher le fichier supprime cette attente, et rien d’autre.

Ce qu’un CDN accélère, et ce qu’il n’accélère pas

C’est la distinction la plus utile de tout le sujet, et celle que les articles promotionnels évitent. Google évalue l’expérience de chargement avec trois indicateurs, dont les seuils sont publics.

Indicateur	Seuil « bon »	Ce qu’il mesure	Effet d’un CDN
LCP	2,5 secondes	L’affichage du plus gros élément visible	Fort, si cet élément est une image ou une police
INP	200 millisecondes	La réactivité aux clics et aux saisies	Aucun, c’est du JavaScript côté navigateur
CLS	0,1	La stabilité visuelle pendant le chargement	Aucun, cela dépend de votre mise en page

Deux des trois indicateurs sont donc totalement hors de portée d’un CDN. Si votre site est lent parce qu’un script bloque l’interface ou parce que les images n’ont pas de dimensions déclarées, aucun réseau de diffusion n’y changera quoi que ce soit.

Même sur le premier indicateur, la nuance compte. Une page générée à la volée par un CMS attend que le serveur d’origine ait interrogé la base de données et construit le HTML. Ce temps-là, le temps jusqu’au premier octet, n’est pas raccourci par le CDN sauf si la page entière est mise en cache, ce qui n’est pas le réglage par défaut.

Le cache, et les trois directives qui le pilotent

Un CDN ne devine pas ce qu’il peut garder ni combien de temps. C’est votre serveur qui le lui dit, par les en-têtes HTTP. Trois directives suffisent à couvrir la quasi-totalité des cas.

Cache-Control: public, max-age=31536000, immutable
Cache-Control: public, s-maxage=3600, max-age=0
Cache-Control: public, s-maxage=60, stale-while-revalidate=600

• La première ligne convient aux fichiers dont le nom contient une empreinte, comme app.9f3c2a.js : ils ne changent jamais, on peut les garder un an.
• La deuxième dissocie les durées : le CDN garde une heure, le navigateur du visiteur ne garde rien. C’est le bon réglage pour une page dont vous voulez maîtriser la mise à jour.
• La troisième autorise le CDN à servir une version périmée pendant qu’il en récupère une neuve. Le visiteur n’attend jamais, au prix de quelques secondes de décalage.

La purge est le point qui pose réellement problème en exploitation. Une modification publiée reste invisible tant que les points de présence servent l’ancienne copie, et une purge globale déclenchée à chaque publication annule une partie du bénéfice. Décidez de cette stratégie avant la mise en service, pas après le premier incident.

Ce qu’il apporte en plus de la vitesse

• L’absorption des pics. Le serveur d’origine ne voit qu’une fraction des requêtes, celles qui manquent au cache. C’est souvent le vrai bénéfice pour un site qui tombe lors d’un pic de trafic.
• Le filtrage du trafic hostile. Les requêtes malveillantes sont arrêtées au bord du réseau, avant l’hébergement, ce qui complète utilement les mesures décrites dans notre article sur la sécurité d’un serveur.
• Le masquage de l’origine. L’adresse réelle du serveur n’est plus exposée, à condition qu’elle ne fuite pas par ailleurs, ce que nous expliquons dans notre article sur l’adresse IP publique.
• Les protocoles récents. Le point de présence parle souvent HTTP/2 ou HTTP/3 au visiteur même si votre serveur d’origine ne les gère pas.

Quand il en faut un, et quand il n’en faut pas

Le critère est géographique avant tout. Un CDN se justifie quand vos visiteurs sont loin de votre serveur, ou quand ils sont nombreux d’un coup.

• Audience internationale : oui, c’est le cas d’école, et le gain est immédiatement mesurable.
• Beaucoup de médias lourds : oui, images produits, vidéos, documents à télécharger.
• Pics de trafic : oui, pour la stabilité plus que pour la vitesse.
• Site vitrine local, visiteurs français, serveur en France : le gain est faible. La distance est déjà courte, et l’effort est mieux investi ailleurs, comme le détaille notre article sur l’optimisation des performances sans changer d’hébergement.

La mise en service passe généralement par une modification DNS pour faire transiter le trafic par le fournisseur. Le délai de bascule se prépare, et il ne dure pas les 24 à 72 heures habituellement annoncées : c’est expliqué dans notre article sur la propagation DNS.

Ce qu’il coûte, et la ligne qui surprend

La facturation combine en général un volume de données sorties et un nombre de requêtes servies. La première ligne est celle que l’on anticipe, la seconde beaucoup moins : un site chargé en petits fichiers, icônes, vignettes, scripts fragmentés, génère énormément de requêtes pour très peu d’octets.

Avant de souscrire, relevez donc deux chiffres sur votre hébergement actuel : le volume mensuel sortant et le nombre de requêtes. Le second détermine souvent davantage la facture que le premier, et personne ne le regarde.

La réserve, clairement posée

Un CDN ne corrige pas un site mal construit. Il rapproche des fichiers, il ne les allège pas. Une image de 4 mégaoctets servie depuis un point de présence voisin reste une image de 4 mégaoctets, et elle restera le facteur dominant de votre temps d’affichage.

L’ordre des opérations est donc toujours le même : réduire le poids des images, supprimer le JavaScript inutile, corriger les requêtes lentes en base, puis seulement rapprocher ce qui reste. Fait dans l’autre sens, le CDN masque le problème pendant quelques mois et le rend plus difficile à diagnostiquer. Le choix de l’hébergement pèse d’ailleurs davantage que le CDN dans la plupart des cas, comme nous le comparons dans notre article sur les serveurs mutualisés, VPS et dédiés.

Questions fréquentes sur les CDN

À quoi sert un CDN pour un site web ?

À servir les fichiers d’un site depuis un serveur proche du visiteur plutôt que depuis le serveur d’origine. Le gain porte sur la distance parcourue par les données, donc sur la latence, et accessoirement sur la charge absorbée lors des pics de trafic.

Un CDN améliore-t-il les Core Web Vitals ?

Partiellement. Il peut améliorer le LCP quand l’élément le plus visible est une image ou une police. Il n’a aucun effet sur l’INP, qui dépend du JavaScript exécuté dans le navigateur, ni sur le CLS, qui dépend de la mise en page.

Quelle différence entre max-age et s-maxage ?

max-age s’adresse au navigateur du visiteur, s-maxage aux caches partagés comme le CDN. Les dissocier permet de laisser le CDN conserver une page une heure tout en demandant au navigateur de ne rien garder.

Un petit site local a-t-il besoin d'un CDN ?

Rarement. Si les visiteurs et le serveur sont dans le même pays, la distance est déjà courte et le gain est faible. L’effort est mieux investi dans le poids des images et la réduction du JavaScript.

Comment un CDN est-il facturé ?

Le plus souvent au volume de données sorties et au nombre de requêtes servies. La seconde ligne surprend : un site composé de nombreux petits fichiers génère beaucoup de requêtes pour peu d’octets.