Lynraske sider med Speculation Rules

Lær hvordan du kan forbedre Core Web Vitals ved å få sider til å laste øyeblikkelig med det nye Speculation Rules API-et

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-07

Forbedre Core Web Vitals øyeblikkelig med 'Speculation Rules API'

Har du noen gang lurt på hvorfor noen sider ser ut til å laste øyeblikkelig? Det er sannsynligvis fordi den siden har implementert Speculation Rules!

Speculation Rules API forbedrer hastigheten på fremtidige sidelastinger i flersidesapplikasjoner (MPAs) ved enten å forhåndshente eller til og med forhåndsrendere dem. Utviklere kan konfigurere speculation rules for å foreslå at nettleseren forhåndshenter eller forhåndsrenderer dokumenter for raskere (eller øyeblikkelige) sidelastinger. Speculation rules erstatter eldre teknikker som `<link rel="prefetch">` for forhåndshenting av ressurser eller den utdaterte Chrome-eksklusive funksjonen `<link rel="prerender">`.

Speculation rules fungerer på dokumentnivå, noe som gjør det egnet for MPAs som involverer fullstendige sidenavigasjoner. Enkeltsideapplikasjoner (SPAs) som primært bruker API-kall eller delvise innholdsoppdateringer ville ikke ha like stor nytte av dette API-et for sine interne ruteendringer. Imidlertid kan Speculation Rules fortsatt være nyttige for SPAs ved å forhåndsrendere applikasjonens opprinnelige tilstand fra en landingsside, noe som potensielt kan kompensere for den innledende lastetiden.

Speculation rules hurtigstart

Vet du allerede hva speculation rules er? Flott! Her er noen klare kodesnutter du kan bruke med en gang. Bare velg den riktige kodesnutten for deg og plasser den i <head> på siden din (du kan gjerne endre preload til prefetch og/eller eagerness)! 

<!-- 
   WordPress speculation rules av corewebvitals.io 
   forhåndshenter alle interne lenker
   hopper over lenker som matcher wp-login, wp-admin, wp content 
   hopper over lenker som har nofollow-attributtet
   hopper over lenker som har en spørringsstreng, for eksempel: /search->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "and": [{ "href_matches": "\/*"},{ "not": {     "href_matches": [         "\/wp-login.php",         "\/wp-admin\/*",         "\/*\\?*",         "\/wp-content\/*",     ] }
                },{ "not": {     "selector_matches": "a[rel~=\\\"nofollow\\\"]" }
                }]
        },
        "eagerness": "moderate"
    }]
}
</script>
<!-- Data-preload-utløste speculation rules av corewebvitals.io -->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "selector_matches": "a[data-preload]"
        },
        "eagerness": "moderate"
    }]
}
</script>

Tips: trenger du raskt å bygge dine egne speculation rules? Hvorfor ikke prøve speculation rules-generatoren

Fordeler med Speculation Rules


Forbedret user experience (UX): Ved å forutsi og forhåndslaste innhold sikrer Speculation Rules nesten øyeblikkelige sidelastinger, noe som gjør navigasjon sømløs for brukerne. Dette matcher ytelsen til enkeltsideapplikasjoner selv for tradisjonelle flersidesnettsteder uten kompleksiteten og JavaScript-avhengigheten. Raskere lastetider betyr en bedre nettleseropplevelse, som sannsynligvis øker brukerengasjement og reduserer fluktfrekvens.

SEO-fordeler: Siden forbedret sidehastighet er en direkte rangeringsfaktor og en bedre Time to First Byte vil resultere i en bedre Largest Contentful Paint, vil implementering av speculation rules garantert forbedre Core Web Vitals og gi deg den hastighetsbonus i søkeresultatene.

