Cache: teljes útmutató

A cache, magyarul gyorsítótár, egy korábban előállított vagy letöltött válasz ideiglenes tárolása, hogy a következő kérésnél ne kelljen újra elkészíteni vagy újra letölteni. Weboldalaknál több rétegben működik: a böngészőben, a CDN-en és a szerveren. Jól beállítva gyorsítja a betöltést és kíméli a szervert, rosszul beállítva elavult tartalmat és SEO jelzéseket szolgál ki.

Alapfogalmak

A gyorsítótárazás alapgondolata, hogy ami egyszer már elkészült, azt nem kell minden alkalommal újra elkészíteni. Egy weboldal betöltésekor sok munka történik: a szerver adatbázisból olvas, sablont tölt ki, a böngésző képeket, stíluslapokat és szkripteket tölt le. Ha ezek egy része változatlan, felesleges újra végigcsinálni. A gyorsítótár ezt a munkát spórolja meg, cserébe azzal a kockázattal, hogy a tárolt példány közben elavulhat.

A cache ezért mindig egy egyensúly: minél hosszabb ideig tárolsz valamit, annál gyorsabb a kiszolgálás, és annál lassabban jut el a változás a látogatóhoz. A jó beállítás nem egyetlen szám, hanem fájltípusonként és oldaltípusonként eltérő szabályrendszer.

A gyorsítótár rétegei

Réteg	Hol él	Mit tárol	Ki szabályozza
Böngésző gyorsítótár	A látogató eszközén	Letöltött fájlok, HTML, képek	A szerver HTTP-fejlécei
Megosztott gyorsítótár (CDN, proxy)	A hálózatban, a látogató és a szerver között	Sok látogatónak ugyanazt a választ	HTTP-fejlécek és a CDN saját szabályai
Oldal gyorsítótár	A webszerveren	Kész HTML oldalak	Szerver vagy bővítmény beállítása
Objektum gyorsítótár	A szerver memóriájában	Adatbázis-lekérdezések eredményei	Az alkalmazás
Kód gyorsítótár	A szerveren	Lefordított alkalmazáskód	A futtatókörnyezet

Friss és elavult

A HTTP gyorsítótárazás két fogalomra épül. Egy tárolt válasz friss, amíg a szerver által megadott élettartamon belül van: ilyenkor a gyorsítótár kérdezés nélkül felhasználhatja. Ha lejárt, elavultnak számít, és a gyorsítótárnak újra kell érvényesítenie, vagyis meg kell kérdeznie a szervert, változott-e a tartalom. Ha nem változott, a szerver rövid választ ad, és a régi példány újra frissnek számít.

Ami a cache-t szabályozza

• Cache-Control. A fő fejléc, amely megadja, tárolható-e a válasz, hol és meddig.
• ETag. A tartalom egy változatának azonosítója, amellyel az újraérvényesítés történik.
• Last-Modified. Az utolsó módosítás időpontja, szintén az újraérvényesítéshez.
• Expires. Régebbi fejléc, amely egy konkrét lejárati időpontot ad meg; ha mellette max-age is van, az utóbbi az erősebb.
• Vary. Megmondja, mely kérésfejlécek szerint térhet el a válasz, és így mely szerint kell külön példányt tárolni.

Hogyan működik?

Amikor a böngésző először kér le egy fájlt, a szerver a tartalommal együtt fejléceket küld. Ezekből a böngésző eldönti, eltárolja-e a választ, és ha igen, meddig tekinti frissnek. A következő alkalommal, ha a példány még friss, a böngésző hálózati kérés nélkül használja. Ez a leggyorsabb eset: a fájl szinte azonnal rendelkezésre áll.

Ha a példány elavult, a böngésző feltételes kérést küld. Ha korábban ETag érkezett, az If-None-Match fejlécben visszaküldi; ha Last-Modified, akkor az If-Modified-Since fejlécben. A szerver összeveti ezt a jelenlegi állapottal. Ha nincs változás, 304 Not Modified választ ad törzs nélkül, és a böngésző a tárolt példányt használja. Ha van változás, a teljes új tartalmat küldi 200 kóddal. A HTTP-státuszkódok közül a 304 kifejezetten ehhez a folyamathoz tartozik.

