Sofort ladende Seiten mit Speculation Rules

Lerne, wie du die Core Web Vitals verbesserst, indem du Seiten mit der Speculation Rules API sofort laden lässt.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-26

Verbessere die Core Web Vitals sofort mit der Speculation Rules API

Hast du dich jemals gefragt, warum manche Seiten scheinbar sofort laden? Wahrscheinlich nutzt diese Seite Speculation Rules!

Die Speculation Rules API beschleunigt zukünftige Seitenaufrufe in Multi-Page-Applications (MPAs) durch Prefetching oder Prerendering. Entwickler konfigurieren Speculation Rules, um dem Browser das Prefetching oder Prerendering von Dokumenten vorzuschlagen. Das führt zu schnelleren oder sofortigen Seitenaufrufen. Speculation Rules ersetzen ältere Techniken wie <link rel="prefetch"> für das Prefetching von Ressourcen oder das veraltete, nur in Chrome verfügbare <link rel="prerender">.

Speculation Rules arbeiten auf Dokumentebene. Das macht sie ideal für MPAs mit vollständigen Seitennavigationen. Single-Page-Applications (SPAs) nutzen primär API-Aufrufe oder partielle Inhaltsaktualisierungen. Sie profitieren bei internen Routenänderungen weniger von dieser API. SPAs können jedoch trotzdem von Speculation Rules profitieren. Die API kann den initialen Zustand der Anwendung von einer Landingpage aus prerendern. Das gleicht die initiale Ladezeit potenziell aus.

Zuletzt überprüft von Arjen Karel im Februar 2026

Speculation Rules Schnellstart

Weißt du bereits, was Speculation Rules sind? Großartig! Hier sind einige sofort einsatzbereite Snippets für deinen direkten Start. Wähle das passende Snippet und füge es in den <head> deiner Seite ein (ändere gerne prerender in prefetch oder passe die eagerness an)!

<!--
   WordPress Speculation Rules von corewebvitals.io
   führt Prefetching für alle internen Links aus
   überspringt Links, die wp-login, wp-admin, wp-content entsprechen
   überspringt Links mit dem nofollow-Attribut
   überspringt Links mit einem Query-String, zum Beispiel: /search?q=welcome
-->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "and": [
                { "href_matches": "\\/*" },
                { "not": {
                    "href_matches": [
                        "\\/wp-login.php",
                        "\\/wp-admin\\/*",
                        "\\/*\\\\?*",
                        "\\/wp-content\\/*"
                    ]
                }},
                { "not": {
                    "selector_matches": "a[rel~=\\"nofollow\\"]"
                }}
            ]
        },
        "eagerness": "moderate"
    }]
}
</script>
<!-- Durch data-preload ausgelöste Speculation Rules von corewebvitals.io -->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "selector_matches": "a[data-preload]"
        },
        "eagerness": "moderate"
    }]
}
</script>

Tipp: Wenn du schnell eigene Speculation Rules erstellen musst, probiere den <b>Speculation Rules Generator</b> aus.

Auswirkungen in der Praxis

Speculation Rules sind nicht theoretisch. Die größten Namen im Web nutzen sie bereits mit messbaren Ergebnissen.

Ray-Ban implementierte Prerender-Regeln auf ihren Produktübersichtsseiten mit moderater Eagerness. Der LCP-Wert sank auf Mobilgeräten von 4,69 Sekunden auf 2,66 Sekunden (43 % schneller). Die mobilen Conversion-Raten stiegen um 101 % und die Desktop-Conversions um 156 %.

Shopify führte im Juni 2025 ein konservatives Prefetching auf der gesamten Plattform ein. Ihre A/B-Tests zeigten eine durchschnittliche Verbesserung von 130 ms auf dem Desktop und 180 ms auf Mobilgeräten über alle Paint-Metriken hinweg.

Cloudflare Speed Brain, gestartet im September 2024, fügt Speculation Rules standardmäßig zu allen Cloudflare-Tarifen hinzu. Seiten mit erfolgreichen Prefetches verzeichneten eine LCP-Reduzierung von 45 %.

