Was ist Speculative Loading – und warum ist das so schnell?

Spekulatius für Webseiten? Fast! Speculative Loading heißt der neue Zucker im WordPress-Teig. Seit Version 6.8 macht dein Blog nämlich schon einen kleinen Schritt nach vorn, bevor jemand überhaupt klickt. Ergebnis: Seitenwechsel so schnell, dass selbst WP Rocket kurz die Stoppuhr fallen lässt. Keine Plugin‑Magie, nur Core‑Liebe – und genau das schauen wir uns heute an.

Kurz gesagt: Der Browser lädt Links vor, bevor der Nutzer wirklich navigiert. Möglich macht es die Speculation Rules API: Regeln definieren, welche Links prefetched (Ressourcen abrufen) oder prerendered (Zielseite „unsichtbar“ komplett vorladen) werden – je nach Nutzersignal (Hover, Pointer‑Down usw.). In 6.8 steckt das standardmäßig im Core. Unterstützte Browser profitieren sofort, andere ignorieren es einfach (progressive enhancement). Und ja: Das fühlt sich an, als würde der Barista den Kaffee einschenken, sobald du nur aufs Schild schaust.

Die Entscheidung für das Feature ist datengetrieben: In großen Datensätzen zeigte sich eine merkliche Verbesserung der LCP‑Passrate (Largest Contentful Paint) – für ein einzelnes Performance-Feature beachtlich. Heißt für uns: schnellerer erster Eindruck und angenehm flüssige Seitenwechsel.

Was macht WordPress 6.8 automatisch – und was nicht?

Die Core‑Implementierung in 6.8 verhält sich bewusst konservativ:

• Aktiv auf der Frontend‑Seite für alle Nutzer ohne Login und mit hübschen Permalinks.
• Nicht aktiv, wenn der User eingeloggt ist (z. B. im Editor) oder die Site keine Pretty Permalinks nutzt.
• Standard‑Modus: prefetch mit conservative eagerness (Vorladen im Wimpernschlag vor der Navigation).

Browser‑Support: Profitieren tun vor allem Chromium‑Browser (Chrome, Edge, Opera). Safari/Firefox? Kein Drama – sie ignorieren die Regeln einfach. Progressive enhancement at its best. Release‑Kontext: WordPress 6.8 („Cecil“) erschien im April 2025.

So prüfst du, ob es bei dir greift

• DevTools → Network öffnen, einen Link anhovern oder antippen – tauchen Requests als prefetch/prerender auf?
• Checke, ob Pretty Permalinks aktiv sind (Einstellungen → Permalinks). Ohne die bleibt’s aus.
• In Chrome gibt’s einen eigenen DevTools‑Bereich für Speculation Rules – inkl. Regeln, Status und Eagerness (praktisch fürs Debugging).

Feintuning: Von „konservativ“ zu „wow“ – aber mit Köpfchen

WordPress liefert Filter & Actions, mit denen du das Verhalten griffig anpassen kannst. Hier die sichersten Stellschrauben – in kleinen Schritten testen:

1) Eagerness anheben (etwas mehr Punch)

add_filter( 'wp_speculation_rules_configuration', function( $config ) {
    if ( is_array( $config ) ) {
        $config['eagerness'] = 'moderate'; // statt 'conservative'
    }
    return $config;
} );

Damit zündest du das Vorladen schon beim Hover früher an – spürbar schneller, aber auch etwas „hungriger“.

2) Prerender aktivieren (Maximal‑Boost)

<add_filter( 'wp_speculation_rules_configuration', function( $config ) {
    if ( is_array( $config ) ) {
        $config['mode']      = 'prerender';
        $config['eagerness'] = 'moderate';
    }
    return $config;
} );

Achtung: Prerender lädt die Zielseite inkl. JavaScript. Prüfe dein Analytics‑Setup und ggf. Client‑Side‑Effekte (A/B‑Skripte etc.), damit nichts „zu früh“ feuert.

3) Bestimmte URLs ausschließen (Shop & „Action‑URLs“)

add_filter( 'wp_speculation_rules_href_exclude_paths', function( $paths ) {
    $paths[] = '/warenkorb/*';
    $paths[] = '/kasse/*';
    $paths[] = '/mein-konto/*';
    return $paths;
} );

