Speculation Rules API: Guide 2026

Q: Är Speculation Rules API säkert att använda i produktion 2026?

Ja. API:t har varit stabilt i Chrome och Edge sedan version 121, och driver redan instant navigation i WordPress core, Shopify Hydrogen och flera stora medieproducenter. Eftersom blocket ignoreras av icke-Chromium-webbläsare är det en ren progressiv förbättring utan risk för Firefox- eller Safari-användare.

Q: Räknas prerenderade sidor som visningar i Google Analytics 4?

Endast om du själv skickar event medan document.prerendering är true. Korrekt implementation skjuter upp page_view -eventet tills prerenderingchange fyrar. Då räknas det först när användaren faktiskt aktiverar sidan, inte under den passiva förrenderingen.

Q: Hur mycket bandbredd förbrukar prerender på mobil?

Chrome avstår automatiskt från prerender på Save-Data, Battery Saver och mätta nät. På normala 4G-anslutningar tillåter moderate -eagerness max 10 samtidiga prerenders, och varje förrenderad sida laddar samma resurser som en vanlig besökare (typiskt 200–800 kB beroende på sajt). Använd conservative för att skala ner.

Uppdaterad: 13 juni 2026

Speculation Rules API är en webbläsarstandard som låter dig instruera Chrome att prerendra eller prefetcha sannolika nästa sidor innan användaren klickar, vilket gör navigationen praktiskt taget omedelbar (LCP-värden under 100 ms är fullt realistiska). Du deklarerar reglerna i ett <script type="speculationrules">-block och Chrome hanterar resten i en separat renderprocess, helt isolerat från huvudtråden på den aktuella sidan. Så, i den här guiden visar jag exakt hur jag konfigurerar reglerna, väljer rätt eagerness-nivå och mäter den verkliga vinsten utan att förstöra analytics eller bränna mobil bandbredd.

Speculation Rules API är stabil i Chrome 121+ och driver i praktiken alla "instant"-navigeringar på t.ex. WordPress 6.6+ och stora e-handelssajter sedan 2025.
Prerender kör en hel sida i en dold flik (HTML, CSS, JS, layout, paint), medan prefetch bara hämtar HTML-svaret. Välj prerender för LCP-vinst, prefetch för bandbreddskontroll.
eagerness: "moderate" är min standardrekommendation: triggar på hover/pointerdown och balanserar träffsäkerhet mot resursförbrukning.
Använd No-Vary-Search-headern för att återanvända prerenders även när URL:er skiljer sig på spårningsparametrar som utm_*.
Mät alltid effekten med NotRestoredReasons, document.prerendering och Web Vitals. Annars vet du inte om reglerna faktiskt aktiveras.
Skjut upp analytics-pings, A/B-tester och annonsauktioner tills prerenderingchange-eventet fyrar, annars dubblerar du visningar.

Vad är Speculation Rules API?

Speculation Rules API är en deklarativ JSON-baserad mekanism där du talar om för webbläsaren vilka URL:er som är troliga nästa navigeringar, och hur aggressivt den får förbereda dem. Specifikationen definierar två typer av regler: prefetch (hämtar dokumentet med kompatibla headers) och prerender (utför en fullständig rendering av målsidan i en separat process). När användaren sedan klickar, "aktiveras" den förrenderade sidan och tar över den synliga fliken på några millisekunder. Det är därför LCP, FCP och TTFB rapporteras nästan på noll.

Den stora arkitekturella skillnaden mot gamla <link rel="prerender"> (som togs bort 2019) är att den nya implementationen kör i en helt isolerad render-process. Din nuvarande sidas huvudtråd märker ingenting av att Chrome bygger upp nästa sida i bakgrunden. Det betyder att du kan satsa hårt på prerender utan att förstöra INP-värdena på den aktuella sidan, vilket var en showstopper med den gamla API:n. Officiell dokumentation finns hos Chrome for Developers: Prerender pages in Chrome.

Hur fungerar prerender jämfört med prefetch?

