L'équipe active le cache page entière. Le TTFB chute de 800 ms à 40 ms — victoire. Sauf que le bandeau « Bonjour Admin » apparaît aux visiteurs anonymes, le compteur panier affiche 0 pour tout le monde, et le test A/B sert la variante B à 100 % des utilisateurs pendant six heures.
Le cache de page dynamique n'est pas un interrupteur. C'est un contrat sur la variabilité : quelles parties de la réponse HTML sont identiques pour quels segments d'utilisateurs, et pendant combien de temps. Mal défini, il accélère le site en créant des bugs silencieux — pires qu'une lenteur honnête.
Matrice : cacheable ou pas ?
| Contenu | Cache page entière ? | Alternative |
|---|---|---|
| Article publié statique | Oui (TTL + purge) | CDN long cache |
| Home liste éditoriale | Oui court TTL | Purge à publish |
| Résultats recherche | Rarement (query string) | Cache clé normalisée |
| Page compte / admin | Non | Bypass cache |
| Panier / checkout | Non | no-store |
| Prix stock temps réel | Non sur shell | Fragment AJAX |
Règle d'or : si Set-Cookie ou Vary: Cookie est nécessaire, cache page edge est suspect.
Clés de cache : ce qui différencie les réponses
Une clé naïve URL suffit pour un blog. Pour un site dynamique, combinez URL, langue, classe appareil, bucket test A/B et segment authentification — pas l'identifiant utilisateur en clé page entière (trop de variantes). Whitelist des paramètres query. Bypass cache si cookie session présent.
Stratégies par pile
WordPress : cache objet plus cache page, exclusion /wp-admin, cookies panier WooCommerce.
Symfony / Laravel : cache HTTP kernel, invalidation tag Redis, ESI pour blocs utilisateur.
Headless : CDN sur JSON public ; jamais sur endpoints authentifiés sans clé.
nginx fastcgi_cache : fastcgi_cache_bypass et fastcgi_no_cache si cookie session.
Invalidation : éviter le « flush all » panique
TTL seul pour contenu peu critique. Purge URL à la modification. Tags / Surrogate-Key à la publication CMS. Ban pattern en refonte thème — avec prudence sur pic origine. À la publication, purgez home plus taxonomies plus article.
Voir HTTP cache headers et Varnish : utilisateurs connectés.
CDN plus origine : deux niveaux
Edge cache soulage l'origine. En-têtes Cache-Control cohérents origine → edge. s-maxage pour CDN, max-age pour navigateur. Ne cachez pas réponses avec Set-Cookie sauf configuration edge explicite.
Le sommet : le cache accélère ou ment — rarement les deux sans design
Mesurez ratio hit et taux d'erreurs fonctionnelles post-cache.
Décider et avancer sans angle mort
Classifiez d'abord les URLs en cacheable, non cacheable ou fragment. Définissez les clés et testez avec session et sans. Liez l'invalidation à la publication CMS. Auditez les en-têtes (curl -I) origine et CDN. Surveillez HIT/MISS plus alertes stale au-delà du TTL métier. Comparez hébergeurs compatibles Surrogate-Key via l'annuaire.
Questions fréquentes
Peut-on cacher une page avec utilisateur connecté ?
Rarement en cache page entière. Séparez un shell public cacheable et des blocs privés chargés en AJAX ou ESI, ou définissez des clés strictes par rôle — sans jamais servir une page membre à un visiteur anonyme.
Quelle durée TTL pour un site d'actualité ?
Pour la home et les listes, comptez 60 à 300 secondes avec purge à la publication. Les contenus publiés peuvent tenir plus longtemps. Le panier et le checkout ne doivent jamais transiter par un cache page entière.
Comment invalider proprement ?
Pilotez la purge par événement : clé URL, tag ou Surrogate-Key à chaque sauvegarde CMS. Réservez le flush global aux incidents où vous acceptez un pic de charge sur l'origine.
Redis ou fichiers pour page cache ?
Les fichiers (Varnish, fastcgi_cache nginx) excellent pour le débit brut. Redis convient aux invalidations fines par tag. L'architecture la plus courante combine CDN en périphérie et cache origine.
Le cache dynamique commence par lister ce qui doit rester faux — pas par ce qui peut aller vite.