Hintergrund: Manche Plugins führen bei GET-Aufrufen Zustandsänderungen aus (Add‑to‑Cart u. ä.). Solche Action‑URLs immer ausschließen – insbesondere, wenn du prerender nutzt. Query‑Parameter sind standardmäßig ohnehin ausgeschlossen.

Nur prerender ausschließen (aber prefetch erlauben)

add_filter( 'wp_speculation_rules_href_exclude_paths', function( $paths, $mode ) {
    if ( 'prerender' === $mode ) {
        $paths[] = '/personalbereich/*';
    }
    return $paths;
}, 10, 2 );

4) Granular per UI (ohne Code)

WordPress versteht die Klassen no-prefetch (opt‑out komplett) und no-prerender (nur Prerender blockieren). Einfach im Block → „Erweitert“ → Zusätzliche CSS‑Klassen setzen.

5) Eigene Regeln ergänzen (fortgeschritten)

add_action( 'wp_load_speculation_rules', function( WP_Speculation_Rules $rules ) {
    $rules->add_rule( 'prerender', 'my-moderate-prerender-url-rule', [
        'source'    => 'list',
        'urls'      => [ '/leistungen/', '/blog/', '/kontakt/' ],
        'eagerness' => 'moderate',
    ] );
} );

Messbar schneller – worauf du bei den Core Web Vitals achtest

• LCP: profitiert besonders, wenn der Ziel‑Hero (Bild/Text) früh kommt – Navigationslatenz ↓.
• INP: gefühlt smoother, weil „die nächste Seite schon da ist“.
• TTFB: echte Userdaten (RUM) sehen den Vorteil, synthetische Lab‑Tests weniger.

Die Verbesserungen sind robust, aber keine Magie. Messen, nicht raten! Z. B. via CrUX/GA4 und mit sauberen Vorher/Nachher‑Vergleichen.

Sicherheit in 6.8: bcrypt – und was sich sonst noch ändert

• Passwörter: Standardmäßig bcrypt statt phpass. Bestehende Passwörter bleiben gültig und werden beim nächsten Login neu gehasht.
• Weitere Schlüssel/Token: u. a. Application Passwords, Reset‑Keys und Recovery‑Mode‑Keys setzen auf moderne, schnelle Hash‑Funktionen.

Für Agenturen & Admins heißt das: bessere Standards out‑of‑the‑box, weniger Bedarf an Zusatz‑Härtung nur für die Hash‑Ebene – und eine schöne Kommunikationschance in Angeboten („Wir aktualisieren und härten Ihre Logins nach Stand der Technik“).

Kompatibilität im Agentur‑Stack (Avada/Enfold, WP Rocket, Plesk)

• Themes (Avada/Enfold): Achte bei Mega‑Menüs & dynamischen Navigations‑Bereichen auf Hover‑Signale. Starte mit moderate; prerender selektiv.
• Caching (WP Rocket): Nicht doppelt „zaubern“. Rocket‑Prefetching und Core‑Speculative‑Loading können koexistieren – aber Konfigurationen können einfach gehalten und die Wirkung jeder Einstellung getrennt gemessen werden.
• Hosting (Plesk, Ubuntu 22.04): Keine Spezial‑Serverflags nötig. Der Browser entscheidet, was er vorlädt.
• Logged‑in Workflows: Im Editor siehst du keinen Effekt – Speculative Loading ist für eingeloggte Nutzer aus. Tests immer „wie Besucher“.

Mini‑Update‑Runde: 6.8.1 & 6.8.2

6.8.1 (Ende April 2025) – reines Wartungsrelease mit mehreren Fixes in Core & Block‑Editor (u. a. Multisite, REST API). Keine neuen Features, aber eine stabile Basis, wenn du direkt von 6.7 kommst.

6.8.2 (Mitte Juli 2025) – weiteres Maintenance‑Release mit behobenen Core‑ und Editor‑Tickets. Parallel hat das Security‑Team die Unterstützung sehr alter WP‑Versionen eingeschränkt – kurz: Wer noch bei 4.x herumgurkt, sollte jetzt wirklich upgraden.

