Speculation Rules API: Instantná navigácia cez prerender a prefetch v roku 2026

Aktualizované: 4. augusta 2026

Speculation Rules API je moderné rozhranie prehliadača, ktoré umožňuje deklaratívne predpovedať budúcu navigáciu používateľa a vopred prefetchnúť alebo prerenderovať cieľové stránky, takže výsledná navigácia prebehne v desiatkach milisekúnd. Namiesto pôvodných <link rel="prerender"> (odstránené v Chrome 63) dostávame JSON-based konfiguráciu s presnou kontrolou nad eagerness, URL vzormi a No-Vary-Search sémantikou. Chrome ju plne podporuje od verzie 121 a je to jedna z mála techník, ktorá dokáže znížiť LCP navigovanej stránky prakticky na nulu.

• Speculation Rules API sa deklaruje ako <script type="speculationrules"> a podporuje dva režimy: prefetch (stiahne dokument) a prerender (kompletne ho vyrenderuje na skrytom vlákne).
• Prerender dokáže znížiť LCP navigovanej stránky pod 100 ms, ale stojí pamäť a CPU. Používajte eagerness: "moderate" alebo "conservative" namiesto "immediate".
• Podpora: Chrome 121+ a Edge (prerender), Chrome 111+ (prefetch). Safari a Firefox v auguste 2026 stále bez podpory, takže je to čisto progresívne vylepšenie.
• No-Vary-Search hlavička umožňuje spárovať aj URL s inými query parametrami, čo dramaticky zvyšuje hit rate pri paginácii a filtroch.
• Analytika musí čakať na prerenderingchange event alebo kontrolovať document.prerendering, inak zaznamená falošné pageviews.
• Chrome má vstavané limity: max 10 prerender stránok, 50 prefetch, celkovo 10 MB pamäte na dokument, takže nemusíte budovať vlastnú throttling logiku.

Čo je Speculation Rules API a ako funguje

Poviem to rovno: Speculation Rules API je deklaratívne rozhranie, ktoré prehliadaču povie „tieto URL sú pravdepodobným ďalším krokom používateľa, priprav ich vopred." Prehliadač potom v pozadí, na samostatnom rendering procese, spustí buď prefetch (stiahne HTML a všetky sub-resource), alebo prerender (kompletne postaví DOM, spustí JavaScript, vyrenderuje pixely). Keď používateľ na odkaz reálne klikne, navigácia je hotová v priemere za 20 až 80 ms, pretože prehliadač len „prepne" už pripravený dokument z pozadia na popredie.

