Speculation Rules API for WordPress og WooCommerce

I 2026 forventer brukere navigasjon under 2 sekunder. Hvert ekstra sekund med lastetid koster rundt 4,42 % av konverteringene (Portent); tallet på 7 % som går igjen, kommer fra Akamai og gjelder 100 millisekunder. Google vet dette og belønner raske nettsteder med høyere rangeringer.

Denne guiden er ikke teori. Det er fungerende kode og en sjekkliste du kan implementere i dag på WordPress-nettstedet eller WooCommerce-butikken din. Speculation Rules hjelper først når kassen og handlekurvfragmentene allerede er under kontroll. Hvordan du kommer dit, beskriver jeg i WooCommerce-ytelsesoptimalisering 2026.

#Hvordan lastetid påvirker avvisningsraten i 2026

#Avvisningsrate etter lastetid

Kilde: Google og SOASTA, benchmarks for mobil sidehastighet. Tallene er økningen i sannsynligheten for avvisning sammenlignet med ett sekund, ikke absolutte avvisningsrater. Think with Google

Google bekreftet: Core Web Vitals er en rangeringsfaktor. I 2024 ble FID erstattet av INP (Interaction to Next Paint), en metrikk som måler sidens respons på brukerinteraksjoner.

#Hva er oppfattet hastighet

Du kan ha en treg server (TTFB 800ms), men hvis brukeren ser innhold umiddelbart og navigasjon føles instant, er oppfattet ytelse utmerket.

Det er akkurat det Speculation Rules API gjør, den forhåndsinnlaster neste sider i bakgrunnen før brukeren klikker.

#Defer JavaScript, AVIF og TTFB i WordPress

Før du tar i bruk avanserte teknikker, må grunnmuren være på plass.

#Slik bruker du defer på JavaScript i functions.php

// functions.php - Utsett ikke-kritisk JS
add_filter('script_loader_tag', function($tag, $handle) {
    $defer_scripts = ['jquery', 'wp-embed', 'comment-reply'];
    if (in_array($handle, $defer_scripts)) {
        return str_replace(' src', ' defer src', $tag);
    }
    return $tag;
}, 10, 2);

#AVIF-støtte i WordPress 6.5+

WordPress 6.5+ støtter AVIF naturlig. AVIF gir 20-30% bedre komprimering enn WebP.

<img 
  src="product.avif" 
  srcset="product-400.avif 400w, product-800.avif 800w"
  sizes="(max-width: 600px) 400px, 800px"
  loading="lazy"
  decoding="async"
  alt="Product"
>

#Slik får du TTFB under 200 ms

#Slik retter du INP og CLS i WordPress

#Slik forbedrer du INP ved å dele opp lange oppgaver

INP blir dårligere når hovedtråden er blokkert. Typiske syndere:

• Tunge sidebyggere (Elementor, Divi)
• Chat-skript (Intercom, Zendesk)
• Sporingspiksler (Facebook, Google Ads)

Løsning: del opp lange oppgaver

// Del lange oppgaver i mindre biter < 50ms
async function longTask(items) {
    for (const item of items) {
        await processItem(item);
        // Gi kontrollen tilbake til hovedtråden
        await new Promise(resolve => setTimeout(resolve, 0));
    }
}

#Slik unngår du CLS fra bilder og annonser

/* Reserver plass til bilder */
img {
    aspect-ratio: 16 / 9;
    width: 100%;
    height: auto;
}

/* Reserver plass til annonser */
.ad-slot {
    min-height: 250px;
}

#Speculation Rules API med prefetch og prerender

Dette er kjernen i guiden. Speculation Rules API er en innebygd nettleserfunksjon som lar deg forhåndslaste sider i bakgrunnen.

#Prefetch-regel for alle interne lenker

