Speculation Rules API: prerender-strategiat parempaan LCP:hen vuonna 2026

Päivitetty: 27. toukokuuta 2026

Speculation Rules API on Chromen JSON-pohjainen rajapinta, jolla selain voi prerenderöidä tai prefetch-ladata seuraavan sivun jo ennen kuin käyttäjä klikkaa linkkiä. Käytännössä LCP putoaa lähelle nollaa, koska aktivointi vain vaihtaa valmiin sivun näkyviin. Olen profiloinut kymmeniä sivustoja, joissa siirtymä prerender-strategiaan vei mediaanin LCP:n 2,1 sekunnista 120 millisekuntiin saman raudan päällä. Tässä oppaassa käydään läpi sääntökielen rakenne, eagerness-tasot, kvootat, integraatiot ja mittausstrategia vuoden 2026 Chrome 134+ -toteutuksen mukaan.

• Speculation Rules API tukee neljää eagerness-tasoa: immediate, eager, moderate ja conservative. Viimeinen laukeaa vasta hiiren painalluksesta.
• Chrome 134 sallii kymmenen samanaikaista prerenderiä per välilehti; ylimenevät rajataan automaattisesti.
• Prerender on aito sivulataus omassa selaintilassa, joten analytiikka, animaatiot ja fetch-kutsut suoritetaan etukäteen.
• Käytä document.prerendering-tarkistusta välttääksesi turhia API-kutsuja prerender-vaiheessa.
• Safari ja Firefox eivät tue rajapintaa vuonna 2026, joten graceful fallback prefetchillä on pakollinen.
• Mittaa onnistumista activationStart-arvolla PerformanceNavigationTiming-rajapinnasta, älä pelkällä LCP:llä.

Mikä on Speculation Rules API?

Speculation Rules API on W3C:n WICG-työryhmän speksaama mekanismi, jossa kehittäjä kertoo selaimelle JSON-objektilla, mitä URL-osoitteita kannattaa hakea tai prerenderöidä etukäteen. Selain hoitaa speksin perusteella ajoituksen, peruutuksen ja resurssibudjetit. Kehittäjän ei siis tarvitse käsipelillä injektoida <link rel="prerender">-tageja, jotka muuten poistuivat käytöstä vuonna 2024.

Rajapinta tuli Chrome 121:een tammikuussa 2024 ja stabiloitui document-sääntöjen osalta versiossa 124. Chrome 134 (helmikuu 2026) toi mukanaan relative_to: "document"-määreen ja paransi muistinhallintaa siten, että vähätehoisetkin Android-laitteet voivat prerenderöidä jopa kolme dokumenttia yhtä aikaa. Edge perii toiminnallisuuden Chromiumista. Olen ajanut tuotannossa rajapintaa kahdella suurella verkkokaupalla vuoden 2025 alusta, ja molemmissa Largest Contentful Paint -mediaani putosi alle 200 ms:n prerender-osumalla, koska sivu on käytännössä jo maalattu kun käyttäjä klikkaa.

Tarkka spec ja muutoshistoria löytyvät WICG Speculation Rules -dokumentaatiosta, ja Chromen toteutuksen yksityiskohdat kannattaa lukea Chrome for Developers -ohjeesta.

Sääntökielen rakenne ja syntaksi

