Øjeblikkelig load tid med Speculation Rules API

Speculation Rules API

Indholdsfortegnelse

Load tid = flere salg

Forestil dig, du står i en fysisk butik og kassedamen er ekstremt langsom. Du bliver irriteret og går uden at købe noget. Det samme sker online: Når din webshop er langsom, forlader folk den før køb.

Fakta fra branchen:

Shopify har allerede implementeret en meget basal version af Speculation Rules, som gav alle butikker ca. 180 ms hurtigere indlæsning. Men med din egen tilpassede opsætning kan du opnå meget større gevinster, som er præcis tilpasset dine kunders adfærd. 

Læs om Googles studie på korrelationen mellem load tid og CVR.

Læs om Shopifys implementering af Speculation Rules API

Denne guide/blogindlæg vil for nogen være en smule teknisk, så ved spørgsmål er du mere end velkommen til at kontakte os eller eventuelt smide linket ind i Claude, Mistral eller en anden LLM og få den til at guide dig videre. 

Hvad er Speculation Rules API?

Det er som en hjælpsom robot, som gætter på, hvad kunden vil gøre næste gang og forbereder siden på forhånd.

Uden Speculation Rules: Kunden klikker → browseren downloader siden → siden vises (med load tid).

Med Speculation Rules: Browseren forudser klikket → downloader eller renderer siden i baggrunden → siden er klar med det samme.

Det er designet til multi-page apps som Shopify (ikke SPA’er). Det erstatter og forbedrer gamle metoder som <link rel=”prefetch”> og den udfasede <link rel=”prerender”>. Reglerne skrives som JSON i en <script type=”speculationrules”>-tag (i din theme.liquid) eller via HTTP-header Speculation-Rules.

Browseren tager den endelige beslutning: Den stopper ved batterisparetilstand, datasparetilstand eller langsom forbindelse.

I dag er det pt. kun Chrome og Edge, som understøtter Speculation Rules API. De andre browsere ignorerer det blot. 

Prefetch vs. Prerender: de to hovedtyper

Prefetch (den nemme og sikre måde)

Browseren downloader sidens HTML i baggrunden, men gør ikke mere. JavaScript kører ikke, siden renderes ikke. Resultatet gemmes i hukommelsen og er klar, når brugeren klikker.

Hastighedsgevinst: 300-800 ms hurtigere indlæsning.

Ressourceforbrug: Lavt. Velegnet til mange sider ad gangen.

Prefetch er dit standardvalg. Det er konservativt, sikkert og giver alligevel mærkbare forbedringer for brugeren.

Prerender (den superhurtige måde)

Browseren downloader, renderer og kører hele siden usynligt – inklusive JavaScript, billeder og data-fetch. Det svarer til at åbne en skjult browserfane. Når brugeren klikker, er siden allerede klar til at vises.

Hastighedsgevinst: 500–1.500 ms. Navigationen kan opleves som øjeblikkelig (under 50 ms).

Ressourceforbrug: Højt. Brug det kun på 1-3 sider, hvor sandsynligheden for klik er stor.

Et vigtigt detalje: prerenderede sider prefetches også automatisk som et forstadie. Begge typer gemmes i hukommelsen og frigives, når brugeren navigerer væk.

Fordele

  • Markant hurtigere navigation → flere køb, gladere kunder.
  • Fungerer på mange sider – f.eks. alle produktsider eller udvalgte samlinger.
  • Bedre end gamle metoder – mere intelligent, respekterer browser-indstillinger, lavere prioritet ved behov, og den bliver ikke blokeret af Cache-Control på samme måde.
  • Browseren styrer – ingen prefetch ved batterispare eller dataspare.

Ulemper og advarsler

  • Serverbelastning Hver prefetch/prerender tæller som en reel sidevisning. Ved 100 besøgende, der prefetcher 5 sider hver, bliver det 500 ekstra requests. På Shopify håndteres det fint, men prerender er værre (som at lave hele måltidet på forhånd).
  • Analytics bliver forkert Google Analytics tæller prefetch/prerender som rigtige besøg selvom kunden aldrig ser siden. Det ødelægger bounce rate, sidevisninger og konverteringstal.
  • Uheld kan ske Undgå farlige sider som logout, add-to-cart eller POST-handlinger. Det kan logge folk ud eller lægge varer i kurven ved et uheld. Vær forsigtig med “unsafe speculative loading conditions”.