Sogar die Google-Suche nutzt Speculation Rules: Suchergebnisse werden mit der Eagerness „eager“ geprefetchet. Das spart pro Klick 67 ms beim Android-LCP.

Auf Seiten, die von CoreDash überwacht werden, haben Navigationen mit Prerendering einen p75-LCP von 320 ms im Vergleich zu 1.800 ms bei Standardnavigationen auf denselben Seiten. Das ist eine Verbesserung von 82 % durch eine einzige API. Bei Seiten, die Speculation Rules mit moderater Eagerness nutzen, werden etwa 28 % der Navigationen erfolgreich geprefetchet oder geprerendert. Geprefetchete Navigationen zeigen eine p75-TTFB von nur 45 ms. Das liegt daran, dass sich das HTML bereits im In-Memory-Cache des Browsers befindet.

Vorteile von Speculation Rules

Verbesserte User Experience (UX): Durch die Vorhersage und das Preloading von Inhalten sorgen Speculation Rules für nahezu sofortige Seitenaufrufe. Das macht die Navigation für Nutzer nahtlos. Dies konkurriert selbst bei klassischen Multi-Page-Websites mit der Performance von Single-Page-Applications. Dabei entfallen die Komplexität und die Abhängigkeit von JavaScript. Schnellere Ladezeiten bedeuten ein besseres Surf-Erlebnis. Das steigert wahrscheinlich die Nutzerinteraktion und reduziert die Absprungraten.

SEO-Vorteile: Eine verbesserte Seitengeschwindigkeit ist ein direkter Ranking-Faktor. Eine bessere Time to First Byte führt zu einem besseren Largest Contentful Paint. Daher wird die Implementierung von Speculation Rules zwangsläufig die Core Web Vitals verbessern und dir diesen PageSpeed-Bonus verschaffen.

Reduzierte Komplexität: Nahezu sofortige Seitenaufrufe waren früher nur mit einer SPA oder benutzerdefinierter Prefetch-Logik für MPAs möglich. Für viele Anwendungsfälle ist der Nachteil einer SPA die initiale Startzeit. Diese kann beträchtlich sein, da SPAs stark auf JavaScript angewiesen sind. Hinzu kommt die erhöhte Komplexität im Vergleich zu einer MPA. Speculation Rules haben diese Probleme nicht. Das macht schnelles Laden für eine breitere Palette von Websites erreichbar, insbesondere für inhaltsfokussierte Seiten.

Die API vereinfacht auch die Entscheidung, welche Seiten geprerendert werden sollen. Sie delegiert einen Großteil der Logik an den Browser. Das ist eine enorme Verbesserung gegenüber früheren Methoden. Diese verließen sich auf JavaScript, um solche Prüfungen durchzuführen und Seiten für das Preloading einzufügen. Browser können den Nutzerkontext nativ berücksichtigen, wenn sie über ein Prerendering entscheiden. Beispiele sind wenig Speicherplatz auf Mobilgeräten oder der Energiesparmodus. Diese dynamische Anpassung schont die Nutzerressourcen. Sie sorgt für ein reibungsloseres Erlebnis, auch unter Einschränkungen.

Weitere Vorteile: Der HTTP-Header Speculation-Rules ermöglicht eine einfachere Bereitstellung über Content Delivery Networks (CDNs). Er macht die direkte Änderung von Dokumentinhalten überflüssig. Granulare Kontrolle durch Dokumentregeln erlaubt es Entwicklern, präzise Bedingungen für Prefetching oder Prerendering festzulegen. Diese basieren auf URL-Mustern oder CSS-Selektoren. Das reduziert manuelle URL-Angaben und ermöglicht seitenweite Regelwerke für Speculation Rules. Die Einstellung „eagerness“ bietet eine feingranulare Kontrolle darüber, wann eine Spekulation stattfindet. Sie balanciert die Preloading-Geschwindigkeit mit dem Ressourcenverbrauch aus. Das reduziert unnötiges Preloading und verhindert Ressourcenverschwendung.

