Prefetch: teljes útmutató

A prefetch egy böngészőnek szóló jelzés: tölts le előre egy olyan erőforrást vagy oldalt, amelyre a látogatónak valószínűleg a következő lépésben lesz szüksége. A letöltés alacsony prioritással, a jelenlegi oldal betöltése után történik, így nem lassítja azt. Ha a látogató valóban továbblép, a következő oldal a gyorsítótárból érkezik, és érezhetően gyorsabban jelenik meg.

Alapfogalmak

A weboldalak sebessége nemcsak azon múlik, milyen gyorsan töltődik be az éppen megnyitott oldal, hanem azon is, milyen gyorsan jut el a látogató a következőre. A prefetch ezt a második pillanatot célozza. A böngésző a tétlen idejében, amikor az aktuális oldal már betöltődött és a hálózat szabad, letölti azt, amire a jövőben szükség lehet. A kifejezés szó szerint előzetes lekérést jelent, és a magyar szakmai szövegekben általában angolul használják.

A prefetch mindig javaslat, nem parancs. A böngésző eldöntheti, hogy végrehajtja-e, és ha a körülmények nem kedvezőek, például lassú a kapcsolat, vagy a felhasználó adatforgalom-kímélő módot kapcsolt be, ki is hagyhatja. Ezért a prefetch soha nem lehet egy funkció működésének feltétele: az oldalnak nélküle is helyesen kell működnie, a prefetch csak gyorsít.

A prefetch családja

A „prefetch" szót a gyakorlatban több, egymáshoz hasonló technikára is használják. Érdemes pontosan elkülöníteni őket, mert mást csinálnak, és más helyzetben hasznosak.

Technika	Mit csinál előre	Mikor hasznos
dns-prefetch	Csak a domainnév feloldását	Ha egy külső domainről később biztosan jön valami, de nem tudni, pontosan mi
preconnect	A névfeloldást, a kapcsolat felépítését és a titkosított kapcsolat egyeztetését	Ha egy külső domainről hamarosan fontos erőforrás érkezik
prefetch (link elem)	Egy konkrét erőforrás vagy dokumentum letöltését, alacsony prioritással	Ha valószínű, hogy a következő navigációhoz kell
Speculation Rules prefetch	Egy teljes oldal dokumentumának előzetes lekérését, szabályok alapján	Ha előre látható, melyik belső oldalra lép tovább a látogató
prerender (Speculation Rules)	A teljes oldal lekérését és a háttérben való megjelenítését	Ha nagyon valószínű a következő lépés, és megéri a nagyobb erőforrás-ráfordítás

Prefetch és preload: a legfontosabb különbség

A két fogalmat gyakran összekeverik, pedig ellentétes irányba néznek. A preload a jelenlegi oldalhoz szükséges, kritikus erőforrást tölti be korábban és magas prioritással, például a fő képet vagy egy betűtípust. A prefetch a jövőbe néz: olyasmit tölt le alacsony prioritással, amire a mostani oldalnak nincs szüksége, csak valószínűleg a következőnek. Ha egy kritikus erőforrást prefetch-csel jelölsz, az a kelleténél később érkezik. Ha egy jövőbeli erőforrást preloaddal jelölsz, elveszi a sávszélességet a jelenlegi oldaltól. A két jelzés részletes összevetését a preload útmutató tárgyalja.

Mi a kapcsolata a SEO-val?

A prefetch nem rangsorolási tényező, és a keresőrobot feltérképezését sem befolyásolja közvetlenül. A hatása a felhasználói élményen keresztül jelenik meg: a gyorsabb oldalváltás jobb betöltési mutatókat eredményezhet a valós felhasználói adatokban, amelyekből a Core Web Vitals értékelése készül. A prefetch tehát a technikai SEO eszköztárában a sebességoptimalizálás része, nem az indexelés része.

Hogyan működik?

Amikor a böngésző egy prefetch jelzéssel találkozik, a kérést egy alacsony prioritású sorba teszi. Először az aktuális oldal saját erőforrásai töltődnek be, és csak ezután, a hálózat szabad kapacitásán kerül sor az előzetes letöltésre. A letöltött tartalom a böngésző gyorsítótárába kerül. Ha a látogató ezután olyan oldalra lép, amelyik ezt az erőforrást kéri, a böngésző nem a hálózathoz fordul, hanem a már meglévő másolatot használja.

