Speculation Rules előtöltés WordPress-oldalon

Scheo · 2026-10-10 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha egy látogató rákattint egy linkre, a böngésző általában csak ekkor kezdi el letölteni a következő oldalt. A Speculation Rules API ezen a sorrenden változtat. Előre megmondhatod a böngészőnek, mely oldalak jöhetnek szóba következőnek, és azokat a kattintás előtt letöltheti, sőt a háttérben teljesen fel is építheti. Ebben a cikkben végigmegyünk azon, hogyan működik, melyik böngésző ismeri, hogyan kapcsolod be WordPressben, és hol okozhat bajt.

A szövegben háromféle jelölést használunk. [Hivatalosan igazolt] az, ami a Chrome fejlesztői dokumentációjában, a WordPress core dokumentációjában vagy a szabványtervezetben szerepel. [Saját tapasztalat] az, amit WordPress-oldalak üzemeltetése közben általánosan látunk. [Szakmai feltételezés] az, ami logikusan következik, de nem mértük minden esetben.

Mi az a Speculation Rules API, és mit nyersz vele?

A Speculation Rules API egy böngészős szabálykészlet, amellyel a weboldal jelzi, mely linkek céloldalait töltse le vagy renderelje elő a böngésző, mielőtt a látogató rákattint. Ha a tipp bejön, a navigáció szinte azonnalinak érződik, mert az oldal már részben vagy teljesen kész.

[Hivatalosan igazolt] A szabályokat egy <script type="speculationrules"> elembe írt JSON-ban vagy a Speculation-Rules HTTP-fejlécben megadott külső JSON-fájlban adod meg. Ez a régi <link rel="prerender"> megoldás utódja, amelyet a Chrome már nem támogat teljes előrendereléssel.

A haszon főleg a felhasználói élményben és a Core Web Vitals mutatókban jelentkezik. [Hivatalosan igazolt] Előrenderelt navigációnál a Largest Contentful Paint (LCP) gyakran közel nullára esik, mert a tartalom a kattintás pillanatában már ki van rajzolva. [Szakmai feltételezés] Keresőhelyezést ez közvetlenül nem garantál, a jobb oldalbetöltési élmény legfeljebb az egyik apró jel a sok közül.

Mi a különbség a prefetch és a prerender között?

A prefetch csak a következő oldal HTML-dokumentumát tölti le, a prerender viszont a teljes oldalt felépíti egy láthatatlan háttérfülön, a JavaScripttel együtt. Az első olcsóbb és biztonságosabb, a második gyorsabb, de több erőforrást használ.

• Prefetch: a böngésző lekéri a HTML-t és eltárolja. Kattintáskor ezt használja, a CSS, a képek és a szkriptek viszont csak ekkor töltődnek. JavaScript nem fut le előre.
• Prerender: a böngésző letölti az aloldalakat és erőforrásaikat, lefuttatja a szkripteket, és kirajzolja az oldalt. Kattintáskor egyszerűen átváltja a háttérfület láthatóra.

[Saját tapasztalat] Egyszerű, cache-elt tartalmi oldalaknál a prefetch már érezhető javulást hoz. A prerender akkor éri meg igazán, ha az oldal nehéz (sok szkript, nagy képek), és a következő kattintás jól megjósolható, például egy blogcikkből a kapcsolódó cikkre.

Melyik böngésző támogatja a Speculation Rules API-t?

A Speculation Rules API-t jelenleg a Chromium-alapú böngészők támogatják, vagyis a Chrome, a Microsoft Edge és az Opera. A Firefox és a Safari alapbeállításban nem hajtja végre a szabályokat, de nem is hibáznak tőlük, egyszerűen átugorják a szkriptet.

[Hivatalosan igazolt] A Chrome a listaszabályokat a 109-es, a dokumentumszabályokat (a linkek automatikus kiválasztását) a 121-es verziótól támogatja asztali gépen és Androidon. A Mozilla és a WebKit is foglalkozik a szabvánnyal, egyes részei kísérleti kapcsolóval már kipróbálhatók. A pontos, aktuális állapotot érdemes a caniuse.com vagy az MDN Web Docs oldalán ellenőrizni, mert ez gyorsan változik.

[Hivatalosan igazolt] Támogatott böngészőben sem fut le minden szabály. A Chrome kihagyja az előtöltést, ha a felhasználó kikapcsolta a „Oldalak előtöltése” beállítást, ha aktív az adatforgalom-csökkentés vagy az energiatakarékos mód, illetve ha kevés a szabad memória. Ez azt jelenti, hogy a funkció mindig fokozatos javítás, sosem lehet rá építeni működést.

Hogyan néz ki egy szabálykészlet a gyakorlatban?

Egy szabálykészlet megmondja, milyen műveletet (prefetch vagy prerender), mely linkekre és milyen hamar indítson a böngésző. Az időzítést az eagerness kulcs szabályozza.

Egy dokumentumszabály, amely az oldal összes belső linkjét előrendereli, ha a látogató az egérrel fölé áll, de kihagyja a kijelentkezést és a kosarat:

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

