Speculation Rules API: Instant-Ladezeiten für Shops

Der schnellste Seitenaufruf ist der, der schon geschehen ist, bevor der Kunde klickt. Genau das ermöglicht die Speculation Rules API: Sie lässt den Browser wahrscheinliche nächste Seiten im Hintergrund laden oder komplett vorrendern, sodass der eigentliche Klick nahezu ohne Wartezeit öffnet. Für Online-Shops ist das ein direkter Conversion-Hebel, denn Produktseiten und Checkout erscheinen dann quasi sofort. Der Modehändler Ray-Ban verdoppelte durch Prerendering seine mobile Conversion-Rate und senkte die Absprungrate um rund 13% (Ray-Ban, web.dev). Dieser Artikel erklärt, wie die Speculation Rules API funktioniert, wie wir sie im Shop einsetzen und wo die Fallstricke liegen.

Was die Speculation Rules API ist

Die Speculation Rules API ist eine Browser-Schnittstelle, mit der eine Website dem Browser mitteilt, welche Folgeseiten er spekulativ vorladen soll. Anders als der veraltete <link rel="prerender">-Ansatz werden die Regeln als JSON in einem <script type="speculationrules">-Block oder über einen HTTP-Header übergeben (MDN Web Docs). Die API zielt bewusst auf Dokument-URLs ab und eignet sich damit für klassische Multi-Page-Anwendungen wie die meisten Shopsysteme, nicht für Single-Page-Apps (MDN Web Docs).

Der Kerngedanke ist einfach: Wenn ein Besucher mit hoher Wahrscheinlichkeit als Nächstes eine bestimmte Produktseite öffnet, kann der Browser diese Seite bereits abrufen und im Speicher bereithalten. Klickt der Nutzer dann tatsächlich, wird die vorbereitete Seite nur noch angezeigt statt neu geladen. Prerendering der wahrscheinlich nächsten Seite ist laut Google eine der wirksamsten Methoden, um die Largest Contentful Paint (LCP) drastisch zu verbessern, weil der Ladevorgang praktisch schon vor dem Klick abgeschlossen ist (web.dev). Das Ergebnis ist ein LCP nahe null, ein reduzierter Layout-Shift und ein besseres Interaktivitätsverhalten (web.dev).

Prefetch und Prerender: der entscheidende Unterschied

Die API kennt zwei Stufen des Vorladens, die sich in Wirkung und Ressourcenverbrauch stark unterscheiden. Prefetch lädt lediglich das HTML-Dokument der Zielseite per GET-Anfrage und legt die Antwort in einem seitenbezogenen Speicher ab; die Seite wird noch nicht gerendert (MDN Web Docs). Prerender geht deutlich weiter: Der Browser lädt die Seite in einen unsichtbaren Tab, führt das JavaScript aus und lädt alle Unterressourcen, sodass die spätere Navigation nahezu sofort erfolgt (Chrome for Developers).

Für die Praxis heißt das: Prefetch lässt sich großzügig für viele Links einsetzen, weil es wenig kostet, während Prerender wegen des höheren Verbrauchs gezielt für die wahrscheinlichsten Navigationsziele reserviert bleiben sollte (MDN Web Docs). Chrome selbst beziffert den Aufwand eines Prerenders mit etwa dem einer zusätzlichen eingebetteten Seite (Chrome for Developers). Cross-Site-Prefetch funktioniert nur, wenn für die Zielseite keine Cookies gesetzt sind, und Cross-Site-Prerender ist derzeit nicht möglich (MDN Web Docs).

Wichtig zu wissen: Der Prefetch-Speicher ist bewusst kurzlebig. Er ist an das aktuelle Dokument gebunden und wird beim Verlassen der Seite wieder freigegeben (MDN Web Docs). Prefetch eignet sich damit für die unmittelbar nächsten Klicks, nicht als dauerhafter Cache-Ersatz. Für wiederkehrende Muster - etwa den immer gleichen Weg von der Startseite in die meistbesuchte Kategorie - bleibt serverseitiges Caching die tragende Schicht, die das spekulative Vorladen sinnvoll ergänzt.

