Gyorsítótár-ürítési stratégia tartalomfrissítés és bővítményfrissítés után

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

Egy WordPress-oldalon ritkán dolgozik egyetlen gyorsítótár. Mire egy látogató vagy egy crawler megkapja a cikkedet, a válasz akár öt rétegen is átmegy, és mindegyik rétegnek saját élettartama és saját ürítési módja van. Ha módosítasz egy árat, és a vásárló még mindig a régit látja, szinte mindig az történt, hogy rossz réteget ürítettél, vagy kihagytál egyet. Ez a cikk sorra veszi a rétegeket, eseményenként megmondja, mit kell üríteni, és megmutatja, hogyan állíthatsz be célzott ürítést és előmelegítést.

A szövegben háromféle jelölést használok. A Hivatalosan igazolt állítás dokumentációból vagy szabványból származik. A Saját tapasztalat azt jelenti, amit WordPress-oldalak üzemeltetése közben rendszeresen látunk. A Szakmai feltételezés logikus következtetés, de nincs rá hivatalos megerősítés.

Hány gyorsítótár-réteg van egy átlagos WordPress-oldalon?

Jellemzően öt van belőle, a böngésző, a CDN, a szerveroldali oldal-gyorsítótár, a bővítmény által kezelt oldal-gyorsítótár és az object cache. Egymásra épülnek, ezért a látogatóhoz legközelebbi réteg mindig előbb válaszol, mint a mögötte lévők, és ha az még a régi változatot tartja, a hátsó rétegek ürítése nem látszik.

• Böngésző-gyorsítótár. A látogató gépén tárolt CSS, JS, képek és ritkábban a HTML. A Cache-Control fejléc szabályozza, működését az RFC 9111 írja le (hivatalosan igazolt). Távolról nem tudod üríteni, csak új fájlnévvel vagy verzióparaméterrel kerülheted meg.
• CDN. Például Cloudflare, Bunny vagy a tárhelyszolgáltató saját peremhálózata. A statikus fájlokat szinte mindig tárolja, a HTML-t általában csak külön beállításra.
• Szerveroldali oldal-gyorsítótár. Nginx FastCGI cache, Varnish vagy a LiteSpeed szerver saját gyorsítótára. Kész HTML-t ad vissza úgy, hogy a PHP el sem indul.
• Bővítményes oldal-gyorsítótár. WP Rocket, W3 Total Cache, WP Super Cache és társaik fájlba mentik a HTML-t, és sokszor a minifikált, összevont CSS- és JS-fájlokat is ők állítják elő.
• Object cache. Redis vagy Memcached, amely a WordPress Object Cache API (wp_cache_get(), wp_cache_set()) adatait a kérések között is memóriában tartja. Lekérdezés-eredményeket és tranzienseket tárol, kész oldalt nem. A WordPress fejlesztői dokumentációja szerint az object cache alapból csak egy kérés idejéig él, tartós tárolást külső bővítménnyel kap (hivatalosan igazolt).

Ide tartozik még a PHP OPcache, amely a lefordított PHP-kódot tartja memóriában. A legtöbb tárhelyen magától észreveszi a fájlváltozást. Ha viszont az opcache.validate_timestamps ki van kapcsolva, bővítményfrissítés után a PHP-folyamatot újra kell indítani, különben a régi kód fut tovább (hivatalosan igazolt a PHP kézikönyvében).

Miért nem elég egyetlen „Gyorsítótár ürítése” gomb?

A gomb általában csak a saját rétegét üríti. A WP Rocket gombja nem nyúl a Cloudflare-hez, ha nincs összekötve vele, a Redisben tárolt adat pedig érintetlen marad.

Saját tapasztalat. A leggyakoribb panasz az, hogy „kiürítettem a cache-t, mégis a régi látszik”. Ilyenkor szinte mindig a CDN vagy a böngésző tartja a régi változatot. A diagnózishoz a válaszfejléceket érdemes megnézni. A Cloudflare a cf-cache-status, a LiteSpeed az x-litespeed-cache fejlécet adja vissza, sok Nginx-beállítás pedig egy saját x-cache fejlécet. Ha HIT áll benne, az a réteg szolgálta ki a kérést, az age fejléc pedig megmutatja, hány másodperce tárolja.

