Speculation Rules API 2026: villámgyors navigáció prerender és prefetch segítségével

Frissítve: 2026. június 4.

A Speculation Rules API egy deklaratív, JSON-alapú böngészőszabvány, amellyel előre megmondhatod a böngészőnek, mely URL-eket töltse le (prefetch) vagy renderelje le teljesen (prerender) a háttérben, így a kattintás után a következő oldal lényegében azonnal, 0–100 ms alatt megjelenik. A 2026-os állapot szerint a Chrome 121+ és az Edge stabil támogatást nyújt, a Speculation Rules pedig a Core Web Vitals (különösen az LCP és az INP) drasztikus javításának egyik leggyorsabban telepíthető eszköze, mert nem igényel build-pipeline átalakítást, csak egyetlen speculationrules script blokkot.

• A Speculation Rules API JSON szintaxissal írja le, mely URL-eket kell előtöltened (prefetch) vagy előrendererelned (prerender) a háttérben.
• A prerender egy teljes, láthatatlan fülön futtatja a célt (beleértve a JavaScriptet, képeket és font letöltéseket), így a navigáció után az LCP gyakorlatilag azonnali.
• Az eagerness paraméter (immediate, eager, moderate, conservative) szabályozza, mikor indítsa el a böngésző a spekulációt; a moderate hover vagy touchstart eseményhez kötődik.
• Chrome a 121-es verzió óta stabilan szállítja, Edge szintén támogatja. A Safari és a Firefox 2026-ban progressive enhancementként kezelendő.
• A document.prerendering flag és a prerenderingchange esemény segítségével ki kell hagyni az analytics beaconöket a prerender szakaszban, hogy ne torzítsd a méréseket.
• Helyesen konfigurálva a Speculation Rules 30–80%-os mediánidő-csökkenést hozhat a navigáció és az LCP között, főleg tartalom-központú oldalakon.

Mi az a Speculation Rules API?

Őszintén szólva, amikor először találkoztam ezzel a szabvánnyal, kicsit túl szépnek tűnt ahhoz, hogy igaz legyen. A Speculation Rules API egy W3C Web Incubator Community Group által gondozott szabvány, amely lehetővé teszi, hogy egy weboldal deklaratívan, JSON formátumban közölje a böngészővel, mely URL-ekre tippel mint valószínű következő navigáció. A böngésző ezután a saját ütemezője szerint, a hálózati feltételeket és a felhasználó eszközterhelését figyelembe véve elindíthat egy spekulatív letöltést vagy egy teljes előrenderelést.

A korábbi link rel="prefetch" és a már elavult NoStatePrefetch mechanizmusokhoz képest a Speculation Rules három fő előnyt nyújt. Először: támogatja a teljes oldal előrenderelését (nem csak az erőforrások letöltését). Másodszor: URL-minta alapú szabályokkal dinamikus, oldal-összelinkelt navigációt is fed. Harmadszor: lehetővé teszi az eagerness finomhangolását, hogy ne pazarold a sávszélességet. A specifikációt és a referenciaimplementációt a Chrome Developers prerender pages dokumentáció tartalmazza.

Fontos kontextus: a 2026-os Chrome már a back/forward cache (bfcache) mellé sorolja a Speculation Rules-t mint a két leggyorsabb navigációs mechanizmus egyikét. Egy sikeres prerender activation után a Largest Contentful Paint mérése a navigáció pillanatától indul, és tipikusan 0–50 ms között marad. Ezt az értéket hagyományos optimalizálással szinte lehetetlen elérni. Ráadásul ez a megközelítés kompatibilis a meglévő gyorsítótárazási stratégiákkal: minél jobb a CDN-réteged konfigurációja, annál olcsóbb a spekulatív letöltés a felhasználó számára adatforgalom szempontjából.

Prefetch vs prerender: mi a különbség?

A Speculation Rules két fő akciót támogat, és a választás drámaian befolyásolja az erőforrás-igényt és a felhasználói élményt. A prefetch csak a céloldal HTML-jét tölti le előre a HTTP cache-be, így a navigáció után a böngésző a már letöltött HTML-ből indítja a renderelést. Gyorsabb TTFB, de a JavaScript futtatása és a képek dekódolása csak utána történik. A prerender ezzel szemben egy láthatatlan, izolált renderelő fülön teljesen feldolgozza az oldalt: lefuttatja a JS-t, betölti a képeket, fontokat, és előállítja a végleges DOM-fát.

