Sebesség és gyorsítótárazás egy webáruháznál

Modul 6: Üzemeltetés és biztonság · Olvasási idő: 10 perc

Tanulási cél: A lecke után úgy tudja beállítani egy WooCommerce-webáruház gyorsítótárazását, hogy az áruház gyors legyen, a személyes oldalak pedig soha ne kerüljenek a gyorsítótárba, és ezt a HTTP-fejlécek alapján ellenőrizni is tudja.

Kulcsfogalmak: oldal gyorsítótár, kizárások (kosár, pénztár, Fiókom), a gyorsítótárat megkerülő sütik, no-cache fejlécek, DONOTCACHEPAGE, objektum-gyorsítótár, Redis, kosárfragmentumok, földrajzi helymeghatározás oldal gyorsítótárral, időzített műveletek takarítása

Kétféle oldal

A gyorsítótárazás alapjait (oldal gyorsítótár, böngésző-gyorsítótár, objektum-gyorsítótár, OPcache, CDN) a WordPress-tanfolyam 6.2. leckéje tárgyalja. Ott szerepel már a webáruházak legfontosabb szabálya is: a személyes oldalak nem kerülhetnek az oldal gyorsítótárba. Ez a lecke ezt fejti ki részletesen.

Egy webáruháznak kétféle oldala van:

Ha valami elromlik, az azonnal látszik: egy vásárló egy másik ember kosarát látja, vagy ami még rosszabb, valaki más címét a pénztár oldalon. Ez a GDPR értelmében adatvédelmi incidens is (KB 6749).

Amit a WooCommerce maga is megtesz

A WooCommerce háromféleképpen segíti a gyorsítótárat, és érdemes ezeket ismerni, hogy észrevegye, ha valami kiiktatja őket:

1. Konstansok. A kosár, a pénztár és a Fiókom oldalon a WooCommerce beállítja a DONOTCACHEPAGE konstanst (és az objektum-, illetve adatbázis-gyorsítótárra vonatkozó társait is). Sok gyorsítótár-bővítmény olvassa ezt a konstanst, és ilyenkor kihagyja az oldalt.
2. Fejlécek. Ugyanezeken az oldalakon a WooCommerce elküldi a WordPress no-cache fejléceit: Cache-Control: no-cache, must-revalidate, max-age=0, private, valamint egy múltbeli Expires értéket. A szabályokat betartó proxy vagy CDN ilyenkor nem tárolja az oldalt. Bejelentkezett felhasználóknál ehhez a no-store is hozzájön.
3. Sütik. Amint valaki terméket tesz a kosárba, a WooCommerce sütiket állít be, például woocommerce_items_in_cart, woocommerce_cart_hash és wp_woocommerce_session_.... A jó gyorsítótárak az ilyen sütivel rendelkező látogatóknak már nem adnak tárolt oldalt, a termékoldalakból sem, mert például a fejlécben lévő kosár ilyenkor látogatónként eltér.

A WooCommerce dokumentációja a gyorsítótár-bővítményekhez ezt írja elő: zárja ki a kosár, a Fiókom és a pénztár oldalt, valamint a woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed és store_notice[...] sütiket. Varnishhoz a ?add-to-cart= paramétert tartalmazó címekre is ad szabályokat.

Hol csúszik el a gyakorlatban