curl -sI https://pelda.hu/cikk/ | grep -i -E "cache|age|cf-"

Ha a böngészőt akarod kizárni, futtasd a parancsot, vagy nyisd meg az oldalt privát ablakban. Ha a CDN-t, kérd le egyszer egy egyedi paraméterrel (például ?nocache=1), és hasonlítsd össze a kettőt.

Melyik eseménynél melyik réteget kell üríteni?

Csak azt a réteget és azokat az URL-eket ürítsd, amelyek az adott változást tartalmazzák. Az alábbi eseménytábla egy jól bevált alapbeállítás, minden oldalnál a saját felépítéséhez kell igazítani.

Cikk vagy oldal módosítása

• Bővítmény és szerver. A módosított URL, a főoldal, az érintett kategória- és címkearchívum, a szerzői oldal és az RSS-feed.
• Object cache. Általában nem kell, mert mentéskor a WordPress a clean_post_cache() függvénnyel maga érvényteleníti a bejegyzés adatait (hivatalosan igazolt).
• CDN. Ugyanazok az URL-ek, ha a CDN HTML-t is tárol.
• Böngésző. Nem kell, ha a HTML élettartama rövid, néhány perc vagy kevesebb.
• Előmelegítés. A módosított URL és a főoldal.

Ár- vagy készletváltozás webshopban

• Bővítmény és szerver. A termékoldal, a szülőkategóriák, a bolt főoldala és minden olyan oldal, ahol a termék blokkban vagy ajánlóban megjelenik.
• Object cache. A WooCommerce mentéskor maga törli a termék tranzienseit. Ha viszont egy külső készletimport vagy ERP-szinkron közvetlenül az adatbázisba ír, a mentési hook nem fut le, és a régi adat bent marad (saját tapasztalat). Ilyenkor az importot követően célzottan kell üríteni.
• CDN. Ugyanazok az URL-ek, a változással egy időben.
• Böngésző. Nem kell.
• Miért sürgős? A Google Merchant Center irányelvei szerint a céloldalon látható árnak egyeznie kell a feedben megadott árral (hivatalosan igazolt). A régi árat mutató gyorsítótárazott oldal emiatt termékelutasításhoz vezethet.

A kosár, a pénztár és a fiókoldal soha ne kerüljön oldal-gyorsítótárba. A nagyobb gyorsítótár-bővítmények ezeket alapból kizárják, de egyedi URL-szerkezetnél érdemes ellenőrizni.

Sablon- és CSS-módosítás

• Bővítmény. A generált, minifikált és összevont CSS- és JS-fájlok újragenerálása, utána teljes oldal-gyorsítótár ürítés, mert minden oldal HTML-je a régi fájlnévre hivatkozik.
• Szerver. Teljes ürítés, ugyanezért.
• Object cache. Általában nem kell, kivéve ha a sablon a beállításait tranziensben tartja.
• CDN. A HTML és a régi statikus fájlok.
• Böngésző. Verzióemeléssel kezeld. A wp_enqueue_style() negyedik paramétere a verzió, ezt a WordPress ?ver= paraméterként fűzi a fájl címéhez.

wp_enqueue_style( 'sablon-stilus', get_stylesheet_uri(), array(), filemtime( get_stylesheet_directory() . '/style.css' ) );

A filemtime() minden mentéskor új verziót ad, így a böngésző biztosan az új fájlt kéri. A Google JavaScript SEO dokumentációja szerint a Googlebot agresszívan gyorsítótárazza az erőforrásokat, és a renderelő szolgáltatás figyelmen kívül hagyhatja a gyorsítótár-fejléceket, ezért a fájlnév-ujjlenyomatot ajánlja (hivatalosan igazolt). A Googlebot gyorsítótárát nem tudod üríteni, csak új fájlcímmel tudod megkerülni.

Bővítményfrissítés