Tulajdonság	Prefetch	Prerender
Mit tölt le	Csak a HTML dokumentum	Teljes oldal: HTML, JS, CSS, képek, fontok
JavaScript futtatás	Nem fut	Teljesen lefut, beleértve a hidratációt is
Memóriahasználat	Alacsony (néhány KB)	Magas (egy teljes oldalnyi)
Navigáció utáni LCP	200–500 ms	0–100 ms
Analytics esemény	Normál módon kiváltódik	Késleltetendő prerenderingchange-ig
Cross-origin támogatás	Igen (CORS-szal)	Csak same-origin alapból
Ideális használat	Sok valószínű cél, kevés bizonyosság	1–2 nagyon valószínű következő oldal

Gyakorlati ökölszabály, amit az utóbbi projektjeimben követek: ha a felhasználó hover-állapota meghaladja a 200 ms-ot egy linken, indíts prefetch-et. Ha tudod, hogy a felhasználó 90%-os valószínűséggel a következő logikus oldalra megy (például checkout flow, paginated lista következő oldala), akkor indíts prerender-t. A két akció kombinálható is: egy speculationrules blokkban definiálhatsz prefetch és prerender szabályokat egyszerre, különböző eagerness szintekkel, és a böngésző automatikusan a megfelelőt választja az adott link viselkedése szerint.

Alap implementáció lépésről lépésre

A Speculation Rules egy beágyazott JSON blokk, amelyet bárhova helyezhetsz a dokumentumon belül. Leggyakrabban a head végére vagy a body aljára kerül. A böngésző parse-olja, validálja, majd a saját ütemezőjével indítja el a spekulációkat. Az alábbi minimum konfiguráció két statikus URL-t renderel elő moderate eagerness mellett:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["/cikkek/legujabb", "/cikkek/kategoriak"],
      "eagerness": "moderate"
    }
  ]
}
</script>

Dinamikus oldalakon, például egy hírportálon, ahol a következő cikk URL-jét a sablon adja, a where klauzulát érdemes használni. Ez CSS-szerű szelektorral vagy href-mintával választja ki a megfelelő linkeket. Ez a megközelítés különösen jól skálázódik nagy listanézeteken, ahol minden URL-t felsorolni egyszerűen nem praktikus:

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

A fenti minta minden /cikk/ útvonalat előrenderelne moderate (hover vagy touchstart) trigger mellett, kivéve a .no-prerender osztályú linkeket. A teljes oldalra pedig conservative prefetch-et alkalmaz, amely csak pointerdown eseményre indul el, minimális sávszélesség-pazarlással. A tapasztalataim szerint ez a kétlépcsős minta a legjobb default: a prerender csak a magas konverziójú cikkekre megy, a prefetch viszont minden látogatott linkre, biztosítva a felgyorsult TTFB-t a kevésbé bizonyos navigációkra is.

Az eagerness szintek és mikor melyiket használd

Az eagerness az egyik legfontosabb finomhangoló kapcsoló, mert ez dönti el, hogy a böngésző mikor kezdeményezi a spekulációt. Rossz beállítás esetén pazarolod a felhasználó adatforgalmát; jó beállítás esetén a navigáció érzékelhetetlen lesz.

• immediate: A szabály parse-olása után azonnal elindítja a spekulációt. Csak akkor használd, ha 1–2 garantáltan következő URL-ed van (például a köszöntő oldalon a dashboardra mutató link).
• eager: Hasonló az immediate-hez, de a böngésző még néhány milliszekundumot vár, hogy ne ütközzön kritikus erőforrásokkal. Listanézeteken 3–5 elemig védhető.
• moderate (alapértelmezett): A felhasználó 200 ms-nál hosszabb hovere vagy touchstart eseménye indítja el. Ez a legjobb arány a sávszélesség és a sebesség között a legtöbb oldalon.
• conservative: Csak pointerdown vagy touchstart pillanatában indul. Akkor használd, ha az átkattintási arány alacsony, de a felhasználó intenciója egyértelmű.

