Un CDN (réseau de diffusion) copie vos fichiers sur des points proches des visiteurs et termine souvent le TLS plus près d’eux. Le gain est net sur les CSS, JavaScript, images et polices déjà en cache au point de présence. Il est faible sur une page HTML que le serveur recalcule à chaque fois et que le CDN a l’ordre de ne pas stocker. Activer un CDN sans décider quoi mettre en cache revient à ajouter un intermédiaire, pas à raccourcir le travail d’origine.
Ce qui voyage bien, et ce qui revient à l’origine
| Contenu | Mise en cache CDN | Effet attendu |
|---|---|---|
| CSS, JS, polices au nom versionné | Longue, identique au cache navigateur | Moins de distance, moins de charge origine |
| Images publiques | Plusieurs jours, URL stable ou versionnée | Premier affichage plus court hors de votre région |
| HTML d’article ou de fiche identique pour tous | Minutes à heures, selon la fréquence de publication | Soulage l’origine si le HIT est réel |
| HTML panier, compte, recherche | Contournement (no-store ou règle d’URL) | Évite de servir la page d’un autre visiteur |
| API authentifiée | Pas de cache partagé | La proximité réseau reste, le calcul non |
| Réponse personnalisée par cookie | Cache seulement si la clé de cache inclut ce cookie | Très peu de HIT dès que les cookies varient |
s-maxage parle aux caches partagés, dont le CDN. max-age parle au navigateur. Vous pouvez garder un HTML revalidé souvent par le visiteur (max-age court) et un peu plus longtemps au CDN (s-maxage). Ne posez pas un an sur le HTML.
Si l’origine envoie Set-Cookie sur les pages publiques, beaucoup de CDN refusent de les mettre en cache partagé. Réservez le cookie à la session, au panier et au compte.
Mettre le CDN sans couper l’origine
- Passez le DNS du domaine (ou un sous-domaine d’assets) vers le CDN, avec le certificat qui couvre bien
wwwet l’apex. - Gardez l’origine joignable uniquement par le CDN si vous le pouvez (IP allowlist ou en-tête secret), pour que les visiteurs ne contournent pas les règles.
- Reprenez les en-têtes d’origine : le CDN doit respecter
Cache-Control, pas imposer un cache agressif sur tout le site. - Versionnez les assets. Une purge totale à chaque déploiement est le symptôme d’URL qui ne changent pas.
- Excluez panier, commande, compte, et toute URL dont le HTML contient un jeton de formulaire.
- Activez Brotli ou gzip sur le CDN pour le texte. Le choix du format est le même qu’à l’origine : Brotli et gzip.
- Comparez un HIT et un MISS. L’en-tête de debug du fournisseur (
cf-cache-status,x-cache, selon l’outil) doit passer à HIT au second appel d’un asset.
Le temps jusqu’au premier octet d’une page dynamique se joue encore sur l’origine. Si ce temps reste haut une fois le CDN en HIT sur les assets seulement, reprenez les causes d’un TTFB élevé côté PHP, base et cache de page.
Pannes propres au CDN
L’origine peut être saine et le site faux. Causes fréquentes : certificat du CDN qui ne couvre pas le nom demandé, règle qui met en cache une 500 (les visiteurs reçoivent l’erreur longtemps), purge oubliée après publication, ou variation de langue ignorée (un seul HTML pour deux langues).
Une 500 mise en cache se traite en baissant le TTL des erreurs à quelques secondes, pas en vidant le CDN à la main à chaque incident. Après une correction de contenu, purgez l’URL du HTML et laissez les assets versionnés expirer seuls.
Surveillez à la fois l’origine et l’URL publique. Un contrôle qui tape l’IP d’origine en http ne voit pas le certificat ni le cache du CDN. Le point de contrôle utile est l’URL que les visiteurs ouvrent, comme indiqué dans Ce qu’il faut surveiller sur un CDN.
Le HTML personnalisé se contourne. Le fichier versionné se garde longtemps. Les deux règles tiennent sur une ligne de configuration chacune.