Kurz gesagt: Mit der Speculation Rules API lädt der Browser die wahrscheinlich nächste Seite schon vor dem Klick. Der Wechsel fühlt sich dann sofort an. Wir haben das auf dieser Website eingerichtet, dabei zwei Fallen gefunden, die den Effekt zerstören, und beide gelöst. Dieser Beitrag zeigt den kompletten Aufbau inklusive Messwerten.
Was ist Speculative Loading?
Speculative Loading bedeutet, dass der Browser eine Zielseite bereits im Hintergrund holt, bevor der Nutzer klickt. Es gibt zwei Stufen: Prefetch lädt nur das HTML-Dokument, Prerender rendert die Seite komplett im Hintergrund. Klickt der Nutzer, wird die fertige Seite eingeblendet. Gesteuert wird das über ein kleines JSON-Regelwerk im Seitenkopf, die Speculation Rules API.
WordPress bringt die Grundfunktion seit Version 6.8 mit, das Plugin „Speculative Loading“ macht die Einstellungen zugänglich. Die Regeln greifen in Chromium-Browsern wie Chrome und Edge. Andere Browser ignorieren sie, ohne dass etwas kaputtgeht.
Die drei Stufen der Auslösebereitschaft
| Eagerness | Wann geladen wird | Kosten |
|---|---|---|
| conservative | Beim Drücken der Maustaste | Sehr niedrig, Gewinn klein |
| moderate | Nach rund 200 ms Hover, auf Touch beim Antippen | Moderat, guter Kompromiss |
| eager | Sofort beim Seitenaufbau | Hoch, nur für wenige Ziele sinnvoll |
Unser Aufbau: zwei Ebenen statt einer
Die Standardeinstellung prerender mit moderate ist ein guter Anfang, hat aber eine Lücke: Auf Mobilgeräten gibt es kein Hover. Dort greift die Regel erst beim Antippen, der Vorsprung schrumpft.
Deshalb arbeiten wir mit zwei Regelsätzen gleichzeitig:
- Prerender mit moderate für alle internen Links. Wer über einen Link fährt, bekommt die fertige Seite.
- Prefetch mit eager für maximal drei kontextabhängige Ziele je Seitentyp. Auf der Startseite sind das Leistungen, Referenzen und Kontakt. Auf einer Leistungsseite sind es Kontakt, Erstgespräch und Referenzen. Rechtsseiten wie Impressum laden gar nichts vor, weil von dort niemand weiterkauft.
Wichtig ist die Begrenzung: Jede Zeile in der Prefetch-Liste ist ein zusätzlicher HTML-Abruf pro Seitenaufruf. Eine feste Liste mit zehn Zielen auf jeder Seite ist Verschwendung. Eine kontextabhängige Liste mit drei Zielen trifft meistens.
Falle 1: Vorladen bringt nichts, wenn der Server langsam antwortet
Der entscheidende Befund aus unserer Messung: Vor der Optimierung lieferte das CDN für fast jede URL den Status cf-cache-status: EXPIRED. Übersetzt heißt das: Der Zwischenspeicher am Rand des Netzes war abgelaufen, jede Anfrage lief bis zum Ursprungsserver durch und löste dort ein vollständiges Rendern der Seite aus. Gemessene Antwortzeiten lagen bei zwei bis fünf Sekunden.
In dieser Situation ist Speculative Loading nicht nur wirkungslos, sondern schädlich: Der Browser löst zusätzliche Abrufe aus, die alle den Server belasten, und der Nutzer wartet trotzdem.
Ursache war eine Kleinigkeit: Der Server schickte für HTML gar keinen Cache-Control-Header. Die Haltbarkeit am Netzrand kam allein aus einer CDN-Regel und betrug vier Stunden. Bei einer Website mit überschaubarem Besucheraufkommen bedeutet das: Fast jeder Besucher trifft auf eine kalte Seite.
Lösung: WordPress sendet jetzt selbst einen Cache-Control-Header mit getrennter Haltbarkeit für Browser und CDN. Ergebnis nach dem Aufwärmen aller Seiten: durchgängig HIT statt EXPIRED, Serverzeit im Bereich von Zehntelsekunden statt Sekunden.
Falle 2: Der Nonce im Formular
Als die CDN-Haltbarkeit von vier Stunden auf sieben Tage stieg, tauchte ein zweites Problem auf, das man leicht übersieht. Formular-Systeme legen ein Sicherheitstoken, den sogenannten Nonce, direkt in den HTML-Quelltext. Für nicht angemeldete Besucher ist dieses Token 24 Stunden gültig.
Eine Seite, die sieben Tage lang unverändert aus dem Cache ausgeliefert wird, trägt nach Tag zwei ein abgelaufenes Token. Das Formular sieht normal aus, das Absenden schlägt aber fehl. Anfragen gehen verloren, ohne dass jemand einen Fehler bemerkt.
Lösung: gestaffelte Haltbarkeit. Seiten mit Formular werden zwölf Stunden zwischengespeichert, alle übrigen Inhaltsseiten sieben Tage. Zwölf Stunden CDN plus maximal vier Stunden Browser ergeben sechzehn Stunden und bleiben damit sicher innerhalb der Gültigkeit.
Was Sie ausschließen sollten
Nicht jede URL darf vorgerendert werden. In unsere Ausschlussliste gehören:
- Adressen mit Parametern, weil sie ohnehin nicht zwischengespeichert werden
- Login, Admin und alles unterhalb von
/wp-json/ - Feeds, Sitemaps, PDF- und ZIP-Dateien
- Links mit
rel="nofollow" - Alles, was beim Aufruf etwas auslöst, etwa Abmeldelinks oder Warenkorb-Aktionen
Als Notbremse für einzelne Links genügt die CSS-Klasse no-prerender am Link oder am umgebenden Element.
Und die Statistik?
Eine berechtigte Sorge: Zählt eine vorgerenderte Seite als Aufruf, auch wenn niemand klickt? Moderne Analyse-Werkzeuge berücksichtigen den Prerender-Zustand und senden erst, wenn die Seite tatsächlich aktiviert wird. Bei selbst gebauten Zählern oder älteren Skripten sollten Sie prüfen, ob sie document.prerendering auswerten. Sonst zählen Sie Aufrufe, die nie stattgefunden haben.
Die Reihenfolge, die wir empfehlen
- Zuerst messen, ob Ihre Seiten überhaupt schnell ausgeliefert werden. Solange der Server Sekunden braucht, lohnt keine Spekulation.
- Caching und Haltbarkeit klären, inklusive Nonce-Frage bei Formularseiten.
- Prerender mit moderate aktivieren und die Ausschlussliste pflegen.
- Erst danach eine kleine, kontextabhängige Prefetch-Liste ergänzen.
- Nach jedem größeren Cache-Leeren die wichtigsten Seiten wieder aufwärmen.
Häufige Fragen
Kostet Speculative Loading zusätzliche Serverlast?
Ja, aber überschaubar, sofern die Seiten aus dem Cache kommen. Kritisch wird es nur bei ungecachten Seiten, dann sollte man die Funktion zurückstellen.
Verbraucht das Datenvolumen der Besucher?
Ein Prefetch holt nur das HTML, meist wenige Dutzend Kilobyte. Chrome deaktiviert die Vorabrufe zudem automatisch bei aktiviertem Datensparmodus, schwachem Gerät oder langsamer Verbindung.
Funktioniert das auch mit Page-Buildern?
Ja. Speculative Loading arbeitet auf Dokumentebene und ist unabhängig davon, womit die Seite gebaut wurde. Wichtig sind Caching und die Formular-Frage.
Wie prüfe ich, ob es funktioniert?
In den Chrome-Entwicklerwerkzeugen unter Application, Bereich Speculative loads, sehen Sie jede ausgelöste Regel und den Status jeder Zielseite.
Die Einrichtung Schritt für Schritt
1. Grundfunktion aktivieren
In WordPress finden Sie die Einstellung unter Einstellungen, Lesen. Drei Optionen sind zu setzen: der Modus (Prefetch oder Prerender), die Auslösebereitschaft (conservative, moderate, eager) und die Frage, für wen die Regeln gelten sollen. Für die meisten Websites ist Prerender mit moderate für ausgeloggte Besucher der richtige Startpunkt.
2. Ausschlüsse ergänzen
WordPress schließt Admin-Bereiche und Dateipfade bereits selbst aus. Ergänzen Sie alles, was in Ihrem Projekt beim bloßen Aufruf etwas verändert oder ohnehin nicht gecacht wird. Die Liste pflegen Sie über einen Filter, nicht durch Bearbeiten der Plugin-Dateien, sonst ist sie beim nächsten Update weg.
3. Kontextabhängige Prefetch-Liste
Ergänzen Sie im Seitenkopf einen zweiten Regelsatz mit maximal drei Zielen, abhängig vom Seitentyp. Wichtig: die aktuelle Seite aus der Liste herausfiltern und auf Seiten mit Parametern gar nichts ausgeben.
4. Aufwärmen nach dem Leeren des Caches
Nach jedem vollständigen Cache-Leeren sind alle Seiten kalt. Rufen Sie die wichtigsten URLs einmal von außen ab, damit der erste echte Besucher nicht die Rechenzeit bezahlt. Ein einfaches Skript über die Sitemap genügt, sequenziell abgearbeitet, damit der Server nicht in die Knie geht.
Wie Sie das Ergebnis überprüfen
- Regeln im Quelltext: Suchen Sie im ausgelieferten HTML nach dem Skriptblock mit dem Typ speculationrules. Prüfen Sie ihn ausgeloggt, denn viele Konfigurationen liefern die Regeln für angemeldete Nutzer bewusst nicht aus.
- Entwicklerwerkzeuge: Im Chrome-Bereich Application, Unterpunkt Speculative loads, sehen Sie jede Regel und den Status jeder Zielseite, inklusive Begründung, falls eine Spekulation verworfen wurde.
- Antwortkopf prüfen: Sehen Sie sich für Ihre wichtigsten Seiten den Cache-Status Ihres CDN an. Steht dort dauerhaft ein Treffer, ist die Grundlage in Ordnung.
- Gegenprobe im Alltag: Öffnen Sie die Website auf einem durchschnittlichen Gerät, fahren Sie über einen Menüpunkt, warten Sie eine Sekunde und klicken Sie. Der Unterschied ist mit bloßem Auge sichtbar.
Besonderheiten bei Shops und Mitgliederbereichen
Sobald Warenkorb, Login oder personalisierte Inhalte im Spiel sind, gelten zusätzliche Regeln:
- Seiten mit persönlichen Daten (Konto, Kasse, Warenkorb) gehören vollständig aus der Spekulation heraus.
- Links, die eine Aktion auslösen, etwa „In den Warenkorb“ als GET-Link, dürfen nie vorgerendert werden. Solche Links markieren Sie mit einer Ausschlussklasse.
- Für angemeldete Nutzer ist es meist sinnvoll, die Regeln ganz abzuschalten, weil deren Seiten ohnehin nicht aus dem Cache kommen.
- Prüfen Sie Zähler und Verfügbarkeitsanzeigen: Was beim Rendern gelesen wird, kann beim Aktivieren veraltet sein.
Grenzen und Nebenwirkungen
Ehrlich betrachtet hat die Technik drei Grenzen. Erstens greift sie nur in Chromium-basierten Browsern, ein Teil Ihrer Besucher hat also nichts davon. Zweitens entscheidet der Browser selbst, ob er eine Spekulation ausführt: Bei knappem Speicher, Sparmodus oder schwacher Verbindung passiert nichts. Drittens verschiebt sie nur die Wartezeit, sie beseitigt sie nicht. Eine Seite, die drei Sekunden zum Rendern braucht, wird durch Vorladen nicht schneller, sie wartet nur woanders.
Deshalb bleibt die Reihenfolge entscheidend: erst Serverantwort und Caching, dann Spekulation. Wer es umgekehrt macht, erzeugt zusätzliche Last ohne spürbaren Gewinn.
Was der Effekt in der Praxis bedeutet
Bei einer Website, deren Seiten aus dem Cache in Zehntelsekunden ausgeliefert werden, verschwindet die wahrgenommene Wartezeit beim Klick fast vollständig. Für Besucher fühlt sich das an wie eine Anwendung statt wie eine Website. Für die Kennzahlen bedeutet es typischerweise: mehr angesehene Seiten je Besuch und weniger Abbrüche auf dem Weg zur Kontaktseite. Wie stark der Effekt ausfällt, hängt von Ihrem Ausgangswert ab: Je langsamer die Seiten vorher waren, desto größer der Sprung.
Nächster Schritt
Wenn Ihre Website sich beim Klicken zäh anfühlt, ist Speculative Loading selten die erste Antwort, aber oft die letzte Feinheit. Der Weg dorthin führt über Ladezeit und Caching: PageSpeed-Optimierung. Laufenden Betrieb inklusive Cache- und Update-Pflege übernehmen wir in der Website-Wartung.