URL minták és dinamikus szabályok

A where klauzula tette a Speculation Rules-t igazán erőteljessé. Logikai operátorokat (and, or, not) és két predikátumot támogat: href_matches és selector_matches. Ez lehetővé teszi, hogy a meglévő DOM-szerkezeted alapján deklaratívan jelöld ki, mely linkek érdemesek spekulációra, anélkül hogy szervergenerált JSON-ba ágyaznád őket.

Az href_matches URL Pattern szintaxist használ (RFC alapján standardizálva), amely glob-szerű mintákat fogad: /blog/*, /termek/:id, https://*.example.com/*. A részletes specifikációt az MDN URL Pattern API referenciája dokumentálja. A selector_matches CSS-szelektort fogad, így ki tudsz zárni például sponsored linkeket vagy logout gombokat:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/termek/*" },
        { "not": { "href_matches": "/termek/*/szerkesztes" } },
        { "not": { "selector_matches": "[data-no-speculate]" } }
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

Ez a minta minden termékoldalt előkészít, kivéve a szerkesztési útvonalakat és azokat a linkeket, amelyek data-no-speculate attribútummal vannak megjelölve (például mert mutating GET-et hajtanak végre, mint logout vagy "kosárba ad").

Hogyan javítja a Core Web Vitals értékeket?

A prerender közvetlen hatása drámai mindhárom Core Web Vital mérőszámra. Amikor a felhasználó rákattint egy előrenderelt linkre, a böngésző aktiválja a már létező oldalt. A Largest Contentful Paint mérése ekkor indul, és tipikusan 0–50 ms között marad, mivel a teljes layout és a hero kép már készen áll. A Cumulative Layout Shift szintén javul, mert a layout-eltolódást okozó aszinkron erőforrások (web fontok, oldalsó hirdetések) már stabilizálódtak. Az Interaction to Next Paint érték pedig azért csökken, mert a JavaScript-hidratáció már lefutott a prerender szakaszban.

A Chrome Web Vitals csapatának 2025-ös mérései szerint a Speculation Rules-t használó site-ok medián LCP-je 1,8 másodpercről 0,4 másodpercre csökkent, ami több mint 75%-os javulás. Ez az INP optimalizálásnál is gyorsabb hatást ad, mert a teljes interakciós ciklus a navigáció előtt zajlik le. Az INP-vel kapcsolatos technikákról bővebben az INP optimalizálás 2026: a felhasználói interakciók sebességének maximalizálása cikkben olvashatsz, amely jól kiegészíti a Speculation Rules stratégiát a hidratáció utáni interakciók finomhangolásával.

Fontos azonban tudni, hogy a Web Vitals JavaScript könyvtár (v4-től) felismeri a prerender activation eseményt, és a méréseket az activation pillanatától kezdi, nem a prerender start időpontjától. Ez azt jelenti, hogy a számokat valódi felhasználói percepció szerint kapod, nem mesterségesen alacsonyak. A Search Console és a CrUX adatbázis szintén ezt a logikát követi, így a mérőszámok konzisztensek maradnak a valós felhasználói tapasztalattal.

Analytics, A/B teszt és prerendering kezelése

A prerender legnagyobb operatív kockázata, hogy a JavaScript a háttérben fut le. Vagyis az analytics beacon, az A/B teszt expozíció és a hirdetésimpresszió esemény még azelőtt kiváltódhat, hogy a felhasználó valaha is látta volna az oldalt. Ez torzítja a méréseket és a hirdetésszámlázást egyaránt. Ezt a hibát szállítottam ki élesbe egyszer, és három napig próbáltuk értelmezni, miért ugrott meg a "bounce rate" hirtelen 22%-kal.

A megoldás a document.prerendering flag és a prerenderingchange esemény. A flag true, amíg az oldal prerender állapotban van, és false-ra vált az activation pillanatában. Egy biztonságos analytics-rétegelhalasztás így néz ki:

