Konfiguration
Die Einstellungen befinden sich in der FUNCKGROUP-Administration unter FG Cache → Einstellungen. Beim Speichern werden die Werte bereinigt, der Page Cache geleert, Runtime-Konfiguration und Drop-in geprüft sowie der Browser-Cache-Fallback synchronisiert.
Page Cache aktivieren
Section titled “Page Cache aktivieren”Standard: aktiviert
Funktion: Schaltet die frühe FG-Cache-Auslieferung ein oder aus.
Wann sinnvoll: Im normalen Produktivbetrieb aktiviert. Zum gezielten Testen kann der Page Cache vorübergehend deaktiviert werden.
Technische Auswirkungen: Der Wert wird in die Runtime-Konfiguration geschrieben. Ist er deaktiviert, beendet das advanced-cache.php-Drop-in seine Ausführung ohne Cache-Auslieferung.
Cache-Laufzeit
Section titled “Cache-Laufzeit”Standard: 3600 Sekunden
Zulässiger Bereich: 60 bis 2592000 Sekunden, also maximal 30 Tage
Funktion: Bestimmt, wie lange eine HTML-Cache-Datei als gültig gilt.
Wann sinnvoll: Kürzere Werte eignen sich bei häufig veränderten Inhalten; längere Werte reduzieren erneute Renderings. Inhaltsänderungen können unabhängig von der TTL eine gezielte oder vollständige Invalidierung auslösen.
Technische Auswirkungen: Ist die Datei älter als die TTL, wird sie beim nächsten Zugriff zusammen mit ihrer Metadatei entfernt und die Seite neu erzeugt.
Diagnose-Header
Section titled “Diagnose-Header”Standard: aktiviert
Funktion: Gibt den Header X-FG-Cache aus. Bei einem HIT wird zusätzlich X-FG-Cache-Age ausgegeben.
Wann sinnvoll: Für Inbetriebnahme, Fehlersuche und technische Kontrolle.
Technische Auswirkungen: Mögliche Werte sind unter anderem HIT, MISS und BYPASS; reason=....
HTTP Basic Auth
Section titled “HTTP Basic Auth”Standard: deaktiviert
Funktion: Erlaubt Cache-Zugriffe auch dann, wenn ein HTTP-Authorization-Header mit dem Schema Basic vorhanden ist.
Wann sinnvoll: Nur wenn die durch HTTP Basic Auth erreichbaren Seiten für alle berechtigten Zugriffe denselben HTML-Inhalt liefern dürfen.
Technische Auswirkungen: Basic-Authorization-Daten sind nicht Bestandteil des Cache-Schlüssels. Bearer- und andere Authorization-Schemata bleiben immer BYPASS.
Cache-relevante Parameter (VARY)
Section titled “Cache-relevante Parameter (VARY)”Standard: leer
Funktion: Jeder eingetragene Query-Parameter wird mit seinem Wert in den Cache-Schlüssel aufgenommen.
Wann sinnvoll: Wenn eine öffentliche Seite abhängig von einem Query-Parameter unterschiedliche, aber weiterhin cachefähige HTML-Ausgaben erzeugt.
Technische Auswirkungen: Unterschiedliche Werte erzeugen getrennte Cache-Dateien. Parameternamen werden beim Speichern mit sanitize_key() normalisiert.
Beispiel:
langlayoutEin Request mit ?layout=grid erhält damit einen anderen Cache-Schlüssel als ?layout=list.
Ignorierte Parameter
Section titled “Ignorierte Parameter”Standard:
utm_sourceutm_mediumutm_campaignutm_termutm_contentgclidfbclidmsclkid_glFunktion: Entfernt diese Parameter vor der Bildung des Cache-Schlüssels.
Wann sinnvoll: Für Tracking-Parameter, die den HTML-Inhalt nicht verändern.
Technische Auswirkungen: Beispielsweise teilen /seite/ und /seite/?utm_source=newsletter denselben Cache-Schlüssel.
BYPASS-Parameter
Section titled “BYPASS-Parameter”Standard:
previewpreview_idpreview_noncecustomize_changeset_uuidcustomize_themecustomize_messenger_channelFunktion: Sobald einer dieser Parameter im Request vorkommt, wird der Page Cache umgangen.
Wann sinnvoll: Für Vorschauen, Editor-Zustände, Callbacks und andere Query-Requests mit dynamischer oder sensibler Ausgabe.
Technische Auswirkungen: Aktive Kompatibilitätsmodule können zusätzliche Parameter automatisch ergänzen. Dazu gehören beispielsweise WooCommerce-, Elementor- oder FG-DocCheck-Parameter. Details stehen unter Kompatibilität.
Unbekannte Parameter
Section titled “Unbekannte Parameter”Standard: BYPASS
Mögliche Werte:
BYPASSIgnorieren
Funktion: Legt fest, wie Query-Parameter behandelt werden, die weder als VARY noch als ignoriert oder BYPASS definiert sind.
Wann sinnvoll: BYPASS ist die konservative Einstellung. Ignorieren ist nur sinnvoll, wenn unbekannte Parameter die HTML-Ausgabe sicher nicht verändern.
Technische Auswirkungen: Bei BYPASS wird für den Request keine Cache-Datei verwendet. Bei Ignorieren fließen unbekannte Parameter nicht in den Cache-Schlüssel ein.
Ausgeschlossene Pfade
Section titled “Ausgeschlossene Pfade”Standard:
/wp-admin/*/wp-login.php/wp-json/*/xmlrpc.phpFunktion: Schließt exakte Pfade oder Pfadpräfixe vom Page Cache aus.
Syntax: Ein Stern * ist nur am Ende vorgesehen und bedeutet, dass der Pfad einschließlich seiner Unterpfade ausgeschlossen wird.
Beispiele:
/konto/*/interner-callback/konto/* trifft sowohl /konto als auch /konto/bestellungen/. /interner-callback trifft nur diesen normalisierten Pfad.
Technische Auswirkungen: Aktive Kompatibilitätsmodule können weitere Pfade automatisch ergänzen.
Zusätzliche Cookies
Section titled “Zusätzliche Cookies”Standard: leer
Funktion: Definiert zusätzliche Cookie-Namen, bei deren Vorhandensein ein Request den Page Cache umgeht.
Syntax: Exakter Cookie-Name oder Präfixregel mit Stern am Ende.
Beispiele:
mein_login_cookieprojekt_session_*Technische Auswirkungen: Unabhängig von dieser Einstellung ergänzt FG Cache automatisch WordPress-bezogene Regeln wie wordpress_logged_in_*, wordpress_sec_*, wp-postpass_* und comment_author_*. Weitere Regeln können durch Kompatibilitätslogik hinzukommen.
Cache nach Invalidierung automatisch aufwärmen
Section titled “Cache nach Invalidierung automatisch aufwärmen”Standard: deaktiviert
Funktion: Startet nach einer Cache-Invalidierung einen automatischen Warmup.
Wann sinnvoll: Wenn häufig aufgerufene Seiten nach Änderungen möglichst schnell wieder als Cache-HIT verfügbar sein sollen.
Technische Auswirkungen: Bei gezielter Invalidierung werden nur tatsächlich entfernte Cache-URLs erneut aufgerufen. Nach einem vollständigen Purge wird die normale Warmup-Liste verwendet. Die Verarbeitung erfolgt sequentiell in kleinen HTTP-Batches über einen token-geschützten Loopback-AJAX-Worker.
Mehr dazu unter Cache-Warmup.
Browser-Cache-Fallback
Section titled “Browser-Cache-Fallback”Standard: aktiviert
Funktion: Schreibt auf Apache oder LiteSpeed einen eigenen .htaccess-Block für statische Assets, wenn FG Performance WP nicht zuständig ist.
Wann sinnvoll: Wenn statische Assets ohne FG Performance mit einem Browser-Cache-Header ausgeliefert werden sollen.
Technische Auswirkungen: Die Regel verwendet für unterstützte statische Dateiendungen eine Laufzeit von 2.592.000 Sekunden, also 30 Tagen. Der Dateiname fg-performance-sw.js wird ausdrücklich von dieser Langzeitregel ausgenommen und mit No-Cache-Headern versehen.
Weitere Details stehen unter Browser-Cache-Fallback.