Speculation Rules API 2026: azonnali oldalnavigáció prefetch és prerender technikákkal

Miért érdemes foglalkozni a Speculation Rules API-val 2026-ban?

Képzeld el, hogy a felhasználó rákattint egy linkre, és az oldal — szó szerint — azonnal megjelenik. Nem 1-2 másodperc, nem fél másodperc. Azonnal. Mintha a böngésző valahogy tudta volna, mi lesz a következő lépés. Nos, pontosan erről szól a Speculation Rules API: a böngésző előre letölti, sőt akár rendereli is a következő oldalt, még mielőtt bárki rákattintana.

A Speculation Rules API a Chrome csapat webes szabványa, amely a régi <link rel="prerender"> megoldást váltja ki. 2026-ban már production-ready a Chromium-alapú böngészőkben (Chrome 108+, Edge 108+, Opera), és a WordPress 6.8 is beépítetten támogatja.

A valós mérések egyébként elég meggyőzőek: a P75-ös LCP akár 170-500 ms-sel is javulhat, a Ray-Ban pedig 156%-os konverziónövekedést ért el asztali gépeken a spekulatív előtöltéssel. Nem rossz egy pár soros JSON konfigurációért, ugye?

Ebben az útmutatóban végigmegyünk mindenen, amit a Speculation Rules API-ról tudnod kell: hogyan működik, hogyan implementáld, milyen buktatókra figyelj, és hogyan integráld WordPress vagy egyedi projektekbe.

Hogyan működik a Speculation Rules API?

A lényeg viszonylag egyszerű. JSON formátumú szabályokat definiálsz, amelyek megmondják a böngészőnek, mely oldalakat töltse elő (prefetch) vagy renderlje elő (prerender) a háttérben. A szabályokat inline <script type="speculationrules"> elemben vagy HTTP fejlécben adhatod meg.

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

A két spekulatív művelet között alapvető különbség van:

• Prefetch (előtöltés): Letölti az oldal erőforrásait (HTML, CSS, JS), de nem rendereli. Navigáláskor az oldalt még renderelni kell. Alacsonyabb erőforrásigényű, szélesebb körben alkalmazható.
• Prerender (előrenderelés): Letölti ÉS rendereli az oldalt egy láthatatlan háttértabban. Navigáláskor a böngésző egyszerűen aktiválja ezt a tabot — az eredmény gyakorlatilag nulla TTFB a felhasználó szemszögéből. Cserébe magasabb az erőforrásigénye, úgyhogy célzottabb használat javasolt.

Az alapszabály tehát: prefetch-et széles körben alkalmazz (például az összes fontos oldalra), prerender-t pedig célzottan, ahol nagy a valószínűsége, hogy a felhasználó tényleg oda fog navigálni.

Alapvető implementáció: URL lista szabályok

A legegyszerűbb megvalósítás az URL lista (list rules), ahol konkrétan megadod, mely oldalakat kell előtölteni:

<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["/rolunk", "/kapcsolat", "/szolgaltatasok"]
    }
  ],
  "prerender": [
    {
      "urls": ["/fooldal-termek", "/legkelendobb"]
    }
  ]
}
</script>

Ez a megközelítés akkor ideális, ha pontosan tudod, mely oldalakra navigálnak leggyakrabban a felhasználóid. Az URL lista szabályok alapértelmezetten immediate eagerness-t használnak, tehát a böngésző azonnal nekiáll az előtöltésnek, amint a szabályokat feldolgozta.

Haladó implementáció: document szabályok

Na, itt válik igazán érdekessé a dolog. A valós projektekben a document szabályok (document rules) sokkal rugalmasabbak. Ahelyett, hogy egyenként felsorolnád az URL-eket, mintákat és CSS szelektor illesztést használhatsz — a böngésző magától megtalálja a releváns linkeket az oldalon.

Minta-alapú illesztés href_matches-szel

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

Ez a szabály lényegében azt mondja: „renderelj elő minden belső linket, KIVÉVE a kijelentkezés, kosár és fizetés oldalakat, illetve azokat, amelyeken a .no-prerender osztály van." A moderate eagerness pedig azt jelenti, hogy mindez csak akkor történik meg, ha a felhasználó legalább 200 ms-ig az egérrel a link fölé mutat.

CSS szelektor illesztés

