So nutzt du die Speculation Rules API bei Shopify

Das Wichtigste in Kürze

• Shopify liefert bereits Speculation Rules auf jeder Storefront aus. Es sendet einen Speculation-Rules-Response-Header, der auf eine JSON-Datei verweist. Diese prefetched Produkt-, Kategorie-, Seiten-, Such-, Blog- und Richtlinien-URLs mit einer moderate Eagerness.
• Shopify nutzt nur Prefetch. Es wird nie gerendert (Prerender). Deine eigene prerender-Regel in der theme.liquid hinzuzufü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 komplette Seite in einem versteckten Tab, inklusive Sub-Ressourcen und JavaScript. Prerender ist weitaus schneller, aber auch deutlich ressourcenintensiver, setze es also gezielt ein.
• eagerness steuert den Auslöser: immediate, eager, moderate (200 ms Hover auf dem Desktop) und conservative (Mausklick/Touch). Document Rules stehen standardmäßig auf conservative, List Rules auf immediate.
• Die echten Risiken bei Shopify sind Nebenwirkungen beim Warenkorb und bei Rabatten, doppelt gezählte Analytics und Drittanbieter-Skripte, die feuern, bevor der Käufer überhaupt auf der Seite ist. Schließe Pfade wie /cart, /account, /checkouts und /discount aus und blockiere Analytics hinter einem document.prerendering-Check.

Die Speculation Rules API ermöglicht es einer Webseite, dem Browser mitzuteilen, welche URLs der Besucher wahrscheinlich als Nächstes öffnen wird, sodass der Browser diese im Voraus abrufen (prefetch) oder vollständig rendern (prerender) kann. Bei Shopify ist das eine der wenigen verbleibenden Möglichkeiten, damit sich die Navigation wirklich sofort („instant“) und nicht nur schnell anfühlt.

Die meisten Leitfäden zu Speculation Rules gehen davon aus, dass du bei null anfängst. Bei Shopify ist das nicht der Fall. Die Plattform injiziert bereits ein Regelwerk für dich. Die eigentliche Aufgabe besteht darin, zu wissen, was es abdeckt, was es absichtlich auslässt und was du in der theme.liquid gefahrlos noch obendrauf packen 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 ist ein JSON-Block innerhalb eines <script type="speculationrules">-Tags. Das JSON benennt URLs – oder ein Muster, das auf Links im Dokument zutrifft – und sagt dem Browser, dass er sie per prefetch oder prerender laden soll.

<script type="speculationrules">
{
  "prerender": [
    { "where": { "href_matches": "/products/*" }, "eagerness": "moderate" }
  ]
}
</script>

Das ersetzt die alten Resource Hints. <link rel="prefetch"> hat lediglich den HTTP-Cache aufgewärmt und dir keine Kontrolle über das Timing gegeben. <link rel="prerender"> wurde nie konsistent implementiert und gilt als veraltet (deprecated). Speculation Rules bieten dir Pattern-Matching, Ausnahmen, spezifische Trigger pro Regel und definierte Einschränkungen dafür, was eine spekulierte Seite tun darf.

Die Regeln sind ein Hinweis, kein Befehl. Ein Browser, der das Script-Tag nicht versteht, ignoriert es. Chrome selbst lehnt Speculation ab, wenn Save-Data aktiv ist, wenn der Arbeitsspeicher des Geräts knapp ist, wenn der Energiesparmodus bei schwachem Akku aktiv ist oder wenn der User das Vorladen von Seiten in den Einstellungen deaktiviert hat.¹ Nichts geht kaputt, wenn keine Speculation stattfindet. Der Besucher bekommt einfach eine ganz normale Navigation.

Prefetch vs. Prerender

Prefetch ist der sichere Standard. Prerender ist das, was für die extremen Zahlen sorgt – aber auch das, was alle Risiken in diesem Guide mit sich bringt.

Welche Speculation Rules führt Shopify bereits aus?

Shopify hat Speculation Rules Ende Juni 2025 plattformweit eingeführt und eine durchschnittliche Verbesserung von 130 ms auf dem Desktop und 180 ms auf Mobilgeräten über alle Perzentile und Lade-Metriken hinweg gemeldet, was TTFB, FCP und LCP zusammengenommen bedeutet.²

Die Regeln befinden sich nicht in deinem Theme. Shopify sendet einen Speculation-Rules-Response-Header, der auf eine JSON-Datei in ihrem CDN verweist, ausgeliefert als application/speculationrules+json. Wenn du diese Datei bei einer aktiven Storefront abrufst, erhältst du das aktuelle Regelwerk 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 aus diesem Block sind besonders wichtig.

Es ist reines Prefetching. Es gibt darin nirgendwo einen prerender-Key. Shopify lädt das Dokument frühzeitig herunter und sonst nichts.