[Hivatalosan igazolt] Az eagerness négy értéke:

• immediate: amint a szabály megjelenik, azonnal indul.
• eager: nagyon korán indul, a Chrome asztali gépen már rövid ráhúzásra, mobilon a látható linkek alapján.
• moderate: asztali gépen kb. 200 ezredmásodperces egérráhúzásnál vagy a kattintás megkezdésekor indul.
• conservative: csak a kattintás vagy érintés megkezdésekor (pointerdown) indul.

[Hivatalosan igazolt] A Chrome korlátozza is a párhuzamos előtöltéseket. Az immediate és eager szabályoknál legfeljebb 50 prefetch és 10 prerender lehet egyszerre, a moderate és conservative szabályoknál 2, és az új kiszorítja a legrégebbit.

Hogyan kapcsolható be WordPressben?

WordPress 6.8 óta semmit nem kell bekapcsolnod, a core alapból óvatos prefetch-et ad a kijelentkezett látogatóknak. Ha erősebb beállítást szeretnél, a hivatalos Speculative Loading bővítménnyel vagy néhány sornyi kóddal hangolhatod.

Mit csinál a WordPress alapból?

[Hivatalosan igazolt] A 6.8-as verziótól a WordPress dokumentumszabályt illeszt az oldalakba prefetch művelettel és conservative időzítéssel. Bejelentkezett felhasználóknak és egyszerű (nem barátságos) permalink-beállításnál nem kapcsol be. A szabály eleve kizárja a /wp-admin/ és /wp-login.php útvonalakat, a feltöltések, bővítmények és sablonok mappáit, a lekérdezési paraméteres URL-eket, valamint a rel="nofollow" linkeket és a no-prefetch osztályú elemeket.

A Speculative Loading bővítmény

[Hivatalosan igazolt] A WordPress Performance Team által fejlesztett Speculative Loading bővítmény a Beállítások / Olvasás oldalon ad egy kezelőfelületet. Itt választhatsz prefetch és prerender között, és beállíthatod az időzítést. A bővítmény alapértéke a prerender, mérsékelt (moderate) időzítéssel, ami lényegesen erősebb a core alapértékénél.

Finomhangolás kóddal

Ha nem akarsz külön bővítményt, a sablon functions.php fájljában vagy egy saját mini bővítményben két szűrővel is elérheted ugyanezt:

add_filter( 'wp_speculation_rules_configuration', function ( $config ) { if ( is_array( $config ) ) { $config['mode'] = 'prerender'; $config['eagerness'] = 'moderate'; } return $config; } );

add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths ) { $paths[] = '/kosar/*'; $paths[] = '/penztar/*'; $paths[] = '/fiokom/*'; return $paths; } );

[Hivatalosan igazolt] Ha a konfigurációs szűrő null értéket ad vissza, a funkció teljesen kikapcsol. Egy-egy linket a no-prefetch vagy no-prerender osztállyal zárhatsz ki.

[Saját tapasztalat] Sok gyorsítóbővítmény (például a WP Rocket vagy a LiteSpeed Cache újabb verziói) saját előtöltést is kínál. Ha mindkettő be van kapcsolva, érdemes megnézni a forráskódban, hány speculationrules szkript fut, mert az egymásra rakódó szabályokat nehéz átlátni.

Milyen kockázatai vannak az előtöltésnek?

A három fő kockázat a felesleges szerverterhelés, a torzuló mérés és az állapotot változtató linkek véletlen meghívása. Mindhárom kezelhető, de nem árt tudni róluk, mielőtt erősebb beállításra váltasz.

Felesleges szerverterhelés

Minden előtöltött oldal valódi kérés a szerver felé, akkor is, ha a látogató végül nem kattint. [Szakmai feltételezés] Gyenge osztott tárhelyen, gyorsítótár nélkül egy agresszív (eager vagy immediate) prerender szabály jelentősen növelheti a PHP-folyamatok számát. A moderate és conservative időzítés jó eséllyel elhanyagolható többletet okoz, mert csak erős szándéknál indul. [Saját tapasztalat] Ha az oldal mögött teljes oldalas gyorsítótár van, a többletterhelés jellemzően nem érezhető.

[Hivatalosan igazolt] A Chrome a spekulatív kérésekhez Sec-Purpose: prefetch fejlécet küld (előrenderelésnél prefetch;prerender). Szerveroldalon ez alapján szűrheted a naplót, vagy szükség esetén 503-as válasszal elutasíthatod a kérést terhelési csúcsban.

Mérési torzulás

[Hivatalosan igazolt] Prefetch-nél nem fut JavaScript, így a kliensoldali analitika nem számol oldalmegtekintést. Prerendernél viszont lefutnak a szkriptek. A Google Analytics (gtag.js) és a Google Publisher Tag kezeli ezt, és a megtekintést az oldal tényleges megjelenítéséig késlelteti. Más eszközöknél ez nem biztos.