// Csak akkor küldjük az eseményt, ha a felhasználó valóban látja az oldalt
function sendAnalyticsEvent(name, payload) {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', () => {
      navigator.sendBeacon('/analytics', JSON.stringify({ name, payload }));
    }, { once: true });
  } else {
    navigator.sendBeacon('/analytics', JSON.stringify({ name, payload }));
  }
}

// Page view tracking, ami prerender-tudatos
if (document.prerendering) {
  document.addEventListener('prerenderingchange', trackPageView, { once: true });
} else {
  trackPageView();
}

A Google Analytics 4 és a Plausible 2025 óta natívan prerender-tudatos, de minden saját telemetriát kézzel kell ellenőrizned. Az A/B teszt platformokat (Optimizely, VWO) is érdemes ellenőrizni, mert sokuk még nem várja meg a prerenderingchange eseményt, és így false expozíciókat naplóz.

Böngészőtámogatás és progressive enhancement

2026 közepén a Speculation Rules API támogatottsága a következő:

• Chrome 121+: Teljes támogatás stabilan, beleértve a where klauzulát is.
• Edge 121+: Chromium alapon ugyanaz.
• Opera, Brave, Vivaldi: Chromium alapon szintén támogatott.
• Firefox: 2026-ban munka alatt, de nem szállít stabilan. Az aktuális Can I Use táblázat mindig naprakész.
• Safari: Az Apple még nem jelentett be implementációt.

Mivel a Speculation Rules egy progressive enhancement, a nem támogató böngészők egyszerűen figyelmen kívül hagyják a speculationrules script blokkot. Nincs hiba, nincs negatív hatás. Ez azt jelenti, hogy bátran telepítheted minden látogatóra: a Chrome-os felhasználók (a globális forgalom 65%-a) megkapják az előnyt, a többiek pedig a hagyományos navigációt látják.

A globális gyorsítótárazási stratégiához érdemes a Speculation Rules-t összekapcsolnod egy jól konfigurált CDN-réteggel. Erről részletesebben írunk a TTFB optimalizálás és gyorsítótárazási stratégiák 2026 cikkben. A két technika kombinációja a leghatékonyabb, mert a CDN-edge gyorsabb választ ad a spekulatív letöltésekre is, így a memória- és sávszélesség-felhasználás minimális marad.

Hibakeresés a chrome://prerender-internals oldalon

A Chrome egy dedikált debug-felületet biztosít a chrome://prerender-internals címen. Ide navigálva valós időben látod, mely spekulációk vannak folyamatban, melyek aktiválódtak, és melyek dobódtak el; utóbbi esetben pontos okkal együtt. Tipikus hibakódok és jelentésük:

• kMaxNumOfRunningPrerendersExceeded: Túl sok prerender egyszerre. A Chrome korlátja 10 same-origin prerender. Csökkentsd az eagerness szintet.
• kMixedContent: A céloldal HTTP erőforrást próbál betölteni HTTPS oldalon. Tisztítsd ki az erőforrás URL-eket.
• kBlockedByCSP: A Content Security Policy nem engedi a prerendert. Ellenőrizd a frame-src és default-src direktívákat.
• kSpeculationRuleRemoved: A DOM-ból kikerült a szabály, mielőtt a prerender lefutott volna. Ne dinamikusan távolítsd el a script blokkot.
• kAudioOutputDeviceRequested: A céloldal autoplay audiót próbál indítani. A prerender nem engedi a hangot az activation előtt.

A DevTools Application paneljén belül egy új "Speculative loads" szekció található, és a Performance lap szintén megjeleníti a prerender timeline-t. Itt láthatod, mikor indult, meddig tartott, és mikor aktiválódott. Ez a leggyorsabb módja, hogy validáld, valóban érvénybe lép-e a szabályod. A staging környezetben érdemes minden új deploy előtt manuálisan átfutni a top 5 leggyakrabban használt útvonalon, mert egyetlen apró CSP-változás is letilthatja a teljes spekulációs réteget. Az utolsó projektemben pont egy nonce-os CSP frissítés tette padlóra a prerendert, és csak a chrome://prerender-internals oldalon derült ki.

Gyakori buktatók és megoldásaik