Checkliste zu Speculative Loading

Vor dem Live‑Gang

• Staging testen → Core Web Vitals & reale Navigationszeiten messen (Startwert notieren).
• Falls Shop/Member‑Bereich: Ausschlussliste pflegen (/warenkorb/, /kasse/, /mein‑konto/, Add‑to‑Cart‑GET‑URLs).
• Analytics auf Prerender‑Kompatibilität prüfen – ggf. Erkennung/Filter setzen.
• Schrittweise vorgehen: conservative → moderate → (selektiv) prerender.

Rollback (falls unerwartete Nebeneffekte)

// Speculative Loading für die aktuelle Anfrage komplett abschalten:
add_filter( 'wp_speculation_rules_configuration', function( $config ) {
    return null;
} );

FAQ – die 5 häufigsten Fragen

1. Bringt das etwas, wenn viele Nutzer Safari/Firefox haben? Ja – zumindest kein Risiko: Nicht unterstützende Browser ignorieren die Regeln. Gewinn gibt’s vor allem bei Chromium‑Nutzern (derzeit Mehrheit).
2. Zerschießt prerender mein Tracking? Moderne Tools berücksichtigen das. Prüfe die Doku deines Anbieters und nutze die gängigen Prerender‑Erkennungen (z. B. via visibilityState und entsprechende Events), falls nötig.
3. Muss ich am Server (Plesk) etwas einstellen? Nein. Das Feature passiert im Browser. Server bleibt entspannt. Wichtig ist nur, keine „Action‑GET‑URLs“ offen herumliegen zu lassen.
4. Kann ich das gezielt für einzelne Bereiche abschalten? Ja – per CSS‑Klassen no-prefetch / no-prerender oder per Exclude‑Filter. So behältst du die Kontrolle über kritische Bereiche.
5. Was passiert mit bestehenden Passwörtern nach dem bcrypt‑Upgrade? Die funktionieren weiter und werden beim nächsten Login automatisch neu mit bcrypt gehasht.

Sonstige Bedeutungen 

Technik/IT (Performance-Optimierung)

• Das Laden von Ressourcen oder Seiteninhalten im Voraus, bevor der Nutzer sie tatsächlich anfordert.
• Beispiele: Browser lädt verlinkte Seiten im Hintergrund (prefetch/prerender), CPU führt mögliche Instruktionspfade schon aus.

Computerarchitektur (Speculative Execution)

• Prozessor führt Befehle „auf Verdacht“ aus, noch bevor klar ist, ob sie benötigt werden.
• Bekannt z. B. im Zusammenhang mit Spectre/Meltdown-Sicherheitslücken.

Allgemeinsprachlich

• „Speculative“ = auf Vermutungen beruhend, unsicher, risikobehaftet.
• „Loading“ = Laden, Beladen, Befüllen.
  → Könnte auch „beladen ohne Garantie, dass es gebraucht wird“ bedeuten.

Militär/Logistik

• Vorbereitung/Aufladen von Ausrüstung oder Munition im Voraus, ohne sicheren Einsatzbefehl.

Fazit zu Speculative Loading

Übersetzt heißt Speculative Loading: Spekulatives Laden oder vorausschauendes Laden (in der IT oft auch vorgeladen oder präventives Laden genannt). WordPress 6.8 liefert dir schnellere Seitenwechsel ohne Plugin – und mit 6.8.1/6.8.2 eine stabile, gepflegte Basis. Mein Rat: konservativ starten, sauber messen, dann punktuell die Eagerness erhöhen oder prerender für deine „Top‑Wege“ aktivieren. Und weil Sicherheit kein „Nice‑to‑have“ ist: Das bcrypt‑Upgrade gibt dir Rückenwind in Kundengesprächen – „Logins nach Stand der Technik“ lässt sich gut verkaufen.

Wenn du willst, setze ich dir die Snippets als Mini‑Plugin auf, prüfe die Excludes (Shop/Member) und wir testen gemeinsam den Effekt auf deinem Stack (Avada/Enfold, WP Rocket, Plesk). Und keine Sorge: Spekulatius bleibt weiter in der Keksdose – wir spekulieren ab jetzt nur noch mit Ladezeiten. 😄