[Szakmai feltételezés] Régebbi hőtérkép-, chat- vagy hirdetési pixelek oldalmegtekintést rögzíthetnek egy soha meg nem nézett oldalra. Saját szkriptnél a document.prerendering tulajdonsággal és a prerenderingchange eseménnyel tudod a futást a valódi megjelenítésig halasztani. A szervernapló alapú statisztikák (pl. AWStats) a prefetch-et is megtekintésnek láthatják.

Kosár-, pénztár- és kijelentkezés-linkek

Ez a legveszélyesebb pont. Ha egy GET-link állapotot változtat, az előtöltés végrehajtja a műveletet a látogató tudta nélkül. Tipikus példa a ?add-to-cart=123 paraméteres kosárba tétel vagy egy kijelentkezés-link. [Hivatalosan igazolt] A WordPress alapszabálya a paraméteres URL-eket kizárja, és a core kijelentkezés-linkje a wp-login.php alatt van, ami szintén kizárt. [Szakmai feltételezés] Egyedi útvonalú kijelentkezés (pl. egy tagsági bővítmény /kijelentkezes/ oldala), egyedi kosár-URL vagy egy kuponkódot élesítő link viszont könnyen kimaradhat, ezeket kézzel kell kizárnod. WooCommerce-nél is ellenőrizd, hogy a kosár, a pénztár és a fiók oldal tényleg szerepel-e a kizárásokban.

Hogyan ellenőrizd a Chrome fejlesztői eszközeivel?

A Chrome DevTools Application paneljén, a Background services alatti Speculative loads résznél látod, milyen szabályok töltődtek be, és melyik URL-re futott sikeresen az előtöltés. Lépésről lépésre így néz ki:

1. Nyisd meg az oldalt kijelentkezve vagy inkognitó ablakban, mert a WordPress bejelentkezett felhasználónak nem ad szabályt.
2. Nyomd meg az F12 billentyűt, és válts az Application fülre.
3. A bal oldali menüben a Background services / Speculative loads pontnál nézd meg az összesítést. Itt látszik, hány szabálykészlet töltődött be, és hány előtöltés sikerült vagy bukott el.
4. A Rules nézetben ellenőrizd, hogy a JSON hibátlanul értelmeződött-e. Szintaktikai hibánál itt piros jelzést kapsz.
5. A Speculations nézetben húzd az egeret egy linkre az oldalon, és figyeld, hogy az URL állapota „Ready” lesz-e. Ha nem, a sorra kattintva a Chrome megírja az okát (pl. memóriakorlát, kizárt útvonal, más origin).
6. A Network fülön keresd meg a kérést, és nézd meg a kérésfejlécekben a Sec-Purpose értéket.
7. Kattints a linkre, majd a Speculative loads felső részén ellenőrizd, hogy az aktuális oldal előtöltve érkezett-e. Konzolban a performance.getEntriesByType('navigation')[0].activationStart nullánál nagyobb értéke is ezt jelzi.
8. Végül ellenőrizd a kosár- és kijelentkezés-linkeket. Ezek egyike sem jelenhet meg a Speculations listában.

[Saját tapasztalat] A leggyakoribb meglepetés, hogy a szabály betöltődik, de egyetlen előtöltés sem indul. Ennek oka szinte mindig az, hogy a tesztelő be van jelentkezve, vagy a Chrome-ban ki van kapcsolva az oldal-előtöltés.

Milyen ellenőrzőlistát érdemes végigvenni élesítés előtt?

Élesítés előtt a kizárásokat, a mérést és a szerver bírását kell ellenőrizni, és csak utána érdemes erősebb időzítésre váltani.

• Fut-e WordPress 6.8 vagy újabb, és barátságos permalink-beállítás van-e?
• Csak egy forrásból (core, bővítmény vagy gyorsítóbővítmény) jön-e szabály?
• Ki vannak-e zárva a kosár, a pénztár, a fiók, a kijelentkezés és minden állapotot változtató GET-link?
• Késlelteti-e az összes analitikai és hirdetési szkript a futást prerendernél?
• Van-e teljes oldalas gyorsítótár, és bírja-e a tárhely a többletkéréseket?
• Látszik-e a DevToolsban sikeres előtöltés egy kijelentkezett tesztnél?
• Néhány hét után változott-e a CrUX vagy a Search Console Core Web Vitals jelentésében az LCP?

[Szakmai feltételezés] A legtöbb tartalmi WordPress-oldalnál a prerender és a moderate időzítés jó egyensúly. Webshopnál érdemes a core óvatos prefetch beállításával indulni, és csak a kizárások ellenőrzése után erősíteni.

Források és további olvasnivalók

• Chrome for Developers: Prerender pages in Chrome for instant page navigations
• Chrome for Developers: Debugging speculation rules
• MDN Web Docs: Speculation Rules API
• WICG: Speculation Rules specifikációtervezet
• Make WordPress Core: Speculative Loading in WordPress 6.8
• WordPress.org: Speculative Loading bővítmény (WordPress Performance Team)
• web.dev: Largest Contentful Paint (LCP)