---
title: "Øjeblikkelig load tid med Speculation Rules API"
date: 2026-03-09
author: "Mads Unger"
featured_image: "https://pixelhouse.dk/wp-content/uploads/2026/03/Speculation-Rules-API.webp"
categories:
  - name: "Blog"
    url: "/category/blog.md"
tags:
  - name: "Digital Marketing"
    url: "/tag/digital-marketing.md"
  - name: "Hastighedsoptimering"
    url: "/tag/hastighedsoptimering.md"
  - name: "SEO"
    url: "/tag/seo.md"
---

# Øjeblikkelig load tid med 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:

- Hvis din butik tager længere end 3 sekunder at indlæse på mobil, bouncer 53 % af brugerne.
- [Hvert 100 millisekunder hurtigere indlæsning kan øge konverteringsraten (CVR) med ca. 7 %.](https://pixelhouse.dk/konverteringsoptimering/)

Shopify har allerede implementeret en meget basal version af Speculation Rules, som gav alle butikker ca. 180 ms [hurtigere indlæsning](https://pixelhouse.dk/ydelser/hastighedsoptimering/). 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.](https://web.dev/case-studies/milliseconds-make-millions)

[Læs om Shopifys implementering af Speculation Rules API](https://performance.shopify.com/blogs/blog/speculation-rules-at-shopify)

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](https://pixelhouse.dk/kontakt/) 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

```

				
					
				
			
```

Forbereder dine vigtigste sider. Meget lav risiko.

#### Eksempel 2: Smart automatisk prefetch af produktsider

```

				
					
				
			
```

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

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

```

				
					
				
			
```

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.

```

				
					

				
			
```

## 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.](https://web.dev/case-studies/rayban-speculation-rules?hl=en)

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.