Quels sont les niveaux de cache dans une pile web typique ?

Question

Accepted Answer

Une requête passe par **plusieurs niveaux de cache**, chacun plus proche de l'utilisateur servant plus rapidement mais stockant moins. L'idée est de répondre aussi loin que possible (près du client) et ne descendre à l'origine que si aucun système en amont ne peut servir la réponse.

## Les niveaux, de l'extérieur vers l'intérieur

```text
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest)                            (closest to data)
```

- **Cache du navigateur** — stocke les ressources statiques (JS, CSS, images) et les réponses mises en cache sur l'appareil de l'utilisateur. Le TTL est contrôlé par `Cache-Control`/`ETag` ; les ressources obtiennent souvent des TTL longs (jours–année) avec des noms de fichiers hachés.
- **CDN** (CloudFront, Cloudflare) — met en cache le contenu statique et parfois dynamique aux nœuds edge près des utilisateurs. TTL de minutes (HTML) à un an (ressources immuables).
- **Reverse proxy** (Varnish, nginx) — met en cache les pages complètes ou des fragments en face de l'application. TTL de secondes à minutes pour les pages chaudes ; supporte la purge lors du changement.
- **Cache applicatif / objet** (Redis, Memcached) — met en cache les résultats calculés, les résultats de requêtes DB, les sessions, les fragments rendus. TTL de secondes à heures, plus l'invalidation explicite.
- **OPcache** — met en cache le **bytecode PHP compilé** en mémoire afin que les scripts ne soient pas réanalysés par requête. Effectivement persistant jusqu'au déploiement du code.
- **Cache de requête DB / buffer cache** — la base de données conserve les pages chaudes et (dans certains moteurs) les résultats de requêtes en mémoire, évitant les lectures disque.

## Comment raisonner à ce sujet

```text
for each layer outward → inward:
  if layer has fresh copy → return it (stop here)   // a hit; cheapest possible
  else → ask the next layer in                      // a miss; falls through
origin (app + DB) → does the real work, fills caches on the way back out
```

Chaque niveau échange **fraîcheur contre vitesse** : les niveaux extérieurs sont les plus rapides mais les plus susceptibles d'être obsolètes, donc appliquez des TTL longs + hachage de contenu sur les choses vraiment statiques et des TTL courts + invalidation sur les choses dynamiques.

## Pourquoi c'est important

La plupart de la réduction de latence et de charge dans une pile web provient de la mise en cache au bon niveau. Savoir ce que chaque niveau retient et son TTL typique vous permet de placer un cache où il aide réellement, d'éviter de servir des données obsolètes, et de raisonner sur la raison pour laquelle un changement n'a pas apparu (quel niveau sert encore une ancienne copie).