Deklarácia vyzerá takto: čistý JSON vložený do <script type="speculationrules">.

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/products/*" },
    "eagerness": "moderate"
  }]
}
</script>

Existujú dva typy pravidiel. List rules obsahujú explicitne vymenované URL v poli urls. Hodia sa napríklad pre landing page, kde presne viete, kam väčšina používateľov ide ďalej. Document rules používajú predikát where (obsahujúci href_matches, selector_matches, alebo booleánsky and/or/not) a Chrome sám prehľadá aktuálny dokument a nájde všetky vyhovujúce <a> odkazy. Document rules sú prakticky vždy lepšie, pretože nevyžadujú manuálnu údržbu URL zoznamu.

Pod kapotou beží prerender v samostatnom rendering procese, ktorý má vlastný DOM, vlastný JavaScript kontext a vlastné sieťové spojenia. Nie je to <iframe>. Je to plnohodnotný „skrytý tab" bez UI. Chrome tento proces aktivuje až vo chvíli, keď používateľ klikne. Vtedy sa proces stane hlavným a pôvodná stránka je zahodená. Špecifikáciu si môžete pozrieť priamo v drafte WICG, ak vás zaujímajú detaily.

Prefetch vs prerender: aký je rozdiel

Prehliadač ponúka dve úrovne špekulácie a je kritické vedieť, kedy použiť ktorú. Nasledujúca tabuľka porovnáva ich charakteristiky.

Vlastnosť	prefetch	prerender
Čo stiahne	Iba HTML dokument (a nič ďalšie)	HTML, CSS, JS, obrázky, fonty (všetko potrebné pre plný render)
Spustí JavaScript?	Nie	Áno, celý pipeline vrátane hydration
Vypočíta LCP?	Nie, LCP sa počíta až po klikne	Áno, LCP pri aktivácii býva < 100 ms
Náklady na pamäť	~50 až 200 kB (len HTML)	Rovnaké ako plne otvorená stránka (10 až 50 MB)
Chrome verzia	111+	121+
Cross-origin	Áno (s requires: ["anonymous-client-ip-when-cross-origin"])	Iba same-origin (od Chrome 121); cross-origin blokované
Vhodné pre	Neisté predikcie, veľa kandidátov, mobilné dáta	Vysokopravdepodobná ďalšia stránka (pagination, produkt z listingu)

Ešte jeden dôležitý detail. Prefetchnutý dokument je v jednorazovej pamäťovej cache mimo HTTP disk cache. Neplete sa s Cache-Control ani so Service Worker cache; je to samostatný layer, ktorý existuje len na dobu jednej používateľskej relácie a limity Chrome sám riadi.

Praktická implementácia: prerender za 10 minút

Najrýchlejší spôsob, ako pridať Speculation Rules na existujúci web, je jeden globálny script v <head>. Toto je konfigurácia, ktorú v produkcii používam pre e-shopy s katalógovou navigáciou.

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

Rozoberme, čo sa deje riadok po riadku.

1. Vonkajší blok prefetch pokrýva všetky same-origin odkazy okrem /logout (nechceme používateľa vylogovať v pozadí; Chrome to síce blokuje, ale explicitná ochrana je lepšia) a /*/edit stránok, ktoré typicky menia stav.
2. Selektor .no-prefetch je escape hatch. Na akýkoľvek odkaz stačí pridať túto triedu a prefetch sa vypne. Nutné napríklad pre linky, ktoré spúšťajú side-effect endpoints (napr. add-to-cart cez GET, čo je aj tak antipattern).
3. Prerender pre /products/*: na kategórii sa prerenderuje ten produkt, na ktorý používateľ pomerne dlho pozerá (hover cez „moderate" eagerness), takže klik znamená okamžité zobrazenie.

Pre React/Next.js aplikácie odporúčam pridať script priamo do app/layout.tsx alebo _document.tsx, aby bol prítomný pri každom SSR response. Dynamicky injektnuté speculation rules cez useEffect síce fungujú, ale strácate okno na prefetch pred prvou interakciou. Ja som si to overil v poslednom projekte a rozdiel v hit rate bol nezanedbateľný (skoro 15 percentuálnych bodov).

Eagerness: ako riadiť agresivitu predikcie

Eagerness je najdôležitejšie ladidlo Speculation Rules API a chybné nastavenie dokáže vyžrať gigabajty pamäte alebo naopak spraviť API neužitočným. Existujú štyri hodnoty s presne definovaným správaním.

• immediate: Chrome začne spracovávať pravidlo hneď, ako parsne script. Vhodné len pre list rules s 1 až 3 URL, kde ste si istí (napr. checkout flow: cart, shipping, payment).
• eager: spustí sa okamžite po parse, ale s nižšou prioritou a v dávkach. Používam len na landing page pre „next natural step" navigation.
• moderate: spustí sa pri hover odkazu ~200 ms alebo pri pointerdown. Toto je default pre document rules a v drvivej väčšine prípadov správna voľba.
• conservative: spustí sa iba na pointerdown alebo touchstart. Získate ~80 až 150 ms časový posun oproti kliku, čo pre prefetch stačí, pre prerender už menej.

V mojej praxi je 90 % nasadení moderate. Jediný scenár, kedy ide na immediate, je paginácia. Ak používateľ pristál na stránke 3 blogových článkov, s 95 % pravdepodobnosťou pôjde na stránku 4 alebo 2. Vtedy list rule s immediate je čistý win.

Chrome má vstavané kvótové limity, ktoré si nemusíte pamätať do detailu, no sú užitočné pre kapacitné plánovanie: max 10 prerender stránok, max 50 prefetch, a agregátny memory budget ~10 MB na hlavný dokument. Keď kvóta praskne, staršie špekulácie sa evict-nú metódou FIFO. Toto je dôvod, prečo je nezmyselné písať vlastnú throttling logiku, keďže prehliadač to už rieši.

No-Vary-Search: matching URL s query parametrami

Historicky bola hlavná bolesť prerender caching, že /products?page=1&sort=price a /products?sort=price&page=1 boli považované za dve rôzne URL. Podobne pri tracking parametroch (utm_source, fbclid) sa cache prakticky nikdy netrafila. HTTP hlavička No-Vary-Search tento problém rieši, pretože server ňou deklaruje, ktoré query parametre nemenia obsah odpovede.

// Server response pre /products
HTTP/1.1 200 OK
Content-Type: text/html
No-Vary-Search: params=("utm_source" "utm_medium" "fbclid" "gclid"), key-order

<html>...</html>

Kľúčové časti hlavičky:

• params=("utm_source" "utm_medium" ...): explicitný zoznam parametrov, ktoré má prehliadač ignorovať pri hľadaní match v prerender/prefetch cache.
• key-order: ignoruje sa poradie parametrov, takže ?a=1&b=2 matchuje aj ?b=2&a=1.
• params, except=("page"): alternatíva, „ignoruj všetko okrem page". Vhodné pre listingy, kde jediné čo mení obsah je stránkovanie.

Alternatívne môžete expects_no_vary_search zadať priamo v speculation rules, ak nechcete meniť server response.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products?page=1"],
    "expects_no_vary_search": "params=(\"utm_source\" \"utm_medium\"), key-order"
  }]
}
</script>

Honestly, toto býva najväčšia jednorazová výhra. Na jednom e-shope som videl skok z ~40 % na ~85 % prerender hit rate len pridaním No-Vary-Search: params=("utm_source" "utm_medium" "utm_campaign"), key-order. Bez toho každý Facebook alebo Google Ads klik generoval unikátne URL a všetka predchádzajúca práca sa zahodila.

Analytika, ads a document.prerendering

Toto je oblasť, kde ľudia najviac chybujú. Ak máte Google Analytics, GTM, alebo iný pageview tracker inicializovaný v <head> bez detekcie prerender state, budete zaznamenávať pageviews aj pre stránky, ktoré používateľ nikdy neuvidel. Výsledkom je nafúknutá návštevnosť a rozbitý bounce rate.

Správna detekcia používa document.prerendering a prerenderingchange event:

function trackPageview() {
  gtag('event', 'page_view', {
    page_location: location.href,
    page_title: document.title
  });
}

if (document.prerendering) {
  // Sme v prerender fáze, čakáme na aktiváciu
  document.addEventListener('prerenderingchange', trackPageview, { once: true });
} else {
  // Bežná (aktívna) navigácia
  trackPageview();
}

Podobne fungujú aj reklamné pixely. Chrome developer docs majú príklady pre GA4, GTM aj Facebook Pixel. Vlastné inline pixely musíte upraviť ručne. Analytics vendor bez natívnej podpory môžete obaliť do vyššie uvedeného kódu.

Pre meranie LCP a Core Web Vitals platí, že PerformanceObserver počas prerender fázy stále beží. Chrome však z RUM dát vylučuje merania, ktoré vznikli mimo aktívneho stavu, a hlási len metriky od aktivačného momentu. Toto rieši samotný prehliadač a nemusíte s tým nič robiť; pri vlastnej agregácii cez web-vitals knižnicu si však overte, že používate verziu ≥ 4.0, ktorá prerender už zohľadňuje.

Podpora prehliadačov a cross-origin pravidlá

K augustu 2026 je stav podpory nasledovný:

• Chrome/Edge (desktop aj Android): plná podpora prefetch (od 111) aj prerender (od 121). Chrome 128+ podporuje aj No-Vary-Search v obidvoch smeroch (hlavička aj expects_no_vary_search).
• Safari: stále bez podpory (WebKit tracking issue z 2023 ostáva open). Podľa webkit.org/status je feature „Under Consideration".
• Firefox: bez podpory, žiadny implementation ticket. Mozilla verejne uviedla obavy z memory overhead prerender.

Pre náš argument to znamená jediné: Speculation Rules je čisté progresívne vylepšenie. Chrome používatelia dostanú instantnú navigáciu, Safari a Firefox používatelia dostanú klasickú navigáciu, a nič sa nerozbije. Kvôli tomu ani nikdy nekombinujte prerender s kritickými business rules typu „aktivovať iba ak sa už predtým zobrazila stránka".

Cross-origin špekulácie majú prísne obmedzenia. Prerender je od Chrome 121 povolený iba pre same-origin. Prefetch na cross-origin je možný, ale vyžaduje explicitný opt-in cez requires: ["anonymous-client-ip-when-cross-origin"], čo znamená, že prehliadač odošle request cez CDN proxy bez IP klienta.

{
  "prefetch": [{
    "source": "list",
    "urls": ["https://cdn.partner.com/asset.html"],
    "requires": ["anonymous-client-ip-when-cross-origin"]
  }]
}

Pre 99 % webov nikdy nebudete cross-origin špekulácie potrebovať. Riešte si vlastnú doménu a nechajte prehliadač robiť svoje. Ak ladíte aj stabilitu layoutu, mrknite na kompletný sprievodca CLS optimalizáciou, ktorý Speculation Rules pekne dopĺňa (nemá zmysel prerenderovať stránku, ktorá po aktivácii poskočí).

Ako merať úspešnosť prerender v produkcii

Bez merania nemôžete potvrdiť ani optimalizovať. Máte na to tri komplementárne nástroje.

1. Chrome DevTools, Application > Speculative loads

V DevTools otvorte panel Application → Background services → Speculative loads. Zobrazí zoznam všetkých prerender/prefetch pokusov, ich stav (Ready, Failure, In progress) a dôvod pre failure. Toto je prvá zastávka pri každom debug session, pretože jeden pohľad vám povie, či Chrome pravidlo vôbec akceptoval.

2. Performance panel, trace prerender aktivácie

V Performance paneli nahrajte trace, kliknite na prefetch-nutý odkaz a hľadajte event activateStart. V trace uvidíte, že navigation timing začína pri aktivácii, nie pri kliku, a všetky sub-resource requesty už chýbajú, pretože sú hotové. Rozdiel medzi activateStart a LCP je typicky pod 50 ms.

3. RUM cez PerformanceNavigationTiming

Pre agregátne dáta z produkcie čítajte PerformanceNavigationTiming, ktorý má od 2024 nový atribút activationStart.

const nav = performance.getEntriesByType('navigation')[0];
if (nav.activationStart > 0) {
  // Táto navigácia použila prerender!
  const saved = nav.activationStart; // koľko ms sme ušetrili
  reportMetric('prerender_saved_ms', saved);
  reportMetric('prerender_hit', 1);
} else {
  reportMetric('prerender_hit', 0);
}

V praxi sledujem tri KPI: prerender hit rate (kliky, ktoré trafili pripravený dokument / všetky kliky), priemerné saved ms, a memory-bounded eviction rate (koľko špekulácií Chrome zrušil pre kvótu). Ak hit rate klesne pod 30 %, buď je eagerness príliš konzervatívny, alebo No-Vary-Search nie je nakonfigurovaný. Ak eviction rate presiahne 20 %, ste príliš agresívni a treba prejsť z prerender na prefetch pre časť URL.

Časté chyby, ktoré zabíjajú prerender

Toto je zoznam problémov, ktoré vidím opakovane pri audit engagement. Do jedného som narazil naposledy pri e-shope, kde prerender ticho nefungoval mesiace a nikto to nezachytil.

• Cookie banner blokuje analytics init: ak čakáte na consent pred inicializáciou GA, počas prerender consent event nikdy nepríde. Musíte poslúchať prerenderingchange a init odložiť.
• Chýbajúci Sec-Purpose: prefetch;prerender handling na serveri: Chrome pri špekulatívnych requestoch posiela túto hlavičku. Ak váš backend na jej základe skipuje session update alebo drahé logging, ušetríte prostriedky a nevytvoríte falošné auth zápisy.
• Prerender pre stránky s window.location.href redirectom: Chrome takýto skript pri prerender detekuje ako „mandatory" a zruší celý proces. Použite <meta http-equiv="refresh"> len ak viete, že cieľ je stabilný.
• Príliš široký href_matches: "/*" bez not filtrov: prefetchnete si aj /api/* endpoints, RSS feed, sitemap.xml. Vždy pridávajte negatívne filtre.
• Ignorovanie CSP script-src: <script type="speculationrules"> je stále script. Ak máte striktné CSP, potrebujete 'inline-speculation-rules' keyword (Chrome 116+) alebo nonce.
• Kombinácia s klasickým <link rel="prefetch">: nie je to chyba per se, ale duplicitná práca. Speculation Rules zastreší oba use-case a lepšie sa prispôsobia.

Ak už sledujete INP a odozvu hlavného vlákna prehliadača, prerender vám nepokazí metriky, keďže beží v samostatnom procese, takže main thread aktívnej stránky ostáva čistý. Naopak, po aktivácii dostanete INP prakticky nulové, pretože všetok JS je už pripravený. Podobne nižšie TTFB zvyšuje pravdepodobnosť, že prerender stihne dokončiť pred klikom.

Často kladené otázky

Čo je rozdiel medzi Speculation Rules a starším link rel="prefetch"?

Klasický <link rel="prefetch"> stiahne HTML len do HTTP cache a bez podpory prerender. Speculation Rules API má samostatnú in-memory cache, podporuje plnohodnotný prerender vrátane JavaScript execution, deklaratívne document rules s CSS selektormi a integráciu s No-Vary-Search. V roku 2026 je Speculation Rules nadstavba nad starším API a odporúčaný default.

Podporuje Firefox alebo Safari Speculation Rules API?

K augustu 2026 nie. Chrome a Edge podporujú prerender od verzie 121, prefetch od 111. Safari má feature „Under Consideration" na webkit.org/status, Firefox nemá verejný implementation ticket. Používajte to ako čisto progresívne vylepšenie: používatelia iných prehliadačov dostanú štandardnú navigáciu bez chyby.

Ako zabránim tomu, aby prerender falšoval pageviews v Google Analytics?

Zabaľte tracking kód do kontroly if (document.prerendering) { document.addEventListener('prerenderingchange', trackPageview) } else { trackPageview() }. GTM od 2024 má vstavaný prerender check pre GA4 tag; pre vlastné pixely to musíte spraviť ručne.

Môžem prerenderovať cross-origin stránky?

Prerender je od Chrome 121 povolený iba pre same-origin. Cross-origin prefetch je možný, ale vyžaduje requires: ["anonymous-client-ip-when-cross-origin"], čo posiela request bez IP klienta. Pre plný cross-origin prerender by ste potrebovali speciálny CDN setup, čo v praxi takmer nikto nerobí.

Nezaťaží prerender príliš batériu a mobilné dáta?

Chrome má vstavané ochrany: na mobile s Data Saver módom prerender automaticky vypne, pri slabom sieťovom pripojení (2G/slow-3G) prejde na prefetch-only. Kvóty (max 10 prerender, 10 MB agregátne) obmedzujú worst-case dopad. Napriek tomu odporúčam eagerness moderate alebo conservative, immediate len pre 1 až 3 URL, ktoré si viete obhájiť.