A működés lényege tehát egy fogadás. A fejlesztő arra fogad, hogy a látogató egy bizonyos irányba halad tovább. Ha a fogadás bejön, a következő oldal gyorsabb. Ha nem jön be, a letöltött adat kárba vész: sávszélességet, a szerver oldalán pedig kiszolgálási kapacitást fogyasztott, haszon nélkül. A prefetch jó használata ezért mindig a valószínűség becsléséről szól.

A link elemes prefetch

A klasszikus forma egy link elem a HTML fejlécében:

Egy erőforrásra: <link rel="prefetch" href="/assets/kovetkezo-oldal.js">
Egy dokumentumra: <link rel="prefetch" href="/kategoria/masodik-oldal/">
Csak névfeloldásra: <link rel="dns-prefetch" href="https://cdn.example.com">

A böngésző a letöltést a szokásos HTTP-gyorsítótárazási szabályok szerint kezeli. Ezért számít, hogy a letöltött erőforrás milyen gyorsítótár-fejléceket kap. Ha a szerver úgy válaszol, hogy a tartalom nem tárolható, a böngésző nem tudja biztonságosan újrahasznosítani, és a prefetch hatása elmaradhat. A gyorsítótár működéséről a cache útmutató ad részletes képet.

A Speculation Rules API

Az újabb megközelítés a Speculation Rules API, amelyet a Chromium alapú böngészők támogatnak. Ez egy JSON formátumú szabálykészlet egy <script type="speculationrules"> elemben. A szabályok megmondhatják, mely konkrét URL-eket kell előre lekérni, vagy általánosabban, mely linkekre vonatkozzon az előzetes lekérés, például minden belső linkre, kivéve a kijelentkezés vagy a kosár címét. A szabályban beállítható, mennyire legyen mohó a böngésző: azonnal induljon a lekérés, vagy csak akkor, amikor a látogató a link fölé viszi az egeret, illetve rákattint.

A Speculation Rules prefetch a teljes dokumentumot kéri le, a hozzá tartozó alerőforrásokat nem. A prerender ennél tovább megy: a háttérben meg is jeleníti az oldalt, lefuttatja a szkripteket, így a navigáció szinte azonnalinak hat. A prerender viszont jóval több erőforrást fogyaszt, ezért csak ott érdemes, ahol a következő lépés nagyon valószínű.

Mi történik a szerver oldalán?

A szerver szempontjából az előzetes lekérés ugyanolyan HTTP-kérés, mint bármelyik másik. A Chromium alapú böngészők ezeket a kéréseket egy külön fejléccel jelölik, amelyből a szerver felismerheti, hogy nem valódi oldalmegtekintésről van szó. Ez azért fontos, mert az előre lekért, de végül meg nem nyitott oldalak torzíthatják a szerveroldali statisztikákat, és ha az oldal lekérése valamilyen mellékhatással jár, az a látogató szándéka nélkül is lefut.

Fő módszerek

A prefetch bevezetésének nincs egyetlen helyes útja. A módszer a webhely szerkezetétől, a látogatói utaktól és a technikai környezettől függ. Az alábbi megközelítések a leggyakoribbak, és egy webhelyen többet is lehet kombinálni.

1. Statikus prefetch a legvalószínűbb következő lépésre

A legegyszerűbb módszer: kijelölni azt az egy vagy két oldalt, ahová a látogatók többsége továbblép, és ezekre prefetch jelzést tenni. Egy többlépéses űrlapnál ez a következő lépés, egy lapozott listánál a következő oldal, egy termékoldalnál a kosár. A kiválasztás alapja a saját analitikai adat: melyik oldal a leggyakoribb következő lépés az adott oldalról.

2. Szabályalapú prefetch a Speculation Rules API-val

Nagyobb webhelyen nem praktikus minden oldalra kézzel megadni a következő lépést. A dokumentumszabályokkal általános feltétel adható meg, például minden olyan belső link, amelynek útvonala egy adott mintára illeszkedik. A mohósági beállítással szabályozható, hogy a lekérés csak valódi szándék jelére induljon, például amikor a látogató a link fölé viszi az egeret. Ez a kompromisszum jól működik: kevés felesleges lekérés, de érezhető gyorsulás.

3. Interakcióra induló prefetch

Több JavaScript-könyvtár és keretrendszer azon az elven működik, hogy a linkeket akkor kéri le előre, amikor azok láthatóvá válnak a képernyőn, vagy amikor a látogató föléjük viszi az egeret. Ez a módszer különösen a kliensoldali renderelésű alkalmazásoknál elterjedt, ahol a következő nézet kódja és adatai külön tölthetők le.