• Eltérő címek az áruházi oldalakhoz. Átnevezte a kosarat /mandje/ címre, vagy egy fordítóbővítmény létrehozza a /de/warenkorb/ oldalt. Az a gyorsítótár, amely fix címek alapján zár ki, például /cart, ezeket nem veszi észre. A WooCommerce-t ismerő gyorsítótár-bővítmények a beállításokból olvassák ki az oldalakat; a szerveroldali vagy CDN-es gyorsítótár ezt nem teszi meg.
• Mindent gyorsítótárazó CDN. Egyes CDN-szabályok („cache everything”) figyelmen kívül hagyják a fejléceket. Ilyenkor kifejezetten zárja ki az áruházi oldalakat és a fent említett sütiket.
• A fejléceket felülíró bővítmény. Egy biztonsági vagy gyorsító bővítmény néha minden oldalon Cache-Control: public, max-age=... fejlécet állít be. Ekkor a no-cache fejlécek már nem szerepelnek.
• Munkamenet minden látogatónak. A WooCommerce alapesetben csak akkor állít be munkamenet-sütit, ha van valami a kosárban. Ha egy bővítmény vagy sablon már minden látogatónál munkamenetet indít (az első látogatáskor wp_woocommerce_session_ vagy PHPSESSID süti jelenik meg), akkor az oldal gyorsítótár mindenkinél kiesik, és nagy forgalomnál lassú lesz a webáruháza.
• Földrajzi helymeghatározás. A WooCommerce > Beállítások > Általános menüpontban választhatja ki a vásárló alapértelmezett helyét. Az egyszerű „Földrajzi helymeghatározás” beállításnál a szerver minden látogatónál kiszámítja az országot, ami országonkénti áraknál nem fér össze az oldal gyorsítótárral. Ezért kínálja a WooCommerce a „Földrajzi helymeghatározás (oldal gyorsítótár támogatással)” lehetőséget, amely egy további böngészőoldali lekéréssel határozza meg az országot. Ha a pénztár előtt nincs szüksége országonkénti árakra vagy áfára, válassza az áruház országát: ez a legegyszerűbb. A földrajzi helymeghatározáshoz a WooCommerce rendszeresen letölt egy adatbázist a MaxMindtól.

LiteSpeed-szerveren (mint a WebOké-nál) a LiteSpeed Cache bővítmény maga kezeli a WooCommerce kizárásait; ellenőrizze ezeket a kizárási beállításoknál. Más webszervereknél és tárhelyszolgáltatóknál egy másik gyorsítótár-bővítménnyel hasonlóan működik.

Amit az oldal gyorsítótár nem old meg

A kosarat és a pénztárt mindig a PHP és az adatbázis állítja össze. Nagy forgalomnál (akció, hírlevél) éppen ezek azok az oldalak, ahol a vásárlói pénzt költenek. Itt más dolgok segítenek:

• Egy objektum-gyorsítótár, például a Redis, a memóriában tárolja az adatbázis-lekérdezések eredményét. Egy webáruháznál, ahol sok oldal nem kerülhet az oldal gyorsítótárba, ez érezhetően többet hoz, mint egy átlagos webhelynél. A tárhelynek támogatnia kell a Redist (a WebOké-nál ez lehetséges, DA 15.7); utána egy bővítménnyel kapcsolhatja be.
• Kosárfragmentumok. A klasszikus sablonok egy szkripttel (wc-cart-fragments) frissítik a fejlécben lévő kosarat, amely nem üres kosárnál egy további lekérést indít. A modern blokksablonoknak a mini kosár blokkal erre kevésbé van szükségük. Ne töltse be az ilyen szkripteket olyan oldalakon, ahol nincs szerepük.
• Kitakarított időzített műveletek. A WooCommerce a háttérfeladatokhoz az Action Schedulert használja (7.3. lecke). A befejezett műveletek alapértelmezés szerint egy hónap után törlődnek. Ha a lista mégis több százezer tételre nő, gyakran egy folyamatosan ütemező bővítmény vagy sikertelen műveletek miatt, akkor az adatbázis-lekérdezések lelassulnak. A WooCommerce > Állapot > Időzített műveletek menüpontban nézze meg a sikertelen és a függőben lévő műveletek számát.
• HPOS. A saját táblákban tárolt rendelések (1.2. lecke) gyorsabbá teszik a rendelések közötti keresést, mint a régi bejegyzéstábla. A meglévő áruházaknak maguknak kell átállniuk (a 6.2. lecke szól az előzetes biztonsági mentésről).
• Aktuális PHP verzió és elegendő memória (7.2. lecke).