Es ist eine Allowlist, keine Blocklist. Nur Produkte, Kategorien (Collections), Seiten, die Suche, Shop, Blogs, Richtlinien und die Startseite werden abgeglichen – jeweils in der Stamm-Version und mit eventuellem Markt-Präfix. Warenkorb-, Konto- und Checkout-URLs passen auf keines der Muster, also werden sie niemals spekuliert.

Die Eagerness steht auf moderate. Shopify begann mit conservative und hob den Standard später an. Das führte zu Median-Verbesserungen auf dem Desktop von 285 ms beim TTFB, 224 ms beim FCP und 228 ms beim LCP, wobei rund 10 % der spekulierten Navigationen mit einem TTFB von 0 ms ankamen. Auf dem Smartphone waren die Verbesserungen mit ca. 25 ms, 20 ms und 24 ms deutlich geringer. Die Kehrseite war ein Anstieg der HTML-Gesamtanfragen um 14 % durch unterstützende Browser.³

Shopifys Theme-Performance-Dokumentation bestätigt, dass Themes eigene Regeln darüber hinaus hinzufügen dürfen. Dein Job ist es also nicht, Prefetching neu zu implementieren, sondern zu entscheiden, wo Prerendering seinen Aufwand wert ist.

Eagerness-Level und welches du wählen solltest

eagerness ist der Auslöser, nicht die Priorität. Es beantwortet die Frage: “Wann reagiert der Browser auf diese Regel?”

Mobile Geräte haben kein Hover, also greift Chromium hier auf Viewport-Heuristiken zurück. eager wird auf dem Smartphone kurz nachdem ein Anker im Viewport erscheint ausgelöst (ein Verhalten, das sich in Chrome 143 geändert hat; davor verhielt sich eager wie immediate). moderate wartet auf mobilen Geräten, bis das Scrollen aufhört.

Die Standardwerte hängen vom Regeltyp ab. Eine List Rule mit urls ist standardmäßig immediate. Eine Document Rule mit where ist standardmäßig conservative. Wenn du eine Document Rule schreibst und eagerness vergisst, bekommst du das vorsichtigste Verhalten, was normalerweise nicht das ist, was du wolltest.

Für eine Shopify-Storefront ist moderate ein vernünftiger Startpunkt für Prerendering. Ein immediate-Prerender auf einer Collection-Seite würde versuchen, bis zu zehn Produktseiten zu rendern, die der Käufer vielleicht nie öffnet – und das auf einem Endgerä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 gleichen Links ab, die sich bereits auf der Seite befinden, indem sie where nutzen. Sie eignen sich perfekt für eine Storefront, auf der die interessanten URLs durch Liquid generiert werden und sich pro Seite ändern.

href_matches nutzt die URL Pattern-Syntax. Ein * steht also für einen Wildcard und {...}? markiert eine optionale Gruppe. selector_matches nimmt einen CSS-Selektor entgegen, womit du einzelne Links über eine Klasse von der Regel ausschließen kannst. Beide akzeptieren Arrays und können mit and, or und not verknüpft werden.

Diese Kombination macht Ausnahmen überhaupt erst praktikabel. Du kannst sagen: “Jeder Link auf der Seite, außer denen, die den Server-State verä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 erschien zuerst in Chrome 109, und Edge, Opera sowie Samsung Internet zogen über dieselbe Engine nach.

Der weltweite Support liegt bei ca. 75 % des getrackten Traffics.⁴ Für einen Shopify-Store, dessen Traffic stark iOS/Safari-lastig ist, fällt die nutzbare Quote naturgemäß niedriger aus. Das ist aber eher ein Grund dafür, die Ressourcenkosten deiner Regeln gering zu halten, und kein Grund, sie ganz wegzulassen.

Browser ohne Support ignorieren das Script-Tag vollständig. Du brauchst keinen Polyfill, keinen Fallback und es gibt keine Nachteile – bis auf die paar Hundert Bytes an zusätzlichem Markup.

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 gerenderte (prerendered) Seite führt ihr JavaScript aus, bevor der Käufer sie überhaupt gesehen hat. Wenn du nichts dagegen unternimmst, treibt das die Pageviews künstlich in die Höhe und verfälscht in Folge jede Rate.

Die Lösung ist, alles, was Daten aufzeichnet oder feuert, bis zur echten Aktivierung zu verzögern:

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

Google Analytics unterstützt Prerender nativ. Custom-Tracking, Chat-Widgets, Popup-Timer und Skripte für A/B-Tests tun das im Allgemeinen nicht. Prüfe daher sorgfältig die Skripte deines Themes, bevor du Prerendering aktivierst. Wenn dir die Skripte in deinem Theme unbekannt vorkommen, ist unser Guide zu Render-Blocking-Skripten in Shopify eine gute Möglichkeit, sie einmal komplett 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