Browser-Unterstützung

Speculation Rules werden in Chrome 109+, Edge 109+ und allen Chromium-basierten Browsern unterstützt. Das deckt laut Can I Use etwa 79 % des weltweiten Browser-Traffics ab. Firefox hat eine positive Position zu den Standards für den Prefetch-Teil erklärt, aber noch keinen Support veröffentlicht. Safari 26.2 hat eine funktionierende Implementierung hinter einem Flag, aber diese ist standardmäßig nicht aktiviert.

Für Browser, die Speculation Rules nicht unterstützen, kannst du Feature Detection nutzen, um auf <link rel="prefetch"> zurückzugreifen:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  // Browser unterstützt Speculation Rules
} else {
  // Fallback: <link rel="prefetch"> einfügen
  const link = document.createElement('link');
  link.rel = 'prefetch';
  link.href = '/next-page.html';
  document.head.append(link);
}

Funktionsweise von Speculation Rules

Speculation Rules werden über eine JSON-Struktur definiert und können auf zwei Arten implementiert werden:

  • Inline-Skript: Füge das JSON innerhalb eines <script type="speculationrules">-Tags in den <head> oder <body> des HTML-Hauptdokuments ein.
  • HTTP-Header: Liefere Regeln über den HTTP-Header Speculation-Rules in der Antwort des Dokuments aus. Dieser Header verweist auf eine JSON-Datei mit den Regeln. Das erleichtert CDN-Deployments, ohne den HTML-Inhalt direkt zu ändern.

Die JSON-Struktur nutzt die Arrays „prefetch“ und „prerender“. Diese enthalten Regeln für jeden spekulativen Ladetyp. Jede Regel kann verschiedene Quellen nutzen: entweder eine Liste von URLs oder Dokumentregeln.

  • urls (eine Liste von URLs): Ein Array von URLs für Prefetching oder Prerendering.
  • where (Dokumentregeln): Ein Objekt, das Bedingungen nutzt, um zu bestimmen, welche Links auf der Seite geprefetchet oder geprerendert werden sollen.

Jede Regel ist als Objekt definiert, das Eigenschaften enthält wie:

  • requires: Ein Array von Strings, um Einschränkungen für Spekulationen festzulegen. Aktuell ist der einzige gültige String „anonymous-client-ip-when-cross-origin“. Das gibt an, dass ein Cross-Origin-Prefetch die IP-Adresse des Clients anonymisieren soll.
  • target_hint: Ein String, der einen Hinweis auf den Namen des navigierbaren Ziels gibt („_self“ oder „_blank“). Das erlaubt dem User Agent, den Ladeprozess zu optimieren.
  • referrer_policy: Eine Referrer-Policy zur Anwendung auf geprefetchete oder geprerenderte URLs.
  • relative_to (nur für die Quelle „list“): Legt fest, ob die im Array „urls“ angegebenen URLs relativ zur Basis-URL des Dokuments („document“) oder zum Speicherort der JSON-Datei der Speculation Rules („ruleset“) sind.
  • eagerness: Steuert, wie aggressiv der Browser Prefetching oder Prerendering durchführen soll. Die verfügbaren Einstellungen sind „immediate“, „eager“, „moderate“ und „conservative“. Jede hat unterschiedliche Auslöser.
  • expects_no_vary_search: Ein Hinweis für den Browser, ob für die spekulierte URL eine andere Antwort basierend auf den Suchparametern erwartet wird. Nützlich für Seiten mit UTM-Parametern oder anderen Tracking-Query-Strings, die den Inhalt nicht verändern.