Redusert kompleksitet: Nesten øyeblikkelige sidelastinger var tidligere mulig ved å bruke en SPA eller skrive tilpasset forhåndshentingslogikk for MPAs.
For mange brukstilfeller er ulempen med en SPA den innledende oppstartstiden, som kan være betydelig siden de er tungt avhengige av JavaScript, og den økte kompleksiteten sammenlignet med en MPA. Speculation rules har ikke disse problemene. Dette gjør raske sidelastinger oppnåelige for et bredere spekter av nettsteder, spesielt innholdsfokuserte.
API-et forenkler også prosessen med å bestemme hvilke sider som skal forhåndsrenderes ved å delegere mye av logikken til nettleseren. Dette er en stor forbedring sammenlignet med tidligere metoder som var avhengige av JavaScript for å utføre disse sjekkene og injisere sider for forhåndslasting. Nettlesere kan nativt ta hensyn til brukerkontekst, som lite minne på mobilenheter eller batterisparemodus, når de bestemmer om de skal forhåndsrendere. Denne dynamiske tilpasningen bidrar til å spare brukerressurser og sikrer en jevnere opplevelse selv under begrensninger.

Andre fordeler: Speculation-Rules HTTP-headeren gjør det enklere å distribuere via Content Delivery Networks (CDNs), og eliminerer behovet for å endre dokumentinnholdet direkte. Granulær kontroll med dokumentregler lar utviklere definere presise betingelser for forhåndshenting eller forhåndsrendering basert på URL-mønstre eller CSS-selektorer. Dette reduserer manuell URL-spesifisering og muliggjør speculation-regelsett for hele nettstedet. «eagerness»-innstillingen gir finkornet kontroll over når spekulasjon skjer, og balanserer forhåndslastingshastighet med ressursforbruk. Dette bidrar til å redusere unødvendig forhåndslasting og forhindrer ressurssløsing.

Mekanikken bak Speculation Rules

Speculation rules defineres ved hjelp av en JSON-struktur og kan implementeres på to måter:

  • Inline-skript: Inkluder JSON-en i en `<script type="speculationrules">`-tagg enten i `<head>` eller `<body>` i hoveddokumentet HTML.
  • HTTP-header: Lever reglene ved hjelp av `Speculation-Rules` HTTP-headeren i dokumentets respons. Denne headeren peker til en JSON-fil som inneholder reglene, noe som forenkler CDN-distribusjon uten å endre HTML-innholdet direkte.

JSON-strukturen bruker «prefetch»- og «prerender»-arrayer for å inneholde regler for hver type spekulativ lasting. Hver regel kan bruke forskjellige kilder: enten en liste med URLer eller dokumentregler

  • urls (en liste med URLer) En array med URLer som skal forhåndshentes eller forhåndsrenderes.
  • where (dokumentregler) Et objekt som bruker betingelser for å bestemme hvilke lenker på siden som skal forhåndshentes eller forhåndsrenderes.

Hver regel er definert som et objekt som inkluderer egenskaper som:

  • requires En array med strenger for å sette begrensninger på spekulasjoner. For øyeblikket er den eneste gyldige strengen «anonymous-client-ip-when-cross-origin», som indikerer at en forhåndshenting på tvers av opprinnelser skal anonymisere klientens IP-adresse.
  • target_hint En streng som gir et hint om det navigerbare målnavnet, slik at nettleseren kan optimalisere lasteprosessen. Det har ingen normative implikasjoner utover å være et hint.
  • referrer_policy En referrer-policy som skal brukes på forhåndshentede eller forhåndsrenderte URLer.
  • relative_to (Kun for «list»-kilde) Spesifiserer om URLene i «urls»-arrayen er relative til dokumentets basis-URL («document») eller plasseringen til speculation rules JSON-filen («ruleset»).
  • eagerness Kontrollerer hvor aggressivt nettleseren skal forhåndshente eller forhåndsrendere. De tilgjengelige innstillingene er «immediate», «eager», «moderate» og «conservative», hver med forskjellige utløsere.
  • expects_no_vary_search En streng som brukes til å gi et hint om URL-søkevariasjon, slik at utviklere kan signalisere om den spekulerte URLen forventes å ha en annen respons basert på søkeparameterne. .