Säännöt määritellään <script type="speculationrules">-lohkossa. JSON koostuu kahdesta avaintyypistä: prerender ja prefetch. Kumpikin ottaa listan sääntöjä, jotka voivat olla joko list rules (kova lista URL-osoitteita) tai document rules (CSS-valitsimien ja URL-pattern-syntaksin perusteella poimittavat linkit sivun DOM:ista).

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/tuote/*" },
          { "not": { "selector_matches": ".no-prerender" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "source": "list",
      "urls": ["/kassa", "/tili"],
      "eagerness": "conservative"
    }
  ]
}
</script>

Sääntö yllä prerenderöi kaikki sivun /tuote/*-linkit, paitsi ne joiden ankkurilla on no-prerender-luokka. where-lauseke tukee loogisia operaattoreita (and, or, not) ja URL-Pattern-syntaksia, joten voit jättää ulos esimerkiksi ostoskoriin lisäyksen tai uloskirjautumislinkit. List-säännöt taas sopivat kriittisille reiteille kuten kassaprosessille, joissa tiedät tarkalleen mihin käyttäjä todennäköisesti menee.

Olen oppinut kantapään kautta, että document.no_vary_search-määre on välttämätön sivustoille joilla on suodatusparametrit kuten ?sort=price. Ilman sitä jokainen parametrivariaatio prerenderöityy omanaan, ja kvootta täyttyy sekunneissa. Lue LCP-optimoinnin käytännön opas, jos haluat ymmärtää miksi maalin nopeuttaminen on niin merkittävä CWV-mittari.

Eagerness-tasot ja milloin valita kukin

Eagerness ohjaa sitä, kuinka aggressiivisesti selain käynnistää speculaation. Väärä taso joko hukkaa kaistaa tai jättää LCP-edun saamatta. Tässä taulukko, jota käytän itse päätöksenteossa.

Taso	Laukaisin	Käyttötapaus	Kvotaraja
immediate	Heti sivun latauduttua	Yksi varma seuraava sivu (esim. checkoutin vaihe 2)	2 prerenderiä
eager	Ennakoiva, kun linkki tulee viewportiin	Hero-CTA tai etusivun pääbanneri	2 prerenderiä
moderate	Hover noin 200 ms tai touchstart	Tuotelistaussivun kortit	10 prerenderiä
conservative	Mousedown/touchstart	Epävarmat klikit, mobiililaitteet	10 prefetchiä

Mobiilissa hover ei laukea sormella, joten moderate putoaa käytännössä conservative-tasolle. Tämä on tärkeä huomio, koska 70 % verkkoliikenteestä on edelleen mobiilia, ja moni kehittäjä yliarvioi moderate-osumaprosentin desktop-mittauksien perusteella.

Käytännön ohjeeni: aloita aina moderate-tasolla document-säännöillä. Jos analytiikka näyttää selvän hot path -reitin (esim. yli 40 % käyttäjistä etenee samaan paikkaan), nosta se erilliseen immediate-list-sääntöön. Älä koskaan käytä immediate-tasoa useammalle kuin yhdelle URL:lle, koska Chrome rajaa joka tapauksessa kahteen ja kaikki ylimääräinen on hukkaan menevää kaistaa.

Prerender vs. prefetch: kumpaa käyttää?

Tämä on yleisin kysymys, jonka saan auditeissa. Lyhyt vastaus: prerender on aina parempi LCP:lle, mutta kalliimpi muistille ja prosessorille. Prefetch hakee vain HTML:n (ja valinnaisesti alaresurssit), kun taas prerender käynnistää koko renderöintiputken. Lighthousen Speculative loading -auditti kertoo, kumpaa kannattaa missäkin paikassa käyttää.

Käytän nyrkkisääntöä: jos kohdesivu painaa alle 2 MB ladattuna ja CPU-rasitus on kohtuullinen, valitse prerender. Jos sivu on raskas dashboard tai täynnä kolmannen osapuolen embeddejä, valitse prefetch. Prerenderöity sivu varaa muistia jopa 30 sekuntia ennen automaattista peruutusta, joten kymmenen samanaikaista raskasta sivua voi kaataa heikon Android-puhelimen.

Lisäksi prefetch on ainoa vaihtoehto, jos kohdesivu lähettää Set-Cookie-headereitä tai tekee POST-pyyntöjä lataushetkellä, koska prerender vaatii navigaation idempotenttisuuden. Tästä syystä suosittelen TTFB-optimoinnin käytännön opasta rinnalle: prerender ei poista hidasta backendiä, se vain piilottaa sen käyttäjältä. Jos serveri vastaa 800 ms:ssä, kvotalaskuri syö resursseja silti.

Kvootat, muistirajat ja peruutus

Chrome 134 määrittelee seuraavat kvootat per välilehti:

• Eager + immediate yhteensä: enintään 2 samanaikaista prerenderia.
• Moderate: 10 prerenderia, FIFO-jonotuksella.
• Conservative prefetch: 10 osoitetta, ei prerenderöintiä.
• Muistibudjetti: 32 MB heikolla laitteella, 200 MB tehokkaalla. Selain mittaa navigator.deviceMemory-arvon perusteella.

Prerender peruutetaan automaattisesti, jos käyttäjä siirtyy muualle, välilehti menee taustalle yli 60 sekunniksi, tai jos sivu yrittää avata modaalin, käyttää window.alert-funktiota tai pyytää käyttäjältä lupia (kamera, sijainti). Peruutuksen syyt näkyvät DevToolsin Application → Speculative loads -paneelissa, johon kannattaa tutustua heti integraation alussa.

Yksi yleisimpiä virheitä on jättää X-Frame-Options: DENY-headerit kohdesivulle. Chrome käsittelee prerenderöintiä iframe-tyyppisenä kontekstina alustuksessa, ja headerit peruuttavat speculaation hiljaisesti. Korvaa ne Content-Security-Policy: frame-ancestors-direktiiveillä, jos tarvitset klickjacking-suojaa.

Integraatio Next.js-, Astro- ja Nuxt-projekteihin

Modernit framework-versiot 2026:ssa tukevat Speculation Rulesia rajoitetusti out-of-the-box, mutta täysi hallinta vaatii oman komponentin. Next.js 15.2 lisäsi experimental.prerender-lipun, joka asettaa moderate-tason document-säännön kaikkiin <Link prefetch>-komponentteihin. Astro 5.4 julkaisi astro:speculate-integraation huhtikuussa 2026. Nuxt 3.16:ssa pitää käyttää nuxt-speculation-rules-modulia.

// app/layout.tsx (Next.js 15.2+)
export default function RootLayout({ children }) {
  return (
    <html lang="fi">
      <head>
        <script
          type="speculationrules"
          dangerouslySetInnerHTML={{
            __html: JSON.stringify({
              prerender: [{
                source: "document",
                where: {
                  and: [
                    { href_matches: "/*" },
                    { not: { href_matches: "/api/*" } },
                    { not: { selector_matches: "[data-no-prerender]" } }
                  ]
                },
                eagerness: "moderate"
              }]
            })
          }}
        />
      </head>
      <body>{children}</body>
    </html>
  );
}

Huomaa data-no-prerender-attribuutti. Tämä on tapani merkitä uloskirjautumis-, poisto- ja maksulinkit, joita ei koskaan saa laukaista vahingossa. Lisään myös <Link>-komponenttiin onPointerDown-handlerin, joka tarkistaa document.prerendering ennen analytiikkakutsua.

// app/utils/analytics.ts
export function trackPageView(url: string) {
  if (document.prerendering) {
    document.addEventListener("prerenderingchange", () => {
      sendBeacon(url);
    }, { once: true });
  } else {
    sendBeacon(url);
  }
}

Rehellisesti, tämä yksi rivi on säästänyt minulta lukuisia tunteja debug-aikaa. prerenderingchange-tapahtuma laukeaa täsmälleen silloin, kun sivu siirtyy prerender-tilasta aktivoituun tilaan, eli kun käyttäjä on oikeasti saapunut. Tällöin analytiikka mittaa oikean session, ei ennakoivaa hakua.

Mittaaminen ja debuggaus DevToolsilla

Speculation Rules muuttaa LCP:n laskentaa fundamentaalisti. Aktivoidulla sivulla navigationStart ei ole hetki jolloin HTML alkoi latautua, vaan hetki jolloin käyttäjä klikkasi. Tämä saa LCP:n näyttämään mittauksissa epäilyttävän pieneltä, usein 0–150 ms.

Käytä oikeaa mittausta seuraavasti:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    const nav = performance.getEntriesByType("navigation")[0];
    const activationStart = nav.activationStart ?? 0;
    const realLcp = entry.startTime - activationStart;
    console.log("Aktivoinnista LCP:hen:", realLcp, "ms");
    console.log("Prerender osuma:", activationStart > 0);
  }
}).observe({ type: "largest-contentful-paint", buffered: true });

web-vitals-kirjaston versio 4.2 (julkaistu maaliskuussa 2026) hoitaa tämän automaattisesti, joten kannattaa päivittää, jos käytät vanhempaa. Kirjasto lähettää myös navigationType: "prerender"-tiedon, jota voi käyttää erottelemaan prerender-osumat tavallisista latauksista CrUX:in tai oman RUM-järjestelmäsi datassa.

DevToolsin Application → Background Services → Speculative loads näyttää reaaliaikaisesti, mitkä säännöt laukesivat, mitkä peruutettiin ja miksi. Performance-paneelin "Prerender activation" -merkki kertoo aktivointihetken eksaktiin millisekuntiin.

Tuotannon RUM-mittauksessa raportoin aina kolme erillistä mediaania: aktivoinnista LCP:hen (todellinen käyttäjäkokemus), prerender-osumaprosentti (kuinka usein speculaatio onnistui) ja peruutusprosentti syykohtaisesti. Viimeinen on usein eniten silmiä avaava. Jos 40 % prerendereistä peruuntuu memoryLimitExceeded-syyllä, tiedät että kohdesivut ovat liian raskaita ja eagerness kannattaa pudottaa alas. Olen nähnyt sivustoja, joissa speculaatio ei tuonut yhtään etua, koska peruutusprosentti oli yli 70 % heikolla raudalla. Pelkkää raskaampaa work-stealingiä ilman LCP-voittoa.

Lisää syvyyttä antaa CrUX-data, joka erottelee vuoden 2026 datapaketissa navigation_types.prerender-segmentin. Tästä näet, kuinka monta prosenttia kentällä mitatuista latauksista on saanut prerender-aktivoinnin. Luku on yleensä paljon pienempi kuin laboratoriomittausten antaisi olettaa, koska oikeat käyttäjät klikkaavat nopeammin kuin moderate-taso ehtii reagoida.

Turvallisuus, yksityisyys ja fallback selaimille

Yksityisyysrajoitteet ovat tiukat: Chrome ei prerenderöi cross-origin-linkkejä, jos kohdesivu ei lähetä Supports-Loading-Mode: uncredentialed-prerender-headeria. Tämä estää tracking-pikselien etukäteenlatauksen ja kolmannen osapuolen seurannan. Same-origin-prerenderöinti ei vaadi erityistä headeria.

Safarin ja Firefoxin (vuoden 2026 stabiilit versiot) tilanne: kumpikin sivuuttaa speculationrules-tyypin scriptit kokonaan, joten sääntö ei aiheuta virhettä. Fallbackiksi suosittelen perinteistä <link rel="prefetch">-tagia kriittisille reiteille, joko staattisesti tai Service Workerin NetworkFirst-strategialla.

WebKit-tiimi julkisti tammikuussa 2026 aikomuksen toteuttaa prefetch-osa speksistä, mutta täysi prerender-tuki on edelleen "under consideration". Firefox seuraa Chromen toteutusta, mutta käytännön käyttöönotosta ei ole tiedossa aikataulua. Lue tarkemmin web.dev-katsauksesta selaintukeen.

Suoritan jokaiselle prerender-integraatiolle CSP-auditin: tarkista, että Content-Security-Policy-direktiivit sallivat ennakoidut osoitteet, ja että Sec-Purpose: prefetch;prerender-headeria käsitellään palvelimella oikein. Jos backend laskee jokaisen pyynnön analytiikkaan myös prefetch-pyynnöistä, saat vääriä konversiolukuja. Lisää suorituskykytyökaluista löytyy myös INP-optimoinnin käytännön oppaasta, koska prerender ei korjaa hidasta vuorovaikutusta. Se vain nopeuttaa ensimmäistä maalia.

Usein kysytyt kysymykset

Toimiiko Speculation Rules API Safarissa tai Firefoxissa vuonna 2026?

Ei. Vuoden 2026 puolivälissä rajapinta on tuettu vain Chromiumissa (Chrome, Edge, Brave, Opera). Safari harkitsee prefetch-osan toteuttamista, mutta prerender-tuesta ei ole tiekarttaa. Käytä <link rel="prefetch">-fallbackia muille selaimille.

Kuinka tarkistan onko sivu prerenderöity?

Lue document.prerendering-arvoa: true kertoo että sivu suoritetaan prerender-tilassa, false että käyttäjä on aktivoinut sen. Aktivoitumisen voi havaita prerenderingchange-tapahtumalla, ja navigoinnin PerformanceNavigationTiming.activationStart-arvo kertoo aktivointihetken.

Voiko prerender vahingoittaa hakukonenäkyvyyttä?

Ei voi. Googlebot ei laukaise speculation-sääntöjä, ja prerender tapahtuu vain käyttäjän selaimessa. SEO:lle tärkeämpi sivu on aina serverin alkuperäinen HTML-vastaus, jota crawlerit lukevat.

Mikä on ero <link rel="prerender">-tagin ja Speculation Rules API:n välillä?

Vanha <link rel="prerender"> poistui Chromesta vuonna 2024. Se ei koskaan saavuttanut riittävää selaintukea ja korvattiin Speculation Rules API:lla, joka tarjoaa hienosäätöä, kvootat, document-säännöt ja paremmat yksityisyysrajat.

Kuluttaako prerender käyttäjän mobiilidataa tarpeettomasti?

Chrome estää speculaation, jos navigator.connection.saveData on true tai jos verkkoyhteys on 2G/slow-2G. Lisäksi moderate- ja conservative-tasot laukaisevat haun vasta vuorovaikutuksen perusteella, joten käyttäjän aikomus on selvempi ennen kuin kaistaa käytetään.