4. Külső domainek előkészítése

Ha a webhely külső szolgáltatásokat használ, például egy CDN-t, betűtípus-szolgáltatót vagy beágyazott tartalmat, a dns-prefetch és a preconnect lerövidítheti az első kérés idejét. A preconnect erősebb, de minden felépített kapcsolat erőforrást köt le, ezért csak a valóban fontos, néhány domainre érdemes használni. A dns-prefetch olcsóbb, szélesebb körben alkalmazható. A névfeloldás működéséről a DNS útmutató ír részletesen.

Döntési szabály: melyik módszert válaszd?

Van egy egyértelmű következő lépés? Statikus prefetch arra az egy oldalra.
Sok belső link van, de nincs egyértelmű irány? Speculation Rules, mérsékelt mohósággal, azaz csak valódi szándék jelére.
A következő lépés szinte biztos, és a gyorsaság üzletileg fontos? Megfontolható a prerender, szűk URL-körre.
Csak a külső domain elérése lassú? preconnect vagy dns-prefetch, nem teljes prefetch.
A link mellékhatással jár? Kizárni minden előzetes lekérésből.

Kidolgozott példa: lapozott blog archívum

Egy szakmai blog archívumában a látogatók jelentős része végiglapozza a listát. Az analitika szerint az archívum első oldaláról a leggyakoribb következő lépés a második oldal, a cikkoldalakról pedig a látogatók többnyire visszalépnek a listára vagy egy kapcsolódó cikkre kattintanak. A csapat két dolgot vezetett be. A lapozott listán a következő oldalra link elemes prefetch került. A cikkoldalakon a belső cikklinkekre Speculation Rules szabály vonatkozott, amely csak akkor indította a lekérést, amikor a látogató a link fölé vitte az egeret. A kijelentkezési, keresési és hozzászólás-küldő címeket a szabály kizárta. Az eredményt a valós felhasználói adatokból mérték: a navigációk egy részénél a következő oldal már a gyorsítótárból érkezett, és a szerver terhelése nem nőtt érezhetően, mert a lekérések többsége tényleges kattintáshoz kapcsolódott.

Gyakori hibák

A prefetch hibái ritkán látványosak. Az oldal nem törik el tőlük, csak éppen nem gyorsul, vagy csendben pazarol. Ezért könnyű őket évekig észre sem venni. A legtöbb hiba abból fakad, hogy a prefetch-et ingyenesnek tekintik, pedig minden előzetes lekérés valakinek a sávszélességébe és valakinek a szerverkapacitásába kerül.

Tipikus hibák

Mindent előre letölteni. Ha egy oldal minden linkjét azonnal előre lekéri, a letöltések nagy része kárba vész, a mobilos látogató adatkerete fogy, a szerver pedig felesleges kéréseket szolgál ki.
Mellékhatással járó linkek előre lekérése. Ha egy GET kérés kijelentkeztet, kosárba tesz vagy állapotot módosít, az előzetes lekérés ezt a látogató szándéka nélkül is végrehajthatja.
Prefetch a kritikus erőforrásra. Az aktuális oldalhoz szükséges fájl alacsony prioritással, túl későn érkezik. Ide preload kell.
Nem tárolható válaszok előre lekérése. Ha a szerver megtiltja a tárolást, a böngésző nem használhatja fel a letöltött másolatot, így a lekérés haszontalan.
Személyre szabott oldalak előzetes lekérése. Ha az oldal tartalma a lekérés és a megnyitás között megváltozhat, a látogató elavult állapotot láthat, vagy az oldal újra lekéri a tartalmat.
A statisztika torzulásának figyelmen kívül hagyása. Az előzetes lekéréseket a szerveroldali naplók és egyes analitikai megoldások megtekintésnek számolhatják.

Tévhit: a prefetch javítja a helyezést

A prefetch nem jelzés a keresőnek, és a keresőrobot nem jutalmazza. Az egyetlen kapcsolat a SEO-val a valós felhasználói élmény: ha a navigációk gyorsabbak, a terepi adatokban javulhatnak a betöltési mutatók. Ez azonban közvetett, és csak akkor következik be, ha a prefetch ténylegesen a látogatók által megnyitott oldalakat gyorsítja. Egy rosszul célzott prefetch semmin nem javít.

Ellenpélda: amikor a prefetch lassít