<script type="speculationrules">
{
  "prefetch": [
    {
      "where": {
        "selector_matches": "nav a, .cikk-kartya a, .ajanlott-cikkek a"
      },
      "eagerness": "moderate"
    }
  ],
  "prerender": [
    {
      "where": {
        "selector_matches": "nav a.fo-navigacio"
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

Ez a kétszintű megközelítés jól demonstrálja a bevált gyakorlatot: prefetch a szélesebb körű linkekre (navigáció, cikkkártyák), prerender pedig csak a legfontosabb navigációs elemekre. Egyszerű, mégis hatékony.

Az eagerness beállítás megértése

Az eagerness (szó szerint: „lelkesség") az egyik legfontosabb döntés a Speculation Rules implementálásakor. Ez határozza meg, mikor kezdi el a böngésző a spekulatív műveletet:

• immediate: Azonnal végrehajtja a spekulációt, amint a szabályok betöltődnek. Ez az alapértelmezés az URL lista szabályoknál. Óvatosan használd document szabályokkal — rengeteg oldalt előrenderelhet feleslegesen.
• eager: Chrome 143-tól asztali gépen 10 ms-os hover után aktiválódik, mobilon pedig 50 ms-cel a link viewportba kerülése után (2026 januárjától).
• moderate: 200 ms-os hover után aktiválódik (vagy pointerdown eseményre, ha az hamarabb jön). Mobilon a pointerdown az elsődleges trigger. Ez a legjobb egyensúly teljesítmény és erőforrás-felhasználás között — személyes tapasztalatom szerint is ezt érdemes alapértelmezésnek választani.
• conservative: Csak pointerdown vagy touchstart eseményre aktiválódik, tehát amikor a felhasználó már megkezdte a kattintást. Ez az alapértelmezés document szabályoknál.

A conservative beállításnál jogos a kérdés: van értelme, ha a felhasználó már úgyis kattint? A válasz meglepően egyszerű: a háttérben történő betöltés már az egérgomb lenyomásakor elindul, a tényleges navigáció viszont csak a felengedésnél. Ez a néhány száz milliszekundum is érezhető különbséget jelent — különösen mobilon, ahol a tap interakció időtartama hosszabb.

HTTP fejléc alapú megvalósítás

Ha nem akarsz <script> elemekkel telezsúfolni minden oldalt, használhatsz HTTP fejlécet is. Ez különösen hasznos dinamikus oldalaknál, ahol szerver oldalon szeretnéd vezérelni a szabályokat:

# Nginx konfiguráció
location / {
    add_header Speculation-Rules "/speculation-rules.json";
}

# Apache .htaccess
Header set Speculation-Rules "/speculation-rules.json"

A speculation-rules.json fájl tartalma:

{
  "prefetch": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/api/*" } },
          { "not": { "href_matches": "/admin/*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}

Ennek a megoldásnak az a nagy előnye, hogy a szabályokat egy helyen, szerver oldalon kezeled — nem kell minden egyes HTML sablont módosítanod.

WordPress integráció

A WordPress 6.8-tól kezdve a spekulatív betöltés beépített funkció. Alapértelmezetten prefetch + conservative eagerness beállítással működik, ami biztonságos, de őszintén szólva nem a leghatékonyabb konfiguráció.

Speculative Loading plugin

A WordPress Performance Team (Google fejlesztőkkel együttműködve) által készített Speculative Loading plugin kibővíti az alapértelmezett beállításokat. A plugin alapértelmezése prerender + moderate eagerness, ami lényegesen jobb teljesítményt nyújt:

// WordPress Speculative Loading plugin beállítás testreszabása
// functions.php fájlba
add_filter( 'wp_speculation_rules_configuration', function( $config ) {
    // Prerender moderate eagerness beállítással
    $config['mode'] = 'prerender';
    $config['eagerness'] = 'moderate';
    return $config;
});

// Bizonyos URL-ek kizárása a spekulatív betöltésből
add_filter( 'wp_speculation_rules_href_exclude_paths', function( $exclude_paths ) {
    $exclude_paths[] = '/kosar/*';
    $exclude_paths[] = '/penztar/*';
    $exclude_paths[] = '/fiokom/*';
    return $exclude_paths;
});

Fontos tudni: alapértelmezetten a spekulatív betöltés csak kijelentkezett felhasználóknak aktív, mivel a hitelesített oldalak jellemzően nem gyorsítótárazhatók. E-kereskedelmi vagy közösségi oldalaknál, ahol sok a bejelentkezett felhasználó, ez korlátozhatja a funkció hasznosságát (sajnos).

Egyedi implementáció JavaScript-tel

Komplexebb esetekben dinamikusan is injektálhatsz speculation rules-t JavaScript segítségével. Ez akkor jön jól, ha a felhasználói viselkedés alapján szeretnéd finomhangolni az előtöltési stratégiát:

// Dinamikus speculation rules injektálás
function addSpeculationRules(urls, action = 'prefetch', eagerness = 'moderate') {
  // Böngészőtámogatás ellenőrzése
  if (!HTMLScriptElement.supports ||
      !HTMLScriptElement.supports('speculationrules')) {
    console.log('Speculation Rules API nem támogatott');
    return;
  }

  const rules = {
    [action]: [{
      urls: urls,
      eagerness: eagerness
    }]
  };

  const script = document.createElement('script');
  script.type = 'speculationrules';
  script.textContent = JSON.stringify(rules);
  document.head.appendChild(script);
}

// Használat: a leggyakrabban látogatott oldalak előrenderelése
addSpeculationRules(
  ['/termekek', '/akciok', '/ujdonsagok'],
  'prerender',
  'moderate'
);

// Analitika alapján a legvalószínűbb következő oldal
const topNextPages = getTopNextPagesFromAnalytics();
addSpeculationRules(topNextPages, 'prefetch', 'eager');

Prerender állapot detektálása

Ha az oldalad analitikát, hirdetéskövetést vagy más mellékhatással járó kódot futtat, nagyon fontos detektálni, hogy az oldal éppen előrenderelés alatt áll-e. Ha ezt kihagyod, garantált a fejfájás.

// Ellenőrzés: előrenderelés alatt vagyunk-e?
if (document.prerendering) {
  console.log('Az oldal előrenderelés alatt áll');

  // Analitika és mellékhatások késleltetése
  document.addEventListener('prerenderingchange', () => {
    // Az oldal most vált aktívvá — biztonságos a futtatás
    initAnalytics();
    trackPageView();
    initAdTracking();
  });
} else {
  // Normál betöltés — azonnal futtathatjuk
  initAnalytics();
  trackPageView();
  initAdTracking();
}

Ez tényleg kritikus lépés. Enélkül az analitika dupla oldalmegtekintést rögzít, a hirdetésrendszerek meg hibás konverziós adatokat mutatnak — és utána hetekig keresheted, mi a baj.

Biztonsági szempontok és kizárások

Nem minden oldal alkalmas spekulatív előtöltésre. A következő URL-eket mindig zárd ki:

• Kijelentkezés URL-ek: Az előrenderelés végrehajthatja a kijelentkezést a háttérben. (Igen, ez tényleg megtörténhet.)
• Nyelvváltó URL-ek: Megváltoztathatják a felhasználó nyelvi beállítását.
• OTP/SMS küldő URL-ek: A szerver oldali mellékhatás nem kívánt SMS-eket küldhet.
• Kosár és fizetési URL-ek: A felhasználó nem várt állapotváltozásokat tapasztalhat.
• Felhasználás-számlálót módosító URL-ek: Például API kvóta vagy letöltésszámláló.

Adatvédelmi szempontból is jó tudni: a cross-site prefetch jelenleg csak akkor működik, ha a felhasználónak nincsenek cookie-jai a céltartomány felé. Ez megakadályozza a cookie-kon keresztüli követést az előtöltött oldalak között.

Böngésző korlátok és feltételek

A Chrome több korlátozást is alkalmaz a Speculation Rules API-ra, és ezeket érdemes ismerni, mielőtt élesben bevezeted:

• Memória korlátok: Maximum 50 prefetch és 10 prerender tartható memóriában egyszerre (immediate vagy eager eagerness esetén).
• Energiatakarékos mód: Alacsony akkumulátorszintnél a böngésző kikapcsolja a spekulációkat.
• Memória-korlátozás: Ha a rendszer memóriája alacsony, a spekulációk szünetelnek.
• Háttértabok: A háttérben nyitott oldalaknál nem futnak spekulációk.
• Felhasználói beállítás: A „Preload pages" beállítás kikapcsolása meggátolja a spekulációkat.

Böngésző támogatás 2026-ban

Szóval, hogy áll a támogatottság jelenleg?

• Chrome 108+ — teljes támogatás
• Edge 108+ — teljes támogatás
• Opera — teljes támogatás
• Safari — működő implementáció létezik, de alapértelmezetten nincs bekapcsolva
• Firefox — még nincs támogatás

A jó hír viszont az, hogy ha a böngésző nem támogatja a Speculation Rules API-t, egyszerűen figyelmen kívül hagyja a <script type="speculationrules"> elemet — semmi nem törik el. Progresszív fejlesztésként (progressive enhancement) tökéletesen működik, tehát nincs kockázata a bevezetésnek.

Hibakeresés Chrome DevTools-ban

A spekulatív betöltés hibakeresése szerencsére nem bonyolult. A következő lépéseket kövesd:

1. Nyisd meg a DevTools-t (F12 vagy Ctrl+Shift+I).
2. Navigálj az Application fülre.
3. A bal oldali menüben keresd a Background Services > Speculative Loads > Speculations részt.
4. Fontos: Nyisd meg ezt a panelt mielőtt betöltöd a tesztelni kívánt oldalt — különben nem fog adatokat mutatni.
5. Most töltsd be az oldalt, és a DevTools megjeleníti az összes spekulációt, azok állapotát és az esetleges hibákat.

A Network fülön is nyomon követheted a prefetch kéréseket: keresd a Purpose: prefetch jelölésű kéréseket a fejlécekben.

Valós teljesítményeredmények

A Speculation Rules API nem csak papíron hoz javulást. Íme néhány valós mérési eredmény, ami meggyőzhet:

• Scalemates weboldal: A P95-ös LCP ~500 ms-sel, a P75-ös LCP ~170 ms-sel javult. A navigációk 59%-a aktiválta az előrenderelést.
• Ray-Ban: Asztali gépeken 156%-os konverziónövekedést ért el a spekulatív előtöltéssel.
• Általános tendencia: A Core Web Vitals összes küszöbértékét teljesítő oldalak 24%-kal alacsonyabb visszafordulási arányt mutatnak.

A tapasztalat az, hogy a legjobb eredményeket azok az oldalak érik el, ahol a navigációs minták kiszámíthatók — gondolj e-kereskedelmi termékoldalakra, blogok cikk navigációjára, vagy dokumentációs oldalak szekvenciális tartalmára.

Lépésről lépésre: implementáció a gyakorlatban

Íme egy bevált, fokozatos implementációs terv. Az én ajánlásom: ne ugorj be a mély vízbe, hanem szépen, lépésről lépésre haladj.

1. lépés: Alapvető prefetch bevezetése

Kezdd a legbiztonságosabb konfigurációval — prefetch + conservative eagerness:

<script type="speculationrules">
{
  "prefetch": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/kijelentkezes" } },
          { "not": { "href_matches": "/api/*" } }
        ]
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

2. lépés: Eagerness növelése

Ha a prefetch stabil és nem látsz problémát, emeld az eagerness-t moderate-ra, és add hozzá a prerender-t a legfontosabb oldalakra:

<script type="speculationrules">
{
  "prefetch": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ],
  "prerender": [
    {
      "where": {
        "selector_matches": "nav a"
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

3. lépés: Finomhangolás analitika alapján

Vizsgáld meg az analitikádat, és azonosítsd a leggyakoribb navigációs útvonalakat. Ezekre alkalmazz célzott prerender + moderate eagerness beállítást:

<script type="speculationrules">
{
  "prefetch": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/kijelentkezes" } },
          { "not": { "href_matches": "/kosar/*" } },
          { "not": { "selector_matches": ".no-prerender" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prerender": [
    {
      "where": {
        "selector_matches": "nav a, .kiemelt-termek a, .kovetkezo-cikk a"
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

GYIK — Gyakran Ismételt Kérdések

Működik a Speculation Rules API egyoldalas alkalmazásokkal (SPA)?

Sajnos nem. A Speculation Rules API kifejezetten többoldalas alkalmazásokhoz (MPA) készült. SPA-k esetén a keretrendszered saját megoldását használd — például a Next.js Link komponens prefetch tulajdonságát, vagy a React Router lazy loading funkcióját.

Mennyibe kerül erőforrás szempontjából a prerender?

Lényegesen többet fogyaszt, mint a prefetch, mivel a teljes oldalt rendereli egy láthatatlan háttértabban. A Chrome maximum 10 prerender oldalt tart memóriában egyszerre. Ha a felhasználó nem navigál az előrenderelt oldalra, az erőforrás elvész — bár a HTTP cache-ben maradhatnak az erőforrások, ha a fejlécek engedélyezik.

Hogyan mérem a hatását a Core Web Vitals mutatókra?

A Chrome User Experience Report (CrUX) és a Real User Monitoring (RUM) eszközök mutatják a valós felhasználói adatokat. A Chrome DevTools Application fülén a Speculative Loads szekcióban közvetlenül nyomon követheted a spekulációk állapotát. Érdemes riasztásokat beállítani az LCP > 2.0s és INP > 160ms küszöbértékekre, hogy a 28 napos CrUX ablak előtt észrevedd a regressziókat.

Mit tegyek, ha az oldalam analitikát vagy hirdetéskövetést futtat?

Használd a document.prerendering tulajdonságot és a prerenderingchange eseményt az analitika késleltetésére. Az előrenderelt oldalon ne indíts mellékhatásos műveleteket — várd meg, amíg az oldal aktívvá válik. Enélkül dupla oldalmegtekintéseket és hibás konverziós adatokat fogsz kapni.

Hogyan kezeljem a böngésző-kompatibilitást?

Gyakorlatilag nem kell vele külön foglalkozni. A nem támogatott böngészők figyelmen kívül hagyják a <script type="speculationrules"> elemet. JavaScript-ből az HTMLScriptElement.supports('speculationrules') metódussal ellenőrizheted a támogatást dinamikus injektálás előtt. Fallback megoldásra nincs szükség — az oldal ugyanúgy működik, csak a spekulatív gyorsítás marad ki.