FAQ

Was macht FG Performance WP?

FG Performance WP bündelt mehrere optionale Browser-, Navigations-, Asset- und Serveroptimierungen für WordPress. Dazu gehören Speculative Navigation, Resource Hints, Preloads, Asset Loading, Render Optimization, ein statischer Service-Worker-Cache sowie Browser-Cache- und Komprimierungsregeln.

Ist FG Performance WP ein Full Page Cache?

Nein. Der aktuelle Code enthält keinen Full Page Cache für WordPress-HTML-Seiten.

Das Browser-Cache-Modul setzt Header für statische Dateien. Der Service Worker cached nur statische Same-Origin-Ressourcen der Typen Style, Script, Font und Image.

Minifiziert FG Performance CSS, JavaScript oder HTML?

Nein. Der aktuelle Code enthält keine Minifizierung.

Unterstützt FG Performance Prerender?

Ja. Auf WordPress 6.8 oder neuer kann im Admin ausdrücklich prerender als Navigationsmodus gewählt werden. FG Performance setzt dabei weiterhin eagerness = moderate und verwendet die WordPress-Core-Speculation-Rules-Integration.

Funktioniert Speculative Navigation auch auf älteren WordPress-Versionen?

Ja, innerhalb der Mindestanforderung ab WordPress 6.0. Vor WordPress 6.8 verwendet FG Performance einen eigenen rel=prefetch-Fallback mit Hover-, Pointer- und Touch-Intent.

Cached der Service Worker HTML oder Consent-Zustände?

Nein. Der Worker ist auf statische Request-Destinations begrenzt und lehnt HTML- sowie JSON-Responses beim Cache-Schreiben ab. Responses mit Vary: Cookie, Vary: *, Cache-Control: private oder no-store werden ebenfalls nicht gecacht.

Kann FG Performance einen vorhandenen fremden Service Worker ersetzen?

Nicht automatisch. Wenn im gleichen Scope bereits ein Worker aktiv oder in Installation ist und dessen Script-URL nicht zu FG Performance gehört, wird die FG-Registration nicht darüber geschrieben.

Funktioniert der Service Worker ohne HTTPS?

Nur in den im Code zugelassenen lokalen Entwicklungsumgebungen wie localhost, 127.x.x.x oder ::1. Für normale Websites ist HTTPS erforderlich.

Schreibt FG Performance automatisch Nginx-Konfiguration?

Nein. Unter Nginx erzeugt der Diagnose-Tab lediglich Snippets. Diese müssen außerhalb von WordPress geprüft und manuell in die Serverkonfiguration übernommen werden.

Was passiert bei Plugin-Deaktivierung?

FG Performance versucht, die eigenen .htaccess-Marker für Browser Cache und HTTP-Komprimierung zu entfernen. Partielle Marker oder eine nicht schreibbare .htaccess werden nicht automatisch verändert. Ein browserseitig registrierter Service Worker sollte vorher über den Modulschalter deaktiviert und das Frontend einmal geladen werden, damit Registration und FG-Caches entfernt werden können.

Was wird bei der Deinstallation gelöscht?

uninstall.php versucht, die beiden FG-Servermarker unter denselben Schutzbedingungen zu entfernen und löscht die Plugin-Option fg_performance_settings.

Der aktuelle Uninstall-Code löscht keine FG-Core-Statusoptionen und räumt keinen FG-Core-Cronjob ausdrücklich auf.

Setzt FG Performance Cookies?

Im aktuellen FG-Performance-Code werden keine eigenen Cookies gesetzt. Der optionale Service Worker nutzt jedoch die Browser Cache Storage API.

Überträgt das Plugin Daten an FUNCKGROUP?

Das eingebettete FG Core 1.1.3 sendet standardmäßig einmal täglich einen Installationsstatus an einen im Code definierten FUNCKGROUP-Endpunkt. Enthalten sind technische Installationsdaten wie Domain, URLs, WordPress-/PHP-Versionen und erkannte FUNCKGROUP-Plugins. Details stehen unter Datenverarbeitung.

Ist WooCommerce speziell berücksichtigt?

Teilweise. Speculative Navigation erkennt bei vorhandenen WooCommerce-Funktionen dynamisch Warenkorb-, Checkout- und My-Account-URLs und behandelt sie als sensible Ausschlüsse. Weitere WooCommerce-spezifische Logik ist im aktuellen Code nicht vorhanden.