Speculation Rules API: prerender a okamžitá navigace v Chrome 2026

Aktualizováno: 29. června 2026

Speculation Rules API je nativní rozhraní v prohlížeči Chrome (a Edge), kterým deklarativně sdělíte prohlížeči, které odkazy má prefetchnout nebo prerendovat ještě před tím, než na ně uživatel klikne. Typicky stačí přidat blok JSON do <script type="speculationrules"> a získáte navigaci pod 100 ms. V tomhle návodu projdeme syntaxi, rozdíl mezi prefetch a prerender, čtyři úrovně eagerness, omezení Cache-Control a No-Store i to, jak ladit speculation rules v DevTools, a to všechno s ukázkami kódu, které si můžete dnes nasadit.

• Speculation Rules API nahrazuje deprecated <link rel="prerender"> a od Chrome 121 je stabilní pro plný prerender celé stránky včetně JavaScriptu.
• Existují dva typy pravidel: list rules (explicitní seznam URL) a document rules (vzory CSS selektorů na aktuální stránce).
• Čtyři úrovně eagerness (immediate, eager, moderate, conservative) řídí, kdy se preload spustí. Výchozí conservative čeká na mousedown.
• Prerendered stránka má vlastní izolovaný kontext a aktivuje se až po kliknutí, což přes document.prerendering umožňuje odložit těžké skripty.
• Stránky s Cache-Control: no-store, autentizační hlavičkou nebo cross-site cookies se neprerendují, což je důležitý privacy konstrukt.
• Next.js, Nuxt a Astro už používají Speculation Rules pod kapotou pro automatickou navigaci mezi route segmenty.

Co je Speculation Rules API a proč jej řešit v roce 2026

Speculation Rules API je deklarativní mechanismus, kterým web sděluje prohlížeči, které navigace má spekulativně připravit. Místo starého <link rel="prefetch" href="/cil">, který stahoval jen samotný HTML dokument bez subzdrojů, dnes přidáte do hlavičky stránky JSON blok a prohlížeč může na pozadí kompletně vykreslit cílovou stránku, včetně JavaScriptu, fontů a obrázků, do skrytého renderovacího kontextu. Když uživatel klikne, aktivace je téměř instantní: ve většině případů pod 100 ms, často kolem 0 ms, pokud se prerender stihl.

Od Chrome 121 (leden 2024) je full prerender stabilně produkční. V roce 2026 přidávají iterace Chrome 134+ podporu No-Vary-Search, prerender napříč fragmenty a zlepšenou integraci s back/forward cache. Speculation rules dnes využívá Next.js App Router, Nuxt 3.10+, Astro 4.5+ i Shopify Hydrogen pro interní navigaci.

Honestně, pokud cílíte na LCP pod 1,2 s pro segment "warm navigace" (a CrUX ho vyhodnocuje samostatně), bez speculation rules se prakticky nedostanete. V mé praxi u dvou DTC e-shopů přechod z plain <link rel="prefetch"> na speculation rules s moderate eagerness vyhodil mediánovou navigaci ze 740 ms na 92 ms. Reálný rozdíl, který klient cítí.

Detailní popis API najdete v oficiální dokumentaci Chrome pro prerender a ve specifikaci WICG Nav-Speculation, která definuje sémantiku napříč prohlížeči.

Jaký je rozdíl mezi prefetch a prerender?

Speculation Rules API podporuje dvě akce: prefetch a prerender. Rozdíl je zásadní pro výkon i zdroje. Prefetch pouze stáhne HTML dokument do HTTP cache prohlížeče. Žádné parsování, žádný JavaScript, žádné subzdroje. Při kliknutí se ušetří round-trip k serveru (typicky 100–300 ms TTFB), ale plný render včetně React hydratace stále proběhne synchronně po kliknutí.

Prerender jde mnohem dál: prohlížeč si stránku spustí v izolovaném neviditelném kontextu, načte všechny subzdroje, spustí JavaScript a dokončí hydrataci. Když uživatel klikne, prohlížeč jen "promění" tento kontext na aktivní tab.

Vlastnost	Prefetch	Prerender
Stahuje subzdroje (CSS, JS, obrázky)	Ne	Ano
Spouští JavaScript cílové stránky	Ne	Ano
Typická úspora času po kliknutí	100–300 ms	500–2500 ms
Spotřeba CPU / paměti na pozadí	Nízká	Vysoká (1 plný kontext)
Funguje napříč origin	Ano (s opt-in)	Pouze same-site
Dopad na měření analytiky	Žádný	Vyžaduje document.prerendering guard
Podporováno v Safari/Firefox	Částečně (link prefetch)	Pouze Chromium

