Die wichtigsten Takeaways
- Shopify liefert Speculation Rules bereits für jeden Storefront aus. Es sendet einen
Speculation-RulesResponse Header, der auf eine JSON-Datei verweist. Diese macht ein Prefetching von Produkt-, Collection-, Page-, Search-, Blog- und Policy-URLs mit einereagernessvonmoderate.- Shopify macht nur Prefetching. Es gibt kein Prerendering. Deine eigene
prerender-Regel in dertheme.liquidhinzuzufügen, ist die eigentliche Chance. Shopifys eigene Theme-Docs besagen, dass Themes zusätzliche Regeln hinzufügen dürfen.- Prefetch lädt das HTML herunter. Prerender rendert die gesamte Seite in einem versteckten Tab, inklusive Subressourcen und JavaScript. Prerendering ist deutlich schneller und deutlich teurer, also setze es gezielt ein.
eagernesssteuert den Trigger:immediate,eager,moderate(200ms Hover auf dem Desktop) undconservative(Mausklick/Pointer Down). Document Rules haben standardmäßig den Wertconservative, List Rules den Wertimmediate.- Die echten Risiken bei Shopify sind Seiteneffekte beim Warenkorb und bei Rabatten, doppelt gezählte Analytics und Third-Party-Skripte, die feuern, bevor der Käufer überhaupt auf der Seite ist. Schließe Pfade wie
/cart,/account,/checkoutsund/discountaus und knüpfe Analytics andocument.prerendering.
Die Speculation Rules API ermöglicht es einer Seite, dem Browser mitzuteilen, welche URLs der Besucher als Nächstes wahrscheinlich öffnen wird. So kann der Browser diese im Voraus abrufen (Prefetch) oder vollständig rendern (Prerender). Bei Shopify ist dies eine der wenigen verbleibenden Möglichkeiten, um eine Navigation so wirken zu lassen, als passiere sie sofort statt einfach nur schnell.
Die meisten Guides zu Speculation Rules gehen davon aus, dass du bei null anfängst. Bei Shopify ist das nicht der Fall. Die Plattform injiziert bereits ein Regelset für dich. Die nützliche Arbeit besteht darin, zu wissen, was es abdeckt, was es absichtlich weglässt und was du bedenkenlos oben drauf in deiner theme.liquid hinzufügen kannst.
Warum du uns vertrauen kannst
Wir sind seit über vier Jahren im Shopify-Umfeld tätig und haben mit Hunderten von Shopify-Marken an ihren Storefronts gearbeitet. Jacques hat über 15 Jahre Entwicklungserfahrung. Wir entwickeln Fudge, einen KI-Storefront-Editor mit einer 5,0-Bewertung im Shopify App Store und „Built for Shopify“-Status. Wir arbeiten also genau auf der Theme-Ebene, auf der auch diese Regeln leben.
Was ist die Speculation Rules API?
Es handelt sich um einen JSON-Block in einem <script type="speculationrules">-Tag. Das JSON benennt URLs oder ein Muster (Pattern), das auf Links im Dokument zutrifft, und weist den Browser an, diese mit prefetch oder prerender vorzuladen.
<script type="speculationrules">
{
"prerender": [{"where": {"href_matches": "/products/*"}, "eagerness": "moderate"}]
}
</script>
Es ersetzt die alten Resource Hints. <link rel="prefetch"> hat nur den HTTP-Cache aufgewärmt und dir keine Kontrolle über das Timing gegeben. <link rel="prerender"> wurde nie konsistent implementiert und ist mittlerweile veraltet (deprecated). Speculation Rules bieten dir Pattern Matching, Ausschlüsse (Exclusions), Triggers pro Regel und ein definiertes Set an Einschränkungen dafür, was eine per Speculation vorgeladene Seite überhaupt tun darf.
Die Regeln sind ein Hinweis (Hint), kein Befehl. Ein Browser, der das Script-Tag nicht versteht, ignoriert es einfach. Chrome selbst weigert sich zu spekulieren, wenn der Datensparmodus (Save-Data) aktiviert ist, der Arbeitsspeicher des Geräts knapp ist, der Energiesparmodus bei niedrigem Akkustand aktiv ist oder der Nutzer das Preloading von Seiten deaktiviert hat.1 Es geht nichts kaputt, wenn keine Speculation stattfindet. Der Besucher bekommt einfach eine normale Navigation.
Prefetch vs. Prerender
| Prefetch | Prerender | |
|---|---|---|
| Was wird geladen | Nur das HTML-Dokument | Dokument, Subressourcen und JavaScript |
| Was läuft | Nichts | Die komplette Seite, im versteckten Tab |
| Kosten | Ein zusätzlicher GET-Request | Ungefähr so viel wie ein extra Tab |
| Typischer Nutzen | Eliminiert Server-/Netzwerk-Zeit | Kann LCP von fast null ms erreichen |
| Risiko für Bugs | Gering | Hoch |
| Wann nutzen | Großflächig | Gezielt, bei Links mit hoher Klick-Wahrscheinlichkeit |
Prefetch ist der sichere Standard. Von Prerender kommen die dramatischen Zahlen – und genau hier lauern auch alle Risiken, die in diesem Guide behandelt werden.
Welche Speculation Rules führt Shopify bereits aus?
Shopify hat die Speculation Rules Ende Juni 2025 plattformweit ausgerollt und eine durchschnittliche Verbesserung von 130ms auf dem Desktop und 180ms auf Mobile über alle Perzentile und alle Lade-Metriken hinweg gemeldet – das bedeutet TTFB, FCP und LCP zusammen.2
Die Regeln befinden sich nicht in deinem Theme. Shopify sendet einen Speculation-Rules Response Header, der auf eine JSON-Datei auf dem CDN verweist, welche als application/speculationrules+json ausgeliefert wird. Rufst du diese Datei für einen beliebigen Live-Storefront auf, erhältst du das aktuelle Regelset der Plattform:
{
"tag": "shopify_storefront_moderate",
"prefetch": [
{
"where": {
"or": [
{"href_matches": "/(products|collections|pages|search|shop|blogs|policies){/*}?"},
{
"href_matches": "/([a-z]{2,3}|zh-hans|zh-hant)(-[a-z]{2,3})?/(products|collections|pages|search|shop|blogs|policies){/*}?"
},
{"href_matches": "/"},
{"href_matches": "/([a-z]{2,3}|zh-hans|zh-hant)(-[a-z]{2,3})?{/}?"}
]
},
"eagerness": "moderate"
}
]
}
Drei Dinge solltest du aus diesem Block mitnehmen.
Es ist nur Prefetch. Es gibt darin nirgends einen prerender-Key. Shopify besorgt sich das Dokument einfach früher, sonst nichts.
Es ist eine Allowlist, keine Blocklist. Nur Produkte, Collections, Seiten, Suche, Shop, Blogs, Richtlinien (Policies) und die Startseite werden erfasst – jeweils in der Root-Form und in der Form mit Markt-Prefix. Warenkorb-, Account- und Checkout-URLs matchen nie, daher wird für sie nie Speculation angewendet.
Die Eagerness ist moderate. Shopify begann mit conservative und hob den Standard später an. Das brachte laut eigenen Angaben bei den Medianwerten auf dem Desktop Verbesserungen von 285ms (TTFB), 224ms (FCP) und 228ms (LCP). Rund 10 % der per Speculation geladenen Navigationen erreichten eine TTFB von 0ms. Bei Mobile waren die Gewinne mit ca. 25ms, 20ms und 24ms deutlich geringer. Der Preis dafür war ein Anstieg der gesamten HTML-Requests um 14 % durch Browser, die das Feature unterstützen.3
Shopifys Dokumentation zur Theme-Performance bestätigt, dass Themes zusätzlich eigene Regeln hinzufügen dürfen. Dein Job ist es also nicht, Prefetching neu zu implementieren. Es geht darum zu entscheiden, wo Prerendering wirklich Sinn macht.
Eagerness-Level und welches du wählen solltest
eagerness ist der Trigger, nicht die Priorität. Er beantwortet die Frage: „Wann reagiert der Browser auf diese Regel?“
| Wert | Desktop-Trigger | Chrome-Limit pro Seite |
|---|---|---|
immediate | Sobald die Regel geparst wurde | 50 Prefetch, 10 Prerender |
eager | 10ms Pointer Hover (Maus über dem Link) | 2, First In, First Out |
moderate | 200ms Pointer Hover oder Pointer Down | 2, First In, First Out |
conservative | Nur bei Pointer Down oder Touch Down | 2, First In, First Out |
Mobile hat kein Hover, deshalb greift Chromium auf Viewport-Heuristiken zurück. Auf mobilen Geräten feuert eager kurz nachdem ein Anker-Link (Anchor) in den Viewport kommt. Dieses Verhalten hat sich in Chrome 143 geändert; davor verhielt sich eager wie immediate. Bei moderate auf Mobile wird gewartet, bis das Scrollen zum Stillstand kommt.
Die Standardwerte (Defaults) unterscheiden sich je nach Regeltyp. Eine List Rule mit urls hat standardmäßig immediate. Eine Document Rule mit where hat standardmäßig conservative. Wenn du eine Document Rule schreibst und eagerness vergisst, bekommst du das vorsichtigste Verhalten – und das ist meistens nicht das, was du wolltest.
Für einen Shopify Storefront ist moderate der vernünftige Startpunkt für Prerendering. Ein immediate Prerender auf einer Collection Page würde versuchen, bis zu zehn Produktseiten zu rendern, die der Shopper vielleicht niemals öffnet – und das auf einem Gerät, das du nicht kontrollierst.
Document Rules vs. List Rules
List Rules benennen URLs direkt. Sie eignen sich für einen bekannten, festen nächsten Schritt.
{"prefetch": [{"urls": ["/collections/all", "/pages/size-guide"]}]}
Document Rules erfassen Links, die bereits auf der Seite existieren, über das where-Feld. Sie eignen sich für einen Storefront, bei dem die interessanten URLs durch Liquid generiert werden und sich pro Seite ändern.
href_matches nutzt die Syntax von URL Pattern. Das * ist also ein Wildcard und {...}? markiert eine optionale Gruppe. selector_matches nimmt einen CSS-Selektor entgegen, womit du einzelne Links über eine CSS-Klasse ausschließen kannst. Beide akzeptieren Arrays, und mit and, or und not lassen sie sich kombinieren.
Diese Kombination ist es, die Exclusions (Ausschlüsse) so praktisch macht. Du kannst sagen: „Jeder Link auf der Seite, außer denjenigen, die den Serverstatus (Server State) ändern.“
So fügst du Speculation Rules zu einem Shopify-Theme hinzu
Die Regeln kommen ins Layout, damit sie auf jeder Seite existieren, die dieses nutzt. Öffne deinen Theme-Code-Editor, bearbeite layout/theme.liquid und platziere das Skript kurz vor dem schließenden </head>-Tag. Wenn du noch nie Theme-Dateien bearbeitet hast, lies dir zuerst unseren Guide zum Thema Shopify Theme bearbeiten durch und dupliziere das Theme, bevor du etwas änderst.
Die gezielte Version: Produkte von Browse-Seiten prerendern
Das ist die Version, mit der du anfangen solltest. Sie prerendert Produktseiten, aber nur von den Templates aus, bei denen der Käufer gerade wirklich ein Produkt auswählt.
{%- if request.page_type == 'collection'
or request.page_type == 'index'
or request.page_type == 'search' -%}
<script type="speculationrules">
{
"tag": "theme-product-prerender",
"prerender": [
{
"where": {
"and": [
{ "href_matches": [
"/products/*",
"/([a-z]{2,3}|zh-hans|zh-hant)(-[a-z]{2,3})?/products/*"
]
},
{ "not": { "selector_matches": ".no-prerender" } },
{ "not": { "selector_matches": "[rel~=nofollow]" } }
]
},
"eagerness": "moderate"
}
]
}
</script>
{%- endif -%}
Das Liquid-if nutzt request.page_type, das Shopify auf Werte wie collection, index, search, product oder cart setzt. Durch diese Bedingung wird die Regel nicht auf Templates geladen, bei denen ein Prerendering der Produktseite ohnehin sinnlos wäre.
Der zweite href_matches-Eintrag deckt die Shopify-Märkte ab. Shopify stellt lokalisierten URLs ein Locale-Segment voran, und die Gruppe hier ist aus Shopifys eigenen Regeln kopiert, sodass sich beide exakt gleich verhalten.
Die .no-prerender-Ausnahme ist wichtig. Füge diese Klasse jedem Link hinzu, bei dem ein Shop-Manager später entscheidet, dass er nicht spekuliert werden soll, und schon ist keine weitere Code-Änderung mehr nötig.
Die breite Version: Alles außer den gefährlichen Pfaden
Wenn du eine größere Abdeckung möchtest, kehre die Logik um. Matche alle Links und ziehe dann die Routen ab, die den Status verändern.
<script type="speculationrules">
{
"tag": "theme-broad-prerender",
"prerender": [
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": [
"/cart{/*}?",
"/checkouts/*",
"/account{/*}?",
"/discount/*",
"/apps/*",
"/([a-z]{2,3}|zh-hans|zh-hant)(-[a-z]{2,3})?/cart{/*}?",
"/([a-z]{2,3}|zh-hans|zh-hant)(-[a-z]{2,3})?/account{/*}?",
"/([a-z]{2,3}|zh-hans|zh-hant)(-[a-z]{2,3})?/discount/*"
]
}},
{ "not": { "href_matches": "/*\\?*(^|&)logout=*" } },
{ "not": { "selector_matches": "[rel~=nofollow]" } },
{ "not": { "selector_matches": ".no-prerender" } }
]
},
"eagerness": "moderate"
}
]
}
</script>
/discount/* verdient eine eigene Zeile. Shopify-Rabattlinks wenden einen Code an und setzen ein Cookie bei einem einfachen GET-Request. Wenn man einen solchen Link prerendert, wird der Rabatt angewendet, bevor der Käufer überhaupt auf irgendetwas geklickt hat.
Teste beide Versionen zuerst in einem unveröffentlichten Duplikat deines Themes. Eine Speculation Rule ist schnell geschrieben – und ebenso schnell macht man unauffällige, aber fatale Fehler.
Browser-Support im Jahr 2026
Speculation Rules sind ein Chromium-Feature. Prerendering über die API wurde in Chrome 109 ausgeliefert, und Edge, Opera sowie Samsung Internet zogen über dieselbe Engine nach.
| Browser | Status |
|---|---|
| Chrome | Unterstützt ab 109 |
| Edge | Unterstützt ab 109 |
| Opera | Unterstützt ab 95 |
| Samsung Internet | Unterstützt ab 21 |
| Firefox | Nicht unterstützt. Mozillas Standardisierungs-Position zu Speculation Rules ist neutral, unter Verweis auf die Komplexität. |
| Safari | Implementiert, aber ab 26.2 standardmäßig deaktiviert, mit aktiver WebKit-Arbeit bis 2026. |
Die globale Unterstützung liegt bei etwa 75 % des getrackten Traffics.4 Für einen Shopify-Store, dessen Traffic stark zu iOS Safari tendiert, ist der erreichbare Anteil deutlich geringer. Das ist allerdings eher ein Grund dafür, die Kosten für deine Regeln niedrig zu halten, als sie ganz wegzulassen.
Nicht unterstützende Browser ignorieren das Script-Tag komplett. Es gibt kein Polyfill, du brauchst keinen Fallback und es gibt keinen Nachteil, der über ein paar hundert Bytes Markup hinausgeht.
Die echten Risiken bei Shopify
Verschwendete Bandbreite und zusätzliche Serverlast
Jede Speculation, der kein Klick folgt, ist ein Request, den niemand genutzt hat. Shopify hat bereits einen Anstieg von 14 % bei den HTML-Requests gemessen, nur weil die Eagerness bei Prefetch um eine Stufe angehoben wurde. Prerender ist noch deutlich schwerfälliger, da es auch Sub-Ressourcen lädt und Skripte ausführt.
Shopify fängt die Last auf der Serverseite für dich ab, deine Apps und Drittanbieter-Endpunkte tun das jedoch nicht. Wenn eine Produktseite beim Laden eine Reviews-API oder einen Personalisierungsdienst abfragt, werden diese auch durch ein Prerendering aufgerufen.
Doppelt gezählte Analytics
Eine via Prerender geladene Seite führt ihr JavaScript aus, bevor der Shopper sie überhaupt gesehen hat. Belässt man es dabei, werden Pageviews künstlich aufgebläht und sämtliche Conversion-Rates verfälscht.
Die Lösung ist es, alles, was Daten trackt oder feuert, bis zur Aktivierung (Activation) hinauszuzögern:
if (document.prerendering) {
document.addEventListener('prerenderingchange', initAnalytics, {once: true})
} else {
initAnalytics()
}
Google Analytics handhabt Prerendering von Haus aus (nativ). Bei Custom-Tracking, Chat-Widgets, Popup-Timern und der Gruppenzuteilung (Bucketing) für A/B-Tests ist das im Regelfall nicht so. Überprüfe (Audit) die Skripte, die dein Theme lädt, bevor du Prerendering aktivierst. Falls dir dieses Inventar unbekannt vorkommt, ist unser Guide zu Render-Blocking Scripts in Shopify ein guter Weg, sie aufzulisten.
Nebenwirkungen bei Warenkorb und Sessions
Das ist die Shopify-spezifische Gefahr. Jede URL, die den Status per GET-Request ändert, ist ein Risiko fürs Speculative Loading: Rabattlinks, ?logout=-Links, Warenkorb-Permalinks, Query-Parameter fürs automatische Hinzufügen zum Warenkorb, Referral- und Affiliate-Landing-URLs. Shopifys eigenes Regelwerk umgeht das Problem elegant, indem es ausschließlich schreibgeschützte Routen per Allowlist erlaubt. Mach dir diesen Instinkt zu eigen.
Du kannst in Liquid nicht serverseitig filtern
Browser senden Sec-Purpose: prefetch oder Sec-Purpose: prefetch;prerender bei spekulativen Requests, und ein normales Backend kann basierend auf diesem Header Fallunterscheidungen vornehmen. Liquid kann das nicht. Das request-Objekt bietet nur Zugriff auf host, origin, path, page_type, locale, design_mode und visual_preview_mode, aber keinen Zugriff auf Request-Header. In einem Shopify-Theme muss also jeder Schutzmechanismus direkt in der Regel selbst oder über clientseitiges JavaScript realisiert werden.
Überschneidung mit existierenden Prefetch-Skripten im Theme
Viele kostenpflichtige Themes liefern immer noch ein Hover-Preload-Skript mit, sei es instant.page oder eine eigene Kopie davon. instant.page lädt nach 65 ms Hover über einen eigenen Fetch-Aufruf vor, der komplett unabhängig von der Speculation-Mechanik des Browsers ist. Wenn du das zusammen mit Shopifys moderate-Prefetch laufen lässt, rufen zwei völlig unterschiedliche Systeme ungefähr beim selben Auslöser (Trigger) exakt dasselbe Dokument ab.
Durchsuche deine Theme-Assets nach instant.page und nach rel="prefetch", bevor du eigene Regeln hinzufügst. Wenn ein Skript nur das dupliziert, was die Plattform ohnehin schon tut, entferne es. In unserem Guide So fügst du Custom JavaScript in Shopify hinzu erfährst du, wo sich diese Snippets üblicherweise verstecken.
So misst du, ob es funktioniert hat
Chrome DevTools. Öffne das Application-Panel und suche nach Speculative loads unter Background services. Es hat drei Tabs: den Status der aktuellen Seite, jedes auf der Seite gefundene Regelwerk (Rulesets) und jede durch diese Regeln spekulierte URL mitsamt ihrem Ergebnis. Misserfolge werden mit Begründungen aufgelistet, etwa wegen einer Non-2xx-Response oder einem bereits erreichten Limit. Lade die Seite neu, nachdem du das Panel geöffnet hast, sonst bleibt es leer.
Field Data. CrUX schlüsselt Metriken seit März 2024 nach Navigationstyp auf, und prerender ist einer der Typen, neben navigate, back_forward_cache und restore. Das ist der ehrlichste Weg, um zu sehen, wie viel von deinem echten Traffic tatsächlich auf einer prerendered Seite landet und wie der LCP im Vergleich zu einer kalten Navigation aussieht.
Was du erwarten kannst. Prerender verbessert hauptsächlich den LCP, da die Seite bereits gezeichnet (painted) ist, wenn der Klick landet. Der INP kann sich als Nebeneffekt verbessern, da Skripte bereits geparst und ausgeführt wurden. Für den Anteil der Nutzer, die über Safari oder Firefox kommen, bewegen sich die Metriken überhaupt nicht – ein seitenweiter Durchschnitt wird den Effekt für Chrome-Nutzer also immer untertreiben.
Speculation Rules sind eine Optimierung der Navigation, keine Lösung für riesige und überladene Seiten (Page-Weight). Eine langsame Produktseite ist immer noch langsam, wenn jemand sie zum ersten Mal aufruft. Kombiniere dies am besten mit den Grundlagen aus unserem Guide Wie man ein Shopify-Theme schneller macht, und schau dir den Stand der Shopify-Performance im Jahr 2026 an, um zu sehen, wo typische Shops aktuell stehen.
Wo Fudge ins Spiel kommt
Speculation Rules sind nur ein winziger JSON-Block, aber die eigentliche Arbeit drumherum ist klassische Theme-Arbeit: Den richtigen Platz in der theme.liquid finden, per request.page_type abfragen, auditieren, welche Skripte beim Laden feuern, und ein veraltetes Preload-Skript entfernen, das die Arbeit der Plattform inzwischen nur noch dupliziert.
Fudge ist ein KI-Storefront-Editor, der natives Liquid, CSS und JavaScript direkt in dein Theme schreibt. Du kannst Fudge bitten, ein Prerender-Regelwerk nur für Produkt-Links auf Collection-Seiten hinzuzufügen. Oder du kannst die KI bitten, das nervige Hover-Preload-Skript ausfindig zu machen und zu entfernen, mit dem dein Theme ausgeliefert wurde – den Code-Diff kannst du danach bequem checken und dann veröffentlichen.
Da der Output echter Theme-Code ist und kein über eine App gerenderter Layer, hast du danach kein zusätzliches Script-Tag eines externen Anbieters im Code. Und nichts verschwindet auf magische Weise, falls du die App jemals deinstallierst. Das Gleiche gilt auch für alles andere, was du mit unserem Shopify Store Editor baust.
FAQ
Ja. Shopify hat Speculation Rules Ende Juni 2025 plattformweit ausgerollt und liefert diese über einen Speculation-Rules Response Header aus, der auf eine JSON-Datei auf dem CDN verweist. Das Regelset der Plattform macht ein Prefetching von Produkt-, Collection-, Page-, Search-, Shop-, Blog-, Policy- und Homepage-URLs mit einer Eagerness von moderate, sowohl für Root-URLs als auch für solche mit Markt-Prefix. Es wird nichts per Prerender geladen.
Shopify übernimmt bereits das Prefetching für die sicheren Read-Only-Routen. Zusätzliche Prefetch-Regeln würden also meist nur Arbeit duplizieren. Prerender ist die Ergänzung, die sich wirklich lohnt, da es die Seite vollständig in einem versteckten Tab rendert und den LCP auf nahezu null drücken kann. Setze es gezielt ein, zum Beispiel für Produkt-Links auf Collection- und Suchseiten, und nutze eine moderate Eagerness.
In der layout/theme.liquid, kurz vor dem schließenden Head-Tag, damit die Regeln auf jeder Seite greifen, die das Layout verwendet. Wickle das Skript in eine Liquid-Bedingung wie request.page_type ein, wenn du es nur auf bestimmten Templates haben willst. Dupliziere dein Theme und teste alles auf der unveröffentlichten Kopie, bevor du live gehst.
Prerendering kann Pageviews künstlich aufblähen, weil die Seite ihr JavaScript ausführt, bevor der Shopper sie überhaupt sieht. Google Analytics handhabt Prerender nativ, aber Custom Tracking, Chat-Widgets und A/B-Test-Skripte tun das in der Regel nicht. Schiebe diese hinter einen document.prerendering-Check und einen prerenderingchange-Listener, damit sie erst bei der Aktivierung (Activation) feuern.
Noch nicht. Die API funktioniert in Chrome und Edge ab Version 109, Opera ab 95 und Samsung Internet ab 21 und deckt so etwa 75 % des getrackten Traffics ab. Safari hat eine Implementierung, die (Stand 26.2) standardmäßig deaktiviert ist. Firefox hat sie nicht ausgeliefert und die Position von Mozilla zu dem Standard wird als neutral eingestuft. Browser ohne Unterstützung ignorieren das Script-Tag einfach, sodass nichts kaputtgeht.
Ja, wenn du für die falschen URLs Speculation nutzt. Jede Route, die bei einem GET-Request den Server-State ändert, ist unsicher. Dazu zählen Shopify-Rabatt-Links, die ein Cookie setzen, Logout-Query-Parameter, Cart-Permalinks und Add-to-Cart-Parameter. Schließe /cart-, /account-, /checkouts- und /discount-Pfade in deiner Regel aus, und zwar in der Root-Form und in der Form mit Locale-Prefix.
Öffne die Chrome DevTools, gehe in das Application-Panel und suche unter Background services nach Speculative loads. Dort ist jedes Regelset auf der Seite aufgelistet, jede darüber per Speculation geladene URL und das Ergebnis – inklusive Fehlergrund, falls zutreffend. Lade die Seite neu, nachdem du das Panel geöffnet hast. Für Field Data meldet der CrUX-Report Metriken, die nach Navigationstyp aufgeschlüsselt sind, einschließlich Prerender.
Footnotes
-
Chrome for Developers, “Prerender pages in Chrome for instant page navigations” - Bedingungen, unter denen Chrome Prerendering ablehnt, plus Eagerness-Trigger und Limits für Speculation pro Seite. https://developer.chrome.com/docs/web-platform/prerender-pages ↩
-
Performance @ Shopify, “Speculation Rules at Shopify” - plattformweiter Rollout Ende Juni 2025, mit einer durchschnittlichen Verbesserung von 130ms auf Desktop und 180ms auf Mobile über alle Perzentile und Lade-Metriken hinweg. https://performance.shopify.com/blogs/blog/speculation-rules-at-shopify ↩
-
Performance @ Shopify, “Faster storefront navigations with moderate speculation rules” - Median-Gewinne auf dem Desktop von 285ms TTFB, 224ms FCP und 228ms LCP nach dem Wechsel von conservative auf moderate eagerness, bei einem Anstieg der gesamten HTML-Requests um 14 % durch unterstützende Browser. https://performance.shopify.com/blogs/blog/faster-storefront-navigations-with-moderate-speculation-rules ↩
-
Can I Use, “Speculation Rules API” - ca. 75 % globale Unterstützung, mit Chrome und Edge ab 109, Opera ab 95 und Samsung Internet ab 21. https://caniuse.com/mdn-html_elements_script_type_speculationrules ↩