Schließlich hat jede Regel eine Eagerness-Einstellung. Damit kannst du definieren, wann Spekulationen ausgeführt werden sollen. Das trennt den Zeitpunkt der Spekulation von den URLs, auf denen Spekulationen ausgeführt werden. Die Eagerness-Einstellung ist sowohl für Listen- als auch für Dokumentquellenregeln verfügbar. Sie hat vier Einstellungen: immediate, eager, moderate und conservative.

  • immediate: Dies wird genutzt, um so schnell wie möglich zu spekulieren, sobald die Speculation Rules erkannt werden.
  • eager: Auf dem Desktop wird dies nach 10 Millisekunden Hovern über einem Link ausgelöst. Auf Mobilgeräten (ab Januar 2026) löst es 50 ms nach Eintritt eines Links in den Viewport aus.
  • moderate: Dies führt Spekulationen aus, wenn du 200 Millisekunden über einem Link hoverst (oder beim pointerdown-Event, falls das früher eintritt. Ebenso auf Mobilgeräten, wo es kein Hover-Event gibt).
  • conservative: Dies spekuliert bei Pointer- oder Touch-Down.

Chrome-Limits

Chrome erzwingt Limits für gleichzeitige Spekulationen. Das verhindert Missbrauch und schützt die Geräteressourcen:

  • immediate / eager: Bis zu 50 Prefetches und 10 Prerenders.
  • moderate / conservative: Bis zu 2 Prefetches und 2 Prerenders (FIFO: neue Spekulationen ersetzen die ältesten).

Chrome deaktiviert Spekulationen auch vollständig in bestimmten Fällen. Das gilt, wenn der Datensparmodus aktiviert ist, sich das Gerät im Energiesparmodus mit niedrigem Akkustand befindet oder der Nutzer die Einstellung „Seiten vorladen“ deaktiviert hat.

Prefetch oder Prerender

Die Speculation Rules API unterstützt zwei primäre Formen des spekulativen Ladens: Prefetching und Prerendering. Beide Techniken können zu schnelleren Seitenaufrufen führen. Sie unterscheiden sich jedoch in ihrer Komplexität und im Ressourcenverbrauch.

  • Prefetching ist die leichtere Form des spekulativen Ladens. Es lädt das HTML der Ziel-URL herunter und speichert es im Cache. Die Seite oder ihre Unterressourcen werden nicht gerendert. Dieser Ansatz verbessert hauptsächlich die Time to First Byte. Eine verbesserte Time to First Byte führt zu besseren Paint-Metriken wie dem Largest Contentful Paint und First Contentful Paint.
  • Prerendering macht viel mehr als nur das HTML herunterzuladen. Es lädt das HTML und alle Unterressourcen herunter. Zudem rendert es die gesamte Seite in einem versteckten, unsichtbaren Tab. Bei der Navigation zu dieser Seite führt das zu einer nahezu sofortigen Anzeige. Diese Technik verbessert den Largest Contentful Paint auf mehr Arten als nur durch die Verbesserung der Time to First Byte. Sie lädt und rendert auch das LCP-Element. Prerendering kann zudem den Cumulative Layout Shift eliminieren. Die Dimensionen der Ressourcen sind nach dem Prerendering bereits bekannt.

Es gibt auch eine dritte Option: prerender until script. Diese neue Funktion (Chrome 144, Januar 2026) ruft HTML ab, beginnt mit dem Rendering und dem Laden von Unterressourcen. Sie pausiert jedoch die JavaScript-Ausführung beim ersten blockierenden Skript-Tag. Dies eliminiert Skript-Seiteneffekte (wie das Auslösen von Analytics). Gleichzeitig werden CSS, Bilder und Schriftarten vorab geladen.

Was ist also besser? Prerendering oder Prefetching? Das hängt von der Seite und dem durchschnittlichen Besucher ab. Prerendering ist von Natur aus schneller. Es verbraucht jedoch viel mehr Ressourcen auf dem Client und dem Server. Die Wahl zwischen Prerendering und Prefetching hängt von folgenden Faktoren ab:

  • Gerätefähigkeiten der Nutzer: Prerendering ist möglicherweise nicht die beste Wahl. Besonders, wenn ein hoher Prozentsatz der Besucher Geräte mit begrenztem Arbeitsspeicher nutzt.
  • Spezifität der Prerender- oder Prefetch-Regel: Einige Links werden wahrscheinlicher angeklickt. Einige Seiten konvertieren wahrscheinlicher. Diese Seiten sind perfekte Kandidaten für eine Prerender-Regel. Andere Seiten eignen sich eher für Prefetching.

