Rákattintasz egy termékre, megnézed, majd a Vissza gombbal visszalépsz a listához. Az egyik webshopban a lista ugyanott áll, ahol hagytad, és egy szempillantás alatt megjelenik. A másikban újratöltődik, a görgetés az oldal tetejére ugrik, a beállított szűrők pedig elvesznek. A különbség mögött sokszor egyetlen böngészőfunkció áll, a back/forward cache, röviden bfcache. Ebben a cikkben végigmegyünk azon, mit csinál, hogyan ellenőrzöd, mi akadályozza, és milyen sorrendben érdemes javítani egy átlagos WordPress-oldalon. A cikkben külön jelöljük, mi a hivatalos információ, mi a saját tapasztalat, és mi a szakmai feltételezés.
Mi az a back/forward cache (bfcache)?
A bfcache egy teljes pillanatkép az oldalról, amelyet a böngésző a memóriájában tart, és a Vissza vagy Előre gombra újratöltés nélkül, azonnal visszaállít. Ez nem azonos a megszokott HTTP-gyorsítótárral. A HTTP-cache a letöltött fájlokat (HTML, CSS, képek, szkriptek) őrzi meg, így azokat nem kell újra letölteni, de az oldalt ettől még újra fel kell építeni, és a JavaScriptet újra le kell futtatni. A bfcache ezzel szemben a már felépített, működő oldalt fagyasztja le, a DOM-mal, a JavaScript-memóriával, a görgetési pozícióval és a kitöltött űrlapmezőkkel együtt.
Amikor elnavigálsz, a böngésző szünetelteti az oldal futását, az időzítők és a függő feladatok megállnak. Ha a látogató visszalép, a böngésző onnan folytatja, ahol abbahagyta. Hivatalosan igazolt: a Chrome, a Firefox és a Safari is használ ilyen gyorsítótárat. A Google web.dev oldalán közölt Chrome-használati adatok szerint asztali gépen nagyjából minden tizedik, mobilon nagyjából minden ötödik navigáció vissza vagy előre irányú. Vagyis a látogatások jelentős része érinti ezt a funkciót, akár foglalkoztál vele eddig, akár nem.
Miért számít a bfcache a felhasználói élményben és a Core Web Vitals adatokban?
A bfcache-ből visszaállított oldal gyakorlatilag azonnal megjelenik, ezért javítja az élményt, és a valós felhasználói mérésekben jó eséllyel kedvezőbb LCP- és CLS-értékeket hoz. A látogató szemszögéből ez a legolcsóbb sebességnyereség, mert nincs hálózati kérés, nincs újrarenderelés, és nincs elrendezés-ugrálás sem.
Hivatalosan igazolt: a Chrome UX Report (CrUX) a bfcache-ből visszaállított oldalmegtekintéseket is beszámítja a Core Web Vitals mezőadatokba, és ezek az adatok jelennek meg a Search Console Core Web Vitals jelentésében is. A Chrome csapata a web.dev-en arról is írt, hogy a bfcache szélesebb körű engedélyezése után javulás látszott a mért LCP-eloszlásokban. A web-vitals JavaScript-könyvtár bfcache-visszaállításkor új mérést indít, így a saját valós felhasználói méréseidben (RUM) is külön látszik.
Van egy fontos korlát. A laboratóriumi eszközök, például a Lighthouse vagy a PageSpeed Insights laborrésze, friss betöltést mérnek, így ott a bfcache nem javít a pontszámon. A hatás a mezőadatokban, vagyis a valódi látogatóktól gyűjtött számokban jelenhet meg. Szakmai feltételezés: egy eleve gyors oldalon a különbség kicsi lehet, egy lassú, sok bővítményt futtató WordPress-oldalon viszont, ahol a látogatók sokat lépkednek lista és részletoldal között, érezhető. Helyezésjavulást ettől senki nem tud garantálni, a Core Web Vitals csak egy jel a sok közül.
Hogyan nézed meg a Chrome DevToolsban, hogy az oldal bekerül-e a bfcache-be?
A Chrome DevTools Application paneljén, a Back/forward cache részben egy gombnyomással lefuttathatod a tesztet, és a böngésző megmondja, sikerült-e a visszaállítás, és ha nem, miért. Lépésről lépésre így megy:
- Nyisd meg a vizsgált oldalt Chrome-ban, lehetőleg inkognitóablakban, mert a böngészőbővítmények is befolyásolhatják az eredményt.
- Nyisd meg a DevToolst (F12, Macen Cmd+Option+I), és válts az Application fülre.
- A bal oldali menüben a Background services csoportban kattints a Back/forward cache elemre.
- Kattints a Test back/forward cache gombra. A Chrome elnavigál egy tesztoldalra, majd automatikusan visszalép.
- Olvasd el az eredményt. Sikeres esetben a „Successfully served from back/forward cache” üzenet jelenik meg, különben az okok listája.
Az okokat a DevTools három csoportba sorolja. Az Actionable tételek a te kódodban vagy a betöltött külső kódokban vannak, ezekkel tudsz dolgozni. A Pending Support tételek olyan funkciók, amelyeket a Chrome egyelőre nem támogat a bfcache mellett, de a fejlesztésük folyamatban van. A Not Actionable tételek rajtad kívül álló okok.
A Lighthouse külön auditban is jelzi a problémát („Page prevented back/forward cache restoration”), így egy PageSpeed Insights futtatás is adhat támpontot. Valódi látogatóknál a notRestoredReasons API mutatja meg, miért maradt el a visszaállítás. A konzolban így nézheted meg egy visszalépés után:
const nav = performance.getEntriesByType('navigation')[0]; console.log(nav.notRestoredReasons);
Hivatalosan igazolt: ez az API a Chrome 123-as verziójától érhető el, más böngészőkben nem feltétlenül. Azt pedig, hogy egy oldal bfcache-ből jött-e vissza, a pageshow esemény persisted tulajdonsága mutatja meg, ez ilyenkor igaz értéket ad.
Miért nem kerül be egy oldal a bfcache-be?
Egy oldal akkor marad ki, ha olyan funkciót használ vagy olyan állapotban van, amelyet a böngésző nem tud biztonságosan lefagyasztani és később folytatni. A böngésző inkább eldobja a pillanatképet, mint hogy hibás vagy elavult tartalmat mutasson. WordPress-oldalakon három akadály fordul elő a leggyakrabban.
Az unload eseménykezelő
Az unload esemény az oldal elhagyásakor fut le. A bfcache-be tett oldal viszont nem „töltődik ki” végleg, így az erre építő kód hibásan működne. Hivatalosan igazolt: asztali Chrome-ban és Firefoxban egy unload kezelő jellemzően kizárja az oldalt a bfcache-ből, a Chrome pedig fokozatosan kivezeti az unload eseményt. A Google helyette a pagehide eseményt ajánlja, adatküldésre pedig a visibilitychange eseményt.
A csere egyszerű. A régi window.addEventListener('unload', sendData); sor helyett ez kell: window.addEventListener('pagehide', sendData);. Ha az oldal visszaállítás után elavult adatot mutathat, a pageshow eseményben frissítsd:
window.addEventListener('pageshow', (e) => { if (e.persisted) { refreshCartCount(); } });
Gyakran nem a saját kódod tartalmazza az unloadot, hanem egy régebbi bővítmény, egy jQuery-alapú szkript vagy egy beágyazott külső widget. Chrome-ban a Permissions-Policy: unload=() HTTP-fejléccel az egész oldalon letilthatod, ami a beágyazott külső kódok unloadját is semlegesíti. Ezt csak tesztelés után vezesd be, mert ha egy szkript tényleg erre építi az utolsó adatküldést, az elveszhet.
A Cache-Control: no-store fejléc
A Cache-Control: no-store azt üzeni a böngészőnek, hogy az oldal tartalmát semmilyen formában ne tárolja. A böngészők ezt sokáig a bfcache-re is kiterjesztették. Hivatalosan igazolt: a Chrome a no-store fejlécű oldalakat hagyományosan kizárta, az újabb verziókban viszont bizonyos feltételekkel, például ha közben nem változtak a sütik, kezdi engedni. Ezt változó területként kezeld, a Firefox és a Safari viselkedése is eltérhet, ezért mindig a saját tesztedre hagyatkozz.
WordPressen a no-store jellemzően három helyről jön. Az egyik a WordPress saját no-cache fejléccsomagja, amelyet bejelentkezett felhasználóknak és az adminfelületen küld. A második a WooCommerce kosár-, pénztár- és fiókoldala. A harmadik egy gyorsítótár- vagy biztonsági bővítmény, illetve egy szerverszintű beállítás, amely minden oldalra ráteszi. Az első kettő rendben van, hiszen érzékeny, személyes oldalakról van szó. A harmadik a gyakori hiba. Saját tapasztalat: sokszor egy biztonsági bővítmény fejléc-keményítő opciója vagy egy tárhelyszolgáltatói alapbeállítás rakja rá a no-store-t a teljesen nyilvános blogcikkekre és kategóriaoldalakra is.
Az ellenőrzéshez a DevTools Network fülén kattints a dokumentum-kérésre, és a Response Headers között keresd a Cache-Control sort. Parancssorból is megnézheted: curl -sI https://pelda.hu/ | grep -i cache-control. Nyilvános oldalon a no-cache vagy a max-age=0, must-revalidate érték nem zárja ki a bfcache-t, a no-store igen.
Chat-, mérő- és egyéb külső kódok
A külső szkriptek akkor okoznak gondot, ha élő kapcsolatot tartanak nyitva, vagy unloadot használnak. Hivatalosan igazolt: a Chrome a nyitott WebSocket- vagy WebRTC-kapcsolattal rendelkező oldalt nem teszi a bfcache-be, és egy folyamatban lévő IndexedDB-tranzakció is akadály lehet.
Az élő chat-widgetek gyakran WebSocketen tartják a kapcsolatot az ügyfélszolgálati rendszerrel. Egyes hőtérkép- és munkamenet-rögzítő eszközök, régebbi követőpixelek és hirdetési szkriptek unloadot használnak az utolsó adatcsomag elküldésére. Szakmai feltételezés: hogy egy adott chat- vagy mérőkód blokkol-e, az verzió- és beállításfüggő, mert a szolgáltatók folyamatosan frissítik a kódjukat. Ezért ne termékneveket tilts le találomra, hanem a DevTools tesztje alapján dönts. Kapcsold ki ideiglenesen a gyanús kódot (például a Google Tag Manager előnézeti módjában), és futtasd le újra a tesztet. Saját tapasztalat: a Google Analytics 4 alapbeállításban jellemzően nem okoz gondot, gyakoribb ok egy régebbi chat-widget vagy egy munkamenet-rögzítő eszköz.
Milyen sorrendben javítsd egy átlagos WordPress-oldalon?
Először mérj, utána a nyilvános oldalakon szüntesd meg a felesleges no-store fejlécet és az unload kezelőket, végül a külső kódokat vizsgáld meg egyenként. Ez a sorrend azért praktikus, mert az első két lépés többnyire beállítási kérdés, és egyszerre sok oldalt érint.
- Felmérés. Válassz ki 4-5 sablont, például főoldalt, blogcikket, kategória- vagy listaoldalt, termékoldalt és kapcsolatoldalt. Mindegyiken futtasd le a DevTools tesztjét, és írd fel az okokat. WordPressen az azonos sablonú oldalak jellemzően ugyanúgy viselkednek, így nem kell minden URL-t végignézni.
- A Cache-Control fejléc a nyilvános oldalakon. Ha no-store-t látsz, keresd meg a forrását. Lehet gyorsítótár-bővítmény, biztonsági bővítmény, .htaccess- vagy Nginx-szabály, illetve CDN-beállítás. A nyilvános oldalakról vedd le, a bejelentkezett, kosár-, pénztár- és fiókoldalakon hagyd meg.
- Az unload kezelők megkeresése. Ha a teszt unloadot jelez, a Chrome konzoljában a
getEventListeners(window)parancs megmutatja a regisztrált kezelőket, és rájuk kattintva a forrásfájlhoz jutsz. Ha bővítményből jön, frissítsd. Ha a frissítés sem segít, jelezd a fejlesztőjének, vagy keress alternatívát. A saját kódban cseréldpagehide-ra. - Külső kódok egyenként. Chat, hőtérkép, pixelek. Tesztkörnyezetben vagy előnézeti módban kapcsold ki őket egyesével, és minden lépés után teszteld újra. Chatnél jó megoldás lehet a késleltetett betöltés, amikor a widget csak kattintásra indul el, így amíg a látogató nem nyitja meg, nincs nyitott kapcsolat.
- Frissítés visszaállítás után. Ha az oldal már bekerül a bfcache-be, gondoskodj róla, hogy az elavulható adatok (kosárszámláló, bejelentkezési állapot, készletinformáció) a
pageshoweseményben frissüljenek. WooCommerce-nél ez főleg a fejlécben lévő kosárikonra igaz. - Utánkövetés. A CrUX-adatok 28 napos gördülő ablakban frissülnek, ezért a változás a Search Console Core Web Vitals jelentésében és a PageSpeed Insights mezőadataiban csak hetekkel később látszik teljesen. Javítás után legalább négy hétig ne vonj le végleges következtetést.
Mire figyelj, hogy a javítás ne okozzon új hibát?
A bfcache pontosan azt mutatja vissza, amit a látogató elhagyott, ezért a személyes és gyorsan változó adatoknál ügyelni kell arra, hogy visszalépéskor ne elavult állapot jelenjen meg. Ezt a rövid ellenőrzőlistát érdemes végigvenni minden módosítás után:
- Kijelentkezés után a Vissza gomb nem mutathat bejelentkezett tartalmat. A fiók- és adminoldalakon a no-store maradjon meg.
- A kosár tartalma és a készletinformáció frissüljön visszaállításkor.
- A visszaállítás nem futtatja újra az oldalbetöltéskor induló kódot, ezért egyes mérőeszközök nem rögzítenek új oldalmegtekintést. Nézd meg, hogyan kezeli ezt a mérőrendszered, és ha szükséges, a
pageshoweseményben küldj külön jelzést. - A visszaszámlálók, akciós sávok és időalapú tartalmak a visszaállítás után is helyes időt mutassanak.
- A
Permissions-Policyfejléccel ne tiltsd le az unloadot tesztelés nélkül. - Minden módosítás után futtasd le újra a DevTools tesztjét ugyanazokon a sablonokon, amelyeket a felmérésnél használtál.
Megéri-e foglalkozni vele egy kisebb weboldalon?
Általában igen, mert a javítás többnyire beállítási kérdés, nem nagy fejlesztés, a haszna pedig minden egyes visszalépésnél megjelenik. Egy blogon vagy szolgáltatói oldalon, ahol a látogató a cikklistából több cikket is megnyit, a gyors visszalépés kényelmesebbé teszi a böngészést. Webshopban, ahol a termékek és a szűrt listák között ingázás a jellemző viselkedés, még többet számít. Szakmai feltételezés: a gördülékenyebb navigáció segítheti, hogy a látogató több oldalt nézzen meg, de ezt minden oldalon a saját adataidon érdemes ellenőrizni, általános eredményt nem lehet ígérni.
Ha csak egy dolgot csinálsz meg ebből a cikkből, futtasd le a DevTools tesztjét a három legforgalmasabb oldalsablonodon. Öt perc, és utána tudni fogod, hogy van-e egyáltalán teendőd.
Források és további olvasnivalók
- web.dev (Google Chrome csapat): Back/forward cache
- Chrome for Developers: Deprecating the unload event
- Chrome DevTools dokumentáció: Test back/forward cache
- Chrome for Developers: Back/forward cache notRestoredReasons API
- MDN Web Docs: pageshow, pagehide és PerformanceNavigationTiming.notRestoredReasons
- WHATWG HTML Living Standard: Session history and navigation
- Google Search Central: A Core Web Vitals és a Google keresési eredmények
- Chrome UX Report (CrUX) dokumentáció
- A bfcache a teljes, futó oldalt menti el, ezért a visszalépés újratöltés és görgetésvesztés nélkül történik.
- A CrUX mezőadatai a bfcache-ből visszaállított oldalmegtekintéseket is beszámítják, a laboratóriumi Lighthouse-pontszámon viszont nem látszik a hatása.
- A Chrome DevTools Application paneljén, a Back/forward cache részben egy gombnyomással kiderül, mi akadályozza a visszaállítást.
- A leggyakoribb akadály a nyilvános oldalakon feleslegesen beállított Cache-Control: no-store, az unload eseménykezelő és a nyitott WebSocket-kapcsolatot tartó külső kód.
- Javítás után legalább 28 napot várj, mert a CrUX-adatok ennyi idő alatt frissülnek teljesen.
Gyakori kérdések
Mi a különbség a bfcache és a böngésző HTTP-gyorsítótára között?
A HTTP-gyorsítótár a letöltött fájlokat őrzi meg, de az oldalt újra fel kell építeni és a JavaScriptet újra le kell futtatni. A bfcache a teljes, működő oldalt menti el a memóriába, a görgetési pozícióval és az űrlapmezőkkel együtt, ezért a visszalépés azonnali.
Javítja a bfcache a PageSpeed Insights pontszámomat?
A laboratóriumi pontszámot nem, mert a Lighthouse friss betöltést mér. A valódi látogatóktól gyűjtött CrUX-mezőadatokban viszont jó eséllyel megjelenik a hatása, mert a bfcache-ből visszaállított oldalmegtekintések is beleszámítanak.
Hogyan ellenőrizhetem gyorsan, hogy az oldalam bekerül-e a bfcache-be?
Chrome-ban nyisd meg a DevToolst, az Application fülön válaszd a Back/forward cache részt, és kattints a Test back/forward cache gombra. Az eredmény megmutatja, sikerült-e a visszaállítás, és ha nem, mi akadályozta.
Le kell vennem a no-store fejlécet minden WordPress-oldalról?
Nem. A nyilvános oldalakon, például blogcikkeken és kategóriaoldalakon érdemes levenni, de a bejelentkezett felhasználók oldalain, valamint a kosár-, pénztár- és fiókoldalakon maradjon meg, hogy visszalépéskor ne jelenjen meg érzékeny vagy elavult tartalom.
Mi a teendő, ha egy chat-widget miatt nem működik a bfcache?
Először frissítsd a widgetet, mert a szolgáltatók folyamatosan javítják a kódjukat. Ha ez nem segít, megoldás lehet a késleltetett betöltés, amikor a chat csak a látogató kattintására indul el, így addig nincs nyitott kapcsolat, ami kizárná az oldalt.
Mennyi idő alatt látszik a javítás hatása a Search Console-ban?
A CrUX-adatok 28 napos gördülő ablakban frissülnek, ezért a Core Web Vitals jelentésben jellemzően csak néhány hét után látszik teljesen a változás. Javítás után legalább négy hétig ne vonj le végleges következtetést.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.