Fehlerbehebung

Speculative Navigation funktioniert nicht

Mögliche Ursache

Pretty Permalinks sind deaktiviert, die Anfrage wird von WordPress Core für Speculation Rules ausgeschlossen oder der Legacy-Fallback läuft in einem nicht unterstützten Kontext wie Admin, Login-Sitzung, Feed oder Preview.

Lösung

1. Unter FG Performance → Diagnose Pretty Permalinks prüfen.
2. Auf WordPress 6.8+ kontrollieren, ob WordPress selbst Speculation Rules ausgibt.
3. Bei eigenen sensiblen Pfaden die FG-Ausschlüsse prüfen.
4. Auf WordPress vor 6.8 sicherstellen, dass der Link intern ist und keinen Query-String oder Hash enthält.

Prüfung

Auf WordPress 6.8+ die ausgegebenen Speculation Rules in den Browser-DevTools prüfen. Bei Prerender zusätzlich activationStart nach der Navigation kontrollieren.

Der Logo-/Startseiten-Link wird nicht vorbereitet

Mögliche Ursache

Die Website läuft in einem Unterverzeichnis und verlinkt die Startseite ohne abschließenden Slash.

Lösung

FG Performance 1.1.1 oder neuer verwenden. Diese Version ergänzt für WordPress 6.8+ eine eigene Regel für den exakten Startseitenpfad.

Prüfung

Über den verlinkten Logo-/Home-Link navigieren und die Speculation-Rules beziehungsweise bei Prerender activationStart kontrollieren.

Service Worker kann nicht aktiviert werden

Mögliche Ursache

Die Website läuft über normales HTTP und nicht auf einer lokalen Entwicklungs-Origin.

Lösung

HTTPS verwenden oder lokal über localhost, *.localhost, 127.x.x.x beziehungsweise ::1 testen.

Prüfung

Der Schalter im Admin darf nicht mehr deaktiviert sein. Im Diagnose-Tab muss Service Worker verfügbar: Ja erscheinen.

Ein fremder Service Worker bleibt aktiv

Mögliche Ursache

Für denselben Scope existiert bereits eine Registration, deren Worker nicht über fg-performance-sw.js geladen wurde.

Lösung

FG Performance ersetzt einen fremden Worker absichtlich nicht automatisch. Die bestehende Worker-Strategie muss projektspezifisch geklärt werden.

Prüfung

In den Browser-DevTools unter Application/Service Workers die aktive Script-URL kontrollieren.

FG-Service-Worker-Cache bleibt nach Plugin-Deaktivierung bestehen

Mögliche Ursache

Das Plugin wurde deaktiviert, bevor das Service-Worker-Modul im aktiven Plugin ausgeschaltet und das Frontend erneut geladen wurde.

Lösung

Falls das Plugin noch aktivierbar ist:

1. Plugin aktivieren.
2. Service Worker in FG Performance deaktivieren.
3. Einstellungen speichern.
4. Frontend einmal laden.
5. Danach Plugin deaktivieren.

Prüfung

In den Browser-DevTools dürfen keine FG-Registration und keine Cache-Storage-Einträge mit fg-performance-static- mehr vorhanden sein.

Browser Cache oder Komprimierung wird nicht angewendet

Mögliche Ursache

Die .htaccess ist nicht schreibbar, der FG-Marker ist nur teilweise vorhanden oder der Server wird nicht als Apache/LiteSpeed erkannt.

Lösung

1. FG Performance → Diagnose öffnen.
2. Serverfamilie, .htaccess-Pfad und Schreibbarkeit prüfen.
3. Markerstatus kontrollieren.
4. Einen partiellen Marker manuell korrigieren, bevor FG Performance erneut schreibt.
5. Unter Nginx das erzeugte Snippet manuell in die Serverkonfiguration übernehmen.

Prüfung

Markerstatus muss bei Apache/LiteSpeed installed sein. Zusätzlich Response-Header für eine statische Datei beziehungsweise Content-Encoding prüfen.

Nginx ist erkannt, aber es gibt keine automatische Änderung

Mögliche Ursache

Das ist das vorgesehene Verhalten. Nginx verwendet keine .htaccess-Datei.

Lösung

Die Snippets aus dem Diagnose-Tab außerhalb von WordPress prüfen und in die Nginx-Konfiguration übernehmen.

Prüfung

Nach Nginx-Konfigurationstest und Reload die Response-Header erneut kontrollieren.

Ein Conditional Asset Bundle lädt nicht

Mögliche Ursache

Der registrierte Selektor trifft kein Element, ist ungültig oder der Trigger wurde noch nicht ausgelöst.

Lösung

1. Selektor im Browser mit document.querySelectorAll() prüfen.
2. Bei viewport den Bereich bis in die konfigurierte rootMargin scrollen.
3. Bei interaction eine Pointer-, Fokus- oder Touch-Interaktion innerhalb des Selektors auslösen.
4. Browser-Konsole auf Ladefehler der registrierten URL prüfen.

Prüfung

Auf die Events fgperformance:assetload, fgperformance:assetloaded und fgperformance:asseterror hören.

Render Optimization zeigt keine Wirkung

Mögliche Ursache

Der Selektor wurde verworfen, trifft kein Element oder der Browser unterstützt content-visibility nicht.

Lösung

Selektor vereinfachen und sicherstellen, dass er nicht html, body, :root oder verbotene Zeichenfolgen enthält.

Prüfung

getComputedStyle(document.querySelector('.ziel')).contentVisibility

Auf unterstützenden Browsern sollte auto zurückgegeben werden.