Kompatibilität

Diese Seite enthält nur Kompatibilitätsinformationen, die sich aus dem aktuellen Code direkt ableiten lassen.

WordPress und PHP

Bereich	Status
WordPress ab 6.0	Mindestanforderung im Plugin-Header
PHP ab 8.1	Mindestanforderung im Plugin-Header und Composer
WordPress 6.3+	native Script-Strategien verfügbar
WordPress 6.8+	native Speculation Rules werden verwendet
WordPress 6.0–6.7	Legacy-Prefetch-Fallback für Navigation
`wp_preload_resources()` verfügbar	Voraussetzung für das Modul Critical Assets

FG Core

FG Performance enthält FG Core 1.1.3 eingebettet und benötigt dafür keine separat installierte Core-Abhängigkeit. Wenn mehrere FUNCKGROUP-Plugins eigene FG-Core-Kopien laden, wählt der Bootstrap den Kandidaten mit der höchsten Version und danach der höchsten API-Version aus.

Die tatsächlich aktive Core-Version und der bereitstellende Plugin-Provider werden im Diagnose-Tab angezeigt.

Pretty Permalinks

Der Legacy-Prefetch-Fallback läuft nicht ohne Pretty Permalinks. Auf WordPress 6.8+ respektiert FG Performance eine von WordPress Core deaktivierte Speculation-Rules-Konfiguration.

Der Diagnose-Tab weist auf deaktivierte Pretty Permalinks hin.

Webserver

FG Performance unterscheidet folgende Serverfamilien anhand von SERVER_SOFTWARE:

Apache
LiteSpeed
OpenLiteSpeed
Nginx
unbekannt

Automatische .htaccess-Regeln sind standardmäßig nur für Apache und LiteSpeed vorgesehen.

Nginx erhält ausschließlich generierte Konfigurations-Snippets. OpenLiteSpeed und unbekannte Server erhalten standardmäßig keine automatische Apache-Konfiguration.

Service Worker und Browser

Service Worker benötigen im Plugin entweder HTTPS oder eine lokale Entwicklungs-Origin.

Der Code prüft Browserunterstützung vor der Registrierung mit:

"serviceWorker" in navigator

Der Conditional Asset Loader verwendet IntersectionObserver, wenn verfügbar. Fehlt die API, werden registrierte Viewport-Bundles sofort geladen.

Render Optimization verwendet @supports (content-visibility:auto), sodass nicht unterstützende Browser die erzeugten Regeln ignorieren.

WooCommerce

FG Performance enthält eine konkrete WooCommerce-Berücksichtigung für Speculative Navigation: Wenn WooCommerce-Funktionen vorhanden sind, werden Warenkorb-, Checkout- und My-Account-URLs als sensible Ziele ergänzt.

Der aktuelle Code enthält darüber hinaus keine WooCommerce-spezifische Integration. Ein allgemeiner WooCommerce-Teststatus ist aus dem Projekt nicht belegbar.

FG Static Export

Eine lose Kopplung ist im Service-Worker-Modul vorhanden. Der Filter fg_static_export_additional_files kann genutzt werden, um den Service Worker als zusätzliche Exportdatei bereitzustellen.

FG Static Export wird nicht als Pflichtabhängigkeit geprüft.

Themes und Builder

Der aktuelle Code enthält keine spezifischen Integrationen für einzelne Themes oder Page Builder. Aussagen zu Roots Sage, Block Themes, Bricks, Elementor oder anderen Buildern sind aus dem Code allein nicht als getestete Kompatibilität belegbar.

Multisite

FG Performance verwendet normale WordPress-Optionen und keine Network-Settings-API. Der eingebettete FG-Core-Statusreport erfasst einen Multisite-Status, eine dedizierte Multisite-Unterstützungslogik für die Performance-Module ist jedoch nicht vorhanden.

Deshalb wird Multisite hier nicht als ausdrücklich getestet oder offiziell unterstützt eingestuft.

REST, AJAX und WP-CLI

FG Performance registriert im aktuellen Projekt:

keine eigenen REST-API-Routen,
keine wp_ajax_*-Handler,
keine WP-CLI-Kommandos.

Das Speichern der Admin-Einstellungen erfolgt über admin-post.php und die Action admin_post_fg_performance_save_settings.