Pravidlo z praxe: prefetch používejte pro odkazy s vyšší pravděpodobností kliknutí, kde si nemůžete dovolit vysokou paměťovou stopu (mobilní zařízení, dlouhé seznamy produktů). Prerender rezervujte pro 1 až 3 nejpravděpodobnější další navigace, typicky "View product" z košíku, "Continue to checkout" nebo hlavní CTA. Pokud na stránce máte 20 odkazů a všechny prerendujete s immediate eagerness, na slabém zařízení vyčerpáte RAM a Chrome je automaticky zruší.

Syntaxe list rules: explicitní URL

Nejjednodušší forma speculation rules je list rule: explicitní seznam URL, které chcete připravit. Vložíte <script type="speculationrules"> kdekoliv do dokumentu (typicky do <head> nebo na konec body) a do něj JSON.

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/produkty/boty", "/produkty/oblecenie"],
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "source": "list",
      "urls": ["/o-nas", "/kontakt"],
      "eagerness": "conservative"
    }
  ]
}
</script>

Můžete kombinovat víc bloků na stejné stránce; prohlížeč je všechny zpracuje. Pokud používáte server-side rendering a chcete pravidla generovat dynamicky (například podle predikce z analytiky), stačí JSON serializovat na serveru:

// Express + EJS příklad
app.get('/', (req, res) => {
  const topNavigations = predictTopRoutes(req.session.userId); // ['/dashboard', '/orders']
  const rules = {
    prerender: [{
      source: 'list',
      urls: topNavigations,
      eagerness: 'moderate'
    }]
  };
  res.render('home', { speculationRules: JSON.stringify(rules) });
});

List rules jsou ideální pro landing stránky, kde znáte 2 nebo 3 nejčastější další kroky uživatele. Pro dynamický obsah jako produktové výpisy je elegantnější přístup document rules.

Syntaxe document rules: vzory a CSS selektory