Ich warne vor übermäßigem Prerendering aufgrund des Ressourcenbedarfs. Das gilt insbesondere auf Mobilgeräten oder bei langsameren Verbindungen. Die potenziellen Vorteile von Prerendering müssen abgewogen werden. Dem stehen das Risiko von Performance-Einbußen und Ressourcenverschwendung gegenüber.

Die richtige Eagerness festlegen

Welche Eagerness-Einstellung du verwendest, hängt von deiner Seite ab. Für eine sehr einfache statische Seite verursacht eine aggressivere Spekulation (eager) vielleicht kaum Kosten. Sie bietet Nutzern direkte Vorteile. Seiten mit komplexeren Architekturen und größerem Payload wollen Verschwendung reduzieren. Sie spekulieren seltener. Sie warten auf ein deutlicheres Absichtssignal der Nutzer, um Verschwendung zu begrenzen.

Die Eagerness-Einstellung in der Speculation Rules API beeinflusst das Timing. Sie bestimmt, wann der Browser Inhalte basierend auf der vorhergesagten Nutzernavigation prefetcht oder prerendert. Diese Einstellung bietet einen Kompromiss. Sie maximiert die Preloading-Vorteile und minimiert gleichzeitig die Ressourcenverschwendung.

Die Standard-Eagerness für Listenregeln ist immediate. Die Optionen moderate und conservative können genutzt werden. Sie beschränken Listenregeln auf URLs einer bestimmten Liste, mit denen ein Nutzer interagiert. In vielen Fällen sind Dokumentregeln mit einer passenden where-Bedingung besser geeignet.

Die Standard-Eagerness für Dokumentregeln ist conservative. Ein Dokument kann aus vielen URLs bestehen. Die Nutzung von immediate oder eager für Dokumentregeln sollte daher mit Vorsicht erfolgen.

Bei der Konfiguration der Eagerness sollten Entwickler User Experience, Ressourcenkosten und Browser-Limits berücksichtigen. Übermäßige Spekulation kann die Bandbreite, den Arbeitsspeicher und die CPU der Nutzer belasten. Das verschlechtert potenziell die Performance. Dies gilt insbesondere für eingeschränkte Netzwerke oder Geräte. Zusätzlich können nutzerkonfigurierte Datensparmodi, niedriger Akkustand oder Browser-Erweiterungen die Speculation Rules überschreiben. Sie priorisieren dann die Ressourcenschonung.

Speculation Rules prüfen und debuggen

So prüfst du eine Seite auf Speculation Rules: Öffne die Chrome DevTools. Gehe zum Tab „Application“ und navigiere zu Background Services > Speculative Loads > Speculations. (Öffne den Speculations-Bereich, bevor du die zu debuggende Seite lädst). Dieses Panel liefert Informationen über:

  • Die Anzahl der erfolgreichen Spekulationen.
  • Einzelne URLs, die geprerendert oder geprefetchet werden.
  • Den Status jeder Spekulation.

Der Network-Track im Performance-Panel zeigt die Netzwerkaktivität für geprerenderte Ressourcen an. Ein Wechsel des DevTools-Kontexts ist dafür nicht nötig. Zusätzlich kannst du den DevTools-Kontext auf eine geprerenderte Seite wechseln. So kannst du sie wie eine normale Seite untersuchen.

speculative loads inspector devtools