<script type="speculationrules">
{
  "prefetch": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/wp-admin/*" } },
          { "not": { "href_matches": "*.pdf" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

#Prerender av handlekurv, kasse og produktsider

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/handlekurv/", "/kasse/"],
      "eagerness": "immediate"
    },
    {
      "source": "document",
      "where": {
        "or": [
          { "href_matches": "/produkt/*" },
          { "selector_matches": ".viktig-lenke" }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

#Forskjeller mellom prefetch og prerender

#Hva eagerness-nivåene betyr

• conservative: ved pointer down eller touch down, standard for dokumentregler
• moderate: på desktop etter 200 ms hover (eller ved pointer down hvis det skjer før); på mobil 500 ms etter at scrollingen stopper, for store lenker nær siste trykk
• eager: fra Chrome 143 etter 10 ms hover på desktop og 50 ms etter at en lenke kommer inn i viewport på mobil
• immediate: så snart nettleseren leser reglene, standard for listeregler

Tidene er hentet fra Chromes guide om prerendering. Før Chrome 143 oppførte eager seg som immediate, så eldre artikler som beskriver nivået som “umiddelbart og aggressivt”, omtaler den gamle oppførselen.

#Hva WordPress 6.8 gjør med spekulativ lasting som standard

Fra og med WordPress 6.8 er Speculation Rules API en del av kjernen. Funksjonen ble flyttet over fra utvidelsen Speculative Loading, som kjørte på over 50 000 nettsteder før sammenslåingen. Ifølge utviklernotatet for kjernen økte nettstedene som brukte den, andelen godkjente LCP-målinger med rundt 1,9 % i medianen, basert på data fra HTTP Archive og CrUX. Det samme notatet anslår at over 8 % av navigasjonene i Chrome allerede bruker speculation rules.

#Standardinnstillinger for spekulativ lasting i WordPress-kjernen

Rett ut av boksen skriver kjernen ut ett regelsett i frontend med modus prefetch og eagerness conservative. Begge lagres som auto, slik at en fremtidig versjon kan endre hva auto betyr uten å ødelegge konfigurasjonen din. Prefetch starter når brukeren trykker pekeren ned på en lenke. Det gir et lite forsprang på noen hundre millisekunder og koster nesten ingenting i bortkastede forespørsler.

Kjernen slår funksjonen av i tre tilfeller:

• for innloggede brukere, slik at verktøylinjen, forhåndsvisninger og adminlenker aldri spekuleres,
• på nettsteder uten pene permalenker,
• for URL-er med spørringsparametere, som er utelatt fra både prefetch og prerender som standard.

Den siste regelen er viktig for WooCommerce. Lenker for å legge varer i handlekurven bruker en spørringsstreng, så standardkonfigurasjonen henter dem aldri på forhånd. En utvidelse som eksponerer andre “handlings-URL-er” (GET-forespørsler som endrer tilstand), må fortsatt utelate dem selv, særlig hvis du skrur opp eagerness.

#Slik endrer du spekulativ lasting med WordPress-filtre

Kjernen tilbyr to filtre og én action. wp_speculation_rules_configuration mottar en matrise med mode og eagerness, eller null når spekulasjon er slått av for forespørselen. Gyldige moduser er auto, prefetch og prerender; gyldige eagerness-verdier er auto, conservative, moderate og eager. immediate avvises med vilje, fordi verdien frarådes sterkt for regler på dokumentnivå.

// Bytt kjerneregelen til prerender ved hover
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
    if ( is_array( $config ) ) {
        $config['mode']      = 'prerender';
        $config['eagerness'] = 'moderate';
    }
    return $config;
} );

// Hold personaliserte stier unna bare prerender
add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths, $mode ) {
    if ( 'prerender' === $mode ) {
        $paths[] = '/my-account/*';
    }
    return $paths;
}, 10, 2 );

// Legg til en ekstra regel ved siden av kjerneregelen
add_action( 'wp_load_speculation_rules', function ( WP_Speculation_Rules $rules ) {
    $rules->add_rule( 'prerender', 'shop-cart', array(
        'source'    => 'list',
        'urls'      => array( '/cart/' ),
        'eagerness' => 'moderate',
    ) );
} );

Filteret for utelatte stier tar mønstre i URL Pattern-syntaks, relativt til nettstedets frontend, og et valgfritt argument $mode. Actionen wp_load_speculation_rules gir deg et WP_Speculation_Rules-objekt, og add_rule() godtar både listeregler og dokumentregler med en where-betingelse. Returnerer konfigurasjonsfilteret null, er spekulasjon slått av for den forespørselen.

#Slik utelater du lenker med klassene no-prefetch og no-prerender

Redaktører kan utelate enkeltlenker uten kode. Legg til no-prefetch i feltet “Additional CSS class(es)” i blokkens avanserte panel for å holde lenkene helt utenfor spekulativ lasting, eller no-prerender for å tillate prefetch, men blokkere prerender. Siden prefetch er en del av prerender, dekker no-prefetch begge modusene. Dette er den raskeste løsningen når én widget, for eksempel en bookingkalender, oppfører seg rart etter en prerender.

#Innstillingene i Speculative Loading sammenlignet med kjernen

Utvidelsen Speculative Loading fra WordPress Performance Team finnes fortsatt og er mer aggressiv enn kjernen. Standarden er prerender med moderate eagerness, så en side rendres i bakgrunnen når brukeren holder pekeren over en lenke. Modus og eagerness stilles inn under Innstillinger, Lesing.

Utvidelsen advarer når du slår på spekulasjon for innloggede brukere uten vedvarende objektbuffer, fordi hver spekulerte side da koster en full PHP-forespørsel uten cache. Filteret for utelatelser heter plsr_speculation_rules_href_exclude_paths. I en WooCommerce-butikk med mye innlogget trafikk bør spekulasjon for innloggede brukere være av til en objektbuffer som Redis er på plass.

#Slik legger du til Speculation Rules i WordPress

#Metode 1: legg til reglene i en egen utvidelse

Fra WordPress 6.8 skriver kjernen allerede ut sitt eget speculationrules-skript. Et eget skript i wp_head legger til et regelsett nummer to ved siden av, så bruk denne metoden bare på eldre versjoner, eller slå først av kjerneregelen ved å returnere null fra wp_speculation_rules_configuration. På nyere versjoner er filtrene vist over den ryddigste veien.

<?php
/**
 * Plugin Name: Speculation Rules API
 */
add_action('wp_head', function() {
    if (is_admin()) return;
    ?>
    <script type="speculationrules">
    {
      "prefetch": [
        {
          "source": "document",
          "where": {
            "and": [
              { "href_matches": "/*" },
              { "not": { "href_matches": "/wp-*" } }
            ]
          },
          "eagerness": "moderate"
        }
      ]
    }
    </script>
    <?php
});

#Metode 2: dynamiske regler for handlekurv og paginering

add_action('wp_head', function() {
    $prerender_urls = [];
    
    // Prerender produktene i handlekurven
    if (function_exists('WC') && WC()->cart) {
        foreach (WC()->cart->get_cart() as $item) {
            $prerender_urls[] = get_permalink($item['product_id']);
        }
    }
    
    // Prerender neste arkivside
    if (is_archive() || is_home()) {
        $next_link = get_next_posts_link();
        if ($next_link) {
            preg_match('/href="([^"]+)"/', $next_link, $matches);
            if (!empty($matches[1])) {
                $prerender_urls[] = $matches[1];
            }
        }
    }
    
    if (empty($prerender_urls)) return;
    
    $rules = [
        'prerender' => [[
            'source' => 'list',
            'urls' => array_unique($prerender_urls),
            'eagerness' => 'moderate'
        ]]
    ];
    
    echo '<script type="speculationrules">' . json_encode($rules) . '</script>';
});

#Resultater med Speculation Rules i en WooCommerce-butikk og en blogg

#Case 1: WooCommerce-butikk (500 produkter)

Problem: Navigasjon fra kategori til produkt tok flere sekunder

Løsning:

• Prefetch for lenker i viewport
• Prerender for “Legg i handlekurv” og “Kasse”

Resultat:

• Før: flere sekunder med venting
• Etter: oppfattet som instant
• Avvisningsrate: falt merkbart

#Case 2: WordPress-blogg (over 1000 artikler)

Problem: INP utenfor det grønne området, brukerne merket at siden “hang”

Løsning:

• Defer på alle skript
• Prerender for “Les mer”
• Object Cache (Redis)

Resultat:

• INP: flyttet inn i det grønne området
• LCP: flyttet inn i det grønne området
• Organisk trafikk: økte

#Begrensninger i Speculation Rules og sider å unngå

#Hvilke sider du ikke bør prerendre

• Sider med autentisering (login, brukerpanel)
• Sider med sideeffekter (abonnementer, betalinger)
• Eksterne URL-er

#Data Saver, nettleserstøtte og grensen for prerender

• Data Saver slår av spekulasjon, se hele listen over blokkerende forhold nedenfor
• Nettlesere uten støtte (Firefox, og Safari uten det eksperimentelle flagget) ignorerer reglene
• Grense for prerender: Chrome tillater 10 prerenders for immediate-regler og bare 2 for eager, moderate og conservative, der den eldste fjernes først

#Grenser for spekulasjon i Chrome per eagerness-nivå

Chrome begrenser hvor mange spekulasjoner en side kan ha samtidig, og grensen avhenger av eagerness. Tallene under kommer fra Chromes guide om prerendering.

For de tre nivåene som styres av brukerens handlinger, fungerer køen etter prinsippet først inn, først ut: en ny spekulasjon avbryter den eldste. En avbrutt URL kan spekuleres igjen senere, og ressursene som kan caches, ligger som regel fortsatt i HTTP-cachen. Fjerner du et skript med listeregler fra siden, frigjøres kapasitet for immediate. Det er nyttig når en regel for handlekurven skal vike for en annen regel etter kassen.

#Når Chrome ignorerer speculation rules

Speculation rules er et hint, og Chrome dropper dem når:

• brukeren har slått på Save-Data,
• strømsparing er på og batteriet er lavt,
• enheten har lite minne,
• innstillingen “Preload pages” er av, noe enkelte utvidelser som uBlock Origin gjør,
• siden er åpen i en bakgrunnsfane.

Prerendrede sider holder også tilbake iframes fra andre opphav til aktivering, så et innebygd kart eller en videospiller lastes først når brukeren kommer til siden. Speculation rules inne i en prerendret side behandles etter at siden er aktivert, og regler i iframes ignoreres.

#Prefetch som reserveløsning for nettlesere uten støtte

if (!HTMLScriptElement.supports?.('speculationrules')) {
    // Reserveløsning: klassisk prefetch
    document.querySelectorAll('a[href^="/"]').forEach(link => {
        link.addEventListener('mouseenter', () => {
            const prefetch = document.createElement('link');
            prefetch.rel = 'prefetch';
            prefetch.href = link.href;
            document.head.appendChild(prefetch);
        }, { once: true });
    });
}

#Slik gjør du WooCommerce-sider trygge for prerender

En prerendret side kjører JavaScript før brukeren ser den. Det er derfor den føles umiddelbar, og det er også derfor den kan ødelegge en nettbutikk hvis koden forutsetter et ekte besøk.

#Hvilke WooCommerce-URL-er som ikke tåler prefetch eller prerender

MDN regner URL-er med sideeffekter på serveren som utrygge for både prefetch og prerender: utlogging, språkbytte, legg i handlekurv, utsending av engangskoder på SMS, forbruk av brukskvoter og sporing av annonsekonverteringer. I en WooCommerce-butikk gjelder det utloggingslenken under Min konto, en valuta- eller språkvelger laget som GET-lenke, og enhver egen “kjøp nå”-URL. Sider er i tillegg utrygge å prerendre når skriptene deres skriver til lagring i nettleseren som andre åpne faner leser, eller når de sender analysedata eller annonsevisninger før brukeren har sett siden.

Prerendrede sider kan også bli utdaterte. En side som ble prerendret mens besøkeren var utlogget, viser fortsatt utlogget visning hvis besøkeren logger inn i en annen fane. Chrome kan beholde en side hentet med prefetch i rundt fem minutter, så innholdet kan være så gammelt når det vises.

#Slik tømmer du spekulerte sider etter legg i handlekurv

Svarheaderen Clear-Site-Data godtar verdiene prefetchCache og prerenderCache. Sendt på en hvilken som helst forespørsel på samme nettsted, for eksempel AJAX-kallet som legger et produkt i handlekurven, forkaster den spekulasjoner gjort før handlekurven endret seg. Neste hover henter da en fersk handlekurv eller kasseside i stedet for å vise den gamle.

// Forkast utdaterte spekulasjoner etter at WooCommerce endrer handlekurven
add_action( 'woocommerce_add_to_cart', function () {
    if ( ! headers_sent() ) {
        header( 'Clear-Site-Data: "prefetchCache", "prerenderCache"' );
    }
} );

#Slik gjenkjenner du spekulative forespørsler på serveren

Chrome merker spekulative forespørsler med forespørselsheaderen Sec-Purpose. En prefetch sender Sec-Purpose: prefetch, en prerender sender Sec-Purpose: prefetch;prerender. Ethvert endelig svar utenfor området 200 til 299, etter omdirigeringer, stopper spekulasjonen, og status 204 eller 205 stopper en prerender, men tillater fortsatt en prefetch. Å returnere en feil er den groveste måten å blokkere spekulasjon for en rute på. MDN anbefaler heller å tillate forespørselen og utsette sideeffektene i JavaScript, fordi en blokkert spekulasjon er en tapt hastighetsgevinst.

#Slik utsetter du analyse til en prerendret side vises

document.prerendering er true mens siden rendres i bakgrunnen, og hendelsen prerenderingchange utløses når brukeren aktiverer den. Pakk inn analyse, annonsevisninger og alt annet som skal telle en ekte visning:

function initTracking() {
    // analyse, annonsevisninger, chat-widgeter
}

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

Flere nettleser-API-er venter selv på aktivering. Ifølge MDN returnerer geolokasjon, forespørsler om varslingstillatelse, registrering av service worker og kameratilgang et ventende promise til siden vises, mens alert() returnerer med en gang og confirm() returnerer false. Kode som er avhengig av disse resultatene mens siden lastes, trenger den samme sjekken.

#Nettleserstøtte for Speculation Rules i 2026

Versjonene kommer fra MDNs data om nettleserkompatibilitet, som fortsatt merker funksjonen som eksperimentell og ikke Baseline. I praksis gjør reglene Chromium-brukernes navigasjon raskere og har ingen effekt ellers, og derfor behandler WordPress-kjernen dem som progressiv forbedring.

#Slik bruker du Speculation Rules med Content Security Policy

#Slik tillater du speculation rules under en streng CSP

En blokk med speculation rules er et <script>-element, så en streng script-src-policy blokkerer den som et hvilket som helst inline-skript. MDN nevner tre måter å tillate den på: en nonce, en hash eller nøkkelordet 'inline-speculation-rules'. Chromes guide legger til at nøkkelordet dekker regler som settes inn med hash eller nonce, så på nettsteder med streng CSP settes reglene som regel inn med JavaScript. Viser panelet Speculative loads ingen regler på et nettsted med en sikkerhetsutvidelse, er CSP-headeren det første du bør sjekke.

#Slik leverer du speculation rules med headeren Speculation-Rules

Reglene kan også ligge i en JSON-fil som det vises til i en HTTP-svarheader. Da holdes de utenfor HTML-en og utenfor CSP-problemet. URL-en i headeren må stå i anførselstegn, filen må ha MIME-typen application/speculationrules+json, og en fil fra et annet opphav må bestå en CORS-sjekk. Som standard tolkes relative URL-er i filen ut fra JSON-filen, så legg til "relative_to": "document" i en regel hvis stiene er relative til siden.

Speculation-Rules: "/speculationrules.json"

Regler fra headeren og inline-regler slås sammen til ett sett. Chrome 136 innførte feltet tag, som sendes i forespørselsheaderen Sec-Speculation-Tags, slik at et CDN eller en server kan se hvilket regelsett som utløste en forespørsel, og behandle den annerledes.

#Hvilke spekulasjoner på tvers av opphav Chrome tillater

Prerender er som standard begrenset til samme opphav. Et underdomene på samme nettsted, for eksempel en nettbutikk på eget underdomene, kan bare prerendres hvis det svarer med headeren Supports-Loading-Mode: credentialed-prerender, og prerender på tvers av nettsteder er ikke mulig i det hele tatt. Prefetch på tvers av nettsteder fungerer bare når brukeren ikke har informasjonskapsler for målnettstedet, noe som hindrer sporing. Avviste spekulasjoner av denne typen vises i panelet Speculative loads i DevTools.

#Slik overvåker du prefetch med Speculation Rules

#Verktøy for å sjekke spekulativ lasting

• Chrome DevTools: panelet Speculative loads i fanen Application
• Lighthouse CI: automatiserte ytelsestester
• WebPageTest: reelle tester fra ulike steder
• DebugBear: Real User Monitoring (RUM)

#Slik sporer du spekulative treff i GA4

Resource Timing har ingen initiatortype for spekulasjon, så en spekulativ lasting kan ikke observeres fra siden som utløste den. Mål heller på siden brukeren lander på: activationStart over null betyr at siden ble prerendret, og deliveryType med verdien navigational-prefetch betyr at den kom fra en prefetch. Begge feltene er dokumentert hos MDN.

// Rapporter hvordan den nåværende siden ble levert
const nav = performance.getEntriesByType('navigation')[0];
let delivery = 'normal';
if (nav.activationStart > 0) {
    delivery = 'prerender';
} else if (nav.deliveryType === 'navigational-prefetch') {
    delivery = 'prefetch';
}
gtag('event', 'page_delivery', { delivery_type: delivery });

Sammenlign antall treff for prerender og prefetch med antall spekulative forespørsler i serverloggene (se headeren Sec-Purpose over). Differansen er sløsingen. Ifølge Chromes guide om prerendering måler Chrome Core Web Vitals for en prerendret side fra aktiveringen, ikke fra starten av prerenderingen, og biblioteket web-vitals fra versjon 3.1.0 rapporterer slike navigasjoner med navigationType lik prerender. Segmenter feltdataene etter den verdien, ellers skjuler den nesten nullverdige LCP-en i prerendrede visninger en treg vanlig navigasjon.

#Sjekkliste for Speculation Rules i WordPress

#Før implementering

• Mål grunnleggende Lighthouse-score
• Sjekk TTFB < 200ms
• Object Cache er aktivt
• Bilder leveres som AVIF

#Under implementering

• Legg til grunnleggende prefetch (moderate)
• Analyser heatmaps (Hotjar, Clarity)
• Identifiser topp 3 navigasjonsstier
• Legg til prerender for high-intent lenker
• Test på 10 % av trafikken (A/B)
• Overvåk “bortkastede” prefetches

#Etter implementering

• Sammenlign LCP, INP og navigasjonstid
• Sjekk cache hit ratio
• På lang sikt: avvisningsrate og konverteringsrate

#Oppsummering

Speculation Rules API er en stor endring for 2026. Ved å forhåndslaste sider i bakgrunnen blir navigasjon instant, uten infrastrukturendringer.

Viktigste punkter:

1. Start med prefetch med moderate eagerness, det er trygt
2. Legg til prerender for checkout-flyten i e-handel
3. Overvåk metrikker, ikke gjett, mål

Trenger profesjonell optimalisering? Som WordPress-spesialist hjelper jeg med å gjøre WordPress og WooCommerce-sider raskere. Se også WordPress hastighetsoptimalisering.