A Cache-Control leggyakoribb direktívái

Direktíva	Jelentés
max-age=N	N másodpercig friss a válasz
s-maxage=N	Ugyanez, de csak a megosztott gyorsítótárakra (például CDN) vonatkozik
public	Megosztott gyorsítótár is tárolhatja
private	Csak a látogató saját böngészője tárolhatja
no-cache	Tárolható, de minden felhasználás előtt újra kell érvényesíteni
no-store	Sehol nem tárolható
immutable	A tartalom élettartama alatt nem változik, felesleges újraérvényesíteni
stale-while-revalidate=N	Lejárat után még N másodpercig kiszolgálható a régi példány, miközben a háttérben frissül

A szerveroldali cache működése

A szerveroldali gyorsítótár a látogató számára láthatatlan, de a válaszidőt nagyban befolyásolja. Egy tartalomkezelő rendszer egy oldal előállításához sokszor több adatbázis-lekérdezést futtat. Az oldal gyorsítótár a kész HTML-t tárolja, így a következő kérésnél ez az egész munka elmarad. Az objektum gyorsítótár finomabb: a lekérdezések eredményeit tartja memóriában, így akkor is segít, ha a teljes oldal nem tárolható. Ezek együtt határozzák meg, mennyi idő telik el az első bájtig, ami az LCP egyik összetevője.

Hogyan kezeli a Google a gyorsítótárazást?

A Google keresőrobotjai a Google Search Central dokumentációja szerint támogatják a feltételes kéréseket az ETag és a Last-Modified alapján. Ha a tartalom nem változott, a 304 válasz megspórolja a teljes letöltést, ami a szervernek és a crawl budget szempontjából is kedvező. Fontos, hogy a fejlécek őszinték legyenek: ha a szerver akkor is új ETag-et ad, amikor semmi nem változott, vagy akkor is 304-et, amikor igen, a haszon elvész vagy hibába fordul.

Fő módszerek

A jól beállított gyorsítótár fájltípusonként más szabályt követ. Az alábbi módszerek együtt adják a szokásos, bevált felépítést.

Verziózott statikus fájlok hosszú tárolással

A stíluslapok, szkriptek és betűtípusok akkor tárolhatók hosszan, ha a fájlnév minden tartalmi változáskor megváltozik. Ezt nevezik cache bustingnak: a buildfolyamat a fájl nevébe vagy egy paraméterébe beleírja a tartalom lenyomatát, például app.3f9a1c.js. Így a régi fájl nyugodtan élhet a gyorsítótárban akár nagyon hosszan, mert az új változat egy új címen érkezik, és a HTML már az új címre hivatkozik. Ilyen fájloknál a hosszú max-age és az immutable együtt a megszokott beállítás.

HTML rövid tárolással vagy újraérvényesítéssel

A HTML oldal az, amelyik a változásokat hordozza: új tartalom, új belső linkek, módosított canonical vagy meta robots. Ezért a HTML-nél rövid élettartam vagy no-cache a szokásos választás, ETag alapú újraérvényesítéssel. A megosztott gyorsítótárban, például a CDN-en, rövid ideig tárolható, ha van érvénytelenítési folyamat.

Személyes tartalom kizárása

Minden, ami egy adott felhasználóhoz tartozik, private vagy no-store jelölést kap: kosár, fiókoldal, bejelentkezett nézet. Ha ez megosztott gyorsítótárba kerül, egy látogató a másik adatait láthatja. Ez nem SEO hiba, hanem biztonsági és adatvédelmi kérdés, de a cache beállításánál ez az első szempont.

Döntési szabály fájltípusonként

Fájltípus	Javasolt megközelítés
Verziózott CSS, JS, betűtípus	Hosszú max-age, immutable
Nem verziózott kép	Közepes élettartam, újraérvényesítés ETag-gel
Nyilvános HTML oldal	Rövid élettartam vagy no-cache, CDN-en rövid tárolás purge-dzsel
Személyes HTML oldal	private vagy no-store
robots.txt, sitemap	Rövid élettartam, hogy a változás gyorsan érvényesüljön

Érvénytelenítés: a tárolás másik fele