Monitoring und Analyse von Speculation Rules

  • Real User Monitoring (RUM): Nutze RUM-Tools zur Messung der echten User Experience. Beobachte Metriken wie den Largest Contentful Paint (LCP). So bewertest du den Einfluss von Speculation Rules auf die Ladezeiten. Achte auf LCP-Verbesserungen bei geprerenderten Seiten im Vergleich zu nicht-geprerenderten Seiten.
  • A/B-Testing: Führe A/B-Tests durch. Vergleiche verschiedene Konfigurationen von Speculation Rules. Identifiziere das optimale Setup für deine spezifische Website und Nutzerbasis.

speculation rules rum tracking table coredash

Zu beachten

Ressourcenverbrauch: Eine übermäßige Spekulation kann sich negativ auf Bandbreite, Arbeitsspeicher und CPU-Auslastung auswirken. Beginne mit einer Eagerness von conservative oder moderate. Überwache die Ergebnisse vor einer Erhöhung.

Browser-Kompatibilität: Nicht alle Browser unterstützen die Speculation Rules API vollständig. Verwende den obigen Code zur Feature Detection. Biete so einen Fallback für Nicht-Chromium-Browser.

Datenschutz: Entwickler sollten bedenken, dass Speculation Rules das Surfverhalten von Nutzern offenlegen können. Implementiere geeignete Datenschutzmaßnahmen. Nutze für Cross-Origin-Prefetches die Anforderung „anonymous-client-ip-when-cross-origin“. Das maskiert die Client-IP über den privaten Prefetch-Proxy von Chrome.

Analytics: Geprerenderte Seiten führen JavaScript aus. Das bedeutet, dass Analytics-Skripte ausgelöst werden, bevor der Nutzer tatsächlich navigiert. Google Analytics und der Google Publisher Tag handhaben dies automatisch. Bei anderen Analytics-Tools solltest du die Initialisierung verzögern, bis die Seite aktiviert wird:

if (document.prerendering) {
  document.addEventListener('prerenderingchange', function() {
    initAnalytics();
  }, { once: true });
} else {
  initAnalytics();
}

Die Speculation Rules API bietet einen leistungsstarken Ansatz. Sie verbessert die Performance und User Experience von Webanwendungen. Wer ihre Funktionsweise, Vorteile und Besonderheiten versteht, kann diese API optimal nutzen. Entwickler bauen damit schnellere und ansprechendere Websites.

Speculation Rules und WordPress

Seit WordPress 6.8 (April 2025) sind Speculation Rules in den WordPress Core integriert. Die Standardkonfiguration nutzt Prefetching mit der Eagerness conservative. Sie wird auf alle Frontend-Seiten angewendet, wenn der Besucher nicht eingeloggt ist und Permalinks aktiviert sind.

Das WordPress Core Performance-Team pflegt auch ein eigenständiges Speculative Loading Plugin (40.000+ aktive Installationen). Es bietet mehr Kontrolle. Das Plugin enthält zwei Gruppen von Einstellungen:

  • Speculation Mode: Wähle zwischen prefetch und prerender. Prerendering führt zu schnelleren Ladezeiten als Prefetching. Für interaktive Inhalte kann Prefetching jedoch die sicherere Wahl sein.
  • Eagerness: Wähle zwischen conservative (typischerweise beim Klick), moderate (typischerweise beim Hovern) oder eager (beim geringsten Anzeichen). Die Eagerness-Einstellung bestimmt, wie schnell spekulative Ladevorgänge ausgelöst werden.

Mit einem PHP-Filter kannst du bestimmte Pfade von der Spekulation ausschließen:

add_filter(
  'plsr_speculation_rules_href_exclude_paths',
  function($paths) {
    $paths[] = '/cart/*';
    $paths[] = '/checkout/*';
    return $paths;
  }
);

Weitere Möglichkeiten, um Skripte aufzuschieben und das Laden zu optimieren, findest du in unserem vollständigen Guide.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

CoreDash spricht MCP.

Häng es an Claude oder einen beliebigen AI Agent und frag: Warum ist mein INP letzten Dienstag hochgegangen?

So funktioniert's
Sofort ladende Seiten mit Speculation Rules Core Web Vitals Sofort ladende Seiten mit Speculation Rules