Sådan implementerer du det i Shopify

Tilføj scriptet i theme.liquid (f.eks. før </body>). Husk CSP: Tillad ‘inline-speculation-rules’ hvis du har Content-Security-Policy.

Eksempel 1: Simpel og sikker prefetch

				
					<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["/collections/all", "/collections/bestsellers", "/cart"]
    }
  ]
}
</script>
				
			

Forbereder dine vigtigste sider. Meget lav risiko.

Eksempel 2: Smart automatisk prefetch af produktsider

				
					<script type="speculationrules">
{
  "prefetch": [
    {
      "where": {
        "and": [
          { "href_matches": "/products/*" },
          { "not": { "href_matches": "*variant_id=*" } }
        ]
      }
    }
  ]
}
</script>
				
			

Forbereder alle produktsider, men springer varianter med tracking over. Test det først.

Eksempel 3: Superhurtig prerender af én nøgleside HTML

				
					<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["/products/din-best-seller"]
    }
  ]
}
</script>
				
			

Kun til din mest besøgte side. Medium risiko, test grundigt.

Tip: Start med prefetch på sikre sider. Brug kun prerender hvor sandsynligheden for klik er høj.

Eksempel 4: Vær venlig mod serveren brug eagerness

De fire eagerness-niveauer (hvor aggressiv browseren er):

  • immediate: Starter prefetch/prerender med det samme (meget aggressiv, høj serverbelastning). Brug kun på få, sikre sider.
  • eager: Starter når browseren har lidt overskud (idle-tilstand). Balanceret valg for de fleste tilfælde.
  • conservative: Starter først ved brugerinteraktion (f.eks. hover med musen eller touch på mobil). Mest server-venlig – anbefales til at reducere belastning.
  • moderate: (ikke direkte nævnt i artiklen, men ofte brugt i praksis som mellemting – starter ved længere hover eller sandsynlig interaktion).

Anbefaling: Start med conservative på de fleste regler for at være god ved din server.

				
					<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["/collections/all"],
      "eagerness": "immediate"
    }
  ],
  "prerender": [
    {
      "urls": ["/products/bestseller"],
      "eagerness": "conservative"
    }
  ]
}
</script>

				
			

Ray-Bans CVR steg over 100%

Ray-Ban (med over 80 millioner besøgende årligt) implementerede prerendering på deres Product Detail Pages (PDP). Præcis som vi selv kan gøre i Shopify og andre CMS’er.

De brugte to strategier:

  • Desktop: Prerender ved hover over produktfliser (med “eagerness”: “moderate” og CSS-selector).
  • Mobil: Prerender de første 4 produkter automatisk (med “eagerness”: “immediate”).

Resultaterne var imponerende (målt via A/B-test og Adobe Analytics på Chrome-brugere):

  • LCP forbedret med 43 % på både mobil og desktop (Mobil: fra 4,69 s til 2,66 s | Desktop: fra 3,03 s til 1,74 s).
  • Konverteringsrate steg med 101 % på mobil og 156 % på desktop for prerenderede sider.
  • Exit rate faldt med ca. 13 % på begge enheder.
  • Sider pr. session steg med 52 % på mobil og 65 % på desktop.

Ray-Ban fik en næsten SPA-lignende oplevelse uden at skifte arkitektur. De udvidede siden hen og kombinerede med andre optimeringer som bfcache.

Læs Ray-Bans case her.

Det viser det kæmpe potentiale for forskellige webshops: næsten øjeblikkelig load tid, højere CVR, lavere bounce rate og bedre engagement – især på mobilen. Med de rigtige regler (start simpelt med prefetch, udvid til prerender på nøglesider) kan man opnå virkelig gode resultater og gøre sin butik markant mere konkurrencedygtig.

 

Tags
What do you think?