Loading...
OUTIL GRATUIT

Générateur d'en-tête Cache-Control

Choisissez vos directives de cache et copiez l'en-tête Cache-Control exact — ainsi que des snippets nginx et Apache prêts à coller. Fonctionne entièrement dans votre navigateur ; rien n'est envoyé nulle part.

Préréglages :

1 · Choisir les directives

2 · Copier le résultat

En-tête HTTP
Cache-Control: public, max-age=3600
nginx
add_header Cache-Control "public, max-age=3600" always;
Apache (.htaccess)
Header set Cache-Control "public, max-age=3600"

Sur CDN.com.tr, vous ne modifiez pas de fichiers de configuration — réglez le cache par chemin depuis Delivery Rules dans le panneau, et ces directives correspondent aux mêmes options.

Ce que fait chaque directive Cache-Control

L'en-tête Cache-Control indique aux navigateurs et aux caches CDN/proxy s'ils peuvent stocker une réponse, où et pour combien de temps. Bien le régler est l'un des plus grands gains pour la vitesse des pages et la charge de l'origine. Voici ce que signifie chaque directive ci-dessus.

public vs private

public permet à tout cache — y compris un CDN ou un proxy partagé — de stocker la réponse. private limite le stockage au seul navigateur de l'utilisateur final ; utilisez-le pour des réponses personnalisées ou authentifiées qui ne doivent jamais être servies à un autre utilisateur.

max-age et s-maxage

max-age=N est le nombre de secondes pendant lesquelles la réponse reste « fraîche » (servie sans revalidation). s-maxage=N remplace max-age pour les caches partagés (votre CDN), vous pouvez donc mettre en cache longtemps à l'edge tout en gardant les navigateurs sur une fenêtre plus courte — p. ex. max-age=0, s-maxage=3600.

no-cache vs no-store

Ils se ressemblent mais diffèrent : no-cache autorise la mise en cache mais force la revalidation auprès de l'origine avant chaque réutilisation (bon pour du HTML qui change). no-store interdit totalement la mise en cache — rien n'est écrit dans aucun cache ; utilisez-le pour des données sensibles, propres à chaque requête.

stale-while-revalidate et stale-if-error

stale-while-revalidate=N permet à un cache de servir instantanément une réponse un peu périmée pendant qu'il se rafraîchit en arrière-plan — les visiteurs n'attendent jamais l'origine. stale-if-error=N sert la dernière bonne copie si l'origine est en panne, gardant votre site en ligne pendant les incidents.

immutable

Signale que le contenu ne changera jamais pendant son max-age, les navigateurs sautent donc la revalidation même au rechargement. Idéal pour les ressources statiques hachées comme app.9f2c1.js — associez-le à un max-age long : public, max-age=31536000, immutable.

must-revalidate et proxy-revalidate

Une fois une réponse périmée, must-revalidate interdit de la servir sans vérifier d'abord auprès de l'origine (pas de livraison périmée silencieuse). proxy-revalidate applique la même règle aux seuls caches partagés, laissant plus de marge aux navigateurs.

Recettes courantes

Ressource statique hachée : public, max-age=31536000, immutable — mettre en cache « pour toujours » ; le hash change quand le fichier change.

HTML derrière un CDN : public, max-age=0, s-maxage=3600, stale-while-revalidate=86400 — les navigateurs revalident toujours, l'edge sert le HTML en cache et le rafraîchit en arrière-plan.

Personnalisé/authentifié : private, no-store — jamais mis en cache par le CDN ni les proxys partagés.

Vous voulez appliquer ces règles automatiquement ?

CDN.com.tr définit les en-têtes de cache par chemin depuis le panneau — sans fichiers de configuration, avec cache à l'edge, Auto SSL et WAF inclus.

Voir les offres