A gyakorlatban: így néz ki a WooCommerce-ben

Ellenőrizze a Theehuis Example áruházánál egy privát ablakban, a böngésző fejlesztői eszközeivel (F12, Hálózat fül, első kérés):

1. Kezdőlap, kétszeri betöltés: a második alkalommal egy olyan fejléc, mint x-litespeed-cache: hit vagy cf-cache-status: HIT. Az első látogatáskor nincs wp_woocommerce_session_ süti.
2. shop.example.com/winkelwagen/, kétszeri betöltés: nincs találat (hit), és a cache-control tartalmazza a no-cache vagy a private értéket.
3. Ugyanez a pénztárnál és a Fiókom oldalnál.
4. Tegyen egy terméket a kosárba, és töltsön be egy termékoldalt: a saját kosarát látja, nem egy tárolt változatot.

Összefoglalás

• A mindenkinek egyforma oldalak mehetnek a gyorsítótárba; a kosár, a pénztár és a Fiókom soha.
• A WooCommerce maga beállítja a DONOTCACHEPAGE konstanst, a no-cache fejléceket és a sütiket; ellenőrizze, hogy semmi ne iktassa ki vagy hagyja figyelmen kívül ezeket.
• Figyeljen az átnevezett címekre, a CDN-szabályokra, a fejléceket felülíró bővítményekre, a minden látogatónak induló munkamenetekre és a földrajzi helymeghatározásra.
• A Redis, a kitakarított időzített műveletek, a HPOS és egy megfelelő PHP verzió ott segít, ahol az oldal gyorsítótár nem alkalmazható.
• Teszteljen kétszeri betöltéssel egy privát ablakban, és olvassa el a fejléceket.

Kvíz

Feladat

A6.4. feladat: A kosár és a pénztár kimarad a gyorsítótárból? Adja meg a webáruháza címét, valamint a kosár és a pénztár oldal címét (és adott esetben a Fiókom oldalét). A program kétszer kéri le a kezdőlapot, 2 másodperc különbséggel, sütik nélkül, majd minden áruházi oldalt szintén kétszer. Semmi nem kerül a kosárba, és semmit nem rendel meg. Zöld, ha a kezdőlap második alkalommal a gyorsítótárból jön (vagy érezhetően gyorsabb), és nem állít be munkamenet-sütit, valamint ha minden áruházi oldalon a második alkalommal nincs gyorsítótár-találat, és az oldal no-cache, no-store, private vagy max-age=0 értéket tartalmazó Cache-Control fejlécet küld. Narancs, ha a kezdőlap nem használ gyorsítótárat, vagy ha egy áruházi oldalon nincs találat, de no-cache fejléc sincs. Piros, ha a kosár, a pénztár vagy a Fiókom oldalon gyorsítótár-találat van, vagy ha a kezdőlap minden látogatónál WooCommerce-munkamenetet indít.

A zöld pipa azt jelenti, hogy ez az ellenőrzés most rendben van, nem azt, hogy a webáruháza biztonságos.

Bővebben olvasva

A vezérlőpulton belüli lépések a WebOké-ra vonatkoznak; más szolgáltatóknál hasonlóan működik.

• Ingyenes WordPress-tanfolyam 6.2: Gyorsítótárazás (caching)
• Ingyenes WordPress-tanfolyam 6.3: Képek, PHP és egyéb sebességnövelő megoldások
• DirectAdmin útmutató 15.7: Redis
• A weboldalam lassú, vagy túl sok CPU-t használ: így tehető gyorsabbá
• Ez adatszivárgásnak minősül, és be kell jelentenem?
• Configuring caching plugins (developer.woocommerce.com, angol nyelvű): https://developer.woocommerce.com/docs/best-practices/performance/configuring-caching-plugins/