Til slutt har hver regel en eagerness-innstilling som lar deg definere når spekulasjoner skal kjøres, og skiller når det skal spekuleres fra hvilke URLer spekulasjoner skal utføres på. Eagerness-innstillingen er tilgjengelig for både list- og document-kilderegler og har fire innstillinger: immediate, eager, moderate og conservative.

  • immediate: Denne brukes til å spekulere så raskt som mulig, så snart speculation rules er oppdaget.
  • eager: Denne oppfører seg for øyeblikket identisk med immediate-innstillingen, men i fremtiden vil den plasseres et sted mellom immediate og moderate.
  • moderate: Denne utfører spekulasjoner hvis du holder musepekeren over en lenke i 200 millisekunder (eller ved pointerdown-hendelsen hvis det skjer tidligere, og på mobil der det ikke er noen hover-hendelse).
  • conservative: Denne spekulerer ved peker- eller berøringsnedtrykk.

Prefetch eller Prerender

Speculation Rules API støtter to hovedformer for spekulativ lasting: forhåndshenting og forhåndsrendering. Selv om begge teknikkene kan resultere i raskere sidelastinger, skiller de seg i kompleksitet og ressursforbruk.

  • Forhåndshenting (Prefetching) er den «lettere formen» for spekulativ lasting. Den laster ned og cacher HTML-en til mål-URLen uten å rendere siden eller dens underressurser. Denne tilnærmingen forbedrer hovedsakelig Time To First Byte. En forbedret Time to First Byte vil føre til bedre maleberegninger som Largest Contentful Paint og First Contentful Paint.
  • Forhåndsrendering (Prerendering) gjør mye mer enn bare å laste ned HTML-en. Den laster ned HTML-en, alle underressurser og renderer hele siden i en skjult, usynlig fane. Ved navigasjon til denne siden resulterer dette i nesten øyeblikkelig visning. Denne teknikken forbedrer Largest Contentful Paint på flere måter enn bare ved å forbedre Time to First Byte. Den laster også ned og renderer LCP-elementet. Forhåndsrendering kan også eliminere Cumulative Layout Shift fordi ressursdimensjoner allerede er kjent etter forhåndsrendering.

Så hva er best? Forhåndsrendering eller forhåndshenting? Det avhenger av siden og den «gjennomsnittlige besøkende». Selv om forhåndsrendering kan være raskere etter design, bruker det også mye mer ressurser, både på klienten og serveren. Valget mellom forhåndsrendering og forhåndshenting avhenger av:

  • Brukerens enhetskapasitet: Forhåndsrendering er kanskje ikke det beste valget hvis en høy andel besøkende bruker enheter med begrenset minne
  • Spesifisitet av prerender- eller prefetch-regler. «Noen lenker har høyere sannsynlighet for å bli klikket på, og noen sider har høyere sannsynlighet for å konvertere.» Disse sidene er perfekte kandidater for en prerender-regel. Andre sider kan være bedre egnet for prefetch.

CoreWebVitals.io vil advare mot overdreven forhåndsrendering på grunn av ressurskravene, spesielt på mobilenheter eller tregere tilkoblinger. De potensielle fordelene med forhåndsrendering må veies opp mot risikoen for ytelsesforringelse og ressurssløsing.

Sette riktig «Eagerness» - balansekunsten

Hvilken eagerness-innstilling du skal bruke avhenger av nettstedet ditt. For et veldig enkelt statisk nettsted kan det å spekulere mer ivrig ha liten kostnad og være gunstig for brukerne. Nettsteder med mer komplekse arkitekturer og tyngre sidelaster kan foretrekke å redusere sløsing ved å spekulere sjeldnere til du får mer positivt signal om intensjon fra brukerne.

Eagerness-innstillingen i Speculation Rules API påvirker når en nettleser skal forhåndshente eller forhåndsrendere innhold basert på forutsagt brukernavigasjon. Denne innstillingen tilbyr en avveining mellom å maksimere fordelene med forhåndslasting og minimere ressurssløsing.

Standard eagerness for list-regler er immediate. Moderate- og conservative-alternativene kan brukes til å begrense list-regler til URLer som en bruker samhandler med i en spesifikk liste. I mange tilfeller kan document-regler med en passende where-betingelse være mer hensiktsmessig.

Standard eagerness for document-regler er conservative. Gitt at et dokument kan bestå av mange URLer, bør bruken av immediate eller eager for document-regler brukes med forsiktighet.

