Speculation Rules

Kort fortalt: Speculation Rules er en deklarativ måde at fortælle browseren hvilke navigeringer den må optimere med prefetch og/eller prerender. Du beskriver reglerne i HTML (eller via JS), og browseren vælger selv om den vil udføre dem – typisk baseret på netværk, batteri, brugeradfærd og sikkerhed.

Hvad betyder Speculation Rules?

Når en bruger klikker på et link, starter browseren normalt først anmodningen efter klikket. Med Speculation Rules kan browseren starte forberedelsen før klikket, så næste side kan føles øjeblikkelig.

Der er to idéer (som ofte blandes sammen):

• Prefetch: hent ressourcer på forhånd, så download bliver kortere ved klik.
• Prerender: gå længere og forbered hele siden i baggrunden, så den i praksis kan “skifte” uden at lave hele arbejdet fra scratch.

I praksis er prerender den “kraftige” optimering, men også den der nemmest kan koste for meget.

Hvorfor er det vigtigt (og hvornår giver det mening)?

Speculation Rules er især interessant på sites hvor brugeren typisk klikker videre i en forudsigelig sti:

• Artikler der linker videre til en næste guide
• Kategorisider hvor brugeren næsten altid klikker på et af de første resultater
• Interne “hub”-sider (fx emnesider) hvor næste klik ofte er kendt

Hvis du allerede har fornuftig TTFB, caching (Cache-Control) og du har styr på render-blocking, kan Speculation Rules være et lag ovenpå der gør navigationen hurtigere – ikke kun første load.

Sådan ser det ud i praksis

Du kan definere regler i et <script type="speculationrules">-element. Eksemplet nedenfor er konceptuelt (brug kilden i bunden for korrekt syntax i din browser-version):

• vælg en snæver mængde links
• brug en konservativ strategi først (prefetch før prerender)
• mål effekten i virkelige flows, ikke kun på én side

Det vigtigste er ikke “at slå det til”, men at vælge hvilke sider der er realistiske næste klik.

Typiske fejl og misforståelser

1) “Prerender alt i menuen”

Det lyder fristende, men er ofte direkte skadeligt:

• På mobil kan du bruge CPU/batteri og skabe dårligere INP (fordi main thread får mere arbejde).
• Du kan bruge netværk på sider brugeren aldrig åbner.
• Du risikerer at konkurrere med downloads der er kritiske for den nuværende side (CSS, billeder, scripts).

Start småt: 1–3 sandsynlige næste klik.

2) “Hvis prerender er slået til, er LCP løst”

Nej. Prerender kan gøre næste side hurtigere at vise, men hvis selve skabelonen har tung rendering (fx dyre baggrunde, store billeder, render-blocking), er problemet der stadig. Prerender flytter bare hvornår arbejdet sker.

3) “Det kræver altid JavaScript”

Ideen med Speculation Rules er netop at gøre det mindre “script-hack”. Du kan beskrive regler uden at bygge et komplekst runtime-system – og browseren kan vælge at ignorere dem i uegnede situationer.

Hvordan du måler om det virker

For øvede giver det mening at kombinere:

• Chrome DevTools Performance for at se hvad der sker omkring navigationer
• Navigation Timing API og evt. Resource Timing API for timings
• Rigtige brugerflows (RUM) – se RUM hvis du vil måle bredt

Du leder efter lavere “click-to-render” på næste side – uden at nuværende side bliver tungere.

Relaterede begreber og næste skridt

• Prefetch og Prerender – beslægtede teknikker (og forskelle i risiko)
• Preload – når du vil prioritere en kritisk ressource (fx LCP-billede) snarere end hele dokumenter
• HTTP prioritet og fetchpriority – når du vil styre rækkefølgen på netværksarbejde
• Guides: start med Fjern render-blocking og brug derefter speculation til navigationer, når grundfundamentet er sundt