A nyilvános oldalakat cache-elje page cache-ben vagy CDN-en, a személyre szabott fiókokat, kosarakat és callbackeket zárja ki. Az objektum-cache-t ismétlődő számításokhoz és lekérdezésekhez használja, ne azok javításának helyettesítésére. Határozza meg a cache key-t és az érvénytelenítést tartalom, ár vagy jogosultság változásakor, és tesztelje anonim és bejelentkezett felhasználóval is.
A WordPress cache úgy gyorsítja a weboldalt, hogy nem járja be újra és újra a teljes utat a PHP-tól és az adatbázistól a távoli fájlokig. Több réteg is létezik azonban: page cache, objektum-gyorsítótár, opcode cache, CDN és a böngésző. Mindegyik más eredményt tárol, és más érvényességi szabályok vonatkoznak rá. Két, ugyanazt a réteget beállító bővítmény ütközést okozhat, a hiányzó érvénytelenítés pedig régi árat vagy tartalmat jeleníthet meg.
A helyes tervezés az oldalak nyilvános, személyre szabott és érzékeny kategóriába sorolásával kezdődik. Egy nyilvános cikk biztonságosan megosztható sok látogatóval, egy fiók vagy egy kosár nem. A cache-kulcsnak figyelembe kell vennie a nyelvet, a pénznemet vagy a szükséges szerepkört, és az adatok változása után a megfelelő bejegyzést el kell távolítani. A teljesítményt a működéssel együtt kell ellenőrizni, nem csak a hit rate alapján.
Különböztesse meg a gyorsítótár egyes rétegeit
A page cache a kész HTML-választ tárolja, és megkerüli a WordPress nagy részét. Az objektum-gyorsítótár az adatműveletek eredményeit őrzi meg a kérések között. Az opcode cache felgyorsítja a PHP-kód végrehajtását, a böngésző pedig a fejlécek alapján tárolja a statikus fájlokat. A CDN a hálózat peremén gyorsítótárazhatja a képeket, a CSS-t vagy teljes nyilvános oldalakat.
Egy új bővítmény bekapcsolása előtt derítse ki, mit biztosít már a tárhelyszolgáltató vagy a proxy. A kettős page cache megnehezíti a törlést és a diagnosztikát. Dokumentálja minden réteg felelősét, adminisztrációs elérési útját és a vészhelyzeti purge módját. Minden törlése átmenetileg megterhelheti a szervert, ezért nagy weboldal esetén részesítse előnyben a célzott invalidálást.
Osztályozza a nyilvános és a személyre szabott tartalmat
A cikkek, szolgáltatások és nyilvános archívumok jó jelöltek, ha a kimenetük nem függ a felhasználó személyétől. Az adminisztrációt, a vázlatelőnézetet, a fiókot, a kosarat, a pénztárt, a nonce-ot és a fizetési callbacket nem szabad nyilvános cache-ből kiszolgálni. A cache-elt oldalon lévő űrlapnak támogatott módon kell létrehoznia vagy frissítenie a biztonsági tokeneket.
A bejelentkezett szerkesztő láthatja az eszköztárat, a szerkesztési linket és a nem nyilvános tartalmat, ezért a cache a cookie-k alapján különbséget tesz, vagy ezeknél a munkameneteknél megkerülésre kerül. Egy tagsági weboldalnak finomabb, szerepkör vagy jogosultság szerinti kulcsra van szüksége, de ez nem vezethet korlátlan számú változathoz. Először minimalizálja a nyilvános oldal személyre szabását.
- Nyilvános anonim HTML
- Kizárt fiókok és tranzakciók
- Elkülönített bejelentkezett munkamenetek
- Ne legyenek titkok a cache-kulcsban vagy a naplóban
Tervezze meg a cache key-t és az érvénytelenítést
A kulcs tartalmazhatja az URL-t, a nyelvet, a pénznemet, az eszközt – de csak ha a tartalom valóban eltér –, valamint további ellenőrzött változatokat. Hagyja figyelmen kívül azokat a kampányparamétereket, amelyek nem változtatják meg a tartalmat, hogy ne jöjjön létre több ezer másolat. Ezzel szemben az eredményt megváltoztató szűrőparaméter nem kaphatja meg egy másik kombináció HTML-jét. A normalizálást kódolt értékekkel is tesztelje.
Cikk mentésekor a függőségek szerint ürítse a részletes oldalát, a releváns archívumot, a kezdőlap szekcióját és a sitemapet. A globális fejléc módosítása az egész webhelyet érintheti, ezért szélesebb körű érvénytelenítést igényel. Az ár vagy a készlet rövid érvényességi időt vagy az integrációból érkező eseményt igényel. Az időalapú TTL biztosíték, nem helyettesíti a kritikus változás utáni pontos purge-ot.
Az objektum-gyorsítótárat a megfelelő adatokhoz használja
A perzisztens objektum-cache az ismétlődő lekérdezéseknél és számításoknál segít, ha stabil kulccsal és ésszerű élettartammal rendelkeznek. Nem arra való, hogy megmentsen egy olyan lekérdezést, amely korlát nélkül tölti be az összes rekordot. Kövesse a hit rate-et, a memóriát, az evictionöket és a tároló késleltetését. Egy rosszul beállított távoli cache-szerver lassabb lehet a helyi adatbázisnál.
A kulcsokat lássa el névtérrel webhely és környezet szerint, különösen multisite vagy megosztott Redis esetén. Az éles és a staging környezet nem olvashatja ugyanazokat az objektumokat. Az adatformátumot megváltoztató deployment esetén növelje a namespace verzióját, vagy hajtson végre biztonságos invalidálást. Érzékeny választ soha ne tároljon nyilvános objektumként hozzáférés-ellenőrzés nélkül.
- Stabil, névtérrel ellátott kulcs
- Megfelelő élettartam és méret
- Elkülönített környezetek
- A memória és az ürítés monitorozása
Tesztelje a gyorsítótárat funkcionális elemként
Tesztelje az első és az ismételt látogatást, az anonim és a bejelentkezett ablakot, két nyelvet, a mobilnézetet, az űrlapot és az előnézetet. Módosítson egy cikket, menüt, árat vagy jogosultságot, és mérje meg, mennyi idő alatt jelenik meg a helyes kimenet. Ellenőrizze a cache-fejléceket, az Age és Vary fejlécet, valamint a CDN állapotát. Soha ne csak adminisztrátorként teszteljen, mert nála a cache gyakran megkerülésre kerül.
Hiba esetén haladjon a böngészőtől a CDN-en és a szerveroldali page cache-en át az objektumokig, ne töröljön egyszerre mindent. Így kiderül, melyik réteg a hibás. A cache-bővítmény frissítése után végezzen regressziós tesztet a kritikus útvonalakon. A runbooknak le kell írnia a célzott törlést, a teljes purge-öt, a várható átmeneti terhelést és a tárhelyszolgáltató elérhetőségét.
Gyakori kérdések
Miért jeleníti meg a WordPress módosítás után is a régi tartalmat?
A régi választ tárolhatja a böngésző, a CDN, az oldalgyorsítótár vagy az objektumgyorsítótár. Nézze meg a fejléceket, és fokozatosan ürítse a rétegeket. Ezután javítsa ki az érvénytelenítést az adott változtatásnál, hogy a szerkesztőnek ne kelljen mindig mindent törölnie.
Gyorsítótárazhatom a WooCommerce kosarat?
Ne használjon nyilvános oldalgyorsítótárat (page cache) a kosárhoz és a pénztárhoz. A katalógus gyorsítótárazható az ár és a készlet érvénytelenítésével. A konkrét cookie-kat, fragmentumokat és végpontokat a WooCommerce, a tárhely és a használt bővítmények szerint állítsa be.
Mindig gyorsabb a több gyorsítótárréteg?
Nem. Minden réteg újabb szabályokat, érvénytelenítést és esetleges hálózati lépést jelent. Csak mérhető hasznot hozó és egyértelmű felelőssel rendelkező rétegeket használjon. Az egymást duplikáló page cache mechanizmusok ronthatják a megbízhatóságot.
Források és további olvasnivaló
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