A gyorsítótárazás csak akkor biztonságos, ha van mód a tárolt példányok eltávolítására. Megosztott gyorsítótárnál ez a purge: egy adott URL, egy URL-csoport vagy a teljes tároló törlése. A tartalomkezelő rendszerek egy része bővítménnyel vagy beépített funkcióval képes egy oldal mentésekor automatikusan érvényteleníteni a hozzá tartozó URL-eket. Érdemes végiggondolni, mi mindent érint egy módosítás: egy új cikk nemcsak a saját oldalát, hanem a kategóriaoldalt, a főoldalt és a listázó oldalakat is megváltoztatja. Ha csak a cikk URL-je törlődik, a listák régi állapota tovább él.

A böngésző gyorsítótárát a webhely nem tudja távolról törölni. Ezért kell a böngészőben hosszan tárolt fájloknál a verziózott név: ez az egyetlen megbízható módja annak, hogy a változás eljusson minden látogatóhoz. A HTML-nél ugyanezért kerülendő a hosszú böngészőoldali tárolás.

Egyéb gyorsítótárak

A böngészők a vissza és előre gombhoz külön gyorsítótárat is használnak, amely a teljes oldalállapotot megőrzi, így a visszalépés szinte azonnali. Ezt bizonyos kódminták, például egyes eseménykezelők vagy a no-store a HTML-en, megakadályozhatják. A service worker saját gyorsítótárat kezel, amelyet a webhely kódja irányít. Mindkettő a felhasználói élményt érinti, közvetlen keresőhatásuk nincs.

Gyakori hibák

A gyorsítótár hibái azért alattomosak, mert a fejlesztő gyakran nem látja őket: a saját böngészőjében friss állapotot lát, miközben a látogatók vagy a kereső egy régebbit. Az alábbi hibák visszatérően előfordulnak.

Elavult SEO jelzések a gyorsítótárban

Ha a HTML hosszan tárolódik, és egy SEO javítás után nincs érvénytelenítés, a kereső a régi változatot kapja. Egy eltávolított noindex, egy javított canonical vagy egy új belső link csak a tárolt példány lejárta után látszik. Ugyanez igaz a robots.txt és az XML sitemap fájlra, ha azok is hosszú tárolást kapnak.

Hibaválaszok tárolása

Ha egy átmeneti szerverhiba vagy egy tévesen kiadott 404 tárolódik, a hiba a gyorsítótárban tovább él, mint az oka. A megosztott gyorsítótárakban érdemes a hibaválaszokra nagyon rövid vagy nulla élettartamot beállítani.

A no-cache félreértése

Gyakori tévhit, hogy a no-cache tiltja a tárolást. Valójában tárolást enged, csak minden felhasználás előtt újraérvényesítést követel. A tárolás tiltása a no-store. A félreértés két irányban okoz gondot: aki tiltani akart, az tárolt adatot hagy maga után, aki gyorsítani akart, az feleslegesen tiltja a tárolást.

Hamis újraérvényesítés

Ha az ETag minden kérésnél új értéket kap, például mert több szerver eltérően számolja, a feltételes kérés sosem ad 304-et. Ha a Last-Modified mindig az aktuális idő, ugyanez történik. Ilyenkor a böngésző és a keresőrobot minden alkalommal a teljes tartalmat tölti le.

Tévhit: a gyorsítótár mindent megold

Egy lassú webhelyen a gyorsítótár bekapcsolása gyakran látványos javulást hoz az első mérésben, ezért könnyű azt hinni, hogy ezzel a sebesség kérdése le van zárva. A gyorsítótár azonban csak a szállítást és az előállítást gyorsítja. Ha az oldal túl nagy képeket tölt be, vagy a böngészőnek sok JavaScriptet kell feldolgoznia, a tárolt fájlok is lassan jelennek meg, és az INP sem javul attól, hogy a szkript gyorsabban érkezik. Az első látogatás, amikor a böngésző gyorsítótára még üres, egyébként is a leggyakoribb eset a keresőből érkezőknél.

Ellenpélda: amikor a hosszú tárolás helyes

