Mettre en cache une page entièrement rendue transforme une requête de 400 ms en une de 5 ms. Cela veut aussi dire que tout le monde reçoit la même page - parfaitement juste pour un article, et parfaitement faux pour un panier, un tableau de bord ou tout ce qui prononce le nom du visiteur.

La règle

Ne mettez en cache une réponse que si elle serait identique pour un inconnu. Si la moindre partie dépend de qui demande, soit vous ne la mettez pas en cache, soit vous sortez cette partie du HTML mis en cache et vous allez la chercher à part.

Ce qui ne doit jamais être mis en cache

  • Tout ce qui est derrière une connexion, y compris la page qui affiche un état de connexion dans l'en-tête.
  • Les pages panier, paiement, compte et commandes.
  • Tout ce qui contient un jeton CSRF - un jeton partagé n'est pas un jeton. Voyez CSRF et formulaires.
  • Les résultats de recherche contenant un historique personnel.

Dire au cache ce qui varie

# skip the cache when a session cookie is present
fastcgi_cache_bypass $cookie_session $http_authorization;
fastcgi_no_cache   $cookie_session $http_authorization;

Prouver lequel vous avez eu

add_header X-Cache-Status $upstream_cache_status;

curl -sSI https://yourdomain.com/ | grep -i x-cache

HIT, MISS et BYPASS dans cet en-tête répondent en une seconde à ce qu'un après-midi de lecture de configuration ne répondra pas. Si une page connectée dit HIT, arrêtez-vous et corrigez-la avant toute autre chose.

L'autre moitié : l'invalidation

Un cache jamais vidé affiche le prix d'hier. Purgez à la publication, et sachez tout purger à la main quand un déploiement change les gabarits.

Testez connecté, dans une fenêtre normale, pas une privée. Presque toutes les fuites de cache de ce genre ont été trouvées par un client et non par le développeur, parce que le développeur n'a jamais testé que déconnecté.
Sur l'hébergement EGPHP, le cache de pages est configuré avec les chemins de connexion et de paiement déjà exclus. Cet article vise un VPS où les règles sont les vôtres.