Egy webáruház kategóriaoldalán minden termékkártyára azonnali prefetch került, azzal a céllal, hogy bármelyik termékoldal gyorsan nyíljon. Lassú mobilhálózaton a sok párhuzamos előzetes letöltés versengett a kategóriaoldal saját képeivel és szkriptjeivel, amelyek még nem töltődtek be teljesen. A látogató azt tapasztalta, hogy a kategóriaoldal görgetése akadozik, és a képek később jelennek meg. A megoldás a szabály szűkítése volt: a prefetch csak akkor indult, amikor a látogató egy termékkártya fölé vitte az egeret vagy megérintette.

Tévhit: a prefetch mindig lefut

A prefetch javaslat. A böngésző kihagyhatja, ha a kapcsolat lassú, ha adatkímélő mód van bekapcsolva, vagy ha más okból úgy ítéli, hogy nem éri meg. A támogatottság is eltér: a Speculation Rules API-t nem minden böngésző ismeri, és ahol nem ismeri, egyszerűen figyelmen kívül hagyja. Ez nem hiba, hanem a működés része, de azt jelenti, hogy a prefetch-re nem lehet funkciót építeni.

Mérés

A prefetch mérése két kérdésre keres választ. Az első: megtörténik-e egyáltalán az előzetes lekérés, és felhasználja-e a böngésző. A második: a látogatók valóban gyorsabban jutnak-e a következő oldalra, és ez megéri-e a többletforgalmat.

Ellenőrzés a böngésző fejlesztői eszközeiben

A Chrome fejlesztői eszközeinek Network paneljén látszik, hogy az előzetes lekérés elindult-e, és a következő navigációnál a böngésző a gyorsítótárból szolgálta-e ki a kérést. Az Application panelen a spekulatív betöltésekhez külön nézet tartozik, amely megmutatja, mely szabályok léptek életbe, mely URL-ek lekérése sikerült, és ha valami nem futott le, annak okát is. Ez az első lépés: ha itt nem látszik a prefetch, a többi mérésnek nincs értelme.

Terepi adatok

A laboratóriumi mérés megmutatja, hogy a mechanizmus működik, de azt nem, hogy a valós látogatóknak számít-e. Ehhez valós felhasználói mérés kell: a navigációk időzítési adatai, a Search Console Core Web Vitals jelentése, vagy saját valós felhasználói monitorozás. Az előre lekért navigációkat érdemes külön szegmensként vizsgálni, hogy látszódjon, mennyivel gyorsabbak a többinél. Az oldal betöltési idejének átfogó méréséről a page speed útmutató ír.

Találati arány és költség

A prefetch legfontosabb saját mutatója a találati arány: az előre lekért oldalak mekkora részét nyitotta meg végül a látogató. Ha ez alacsony, a prefetch főleg pazarol. Ha magas, a szabály jól célzott. A szervernaplókban a speciális fejléc alapján elkülöníthetők az előzetes lekérések, és összevethetők a valódi oldalmegtekintésekkel.

Ellenőrzőlista

Ellenőrzés	Mit nézel	Jó jel
Lefut-e	Network és Application panel	Az előzetes lekérés elindul, és a navigáció felhasználja
Találati arány	Előzetes lekérések és valódi megnyitások aránya	Az előre lekért oldalak jó részét megnyitják
Kizárások	Mellékhatással járó URL-ek a szabályokban	Kijelentkezés, kosár, űrlapküldés ki van zárva
Gyorsítótár-fejlécek	Az előre lekért válaszok tárolhatósága	A válasz tárolható, a böngésző felhasználhatja
Terepi hatás	Navigációs időzítések, Core Web Vitals	Az előre lekért navigációk gyorsabbak
Statisztika	Előzetes lekérések kiszűrése a naplókból	A megtekintési adatok nem torzulnak

Kidolgozott példa: a találati arány javítása

Egy tudásbázis minden cikkoldalán azonnali prefetch vonatkozott az összes kapcsolódó cikkre. A szervernaplók elemzése megmutatta, hogy az előre lekért cikkeknek csak kis részét nyitották meg a látogatók, a többi lekérés feleslegesen terhelte a szervert. A csapat két változtatást tett: a szabály mohóságát átállította, hogy a lekérés csak az egér fölévitelére induljon, és a kapcsolódó cikkek közül csak az első néhányra alkalmazta. Az új beállítás mellett a naplóban az előzetes lekérések száma csökkent, a megnyitott oldalakhoz viszonyított arányuk javult, és a navigációs időzítésekben a gyorsulás megmaradt.