Tapasztalataim szerint az alábbi öt hiba okozza a Speculation Rules telepítések 90%-át. Ezek elkerülésével azonnal mérhető Core Web Vitals javulást fogsz látni.

1. Side-effecting kódok futása prerender alatt

A window.addEventListener('load', sendAnalytics) mintát mindenhol látom. Ez a prerender pillanatában lefut, mert az oldal "betöltődik" a háttérben. Csomagold be document.prerendering ellenőrzésbe, vagy használd a prerenderingchange eseményt. Külön figyelj a third-party scriptekre, mert ezek többsége nem prerender-tudatos.

2. Túl sok URL aktivált eagerness mellett

Ha 30 link mindegyikét eager eagerness-szel indítod, a Chrome 10 után dobja a többit, és pazarolod a sávszélességet. Tartsd meg az immediate és eager szinteket 1–3 URL-re. A nagyobb skálát mindig moderate vagy conservative szinten futtasd.

3. Hiányzó cache-control fejléc

A prefetch akkor hatékony, ha a céloldal HTML cache-elhető. Egy Cache-Control: private, no-cache fejléc lényegében nullázza az előnyt. Állíts be legalább max-age=60-t a navigálható oldalakra, vagy használj stale-while-revalidate direktívát az edge-en. A képek és fontok optimalizálásáról is érdemes átnézned a Képoptimalizálás 2026 útmutatót, mivel a prerender csak akkor hoz teljes nyereséget, ha a tartalom is gyors.

4. Cross-origin prerender CORS hiányában

A cross-origin prerendert külön opt-inezni kell a célszerveren a Supports-Loading-Mode: credentialed-prerender response fejléccel. Enélkül a Chrome nem engedi az activation-t. Saját domain alatti aldomain-ekre is külön kell engedélyezni.

5. Service Worker konfliktus

Ha a Service Worker a prerender request-eket cache-eli, és nem ismeri fel a Sec-Purpose fejlécet, dupla beacont küldhetsz vagy stale cache-ből szolgálsz fel a felhasználónak. A Service Worker fetch handlerét frissítsd, hogy figyelje ezt a fejlécet, és külön kezelje a prerender request-eket.

Gyakran Ismételt Kérdések

Hogyan engedélyezhetem a prerendering funkciót Chrome-ban?

A prerendering alapból be van kapcsolva a Chrome 121+ verzióban. A weboldal oldaláról kell aktiválnod egy speculationrules típusú script blokk hozzáadásával. Nincs szükség felhasználói beavatkozásra vagy flag-re. Ellenőrizheted a chrome://prerender-internals oldalon, hogy működik-e.

Biztonságos a Speculation Rules API az analytics szempontjából?

Biztonságos, ha a kódod ellenőrzi a document.prerendering flag-et és csak a prerenderingchange esemény után küld page view eseményeket. A Google Analytics 4 és a Plausible natívan kezeli ezt, de egyedi telemetriát manuálisan kell prerender-tudatossá tenned.

Mi a különbség a prerender és a link rel="prefetch" között?

A link rel="prefetch" csak a HTML dokumentumot tölti le előre, és nem futtatja a JavaScriptet. A Speculation Rules prerender egy teljes láthatatlan fülön renderereli az oldalt, beleértve a JS futtatást, képeket és fontokat, így a navigáció után 0–100 ms alatt megjelenik az LCP.

Javítja a Speculation Rules a Core Web Vitals értékeket?

Igen, drasztikusan. Egy sikeresen aktivált prerender esetén az LCP általában 50 ms alá esik, az INP javul (mert a hidratáció már lefutott), és a CLS is stabilabb. A Chrome Web Vitals csapatának mérései szerint a medián LCP 75%-kal csökkent a Speculation Rules-t használó oldalakon.

Mennyi sávszélességet pazarol el a prerender?

A pazarlás mértéke az eagerness szinttől és az átkattintási aránytól függ. Conservative eagerness-szel a sávszélesség-felhasználás csak a pointerdown események száma alapján nő, ami közel ideális. Moderate szint mellett tipikusan 10–15% sávszélesség-növekedéssel számolhatsz, cserébe 30–80% gyorsabb navigációért.