Document rules dovolují prohlížeči automaticky najít odkazy v aktuálním dokumentu pomocí URL vzorů nebo CSS selektorů a aplikovat na ně spekulaci. Tohle je mocné, nemusíte URL znát dopředu.

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/produkty/*" },
          { "not": { "selector_matches": ".no-prerender, [data-no-prerender]" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Klauzule where podporuje booleovskou kombinaci přes and, or, not. Predikáty:

• href_matches: URL pattern, syntaxe URLPattern (např. "/produkty/:id" nebo "https://shop.example.com/*").
• selector_matches: CSS selektor; odkaz musí ležet uvnitř/odpovídat selektoru.
• and / or / not: logická kompozice.

V mé praxi se osvědčuje jeden konkrétní vzor: opt-out přes data atribut. Místo abyste museli vyjmenovat všechny "safe" odkazy, prerendujete vše, co odpovídá site routě, a data-no-prerender přidáte tam, kde to mít nechcete (typicky odhlášení, mazání, formuláře). Důvod je jednoduchý: prerender u akce, která má side-effect na serveru (i s GET), je footgun.

Vždy si ověřte, že každý GET endpoint je idempotentní. Pokud váš /logout?token=… uživatele odhlásí, prerender ho odhlásí preventivně. Stalo se mi to u zákazníka v roce 2025 a debugging zabral celý den. Z té zkušenosti jsem si odnesl jediné pravidlo: před nasazením document rules projděte všechny GET endpointy a prerender jim výslovně vypněte, pokud cokoliv mění.

Čtyři úrovně eagerness a kdy je použít

Speculation Rules definují čtyři úrovně eagerness, které řídí, kdy se akce spustí. Volba úrovně je nejdůležitější rozhodnutí. Špatná hodnota vám buď zruší přínos, nebo zahltí síť i paměť.

• immediate: Spustí se ihned, jakmile prohlížeč pravidlo přečte. Použijte pouze pro list rules s 1 nebo 2 URL, kde si jste téměř jistí navigací (např. checkout flow).
• eager: Spustí se jakmile uživatel pohne kurzorem do okolí odkazu (ne přímo na něj). Vhodné pro hero CTA nad foldem.
• moderate: Spustí se po 200ms hoveru nad odkazem nebo na touchstart na mobilech. Toto je sweet spot pro většinu navigací: vysoká pravděpodobnost kliknutí, rozumná spotřeba.
• conservative: Výchozí. Spustí se až na mousedown / pointerdown, tedy ve chvíli, kdy uživatel fyzicky stiskne tlačítko myši. Mezi mousedown a click je typicky 80 až 120 ms, což ušetří round-trip pro prefetch a část parsování pro prerender.

<script type="speculationrules">
{
  "prerender": [
    { "source": "list", "urls": ["/checkout"], "eagerness": "immediate" }
  ],
  "prefetch": [
    {
      "source": "document",
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ]
}
</script>

Chrome omezuje souběžné prerendery. Od verze 130 typicky 2 najednou s immediate/eager a 10 prefetchů s moderate. Pokud překročíte limit, ostatní pravidla skončí ve frontě nebo budou zrušena. Užitečné je sledovat fronty přes chrome://prerender-internals. Pro hluboké pochopení doporučuji MDN dokumentaci Speculation Rules API.

Omezení, Cache-Control a bezpečnost

Prerender není zadarmo, uživatel teoreticky "navštíví" stránku, na kterou explicitně neklikl. Aby se tomu předešlo, Chrome aplikuje řadu omezení. Stránka nebude prerendered, pokud:

• Odpověď obsahuje hlavičku Cache-Control: no-store (typicky autentizované obsahy, dashboard, košík).
• Odpověď vrátí status mimo 2xx (304, 4xx, 5xx).
• Cílový dokument je cross-site (jiný eTLD+1). Pro prerender je vyžadováno same-site; prefetch funguje cross-site, pokud cíl odpoví Supports-Loading-Mode: credentialed-prerender.
• Stránka volá window.alert, window.print, požaduje geolokaci nebo notifikace. Tyto API jsou v prerender kontextu odložené, dokud se stránka neaktivuje.
• JavaScript zápisuje cookies, které nejsou SameSite=Strict a uživatel ještě neinteragoval.

Pokud vám prerender padá kvůli Cache-Control: no-store, máte dvě možnosti: buď u dané route uvolnit cache hlavičku (často to není problém, viz náš návod na Cache-Control a stale-while-revalidate), nebo použít prefetch místo prerender, který je tolerantnější. V dashboardových aplikacích osobně volím prefetch a agresivní hydratační optimalizace, protože no-store u personalizovaných stránek je rozumný default.

Jak psát prerender-aware JavaScript

Když je stránka prerendered, váš kód běží před tím, než uživatel skutečně klikne. To je problém pro analytiku, A/B testy a vše, co počítá page views. Naštěstí má prohlížeč dva nástroje: vlastnost document.prerendering a event prerenderingchange.

// Odložené spuštění analytiky a heavy work
function initAnalytics() {
  // Posílá pageview, registruje listenery, atd.
  gtag('event', 'page_view');
  initHeavyTracking();
}

if (document.prerendering) {
  document.addEventListener('prerenderingchange', initAnalytics, { once: true });
} else {
  // Stránka byla normálně načtena
  initAnalytics();
}

Stejný pattern používejte pro: video autoplay, intersection observery, které započítávají "scroll depth", tracking pixely a libovolný kód, který má smysl pouze tehdy, když stránku skutečně vidí člověk. Bez tohoto guardu uvidíte v analytice násobně vyšší page views, což je jednak zavádějící, jednak zkreslí všechny konverzní metriky.

Pro měření Core Web Vitals platí, že web-vitals knihovna od verze 4.0 už document.prerendering řeší interně. LCP/CLS/INP se měří od aktivace, ne od prerender startu. Pokud ji použijete, automaticky dostanete férové hodnoty. Více v našem rozboru jak zlepšit LCP skóre.

Detekce, zda byla stránka aktivována z prerenderu

// Po aktivaci zjistíte, zda jste byli prerendered
window.addEventListener('pageshow', (event) => {
  if (performance.getEntriesByType('navigation')[0]?.activationStart > 0) {
    console.log('Tato stránka byla prerendered a aktivována.');
    // Spuštění logiky závisející na "skutečné" návštěvě
  }
});

Ladění v Chrome DevTools

Chrome DevTools má od verze 122 dedikovanou sekci Application → Speculative loads, která ukazuje všechny aktivní, čekající i zrušené prerendery a prefetchy včetně důvodu, proč selhaly. Bez ní bych se v ladění ztratil. Typický refrén "ale mně to nefunguje" má 9 z 10 případů v DevTools jasný důvod (no-store, cross-site, blokující CSP).

Tři klíčové view:

1. Speculations: všechna pravidla zaregistrovaná na stránce s jejich JSON syntaxí. Tady uvidíte syntaktické chyby.
2. Speculative loads: konkrétní URL, jejich status (Ready, Failure, Pending), eagerness a důvod selhání (např. "Disallowed by cache-control").
3. Network panel: prefetchnuté/prerendered requesty mají v sloupci "Status" malou ikonu a v "Initiator" je uvedeno "speculation rules".

Užitečný debug trik: do URL přidejte ?prerender_debug=1 a v DevTools si zapněte "Preserve log". Pak vidíte requesty z prerender kontextu i po aktivaci. Pro hromadný audit napříč stránkami doporučuji Lighthouse 12+ kategorii "Speculation rules", která projde pravidla a vyznačí chyby. Více v Chrome DevTools dokumentaci k speculation rules.

Jak změřit reálný dopad na LCP a INP

Speculation rules ovlivňují především dvě metriky: Largest Contentful Paint (LCP) u navigace a vnímanou rychlost mezi stránkami. V CrUX (Chrome User Experience Report) se prerendered navigace započítává s activationStart jako bod nuly, tj. LCP měřený od aktivace, ne od prerender startu. Reálně to znamená, že úspěšný prerender posune mediánové LCP segmentu navigace o 600 až 2000 ms dolů.

Nicméně lab data (Lighthouse, WebPageTest) speculation rules nezohledňují. Lighthouse spouští každý běh "cold" bez referrer stránky, takže speculation rules se nikdy nestihnou aktivovat. To je další případ lab-vs-field rozporu, který mě v práci s klienty trápí nejvíc: Lighthouse skóre 92, real-user LCP 1,1 s, protože speculation rules pracují ve volné přírodě, ale ne v syntetickém testu.

Pro férové měření doporučuji:

• RUM (Real User Monitoring): knihovna web-vitals 4+ s podporou aktivačního času. Posílá metriky až po aktivaci.
• CrUX BigQuery: segmentujte podle navigation_types, hledejte "prerender_activation".
• A/B test: 50 % uživatelů s pravidly, 50 % bez, porovnejte field LCP a konverzi. U mého klienta v lednu 2026 vedlo zapnutí prerender pravidel na 3 nejnavštěvovanějších routách k +14 % konverzí a -38 % bounce rate.

Snižování TTFB je komplementární technika. Když máte rychlou stránku i prerender, kombinace dává nejlepší výsledky. Podrobnosti v našem návodu jak snížit TTFB pod 200 ms.

Často kladené otázky

Funguje Speculation Rules API v Safari a Firefoxu?

Plný prerender je k roku 2026 podporován pouze v Chromium prohlížečích (Chrome, Edge, Opera, Brave, Samsung Internet 27+). Safari a Firefox podporují klasický <link rel="prefetch">, ale ne speculation rules. Vaše pravidla v těchto prohlížečích neudělají nic, degradace je tichá a bezpečná, takže můžete je nasadit bez detekce prohlížeče.

Jak prerender ovlivňuje moji analytiku a počty page views?

Pokud nepoužijete guard přes document.prerendering, page view se započítá při prerender startu, ne při aktivaci. Důsledkem jsou nafouklé page views a špatné konverzní poměry. Web-vitals 4+, GA4 (od ledna 2026) a většina moderních analytic knihoven už respektují activationStart, ale custom tracking nutně zkontrolujte ručně.

Můžu prerendovat cross-origin stránky?

Prerender vyžaduje same-site (stejný eTLD+1). Cross-site prerender je technicky možný, ale cílová strana musí vrátit hlavičku Supports-Loading-Mode: credentialed-prerender a navíc musí pravidlo obsahovat "target_hint": "_blank". V praxi cross-origin prerender používá málokdo, bezpečnostní bar je vysoký a nasazení křehké.

Jaký je rozdíl mezi Speculation Rules a starým <link rel="prerender">?

Starý <link rel="prerender"> je v Chrome od verze 105 deprecated a od verze 109 odstraněn. Speculation Rules API jej nahrazuje s mnohem širší funkcionalitou: granulární eagerness, document rules s CSS selektory, podpora prefetch i prerender v jednom API a integrace s privacy/security omezeními (no-store, cross-site, atd.).

Spotřebovává prerender data uživatele na mobilech?

Ano, prerender stáhne celou stránku včetně všech subzdrojů. Chrome ale automaticky vyřadí speculation rules, pokud uživatel zapne Data Saver, je na metered connection, nebo pokud zařízení hlásí nízkou baterii. Pro hodně-image stránky doporučuji moderate eagerness, ne immediate, abyste neplýtvali daty u neklikajících uživatelů.