Warum Millisekunden über Umsatz entscheiden

Ladezeit ist im E-Commerce kein technisches Detail, sondern eine harte Umsatzgröße. Nach Analysen von Google steigt die Wahrscheinlichkeit eines Absprungs um 32%, wenn die Ladezeit von einer auf drei Sekunden wächst (Google). Bereits eine Verbesserung der mobilen Ladezeit um nur 0,1 Sekunden steigerte die Conversions im Einzelhandel um 8,4% (Deloitte). Genau hier setzt Prerendering an: Es verschiebt die Ladezeit aus der wahrgenommenen Wartezeit des Kunden heraus in den Hintergrund.

Prerendering der nächsten Seite, die ein Nutzer besucht, ist ein wirksamer Weg, die LCP-Performance drastisch zu verbessern - möglich gemacht durch die Speculation Rules API.

web.dev (Google)

Der Zusammenhang zwischen Ladezeit und Geschäftsergebnis ist quer durch die Branche belegt. Vodafone verbesserte seine LCP um 31% und erzielte damit 8% mehr Verkäufe (web.dev). Lazada erreichte durch eine dreifach schnellere LCP eine um 16,9% höhere mobile Conversion-Rate (web.dev). AliExpress halbierte seine Ladezeit und senkte die Absprungrate um 15% (web.dev). Für Shop-Betreiber bedeutet das: Wer Produkt- und Kategorieseiten sofort erscheinen lässt, gewinnt an genau der Stelle, an der Kaufentscheidungen fallen. Eine solide Performance-Strategie zahlt direkt auf die Marge ein.

Eagerness: das Vorladen präzise steuern

Das wichtigste Steuerungsinstrument der API ist die Eagerness, also die Dringlichkeit, mit der spekuliert wird. Sie bestimmt, wie früh der Browser eine Seite vorlädt - und damit die Balance zwischen Geschwindigkeit und Ressourcenverbrauch. Vier Stufen stehen zur Verfügung (Chrome for Developers):

• immediate: Vorladen, sobald die Regel erkannt wird. Sinnvoll für sehr wahrscheinliche Ziele, etwa das erste Produkt einer Liste.
• eager: Löst sehr früh aus, auf dem Desktop bereits nach rund 10 Millisekunden Hover, auf Mobilgeräten anhand von Viewport-Heuristiken.
• moderate: Der bewährte Mittelweg. Auf dem Desktop nach etwa 200 Millisekunden Hover oder bei pointerdown, auf Mobilgeräten nach dem Ende des Scrollens.
• conservative: Löst erst bei pointerdown beziehungsweise Touch aus - der sparsamste Modus, ideal für breit gefasste Regeln.