Det här är frågan som avgör hela din konfiguration, så jag delar upp det på trådnivå. Prefetch gör en HTTP GET med Sec-Purpose: prefetch och cachar svaret i minnet. Det är billigt, ofta <30 kB för en typisk HTML-respons, och frigör inga huvudtrådscykler. När användaren klickar parsar och kör Chrome sidan precis som vanligt. Du sparar bara nätverkstiden.

Prerender går mycket längre. Chrome startar en hel renderprocess som hämtar HTML, exekverar all inline-JS och alla async/defer-script, bygger DOM och CSSOM, kör layout, målar och till och med pre-warmar Service Worker. När användaren klickar bytar webbläsaren bokstavligen ut den synliga sidan mot den färdigrenderade. LCP rapporteras typiskt på <100 ms eftersom det första "måleriet" redan har hänt.

Min tumregel: använd prerender för måste-vara-snabbt-sidor (kassan, sökresultat, primär artikelmall) och prefetch för bredare sannolika navigeringar (sekundära länkar i headern, kategorier). Då sänker du LCP där det betyder mest utan att spränga datapaketet.

Så konfigurerar du speculation rules steg för steg

Den enklaste implementationen är ett inline-block i <head>. Här är ett minimalt produktionsexempel som jag använder på en e-handelssajt. Det förrenderar produktsidor när användaren hovrar minst 200 ms över en länk, och prefetchar alla interna länkar med moderat aggressivitet.

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/product/*" },
          { "not": { "selector_matches": ".no-prefetch" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/admin/*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Strukturen är rak: top-level-nycklar prerender och prefetch innehåller arrayer av regler. Varje regel har antingen urls (lista av kandidater, kallas list rules) eller where (CSS-/URL-mönsterkriterier, kallas document rules). Document rules är överlägset mer skalbara eftersom de fungerar utan att du regenererar HTML när routing-strukturen ändras. MDN:s Speculation Rules API-referens har den fullständiga grammatiken.

Skicka reglerna via header eller separat fil

För större sajter undviker jag inline-JSON eftersom det bloatar varje sidsvar. Det finns två alternativ:

Lägg JSON i en separat fil och länka via Speculation-Rules-responsheader: Speculation-Rules: "/speculation-rules.json". CDN cachar JSON-filen, du redigerar reglerna på ett ställe.
Servera reglerna från en edge-funktion (Cloudflare Workers, Vercel Edge) som anpassar dem efter användartyp. T.ex. ingen prerender för inloggade admins, aggressiv prerender för anonyma besökare.

Vilken eagerness-nivå ska du välja?

Eagerness styr när webbläsaren faktiskt agerar på en regel. Fyra nivåer finns, och valet styr direkt din mobila bandbreddsförbrukning.

Eagerness	Trigger	Bandbredd	Användning
immediate	Så snart regeln tolkats	Mycket hög	Endast list rules med 1–2 säkra URL:er (t.ex. nästa steg i wizard)
eager	Pekaren närmar sig länken	Hög	Korta, kuraterade listor på desktop
moderate	Hover >200 ms eller pointerdown	Måttlig	Min standard för document rules
conservative	Endast pointerdown / touchstart	Låg	Mobil-tunga sajter, opålitliga nät

Chrome har också ett globalt tak: max 10 prerenders samtidigt med moderate/conservative, max 2 med eager och max 1 (per regel-block) med immediate. Om du överskriver gränsen släpper Chrome bara tysta de äldsta, och du får inget felmeddelande. Verifiera alltid i DevTools-fliken "Application → Speculative loads".

No-Vary-Search och spårningsparametrar

Den största praktiska fällan jag stött på (jag brände en hel eftermiddag på den första gången): en prerender för /product/42 matchar aldrig när användaren faktiskt klickar på /product/42?utm_source=newsletter. Som standard betraktar Chrome varje frågesträng som en ny URL, vilket gör att din kampanjtrafik aldrig drar nytta av prerender.

Lösningen är HTTP-respondheadern No-Vary-Search som signalerar vilka query-parametrar webbläsaren får ignorera när den matchar en prerender mot den klickade URL:en:

No-Vary-Search: params=("utm_source" "utm_medium" "utm_campaign" "utm_term" "utm_content" "gclid" "fbclid")

Med den headern återanvänds samma förrenderade dokument oavsett vilken UTM-tagg som kommer in. Jag sätter den globalt i edge för alla HTML-svar. Det är en av de billigaste prestandavinsterna jag känner till, och den spelar bra ihop med LCP-optimering för kampanjsidor. Du kan också använda params, except=("page") för att ignorera alla parametrar utom de uttryckligen listade.

Hur hanterar du analytics under prerendering?

Här gör de flesta team fel första gången, och det är därför många dashboards visar fördubblade pageviews efter en speculation-rules-utrullning. Under prerendering returnerar document.prerendering värdet true och alla synlighets-API:er rapporterar att sidan är dold. Om ditt analytics-bibliotek skickar en pageview vid script-load (vilket Google Analytics 4 och de flesta andra gör som standard), får du ett event per förrenderad sida även om användaren aldrig klickar.

Korrekt mönster: lyssna på prerenderingchange och skjut upp alla biverkningar tills sidan faktiskt aktiveras.

function sendPageview() {
  // Din vanliga analytics-anrop, t.ex. gtag('event', 'page_view')
  gtag('event', 'page_view', { page_path: location.pathname });
}

if (document.prerendering) {
  // Sidan är förrenderad, vänta tills aktivering
  document.addEventListener('prerenderingchange', sendPageview, { once: true });
} else {
  // Vanlig laddning eller redan aktiverad
  sendPageview();
}

Samma mönster gäller A/B-tester, annonsauktioner (header bidding), conversion pixels och allt annat som räknar "visningar". Lägg också till en visibilitychange-fallback ifall prerendern hinner ut innan användaren klickar. Då vill du inte rapportera något alls. För djupare bakgrund se web.dev: Prerender pages in Chrome for instant page loads.

Vilka webbläsare stöder Speculation Rules?

Stödet är fortfarande Chromium-baserat 2026, men det är inte ett problem i praktiken eftersom det fungerar som en ren progressiv förbättring. Webbläsare som inte stöder reglerna ignorerar bara <script type="speculationrules">-blocket.

Chrome (desktop & Android): Stabilt sedan version 121 (januari 2024). Document rules och No-Vary-Search stabila sedan Chrome 122.
Edge: Stabilt sedan version 121, samma kodbas som Chrome.
Opera, Brave, Samsung Internet: Stöd följer Chromium-uppströmsutgåvor.
Safari: WebKit har signalerat positivt intresse men ingen implementation har skeppats per juni 2026. Speculation Rules räknas inte mot Interop-arbetslistan 2026 än.
Firefox: Position "non-harmful" men inget aktivt utvecklingsarbete. Använd <link rel="prefetch"> som fallback för Firefox-baserade arbetsbelastningar.

Eftersom Chrome plus Edge står för >70 % av desktop- och >65 % av mobiltrafik globalt enligt StatCounter, är det helt motiverat att rulla ut Speculation Rules i produktion redan idag.

Så mäter du den verkliga prestandavinsten

Utan mätning vet du inte om reglerna aktiveras eller bara läses. Jag använder tre signaler parallellt.

1. Web Vitals med prerender-flagga

Biblioteket web-vitals (v4+) rapporterar automatiskt om en mätning kommer från en prerendrad navigation via metric.navigationType === 'prerender'. Skicka detta som en custom dimension till GA4 eller din egen telemetri:

import { onLCP, onINP, onCLS } from 'web-vitals';

function report(metric) {
  gtag('event', metric.name, {
    value: Math.round(metric.value),
    metric_id: metric.id,
    navigation_type: metric.navigationType, // "prerender" | "navigate" | "back-forward-cache"
  });
}

onLCP(report);
onINP(report);
onCLS(report);

Segmentera sedan dina dashboards på navigation_type. Du vill se medianskillnaden i LCP mellan vanliga och prerendrade navigeringar. På sajter där jag rullat ut detta brukar prerendrade LCP ligga på 50–200 ms medan vanliga navigationer ligger på 1500–2500 ms.

2. NotRestoredReasons för misslyckade prerenders

Om en prerender inte kunde aktiveras (t.ex. för att sidan satte cookies, ändrade URL eller använde inkompatibla API:er) rapporterar Chrome detta via Performance Navigation Timing API. Logga dessa orsaker, för de avslöjar varför din eagerness-träffsäkerhet är låg.

3. DevTools "Speculative loads"-panelen

Under utveckling: öppna DevTools → Application → Background services → Speculative loads. Den listar varje regel, om den triggat, statuskod, och eventuellt avvisningsskäl. Spendera tio minuter där innan du rullar till produktion. Honestly, det här steget sparade min senaste utrullning. Jag trodde reglerna aktiverades, men 40 % avvisades på cookie-skrivningar.

Vanliga fallgropar och hur du undviker dem

Efter flera utrullningar är detta de återkommande problemen:

Cookies satta under prerender invaliderar aktivering. Om din förrenderade sida sätter en cookie via Set-Cookie eller document.cookie kasseras prerendern vid klick. Skjut upp cookie-skrivningar tills prerenderingchange.
POST-formulär kan aldrig prerendras. Endast GET-navigeringar är giltiga kandidater. Filtrera bort POST-mål med where: { not: { ... } }.
Tunga tredjepartsskript dödar batteriet. En prerender kör allt, inklusive 200 kB av tag manager. Använd conservative-eagerness eller filtrera bort sidor med tung instrumentation.
Memory-cap på mobil. Chrome avbryter prerenders aggressivt på enheter med <2 GB RAM. Optimera först huvuddokumentets storlek och se min guide för JavaScript bundle-optimering.
CSRF-tokens som genereras per request. Om backend roterar tokens per request kommer prerenderns token inte att stämma vid faktisk POST. Använd session-baserade tokens eller regenerera vid prerenderingchange.

Vanliga frågor

Är Speculation Rules API säkert att använda i produktion 2026?

Ja. API:t har varit stabilt i Chrome och Edge sedan version 121, och driver redan instant navigation i WordPress core, Shopify Hydrogen och flera stora medieproducenter. Eftersom blocket ignoreras av icke-Chromium-webbläsare är det en ren progressiv förbättring utan risk för Firefox- eller Safari-användare.

Räknas prerenderade sidor som visningar i Google Analytics 4?

Endast om du själv skickar event medan document.prerendering är true. Korrekt implementation skjuter upp page_view-eventet tills prerenderingchange fyrar. Då räknas det först när användaren faktiskt aktiverar sidan, inte under den passiva förrenderingen.

Hur mycket bandbredd förbrukar prerender på mobil?

Chrome avstår automatiskt från prerender på Save-Data, Battery Saver och mätta nät. På normala 4G-anslutningar tillåter moderate-eagerness max 10 samtidiga prerenders, och varje förrenderad sida laddar samma resurser som en vanlig besökare (typiskt 200–800 kB beroende på sajt). Använd conservative för att skala ner.

Vad är skillnaden mellan Speculation Rules och <link rel="prefetch">?

<link rel="prefetch"> är en gammal hint som bara hämtar en resurs till HTTP-cachen. Det är ren nätverksspekulation. Speculation Rules API kan dessutom utföra fullständig prerender (parse + execute + paint), aktiverar via en isolerad process och har eagerness-strategier inbyggda. För nya implementationer rekommenderar jag alltid Speculation Rules över <link rel="prefetch"> där Chrome stöds.

Stöder Safari Speculation Rules API ännu?

Nej, inte per juni 2026. WebKit har markerat förslaget som "positivt" men ingen implementation har skeppats i Safari Technology Preview. Använd <link rel="prefetch"> som fallback om du behöver acceleration även för Safari-användare.