• Csak admin-oldali bővítmény. Semmit nem kell üríteni, legfeljebb az OPcache-t, ha az nem figyeli a fájlváltozást.
• Front-end kimenetet változtató bővítmény (űrlap, slider, oldalépítő, SEO-bővítmény sémával). Az optimalizált CSS és JS újragenerálása, teljes oldal-gyorsítótár ürítés, a CDN-en a statikus fájlok ürítése.
• Object cache. Ha a frissítés adatbázis-migrációt futtat, a teljes object cache ürítése indokolt, mert a régi szerkezetű adat bent ragadhat (szakmai feltételezés, sok bővítmény változásnaplója maga is ezt kéri).
• Böngésző. A bővítmények többsége a saját verziószámát fűzi a fájlokhoz, így ezt általában megoldja.

Domain- vagy SSL-váltás

• Minden réteg. Ez az az esemény, ahol a teljes ürítés tényleg indokolt, mert minden tárolt HTML a régi címre hivatkozik.
• Sorrend. Előbb wp search-replace az adatbázisban, utána wp cache flush, majd az oldal-gyorsítótár, végül a CDN teljes ürítése.
• Böngésző. A böngésző a 301-es átirányítást sokáig megjegyezheti, ezért élesítés előtt rövid élettartamú átirányítással tesztelj. HSTS-t csak akkor kapcsolj be, ha a HTTPS minden aldomainen stabilan működik.
• Service worker. Ha az oldalon PWA-bővítmény fut, a service worker a régi fájlokat a böngészőben tovább szolgálhatja, ezt külön frissíteni kell.

Miért árt a gyakori teljes ürítés a válaszidőnek és a crawlereknek?

Teljes ürítés után minden oldal első kérése hidegen készül el, PHP-val és adatbázis-lekérdezésekkel, ami sokszorosa a gyorsítótárból kiszolgált válasz idejének. Ha ebben az ablakban érkezik nagyobb crawler-forgalom, a szerver lelassulhat, és ez visszahat a feltérképezésre.

A Google Search Central feltérképezési kerettel foglalkozó oldala szerint ha a szerver gyorsan válaszol, a Googlebot feltérképezési kapacitása nőhet, ha pedig lassul vagy szerverhibát ad, a Googlebot visszavesz (hivatalosan igazolt). A gyakori teljes ürítés tehát rendszeresen olyan állapotba hozza az oldalt, amelyet a crawler lassú szerverként érzékelhet.

Saját tapasztalat. Teljes ürítés után a szervernaplóban jól látszik, hogy a nem gyorsítótárból kiszolgált kérések aránya és a válaszidő is felugrik, és nagyobb oldalnál órákig tart, mire minden visszamelegszik. A legtöbb ilyen hullámot nem ember indítja. Gyorsítótár-bővítmények „minden frissítéskor teljes ürítés” opciója, komment-jóváhagyásra induló teljes ürítés vagy óránkénti időzített ürítés okozza.

Szakmai feltételezés. Az AI-crawlerek (például GPTBot, ClaudeBot, PerplexityBot) eltérő tempóban kérnek le oldalakat, és ha egy hideg oldalnál időtúllépést kapnak, könnyen előfordulhat, hogy az adott URL-ről a szokásosnál ritkábban gyűjtenek friss adatot. Erre nincs nyilvános dokumentáció, de a kockázat a gyors válaszidővel jó eséllyel csökkenthető.

Hogyan állíts be célzott ürítést?

Úgy, hogy minden tartalommentés csak az érintett URL-eket vagy címkéket ürítse, és ezt az ürítést a CDN is megkapja. Lépésről lépésre így érdemes nekiállni.

