Un fichier Docker Compose ? Votre projet est en ligne en quelques secondes, en une seule commande sur cdn.com.tr. Voir comment App créée avec l'IA ? Du dossier au live en une commande — sans git ni registry : cdnctl deploy. Voir comment Votre code sur GitHub ? Chaque push se déploie tout seul sur cdn.com.tr — connectez votre dépôt. Voir comment

Études de cas

Étude de cas : la configuration des en-têtes de cache d'un site d'actualités

Un site d'actualités sportives turc à fort trafic gère le cache depuis son propre serveur d'origine plutôt que depuis le panneau. Quatre niveaux de contenu, quatre en-têtes Cache-Control différents, le tout vérifiable de l'extérieur.

Retour à l'Aide Plateforme
Ce que couvre cette page

Les en-têtes de réponse réels d'un compte en production, et pourquoi ils ont été choisis ainsi. Le client n'est pas nommé ; chaque en-tête présenté ici est écrit de façon à ce que vous puissiez le vérifier sur votre propre site en exécutant la même commande.

Quatre niveaux, quatre durées différentes

Une seule durée de cache ne suffit pas pour un site d'actualités : la page d'accueil change à la minute, le logo ne change pas pendant des années. Ce compte répartit le contenu selon sa vitesse de changement.

Contenu En-tête envoyé par l'origine Pourquoi
Page d'accueil public, max-age=30, s-maxage=30, stale-while-revalidate=60 Les dernières actualités se renouvellent toutes les 30 secondes ; à l'expiration, le visiteur ne doit pas attendre — l'edge sert l'ancienne copie pendant qu'il la rafraîchit en arrière-plan.
Pages de rubrique et de liste public, max-age=300, s-maxage=300, stale-while-revalidate=600 Les pages de catégorie changent moins souvent que la page d'accueil. Cinq minutes n'est pas un délai que la rédaction remarquerait, et cela réduit nettement la charge sur l'edge.
Fichier statique versionné public, max-age=31536000, s-maxage=31536000, immutable Le nom du fichier porte la version, donc son contenu ne change jamais. immutable empêche le navigateur de revérifier même avant l'expiration de max-age.
Image optimisée max-age=31536000 + public sur une ligne séparée Cette ligne est écrite par l'edge, pas par l'origine — avec Image Optimization activé sur une règle, l'en-tête est régénéré sans condition.

Mettre en place le même schéma sur votre site

1

Répartissez le contenu selon sa vitesse de changement

Décidez d'abord quelle route change à quelle fréquence, pas les durées — la durée découle de cette décision.

  • Change en quelques minutes : page d'accueil, scores en direct, fil d'actualités de dernière minute
  • Change en quelques heures : pages de catégorie, listes d'archives
  • Ne change jamais : CSS, JS, polices, logo — tout ce dont le nom de fichier porte une version
  • Personnel : pages connectées, panier, compte — cela n'est pas mis en cache et ne doit pas l'être
2

Publiez les en-têtes depuis votre origine

L'en-tête est envoyé par votre application ou votre serveur web. Il n'est pas nécessaire de saisir une durée dans le panneau ; les deux méthodes ne fonctionnent pas ensemble sur la même règle.

  • s-maxage est destiné au cache partagé (le CDN), max-age au navigateur ; vous pouvez leur donner des valeurs différentes
  • stale-while-revalidate évite d'attendre au visiteur quand la durée expire — l'ancienne copie est servie pendant qu'une nouvelle est récupérée en arrière-plan
  • immutable ne doit être envoyé que si le nom de fichier est versionné ; sur un fichier non versionné, le navigateur reste bloqué avec une copie vieille d'un an
3

Laissez la règle s'aligner sur l'origine

Dans Delivery Rules, la règle de cette route doit avoir **Use browser cache time** activé et **Cache Expire Time** vide.

  • Si vous saisissez une durée, les en-têtes de l'origine sont ignorés sur cette règle et l'en-tête envoyé au navigateur est lui aussi réécrit
  • Vous pouvez séparer les règles par route : une règle pour les fichiers statiques, une autre pour les pages
4

Mesurez, puis étendez

Testez d'abord sur une seule route. Une fois que l'en-tête attendu revient et que vous obtenez HIT, passez aux autres niveaux.

Comment vérifier que ça fonctionne

Tout est visible dans les en-têtes de réponse ; inutile de regarder le panneau. Demandez la même URL deux fois :

curl -sI https://votre-site.com/une-page | grep -iE "cache-control|x-proxy-cache-mt"
  • X-Proxy-Cache-MT: MISS est normal sur la première requête — le contenu est en train d'être mis en cache. La deuxième requête devrait renvoyer HIT.
  • STALE n'est pas une erreur : cela signifie que stale-while-revalidate fait son travail — le visiteur reçoit l'ancienne copie pendant qu'une nouvelle est récupérée en arrière-plan.
  • Si vous voyez BYPASS, vous êtes presque certainement connecté au site ; un cookie de session contourne volontairement le cache. Réessayez dans une fenêtre privée.
  • Si le Cache-Control renvoyé diffère de celui que vous avez envoyé, c'est qu'une durée fixe a été saisie sur cette règle.
  • Si vous voulez aussi voir ce qu'envoie l'origine, activez les en-têtes de diagnostic d'origine sur la règle ; X-Upstream-CacheControl indique ce que dit l'origine, Cache-Control ce que voit le visiteur.

Trois choses qui rendent le bon en-tête inutile

  • Une réponse qui envoie Set-Cookie n'est jamais mise en cache. Peu importe la justesse du Cache-Control. C'est la raison la plus fréquente pour laquelle un cache ne chauffe jamais : l'application pose un cookie de session à chaque requête.
  • Avec Image Optimization activé sur une règle, les images sont conservées 365 jours et l'en-tête de l'origine est ignoré. Si vous voulez gérer les images vous-même, désactivez ce réglage sur cette règle.
  • N'envoyez pas immutable sur un fichier non versionné. Si le nom du fichier ne change pas, le navigateur garde l'ancienne copie pendant un an et un purge CDN ne corrige pas cela — le purge ne nettoie que l'edge, pas le disque du visiteur.

Pour aller plus loin