Skip to content

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.

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.

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.

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=....

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.

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:

lang
layout

Ein Request mit ?layout=grid erhält damit einen anderen Cache-Schlüssel als ?layout=list.

Standard:

utm_source
utm_medium
utm_campaign
utm_term
utm_content
gclid
fbclid
msclkid
_gl

Funktion: 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.

Standard:

preview
preview_id
preview_nonce
customize_changeset_uuid
customize_theme
customize_messenger_channel

Funktion: 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.

Standard: BYPASS

Mögliche Werte:

  • BYPASS
  • Ignorieren

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.

Standard:

/wp-admin/*
/wp-login.php
/wp-json/*
/xmlrpc.php

Funktion: 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.

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_cookie
projekt_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.

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.