Eine ganze gerenderte Seite zu cachen macht aus einer 400-ms-Anfrage eine von 5 ms. Es heißt aber auch, dass alle dieselbe Seite bekommen - genau richtig für einen Artikel und genau falsch für einen Warenkorb, ein Dashboard oder alles, worin der Name des Besuchers steht.

Die Regel

Cachen Sie eine Antwort nur, wenn sie für einen Fremden identisch wäre. Hängt irgendein Teil davon ab, wer fragt, dann cachen Sie sie entweder nicht, oder holen Sie diesen Teil aus dem gecachten HTML heraus und laden ihn getrennt nach.

Was niemals gecacht werden darf

  • Alles hinter einer Anmeldung, auch die Seite, die im Kopf einen Anmeldezustand zeigt.
  • Warenkorb-, Kassen-, Konto- und Bestellseiten.
  • Alles mit einem CSRF-Token darin - ein geteiltes Token ist kein Token. Siehe CSRF und Formulare.
  • Suchergebnisse, in denen persönliche Historie steckt.

Dem Cache sagen, was variiert

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

Beweisen, was Sie bekommen haben

add_header X-Cache-Status $upstream_cache_status;

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

HIT, MISS und BYPASS in diesem Header beantworten in einer Sekunde, was ein Nachmittag Konfigurationslektüre nicht beantwortet. Sagt eine angemeldete Seite HIT, halten Sie an und reparieren Sie das, bevor Sie irgendetwas anderes tun.

Die andere Hälfte: das Verwerfen

Ein Cache, der nie geleert wird, zeigt den Preis von gestern. Leeren Sie beim Veröffentlichen, und wissen Sie, wie man alles von Hand leert, wenn ein Deployment die Templates ändert.

Testen Sie angemeldet, in einem normalen Fenster, nicht in einem privaten. Fast jedes Cache-Leck dieser Art hat ein Kunde gefunden und nicht der Entwickler, weil der Entwickler immer nur abgemeldet getestet hat.
Auf EGPHP-Hosting ist der Seiten-Cache so eingerichtet, dass Anmelde- und Kassenpfade bereits ausgenommen sind. Dieser Artikel gilt einem VPS, auf dem Sie die Regeln schreiben.