Valget av eagerness avhenger av nettstedets struktur, brukernes atferdsmønstre og utviklerens vurdering av potensielt ressursforbruk kontra fordeler for brukeropplevelsen. For eksempel kan et enkelt statisk nettsted ha fordel av en «eager»-innstilling, som fører til raskere lastetider. Omvendt kan nettsteder med komplekse arkitekturer og krevende sidelaster velge en mindre aggressiv «moderate»- eller «conservative»-tilnærming for å begrense ressursbruken til tydeligere brukerintensjon er oppdaget.

Når du konfigurerer eagerness, bør utviklere ta hensyn til brukeropplevelse, ressurskostnader og nettleserbegrensninger. Overdreven spekulasjon kan belaste brukerens båndbredde, minne og CPU, noe som potensielt kan forringe ytelsen, spesielt på begrensede nettverk eller enheter. Chrome håndhever begrensninger på samtidige forhåndshentede og forhåndsrenderte sider for å redusere overforbruk. I tillegg kan faktorer som brukerkonfigurerte datasparemodi, lav batteritilstand eller nettleserutvidelser overstyre speculation rules, og prioritere ressurssparing.

Sjekk og feilsøk speculation rules 

For å sjekke eventuelle speculation rules på en side, åpne Chrome DevTools, gå til Application-panelet og naviger til Background Services > Speculative Loads > Speculations. (åpne Speculations-panelet før du laster siden du vil feilsøke) Dette panelet gir informasjon om:

  • Antall vellykkede spekulasjoner.
  • Individuelle URLer som forhåndsrenderes eller forhåndshentes.
  • Statusen for hver spekulasjon.

Network-sporet i Performance-panelet viser nettverksaktiviteten relatert til forhåndsrenderte ressurser uten å måtte bytte DevTools-konteksten. I tillegg kan du bytte DevTools-konteksten til en forhåndsrendert side for å inspisere den som en vanlig side.

speculative loads inspector devtools

Overvåking og analyse av Speculation Rules 

  • Real User Monitoring (RUM): Bruk RUM-verktøy for å måle den faktiske brukeropplevelsen. Observer beregninger som Largest Contentful Paint (LCP) for å vurdere effekten av speculation rules på sidelastetider. Se etter forbedringer i LCP for forhåndsrenderte sider sammenlignet med ikke-forhåndsrenderte sider.
  • A/B-testing: Gjennomfør A/B-tester for å sammenligne ulike konfigurasjoner av speculation rules og identifiser det mest optimale oppsettet for ditt spesifikke nettsted og din brukerbase.

speculation rules rum tracking table coredash

Hensyn - de negative sidene

Ressursforbruk: Overbruk av spekulasjon kan negativt påvirke båndbredde, minne og CPU-bruk.

Nettleserkompatibilitet: Ikke alle nettlesere støtter Speculation Rules API fullt ut, så sjekk nettleserkompatibilitet før implementering.

Personvern: Utviklere bør være oppmerksomme på hvordan speculation rules kan avsløre brukernes nettlesermønstre og implementere passende personverntiltak.

Speculation Rules API tilbyr en kraftig tilnærming for å forbedre ytelsen og brukeropplevelsen til webapplikasjoner. Ved å forstå mekanikken, fordelene og hensynene kan utviklere utnytte dette API-et til å bygge raskere og mer engasjerende nettsteder.

Speculation Rules WordPress-kode

WordPress Core Performance-teamet har laget en Speculation Rules-utvidelse som gjør det enkelt å legge til document rule-støtte på ethvert WordPress-nettsted med ett klikk. Utvidelsen tilbyr to grupper med innstillinger:

  • Speculation Mode: Velg mellom prefetch og prerender. Forhåndsrendering vil resultere i raskere lastetider enn forhåndshenting. Imidlertid kan forhåndshenting være et tryggere valg for interaktivt innhold.
  • Eagerness: Velg mellom conservative (vanligvis ved klikk), moderate (vanligvis ved hover) eller eager (ved minste antydning). Eagerness-innstillingen bestemmer hvor raskt spekulative lastinger utløses.
Lynraske sider med Speculation RulesCore Web Vitals Lynraske sider med Speculation Rules