1. Kösd össze a rétegeket. A gyorsítótár-bővítmény küldje tovább az ürítést a CDN-nek (például a Cloudflare saját WordPress-bővítménye, a WP Rocket Cloudflare-integrációja vagy a LiteSpeed és a QUIC.cloud kapcsolata).
2. Szűkítsd az automatikus szabályokat. Mentéskor csak a bejegyzés, a főoldal, az érintett archívumok és a feed ürüljön. Kapcsold ki a teljes ürítést kommentre, menüváltozásra és bővítményaktiválásra, ha nem feltétlenül kell.
3. Használj címkealapú ürítést, ahol elérhető. A LiteSpeed az X-LiteSpeed-Tag fejléccel, a Varnish ban-szabályokkal, a Cloudflare cache-tagekkel tud egy csoportot üríteni. A Cloudflare-nél az elérhető ürítési módok csomagtól függhetnek, ezt a saját fiókodban ellenőrizd.
4. Kezeld a külső importokat. Ha az ár vagy a készlet adatbázis-szinten változik, az import végén hívj meg egy célzott ürítést.
5. Válaszd szét a Redist. A wp cache flush a teljes Redis-adatbázist üríti. Ha több oldal osztozik egy Redisen, mindegyiknek legyen saját adatbázis-indexe vagy előtagja (például WP_REDIS_PREFIX), különben egy oldal ürítése a többit is lehűti (saját tapasztalat).

Egy URL célzott ürítése a Cloudflare API-n keresztül így néz ki.

curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONA_ID/purge_cache" -H "Authorization: Bearer API_TOKEN" -H "Content-Type: application/json" --data '{"files":["https://pelda.hu/termek/kave-500g/","https://pelda.hu/kategoria/kave/"]}'

A tranzienseknél a wp transient delete --expired csak a lejártakat törli, ami biztonságos napi karbantartás. A --all kapcsolót csak akkor használd, ha tudod, mi van bennük.

Mi az előmelegítés, és hogyan érdemes beállítani?

Az előmelegítés azt jelenti, hogy ürítés után egy robot végigkéri a fontos oldalakat, így az első valódi látogató vagy crawler már kész, gyorsítótárazott oldalt kap. A legtöbb gyorsítótár-bővítmény ezt a sitemap alapján csinálja.

• Sorrend. Előbb a főoldal, a fő kategóriák és a legforgalmasabb 50-100 URL, utána a többi.
• Tempó. Állíts be szünetet a kérések közé, és a teljes előmelegítést csúcsidőn kívül futtasd, különben az előmelegítés maga terheli túl a szervert.
• Változatok. Ha külön gyorsítótár van mobilra és asztali gépre, vagy több nyelvre, mindegyik változatot melegíteni kell.
• CDN. A Cloudflare dokumentációja szerint a gyorsítótár adatközpontonként külön él (hivatalosan igazolt), így a szerverről indított előmelegítés jellemzően csak a szerver gyorsítótárát és egy-két peremhelyet tölt fel.
• Átmeneti kiszolgálás. A stale-while-revalidate direktíva (RFC 5861) lehetővé teszi, hogy a gyorsítótár rövid ideig még a régi változatot adja, amíg a háttérben frissít. Ahol a CDN vagy a szerver támogatja, ez jó eséllyel tompítja a hideg kérések hatását.

Mit ellenőrizz minden ürítés után?

Öt gyors ellenőrzés elég ahhoz, hogy lásd, minden réteg az új változatot adja.

• Nézd meg a válaszfejléceket curl -sI paranccsal, és ellenőrizd, hogy a második kérés már HIT.
• Nyisd meg a módosított oldalt privát ablakban, mobilon is.
• Webshopnál hasonlítsd össze a termékoldal árát a feedben szereplő árral.
• Sablonmódosítás után nézd meg a forráskódban, hogy a CSS- és JS-fájlok új verziót kaptak.
• A szervernaplóban figyeld, hogy a 5xx-es válaszok és a lassú kérések száma nem ugrott-e meg az ürítés utáni órában.

Források és további olvasnivalók

• Google Search Central, Feltérképezési keret kezelése nagy webhelyeknél
• Google Search Central, A JavaScript SEO alapjai (gyorsítótárazás és fájl-ujjlenyomat)
• Google Merchant Center Súgó, Az ár egyezésére vonatkozó követelmények
• WordPress Developer Resources, WP_Object_Cache és wp_enqueue_style()
• WP-CLI dokumentáció, wp cache, wp transient és wp search-replace
• IETF RFC 9111, HTTP Caching
• IETF RFC 5861, HTTP Cache-Control Extensions for Stale Content
• Cloudflare Developers dokumentáció, Purge cache
• PHP Manual, OPcache konfiguráció