Full-Page-Cache

FG Cache WP speichert geeignete, fertig gerenderte HTML-Antworten im Dateisystem und liefert gültige Cache-Dateien über das WordPress-Drop-in advanced-cache.php aus.

Ablauf eines Requests

1. WordPress lädt wp-content/advanced-cache.php, wenn WP_CACHE aktiv ist.
2. Das Drop-in lädt wp-content/cache/fg-cache/runtime-config.php.
3. Frühe BYPASS-Regeln werden geprüft.
4. Aus Host, Pfad und gegebenenfalls VARY-Parametern wird ein Cache-Schlüssel gebildet.
5. Existiert eine gültige Cache-Datei, wird sie als HIT direkt ausgegeben.
6. Existiert keine gültige Datei, wird der Request als MISS normal durch WordPress verarbeitet.
7. Die fertige Antwort wird nur gespeichert, wenn sie die Response-Prüfungen besteht.

Cache-Schlüssel

Der Cache-Schlüssel basiert auf:

• dem normalisierten Request-Host,
• dem URL-Pfad,
• den Werten der unter Cache-relevante Parameter (VARY) konfigurierten Query-Parameter.

Ignorierte Parameter werden entfernt. Unbekannte Parameter führen standardmäßig zu einem BYPASS. Die kanonische Zeichenfolge wird mit SHA-256 gehasht; die HTML-Datei wird anhand dieses Hashes abgelegt.

Speicherort

HTML-Cache-Dateien liegen in einer zweistufigen Struktur:

wp-content/cache/fg-cache/pages/<hash-prefix>/<sha256>.html

Daneben wird für neu erzeugte Einträge eine Metadatei abgelegt:

wp-content/cache/fg-cache/pages/<hash-prefix>/<sha256>.meta.json

Die Metadatei enthält Host, Pfad, Cache-URL und Erzeugungszeitpunkt. Sie dient insbesondere der gezielten Invalidierung und dem automatischen Warmup.

Wann wird ein Request früh umgangen?

Das Drop-in verwendet einen BYPASS unter anderem bei:

• anderen Methoden als GET
• nicht erlaubten Hosts
• HTTP-Range-Requests
• klassischen AJAX-Requests mit X-Requested-With: XMLHttpRequest
• Basic Authorization, solange diese nicht ausdrücklich freigegeben ist
• Bearer- oder anderen Authorization-Schemata
• ausgeschlossenen URL-Pfaden
• passenden BYPASS-Cookies
• passenden BYPASS-Query-Parametern
• unbekannten Query-Parametern, wenn die Standardregel BYPASS aktiv ist
• gesetztem DONOTCACHEPAGE
• einem globalen Kompatibilitäts-BYPASS, beispielsweise bei einer entsprechenden FG-Analytics-Konfiguration

Welche Antworten werden gespeichert?

Eine Antwort wird nur gespeichert, wenn insbesondere folgende Bedingungen erfüllt sind:

• der Response-Body ist nicht leer,
• der HTTP-Status ist 200,
• DONOTCACHEPAGE ist nicht aktiv,
• es handelt sich nicht um WordPress-Suche, Feed, Vorschau oder Customizer-Vorschau,
• die Antwort ist als HTML erkennbar,
• die Antwort setzt im Regelfall kein Cookie,
• die Antwort enthält keine Cache-Control-Anweisung mit no-store, private oder no-cache.

Für FG DocCheck existiert eine eng begrenzte Sonderbehandlung für eine leere PHP-Session, damit eine rein technisch gestartete leere Session nicht automatisch jede öffentliche Antwort vom Cache ausschließt. Geschützte DocCheck-Pfade und Callback-Requests werden separat als BYPASS behandelt.

Entwickler können die letzte Speicherentscheidung zusätzlich über den Filter fg_cache_should_store_response beeinflussen.

HIT, MISS und BYPASS

Bei aktivierten Diagnose-Headern gibt FG Cache WP den Status über X-FG-Cache aus.

Status	Bedeutung
HIT	Eine gültige HTML-Cache-Datei wurde direkt ausgeliefert.
MISS	Es existierte keine gültige Cache-Datei; WordPress erzeugt die Antwort regulär.
BYPASS; reason=...	Der Request wurde aufgrund einer Regel nicht aus dem Page Cache bedient.

Bei einem HIT enthält X-FG-Cache-Age das Alter der Cache-Datei in Sekunden.

Ablauf der TTL

Ist eine Cache-Datei älter als die konfigurierte TTL, wird sie beim nächsten Zugriff zusammen mit ihrer Metadatei entfernt. Der aktuelle Request wird danach wie ein MISS behandelt.

Grenzen

FG Cache WP ist kein fragmentierter oder benutzerspezifischer Cache. Inhalte, die sich abhängig von Sitzung, Cookie, Authorization oder anderen Request-Merkmalen unterscheiden, müssen durch BYPASS-Regeln geschützt oder ausdrücklich als VARY modelliert werden.

Query-Varianten werden vom normalen Warmup nicht automatisch erzeugt. VARY-Varianten entstehen durch reale Requests oder durch individuell über Filter ergänzte Warmup-URLs.