Nem minden hosszú tárolás hiba. Egy verziózott JavaScript fájl, amelynek neve a tartalmából képzett lenyomatot tartalmaz, nyugodtan tárolható nagyon hosszan, mert a tartalma soha nem változik az adott címen. Ha egy audit ilyen fájlnál a hosszú élettartamot kifogásolja, az audit téved, nem a beállítás.

Egyéb hibák röviden

• Verziózás nélküli hosszú tárolás. A CSS módosul, a látogatók egy része a régi stílust látja.
• Túl sok Vary érték. Ha a válasz például a teljes User-Agent szerint változik, a megosztott gyorsítótár szinte sosem talál egyezést.
• Követő paraméterek. A kampányparaméterek külön példányokat hoznak létre ugyanabból az oldalból; erről az URL-paraméterek útmutató szól.
• Egymásnak ellentmondó rétegek. A szerver no-cache-t küld, a CDN szabálya mégis órákig tárol.

Mérés

A gyorsítótár mérése a fejlécek ellenőrzésével kezdődik, és a valós látogatói adatokkal folytatódik. Mindkét lépés ingyenes eszközökkel elvégezhető.

Fejlécek ellenőrzése

A böngésző fejlesztői eszközeinek Network lapja minden kérésnél mutatja a válaszfejléceket, és azt is, hogy a fájl a gyorsítótárból jött-e. Parancssorból a curl -I adja vissza a fejléceket. A feltételes kérés is kipróbálható: ha a kérésbe beleteszed a korábban kapott ETag értéket az If-None-Match fejlécben, változatlan tartalomnál 304 választ kell kapnod. Megosztott gyorsítótárnál az Age fejléc mutatja, mióta tárolódik a válasz.

Lighthouse és PageSpeed Insights

A Lighthouse és a PageSpeed Insights jelzi, ha a statikus fájlok gyorsítótárazási élettartama rövid. A figyelmeztetést nem kell vakon követni: ha egy fájl nem verziózott, a rövid élettartam szándékos is lehet. A terepi adatok, vagyis a Chrome felhasználói adatai, azt mutatják meg, hogy a visszatérő látogatók valóban gyorsabban kapják-e az oldalt, és hogyan alakul a Core Web Vitals.

A keresőrobot szemszöge

A Search Console feltérképezési statisztikái jelentésében válaszkódok szerint is látszik, mit kapott a Googlebot, így az is, hogy a 304 válaszok megjelennek-e. A szervernaplóban ugyanez pontosabban követhető: ha a Googlebot kérései mind 200-at kapnak olyan oldalakon, amelyek hetek óta nem változtak, az újraérvényesítés valószínűleg nem működik.

Kidolgozott példa: a javítás, ami nem látszott

Egy webáruház egy kategóriaoldalon véletlenül noindexet hagyott. A hibát észreveszik, kijavítják, de az URL-ellenőrző élő tesztje még mindig a noindexet mutatja. A fejlécekből kiderül, hogy a CDN a HTML-t hosszan tárolja, és a mentés nem indít érvénytelenítést. A csapat kézzel törli az adott URL tárolt példányát, a teszt azonnal a javított oldalt mutatja. Utána a HTML élettartamát rövidre állítják, és a tartalomkezelő mentéséhez automatikus purge-ot kötnek.

Ellenőrzőlista

1. Verziózott statikus fájlok hosszú élettartammal tárolódnak.
2. A HTML rövid ideig vagy újraérvényesítéssel tárolódik.
3. A személyes oldalak private vagy no-store jelölést kapnak.
4. Változatlan tartalomra a feltételes kérés 304-et ad.
5. Hibaválaszok nem tárolódnak hosszan.
6. A robots.txt és a sitemap változása gyorsan érvényesül.
7. A CDN szabályai nem mondanak ellent a szerver fejléceinek.

Kapcsolódó részletes útmutatók

• Technikai SEO: a teljes témakör
• CDN: teljes útmutató
• HTTP-státuszkódok: teljes útmutató
• Page speed: teljes útmutató
• Crawl budget: teljes útmutató
• Robots.txt: teljes útmutató
• Meta robots: teljes útmutató
• X-Robots-Tag: teljes útmutató
• XML sitemap: teljes útmutató