Für einen Shop bewährt sich in der Regel eine Kombination: moderate für das Prerendern der wahrscheinlichsten Produktseiten und conservative für ein breites Prefetch aller übrigen Links. So sieht eine typische Regelkonfiguration aus, die Warenkorb- und Checkout-Seiten bewusst ausschließt:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/produkt/*" },
        { "not": { "href_matches": "/warenkorb" } },
        { "not": { "href_matches": "/checkout" } },
        { "not": { "selector_matches": ".no-prerender" } }
      ]
    },
    "eagerness": "moderate"
  }],
  "prefetch": [{
    "where": { "href_matches": "/*" },
    "eagerness": "conservative"
  }]
}
</script>

Umsetzung im Shop: Produkt- und Checkout-Aufrufe beschleunigen

In einem Online-Shop gibt es mehrere Stellen, an denen sich Prefetch und Prerender besonders lohnen. Entscheidend ist, das Vorladen an tatsächliche Kaufabsicht zu koppeln - etwa an das Hovern über eine Produktkachel - statt wahllos alles vorzuladen. Diese Ansatzpunkte setzen wir in der Shop-Entwicklung typischerweise zuerst um:

Der wichtigste Hebel ist fast immer der Sprung von der Kategorie- zur Produktseite, weil er millionenfach vorkommt. Ray-Ban löste auf dem Desktop das Prerendering per Hover mit moderate-Eagerness aus und lud auf Mobilgeräten die ersten Produktkacheln mit immediate vor (Ray-Ban, web.dev). Für performancekritische Shops lässt sich das Vorladen zusätzlich mit schnellen Netzwerkprotokollen und effizientem Caching kombinieren, sodass selbst der Hintergrundabruf minimal belastet.

Fallstricke im E-Commerce sicher vermeiden

Prerendering ist mächtig, aber im Shop-Kontext mit Vorsicht einzusetzen. Das größte Risiko sind URLs mit Nebenwirkungen: Ein vorab geladener Logout-Link würde den Nutzer ungewollt abmelden, ein vorgeladener Warenkorb-Link könnte Zustände verändern. Chrome empfiehlt ausdrücklich, Adressen auszuschließen, die Serverzustände ändern oder nicht zwischenspeicherbar sind (Chrome for Developers). In der Praxis schließen wir daher Warenkorb, Checkout, Logout und Konto-Aktionen konsequent aus der Regelmenge aus.

// Seitenaufruf erst beim echten Anzeigen zählen, nicht beim Vorrendern
function seitenaufrufTracken() {
  // hier folgt der eigentliche Analytics-Aufruf
}

if (document.prerendering) {
  // Seite wird gerade unsichtbar vorgerendert: warten
  document.addEventListener('prerenderingchange', seitenaufrufTracken, { once: true });
} else {
  // normaler Aufruf oder bereits aktivierte Vorschau
  seitenaufrufTracken();
}

• Zustandsändernde URLs ausschließen: Warenkorb, Checkout, Logout und Konto-Endpunkte gehören nicht in die Prerender-Regeln.
• Seiten aktuell halten: Änderungen wie ein neu gefüllter Warenkorb sollten per Broadcast Channel API in vorgerenderte Seiten gespiegelt werden, damit der Nutzer keinen veralteten Stand sieht (Chrome for Developers).
• Serverlast im Blick behalten: Bei Aktionen und Lastspitzen kann Vorladen zusätzliche Anfragen erzeugen - halten Sie eine Möglichkeit bereit, die Regeln schnell zu deaktivieren (Chrome for Developers).
• Cachebarkeit sicherstellen: Gut zwischenspeicherbare Seiten reduzieren die zusätzliche Serverlast des Vorladens deutlich.
• Rechtliche Vorgaben mitdenken: Automatisch vorgeladene Inhalte sollten mit Ihren Produkt- und Sicherheitspflichten sowie der Einwilligungslogik zusammenpassen.

Messbare Ergebnisse aus der Praxis

Die Wirkung von Prerendering lässt sich an öffentlichen Fallstudien gut belegen. Ray-Ban reduzierte die LCP auf Produktseiten mobil von 4,69 auf 2,66 Sekunden (minus 43%) und auf dem Desktop von 3,03 auf 1,74 Sekunden (minus 43%) (Ray-Ban, web.dev). Parallel stieg die mobile Conversion-Rate um 101%, die Desktop-Conversion sogar um 156%, während die Absprungrate um rund 13% sank (Ray-Ban, web.dev). Auch die Seiten pro Sitzung legten deutlich zu, mobil um 52% und auf dem Desktop um 65% (Ray-Ban, web.dev).

Die Verlagsgruppe Monrif belegt die Wirkung außerhalb des Handels: Auf ihren Nachrichtenseiten sank die LCP je nach Titel um 433 Millisekunden (17,9%), 407 Millisekunden (17,1%) und 350 Millisekunden (15%) (Monrif, web.dev). Die Nutzerbindung stieg im Gegenzug um bis zu 8,9% (Monrif, web.dev). Bemerkenswert ist der Plattformunterschied: Auf dem Desktop lösten 13,9% der Seitenaufrufe ein Prerendering aus, mobil nur 2,9% (Monrif, web.dev) - ein Hinweis darauf, dass sich die Regeln je nach Geräteklasse unterschiedlich stark auswirken.

Selbst hochoptimierte Seiten profitieren. Google Search verkürzte durch Prefetch der ersten beiden Ergebnisse die LCP auf Chrome für Android um 67 Millisekunden und auf dem Desktop um 58,6 Millisekunden (Chrome for Developers). Bei einer bereits stark getunten Seite gelten solche Millisekundengewinne als bemerkenswert (Chrome for Developers). Für einen typischen Shop mit deutlich mehr Optimierungsspielraum sind die Effekte in der Regel größer.

Ein oft übersehener Zwilling des Prerenderings ist der Back/Forward-Cache (bfcache), der komplette Seiten für Vor- und Zurück-Navigationen im Speicher hält. Ray-Ban steigerte die bfcache-Trefferquote einer Kategorieseite von 0,02% auf 72,90% (Ray-Ban, web.dev), indem das Team unload-Listener entfernte und auf das pagehide-Ereignis umstellte. Zusammen mit Prerendering entsteht so ein durchgängig schnelles Navigationserlebnis - vorwärts wie rückwärts. Für Shop-Betreiber lohnt es sich, beide Techniken gemeinsam zu prüfen, statt nur an einer Stellschraube zu drehen.

Browser-Support und Grenzen realistisch einordnen

Die Speculation Rules API ist eine Verbesserung, kein Muss - und genau so sollte sie behandelt werden. Laut MDN gilt sie derzeit als experimentell und nicht als Baseline, weil sie nicht in allen weit verbreiteten Browsern funktioniert (MDN Web Docs). Der praktische Vorteil: Browser, die die Regeln nicht verstehen, ignorieren den speculationrules-Block einfach und laden die Seite ganz normal. Damit ist Prerendering ein idealer Fall von progressiver Verbesserung: Nutzer in unterstützenden Browsern erhalten Instant-Navigation, alle anderen die gewohnte Erfahrung. Ein guter Ausgangswert bei den Core Web Vitals bleibt daher die Grundlage.

Auch die Herkunftsregeln sollte man kennen. Prerendering ist standardmäßig auf Same-Origin-Dokumente beschränkt; Cross-Origin innerhalb derselben Site ist nur möglich, wenn die Zielseite über den Supports-Loading-Mode-Header ausdrücklich zustimmt (MDN Web Docs). Für die meisten Shops ist das unkritisch, weil Kategorie, Produktseite und Checkout ohnehin auf derselben Domain liegen. Bei kopfbasierten Architekturen mit getrennten Frontends lohnt sich hingegen eine genaue Prüfung der Domain-Struktur, bevor Regeln aktiviert werden.

Diese Funktion ist nicht Baseline, weil sie in einigen der meistgenutzten Browser nicht funktioniert - behandeln Sie sie als Verbesserung, nicht als Voraussetzung.

MDN Web Docs

Instant-Navigation als Conversion-Hebel nutzen

Die Speculation Rules API gehört zu den wenigen Performance-Maßnahmen, die die wahrgenommene Ladezeit nicht nur senken, sondern nahezu verschwinden lassen. Für Shops mit vielen Produktaufrufen ist der Weg von der Kategorie zur Produktseite der naheliegende Startpunkt, ergänzt um breites Prefetch und einen konsequenten Ausschluss zustandsändernder URLs. In Kombination mit einer soliden Ladezeit-Optimierung und sauberem Caching entsteht daraus ein spürbar schnelleres Einkaufserlebnis.

Wir begleiten die Einführung von der Analyse der häufigsten Navigationspfade über die Definition sicherer Regeln bis zur Messung in Feld- und Labordaten. Ob als Teil eines Relaunch-Projekts, einer gezielten Shopware-Performance-Optimierung oder als Baustein einer modernen Shop-Architektur mit KI-Anbindung: Prerendering ist ein pragmatischer Hebel mit direktem Effekt auf Conversion und Sichtbarkeit. Beginnen Sie mit einer Bestandsaufnahme Ihrer Top-Navigationspfade - dort liegt in der Regel das größte Potenzial.