Weboldal gyorsítótár optimalizálása

A weboldal “lassúságának” gyökere általában nem egy adott kép, hanem inkábbKérési kapcsolat + kiszolgáló generálása + statikus erőforrás-elosztásamit az egymásra helyezés okoz:

• A felhasználók túl messze vannak a szerverektől, a hálózati RTT magas (ez kontinenseken át jobban észrevehető).
• A WordPress futtatja az PHP-t, ellenőrzi az adatbázist, és minden egyes → kérésre megjeleníti a sablont. TTFB (idő az első bájtig) up
• Az oldalak JS/CSS/betűtípusok/harmadik féltől származó szkriptek is betöltődnek, ami lelassítja a megjelenítést és az interakciót.

Caching PluginA megoldás lényege a “duplán számolt” oldalak eredményeinek elmentése, hogy a szervernek ne kelljen azokat minden alkalommal újraszámolnia, valamint a TTFB jelentős csökkentése azáltal, hogy a megfelelő stratégia mellett több felhasználó is elérheti a gyorsítótárat.WordPress hivatalos dokumentációArra is rámutattak, hogy az olyan bővítmények, mint a W3 Total Cache és a WP Super Cache képesek az oldalakat statikus fájlként gyorsítótárba helyezni, majd közvetlenül a felhasználónak kiszolgálni, csökkentve ezzel a szerverre háruló feldolgozási terhet.

Mielőtt elolvasod ezt az oldalt, emlékezz 3 vaskalapos szabályra

1. Page caching plug-inek egyidejűleg csak egy

A leggyakoribb eredmény, ha egyszerre több gyorsítótárazási bővítményt engedélyezünk, az, hogy nem gyorsabb:

• Egymás gyorsítótár-szabályainak felülírása, egymás gyorsítótárának törlése, a gyorsítótár találati aránya csökken.
• A dinamikus tartalom, mint például a bejelentkezési állapot/nyelv/autó/ár, gyorsítótárba kerül, ami “téves tartalom” incidenseket eredményez.
  Sok plugin dokumentáció/utasítás azt sugallja, hogy egy bizonyos caching plugin használata eseténMás gyorsítótárazási pluginok kikapcsolásaa konfliktusok elkerülése érdekében.

2. E-kereskedelmi/tagsági/többnyelvű webhelyek: a gyorsítótárazás nem egy “be/ki kapcsoló”, hanem egy “szabályrendszer”.”

WooCommerce hivatalos teljesítmény dokumentációKifejezett emlékeztető: a cache plugin, hogy megbizonyosodjon arról. Bevásárlókosár / Pénztár / Számla Javasoljuk továbbá, hogy kerülje a JavaScript-fájlok tömörítését (mivel ez kompatibilitási problémákat okoz).

3. “Cache plug-in ≠ CDN”, de a cache plug-in az CDN alapja.

Cache plugin a “forrásállomás alulszámolásának” megoldására;CDN A “tartalom közelebb a felhasználókhoz” problémájának megoldása. A kettő közötti kapcsolat egymásra van helyezve: először a TTFB forrásállomást nyomják le, majd a statikus erőforrásokat átadják az CDN-nek terjesztésre, ami a globális felhasználók számára a legstabilabb útvonal.

Gyors tippek: 4 leggyakoribb forgatókönyv a weboldalak számára

Ha nem akarod elolvasni az egész cikket, akkor a következő 4 választási lehetőséggel nem tévedhetsz:

1. Szeretne pénzt megtakarítani, stabilnak lenni, és a globális hozzáférés felé orientálódni. → WP Rocket(Fizetett)
2. A tárhely kifejezetten LiteSpeed/OpenLiteSpeed → LiteSpeed gyorsítótár(ingyenes, de erősen függ a szerver kapacitásától): A gyorsítótárazási funkciónak szüksége van A LiteSpeed szerver komponenseicsak akkor működjön
3. Tartalomoldalak/blogok/dokumentumoldalak, amelyek szabadok és stabilak akarnak lenni → WP Super Cache(statikus HTML gyorsítótár): Statikus HTML fájlok generálása a legtöbb bejelentkezetlen felhasználó számára
4. Finom vezérléssel rendelkező műszaki csapata van (CDN/objektum caching/multi-modul) → W3 Total Cache(erős, de összetett): Átfogó teljesítménykeretet tart fenn CDN integrációval

Pontosan mit tárol a gyorsítótár?

“Miért lassúak egyes oldalak a gyorsítótárazással” című cikkünkben a WordPress teljesítményét 5 rétegre bontottuk:

1. böngésző gyorsítótár: A másodlagos hozzáférés gyorsabbá tétele a felhasználók számára (statikus erőforrás-cache fejlécek, verziószámok)
2. oldal gyorsítótár: Cache oldal kimenete HTML-ként (az oldal fő karaktere)
3. objektum gyorsítótár: Adatbázis-lekérdezés eredményobjektumainak gyorsítótárba helyezése (a dinamikus állomások értékesebbek)
4. PHP OPcache: Cache PHP bytecode (általában a szerver konfigurálja, nem a plugin fókuszában)
5. CDN/edge cache: Az erőforrások elhelyezése a felhasználókhoz közelebbi csomópontokban

A cikk középpontjában: az oldal gyorsítótárazási plugin;
De folyamatosan emlékeztetnek arra, hogy a weboldalaknak gyakran a 2 + 5 kombinációjára van szükségük ahhoz, hogy “igazán gyorsak” legyenek.

Plug-in 1:WP Rocket(Díjköteles) - “gondtalan” integrált programok

A WP Rocket nem azért népszerű a “WordPress” szcénában, mert varázslatos, hanem mert a három leggyakoribb teljesítménytípust “kezelhető csomagokká” teszi:

• Oldal gyorsítótárazása (csökkenti a forrásoldali TTFB-t)
• Cache előtöltés/előmelegítés (az első látogatás élményének javítása globálisan elosztott hozzáféréssel)
• Kulcsfontosságú front-end optimalizálás (különösen JS késleltetés, CSS kezelés stb.)

annakhivatalos dokumentumKifejezetten megemlíti azt is, hogy az előtöltés bekapcsolása bizonyos optimalizálásokat (pl. CSS/JS-hez kapcsolódó optimalizációkat) akkor is elindíthat/meghajt, ha kikapcsolja az oldal gyorsítótárazását.

1.1 Kinek szól a WP Rocket

A WP Rocket különösen alkalmas ezekhez az állomásokhoz:

• Vállalati weboldal, márkázási oldal, tartalommarketing oldal, céloldal (több országból és régióból érkező forgalom)
• Azt akarom, hogy “menjünk gyorsan, stabilitás első”, nem akarok betűzni egy csomó ingyenes plugin kombináció
• Nincsenek dedikált Ops/Performance mérnökök, de van tapasztalatuk és SEO követelményeik.
• WooCommerce Ez is használható, de nagyobb óvatossággal (erről később ebben a szakaszban).Szabályok és kockázatok）

1.2 Kulcsértéke webes hozzáférési forgatókönyvekben (nem csak “cache switch”)

A. Cache-előbetöltés: a “weboldalakhoz való elosztott hozzáférés miatti instabil első látogatások” megoldása.”

Nagyon tipikus lassulást fog tapasztalni, amikor a webhely felhasználói szétszóródnak:
Ha egy felhasználó egy régióban először nyit meg egy oldalt, és az történetesen nincs a gyorsítótárban, vagy nem melegedett be → az adott felhasználónak a teljes PHP/DB renderelési költséget kell viselnie.
Előtöltő mechanizmusEnnek az a jelentősége, hogy:Az “első generációs” költségek előre történő kifizetéseA program első látogatása “tengerimalac” lesz, csökkentve ezzel az "első látogatás mint tengerimalac" valószínűségét.

• Nincs előretöltés: aki először hozzáfér, az szenved.
• Előbetöltéssel: a rendszer által a háttérben egységesített gyorsítótár létrehozása, az első látogatás élménye stabilabb

B. Halasztott JavaScript-végrehajtás: a legkönnyebben “azonnal érezhető” funkció egy weboldal látogatásakor, de egyben a legkockázatosabb is.

WP Rocket hivatalosan is hozza “Késleltetett JS végrehajtás” a legerősebb JS-optimalizálásként írja le: a szkriptek végrehajtását addig halasztja, amíg a felhasználó nem lépett interakcióba (mozgatta az egeret, megérintette a képernyőt, görgetett, megnyomott egy billentyűt stb.), hogy az oldal megjelenítését előnyben részesítse.

Ez azért fontos a weboldalak elérése szempontjából, mert a szkriptek betöltésének és végrehajtásának blokkolása nagyobb valószínűséggel erősödik fel a kontinenseken átívelő hálózatokon:

• Lassabb erőforrás letöltés → a főszálat nagyobb valószínűséggel lekötik a szkriptek
• A harmadik féltől származó szkriptek (statisztikák, hirdetések, chat pluginek) nagyobb valószínűséggel rontják az INP/interakciós késedelmeket.

De ez is okozhat problémákat:

• A késleltetett JS valószínűleg a következőket érinti: menük, forgatások, felugró ablakok, űrlap érvényesítés, fizetések, temetések nyomon követése.
• Tehát alkalmas a “lépésről lépésre + feketelista kizárása” stratégiára.

C. Kompatibilitás más bővítményekkel/témákkal: a “zéró konfliktus” nem ugyanaz, mint a "nyugalom".”

WP Rocket hivatalosan is felsorolt “Nem kompatibilis bővítmények/témák” listát, többek között olyan okokból, mint a kimeneti pufferelés, amely hatással lenne a WP Rocket gyorsítótár-optimalizálására.

• Ha a webhelye nagyon plugin- és téma-hangsúlyos, gondoljon a “teljesítmény-optimalizálásra” úgy, mint egy mini go-live projektre: regressziós tesztelés minden változtatásnál (űrlapok, bejelentkezések, fizetések, többnyelvű váltás stb.).

1.3 Különleges emlékeztető a WooCommerce/Dynamic Site számára

Az alapvető emlékeztető a hivatalos WooCommerce dokumentációból a caching plugin konfigurálásakor a következő:

• Bevásárlókosár / Pénztár / Számla Ne gyorsítótárba
• továbbá ajánlott, hogyA JS fájl tömörítésének elkerülése

Miért? A következő okok miatt:

• Erős függőség a kosár, pénztár, számla oldalon cookie / munkamenet / nonce
• Ha a gyorsítótár ezeket az oldalakat “statikus oldalakként” kezeli, a gombok nem fognak működni, és az ár/készlet/számlaadatok összekuszálódnak.
• Itt jön az ijesztő rész: előfordulhat, hogy az egyik régióban jól tesztelsz, a másikban pedig az CDN/cache hit eltérések miatt problémáid vannak!

1.4 Cache plugin stratégiai szintű ajánlások

Tier 1: Alapvető biztonsági előnyök (szinte minden állomásnak ezt kell tennie)

• Az oldal gyorsítótárazásának engedélyezése
• megnyílik aCache előtöltés(Az első látogatás stabilitásának javítása)
• Értelmes böngésző caching politikák (WP Rocket/Server/CDN Bármelyik réteg megvalósítható)

2. szint: Közepes jutalom, közepes kockázat (a legtöbb tartalmi oldal számára alkalmas)

• Képek késleltetett betöltése/iframe (a képoptimalizálási oldal mélyebbre megy)
• CSS mennyiségének szabályozása (pl. a nem használt CSS eltávolítása)

3. szint: Magas hozam, de magas kockázat (regressziós tesztelési ellenőrző listával kell rendelkeznie)

• Késleltetett JavaScript végrehajtás (a renderelést helyezi előtérbe, de befolyásolhatja az interakciót)
• JS/CSS tömörítés/összevonás: különösen óvatosnak kell lenni az e-kereskedelem/tagok/többnyelvűek esetében (A WooCommerce figyelmeztet a JS tömörítés kockázatára is）

1.5 Árak és engedélyek

• A WP Rocket fizetős licenc, a webhelyek számától függően különböző licencekkel.

Plugin 2:LiteSpeed gyorsítótár (LSCWP)--A “szabad csúcsok” előfeltétele az, hogy a szerver valójában a LiteSpeed.

Sok embernek az a tévhite, hogy a LiteSpeed Cache csak egy WordPress plugin, amelyet telepíthetsz, hogy a WP Rocket teljes erejét kihasználhasd bármilyen tárhelyen. Ez nem így van.

LiteSpeed hivatalos dokumentációEgyértelmű magyarázat: Az LSCWP gyorsítótárazási funkciójához a LiteSpeed Serverre van szükség, mivel a LiteSpeed Web Server beépített oldal gyorsítótárával (LSCache) kommunikál; a bővítmény felelős azért, hogy megmondja a szervernek, mely oldalakat és mennyi ideig lehet gyorsítótárba helyezni, és hogy a címkékkel kiváltsa a takarítást.

A LiteSpeed Cache fő erőssége a “Kiszolgálói szintű oldaltárolás (LSCache)”. A LiteSpeed/OpenLiteSpeed szerverek nélkül nincs ilyen alapvető előny.

2.1 LiteSpeed gyorsítótárakinek

Illeszkedés:

• A tárhely panel egyértelműen fel van címkézve LiteSpeed / OpenLiteSpeed(pl. sok cPanel hoszt írja)
• Ön “egy olyan ingyenes megoldást szeretne, amely erős TTFB-t és párhuzamosságot is képes futtatni”.”
• Hajlandó vagy elfogadni: nagyon erős, de koncepcionálisabb is (TTL, Tag, Purge, ESI, Crawler...)

Nem igazán:

• Nem vagy biztos benne, hogy milyen webkiszolgálót használsz, vagy megerősíted, hogy Nginx/Apache (kivéve, ha csak néhány front-end optimalizálási funkcióját szeretnéd használni, de akkor az ár/teljesítmény és a bonyolultság nem feltétlenül költséghatékony).
• Ön egy összetett e-kereskedelmi/tagsági/multi-nyelvi oldal, de nincs tesztelési folyamata (az LSCWP erős, de könnyebb a “rossz tartalom gyorsítótárba helyezése”).

2.2 A gyorsítótárazási mechanizmusa: miért inkább “a szerver kapacitásának egy része”?”

A LiteSpeed Cache mechanikáját akár “mérnöki magyarázatként” is leírhatnád:

• WP Rocket / WP Super Cache Ez inkább a WordPress/PHP cache-elés és optimalizálás oldalát érinti;
• LSCWP Ez a WordPress Vezérlőpult + a LiteSpeed Server beépített LSCache kombinációja: a plugin felelős a szabályok és a tisztítási jelek kiadásáért, az igazi nagy sebességű oldaltárolás pedig aszerver réteg。

Ez közvetlen hatással van a webhely élményére: a szerverszintű spit-caching általában könnyebb, gyorsabb és egyidejűbb (különösen a nagy forgalmú és a keresőmotorok lánctalpasainak nagy gyakoriságú látogatásai esetén).

2.3 Az LSCWP megnyitásának “helyes módja” a weboldal-felhasználói forgatókönyvek esetében”

A “helyes nyitási módot” 4 szintre osztottuk:

1. réteg: Page Cache Policy (meghatározza, hogy a TTFB valóban le tud-e esni)

• Tisztázza, hogy mely oldalakat lehet gyorsítótárba helyezni (a legtöbb nyilvános tartalomoldalt).
• Tegye egyértelművé, hogy mely oldalakat nem szabad gyorsítótárba helyezni (bejelentkezés, fiók, bevásárlókosár, pénztár, nyelv/valuta váltó oldalak, amelyek erős cookie-re támaszkodnak).
• Állítson be egy ésszerű TTL-t a gyorsítótárhoz (minél gyakrabban frissül a tartalom, annál rövidebb a TTL, és annál hosszabb a TTL).
• Hozzon létre egy tisztítási stratégiát: tisztítsa meg a releváns Taget a tartalom frissítése után (ahelyett, hogy nyers erővel tisztítaná meg az egész webhelyet).

Ez a réteg, ha helyesen van megcsinálva, a legközvetlenebbül látható a weboldalon, mint a TTFB le, első képernyő stabilabb。

2. réteg: Warm-up/Crawler (meghatározza a “lassú első látogatást egy hideg oldalra”)

A webhelyek elérésének gyakori “tapasztalati következetlensége” a gyorsítótárazásban jelentkező “hideg/meleg különbségekből” ered:

• A népszerű oldalakat mindig meglátogatják, és a gyorsítótár mindig forró
• A hideg oldalakra már régóta nem kattintottak, és az első alkalommal kattintók lassúak.

A bemelegítés nem a hab a tortán, ez a kulcsa a weboldal látogatói élményének.

3. réteg: Biztonsági programok dinamikus tartalomhoz (e-kereskedelem/tagság/többnyelvűség)

Az LSCWP ereje abban rejlik, hogy rengeteg “fejlett eszközt” ad, például:

• Differenciált gyorsítótárazási stratégiák a bejelentkezett felhasználók, kommentelő felhasználók stb. számára.
• Az Edge Side Inclusion (ESI) lényege, hogy az oldalt "gyorsítótárba helyezhető nyilvános testre" és "nem gyorsítótárba helyezhető dinamikus fragmentumokra" bontja, amelyeket külön-külön dolgoznak fel, majd a peremcsomópontokon összeillesztik.

4. szint: Online szolgáltatások és opcionális fejlesztések

A QUIC.cloud online szolgáltatásait (pl. az oldalakon belüli optimalizálási szolgáltatásokat) sok webmester találja hasznosnak az LSCWP-ben.QUIC.cloud DokumentációKifejezetten azt írják, hogy az LSCWP számára oldaloptimalizálási szolgáltatásokat nyújt, beleértve a kritikus CSS-t (CCSS), az egyedi CSS-t (UCSS), a Viewport Images (VPI) és másokat.

• Ez a fajta szolgáltatás nem kötelező: csak a szerver gyorsítótárazását használhatja, és nem engedélyezheti az online optimalizálást.
• Az online szolgáltatások engedélyezése után a webhely erőforrásai/oldalfeldolgozási linkjei megváltoznak (ez fontos információ a vállalkozások/az adatvédelemre érzékeny ügyfelek számára).

2.4 LSCWP közös gödör

1. A szerver nem LiteSpeed, hanem LSCWP-t használ, mint egy teljes körű caching plugint.
   Eredmény: A gyorsítótárazás nem olyan hatékony, mint vártuk, és növeli a konfiguráció összetettségét. Megoldás: Először erősítse meg a hoszt stacket; ha nem LiteSpeedVegyük például a WP Rocketet vagy a WP Super Cache-t.
2. A túl sok front-end optimalizálás engedélyezése funkcionális anomáliákhoz vezet
   Az oldalon belüli optimalizálások (CSS/JS) gyakran nagyobb valószínűséggel okoznak kompatibilitási problémákat, mint maga a “gyorsítótárazás”. Javaslat: először futtassa az oldal gyorsítótárát, majd kapcsolja be egyenként az optimalizálásokat, és készítsen egy listát a regressziós tesztekből (űrlapok, menük, fizetések, nyomon követés, nyelvváltás stb.).
3. A dinamikus oldalak kizárási/szeletelési stratégiáinak hiánya
   Tipikus incidensek: a kosár, a pénztár, a számlaoldal gyorsítótárba kerül; vagy helytelen többnyelvű/máspénzű váltás. Az e-kereskedelmi oldalaknak ezt a bevezetés előtti ellenőrzésként kell figyelembe venniük (és a WooCommerce tisztviselői is hangsúlyozzák).Ne gyorsítótárazza a kulcsfontosságú oldalakat）。

Plugin 3:WP Super Cache(Ingyenes) - Klasszikus “alacsony kockázatú, magas hozamú” megoldás a tartalmi oldalak számára.

WP Super Cache Miért volt ilyen sokáig népszerű? Mert nagyon közvetlen, nagyon “szerverbarát” módon oldja meg a problémákat:
Statikus HTML fájlok generálása dinamikus WordPress oldalakbólA HTML-fájlok ezután közvetlenül a webszerverről kerülnek kiszolgálásra, megkerülve a költséges PHP-feldolgozást.

A plugin oldal azt is megemlíti, hogy: statikus HTML lesz kiszolgálva a nem bejelentkezett felhasználók túlnyomó többségének, és egy nagyon intuitív nyilatkozatot ad - “99% látogatókat statikus HTML fájlokat szolgálnak ki”, és egyetlen gyorsítótárazott fájl is kiszolgálható. több ezerszer is.

3.1 Kinek szól a WP Super Cache?

Nagyon ajánlott:

• Blogok, médiatartalom-oldalak, dokumentumoldalak, vállalati bemutató oldalak, céloldalak
• A látogatók főként nem bejelentkezett felhasználók.
• Ön azt szeretné: ingyenes, stabil, alacsony fenntartási költségek

Óvatosan/erősebb stratégiákra van szükség:

• Erősen dinamikus oldal: sok személyre szabott tartalom, a felhasználó állapotának megfelelően változó oldalak.
• Nagy e-kereskedelem: működhet, de győződjön meg róla, hogy a kulcsfontosságú oldalak nincsenek gyorsítótárba helyezve, és működjön együtt a tesztelési folyamatával.

3.2 A három gyorsítótárazási módszer:

A WP Super Cache plugin leírása 3 gyorsítótárazási módszert sorol fel sebesség szerint, és elmagyarázza a különbségeket:

• mod_rewrite (szakértő): a leggyorsabb, teljesen megkerülve PHP, de meg kell változtatni .htaccess, helytelen konfiguráció vezethet a webhely elérhetetlenségi kockázat magasabb!
• Egyszerű (ajánlott megközelítés): Az PHP által biztosított “Super cached” statikus fájlok, közel a mod_rewrite sebességéhez, de könnyebben konfigurálható.
• WP-Cache gyorsítótár: rugalmasabb az ismert felhasználók, paraméterekkel rendelkező URL-ek, előfizetési feedek stb. esetében, de lassabb.

Ajánlott választás:

• Kezdők/stabilitást keresők: használja az ajánlott módszert (egyszerű)
• Ismeri a szerver szabályait, és hajlandó vállalni az átírás kockázatát: fontolja meg újra a szakértői modellt!
• Rugalmasabb “Ismert felhasználó/paraméterekkel” kezelésre van szükséged: A WP-Cache helyzetének megértése

3.3 A WP Super Cache erősségei és gyengeségei

Előny:

1. Ideális az CDN készülékkel való használatra.
   Mivel lényegében “statikus HTML-t generál”, ez természetesen illeszkedik az CDN/edge cache ötletéhez.
2. Az CPU forrásállomás/adatbázis nyomásának javítása nagyon egyszerű.
   A keresőmotorok és a közösségi média lánctalpasok a világ minden tájáról is érkezhetnek, ha a weboldal forgalma szétszórt. A staticizálás hatékonyan küzd az “újrarendezés” ellen.

Rövid deszka:

1. Ez nem egy “mindenre kiterjedő teljesítményoptimalizálási csomag”.”
   Főleg az oldal gyorsítótárazásában erős, és a mély CSS/JS optimalizálás nincs olyan csomagban, mint a WP Rocketben. A “Képoptimalizálási oldal” és a “Frontend optimalizálási oldal” (vagy más plugin/téma szintű optimalizálások használata) többet kell vállalnia.
2. Legyünk óvatosabbak a “dinamikus személyre szabással” kapcsolatban
   Például különböző tartalmak megjelenítése régió szerint, különböző árak/nyelvek/ajánlások megjelenítése felhasználói státusz szerint stb. Ezen a ponton vagy egy kizárási szabályzatot kell létrehoznia, vagy egy megfelelőbb szelet-és-kocka gyorsítótárazási sémát kell bevezetnie.

3.4 WooCommerce kompatibilitás: miért “biztonságosabb”

Hivatalos WooCommerce súgóEmlítettük: A WooCommerce natívan kompatibilis a WP Super Cache-sel, és a WooCommerce üzenetet küld a WP Super Cache-nek, hogy alapértelmezés szerint ne gyorsítótárasítsa a Kosár, Pénztár, Saját fiók oldalakat.

• Még ha új vagy a WP Super Cache + WooCommerce-ben, akkor is sokkal kevésbé valószínű, hogy rálépsz a “kulcsoldalak cache-elve” aknára!
• Mindazonáltal továbbra is ajánlott regressziós tesztelést végezni, mielőtt élesben elindul (fizetés, kuponok, szállítás, adókulcsok, több pénznem stb.).

Plugin 4:W3 Total Cache (W3TC)-A legsokoldalúbb “teljesítmény keretrendszer” a mérnöki csapatok számára.

W3 Total Cache Az “egyetlen gyorsítótár-csatlakozó” helyett a WordPress.org inkább egyfajta “webhelyteljesítmény-optimalizálási keretrendszerként” van pozícionálva: az CDN integrációra és a SEO, a Core Web és a legjobb gyakorlatokra helyezi a hangsúlyt. Vitals és az általános élményt az CDN integráció és a legjobb gyakorlatok révén.

A plugin leírása a képességek széles skáláját sorolja fel: oldal/poszt gyorsítótárazása, CSS/JS gyorsítótárazása, Feed gyorsítótárazása, keresési eredmények gyorsítótárazása, adatbázis objektum gyorsítótárazása, objektum gyorsítótárazása, fragmentum gyorsítótárazása (fragment cache), és különböző gyorsítótárazási módszerek támogatása, mint például Redis/Memcached/APC, de tartalmazza a mobil csoportosítású gyorsítótárazást UA/Referrer szerint is, AMP-támogatás, fordított proxy (Nginx/Varnish) integráció és így tovább.

4.1 Kinek szól a W3 Total Cache?

Tökéletes:

• Fejlesztési/üzemeltetési készségekkel rendelkezik, és hajlandó “engedélyezés + nyomástesztelés + regressziós tesztelés” elvégzésére.”
• Az Ön webhelye összetett: többnyelvű, több témát vált, mobil differenciálás, összetett tartalmi struktúra.
• Nem csak az oldalak gyorsítótárazását szeretné, hanem objektum- és töredéktárazást is szeretne beépíteni a rendszerbe (különösen a dinamikus oldalak esetében).

Nem illik bele:

• “Telepíteni és indulni” akarsz, nem akarod megérteni a cache-hierarchiákat!
• Nincs tesztelési folyamata, de egy csapásra be akarja kapcsolni a nagy kockázatú elemeket, például a tömörítést és a késleltetett szkripteket.

4.2 Miért “erős, de összetett”: a weboldalak értéke az “ellenőrizhetőség”.”

A W3TC értéke nem abban rejlik, hogy “gyorsabbnak kell lennie, mint mindenki másnak”, hanem abban, hogy elég vezérlőgombot ad ahhoz, hogy teljesítménystratégiát tervezzen:

• Oldal gyorsítótár: lehet a memóriában, a lemezen vagy az CDN-ben.
• Adatbázis objektum cache, objektum cache: elérhető Redis/Memcached stb.
• Töredékek gyorsítótárazása: Jó a “félig dinamikus oldalakhoz”
• Mobil támogatás: az oldalak gyorsítótárazása a hivatkozó vagy a felhasználói ügynök csoportja alapján
• CDN kezelés: A médiatárak, témafájlok stb. átlátható CDN kezelése.

Ezek a képességek különösen értékesek a weboldalak esetében, ahol a globális hozzáférés gyakran előfordul:

• Ugyanazon oldal változatai különböző eszközökön, különböző régiókban, különböző nyelveken
• Egyes tartalmak gyorsítótárazhatók, más tartalmaknak valós idejűnek kell lenniük (pl. ár, készlet, felhasználói státusz).

4.3 A W3TC “Ajánlott engedélyezési sorrendje”

Ajánlott rendelés:

1. Kezdje azzal, hogy csak az oldal gyorsítótárazását engedélyezi
   Ellenőrizze: a TTFB nem működik, a tartalom konzisztens, a bejelentkezési állapot/többnyelvűség/e-kereskedelmi kulcsfolyamatok működnek.
2. A böngésző gyorsítótárának újbóli engedélyezése
   Cél: A visszatérő látogatások és a statikus erőforrások gyorsabb betöltése, valamint az ismételt letöltések csökkentése a kontinenseken keresztül.
3. Objektum gyorsítótár / adatbázis objektum gyorsítótárának újraértékelése
   Alkalmazható: dinamikus webhely (WooCommerce, tagsági rendszer, összetett lekérdezés).
   N/A: A csak a tartalomra korlátozódó állomások korlátozott hozammal rendelkezhetnek, vagy akár növelhetik az erőforrás-fogyasztást.
4. Végső érintés Tömörítés / Latency Scripting / Front End optimalizálás
   Mivel ez az a réteg, amely a legnagyobb valószínűséggel funkcionális rendellenességeket okozhat, regressziós tesztlistát kell készíteni (fizetések, űrlapok, nyomon követés, felugró ablakok, menük, nyelvváltás stb.).

WooCommerce emlékeztető a “Cache Plugin konfigurációról”: A kritikus oldalak nem kerülnek gyorsítótárba, és ajánlott elkerülni a JS fájl tömörítését.

A négy plug-in összehasonlító mátrixa

Megjegyzés: Nem az a kérdés, hogy “ki a jobb”, hanem az, hogy “ki felel meg jobban az Ön forgatókönyvének”.

dimenzió (matematika)	WP Rocket	LiteSpeed gyorsítótár	WP Super Cache	W3 Total Cache
alapvető pozícionálás	Elmegyógyító integráció (gyorsítótárazás + optimalizálás)	Kiszolgálói szintű gyorsítótárazás (az LSCache-ra támaszkodik)	Statikus HTML gyorsítótárazás	Teljesítmény keretrendszer (több gyorsítótár réteg + CDN)
gazdától függő	Alacsony (univerzális)	Magas (LiteSpeed/OpenLiteSpeed szükséges a mag gyorsítótárként való működéshez)	Alacsony (univerzális)	Közepes (univerzális, de jobban függ a környezettől/konfigurálhatóságtól)
Tanulási költségek	alacsony-közepes	Közepes	低	Magas
Tartalomállomás-ajánlás	Nagyon magas	Nagyon magas (feltéve, hogy teljesül)	Nagyon magas	Közepes-magas (csapattól függően)
E-kereskedelmi/tagsági oldal	Elérhető, de óvatosan zárja ki (a WooCommerce kulcsoldalak nem kerülnek gyorsítótárba)	Elérhető, de több szabályra/szeletelési stratégiára van szükség.	elérhető, és a WooCommerce megemlíti a natív kompatibilitást és a kulcsoldalak alapértelmezett gyorsítótárazását.	Rendelkezésre áll és alkalmas mérnöki ellenőrzésre
költségvetés	fedezi a költségeket	freeware	freeware	Ingyenes + fizetős verzió

“Cache incidensek” és megelőzési ellenőrző lista

1. A gyorsítótárazással kapcsolatos “rossz tartalom” három alapvető oka

A. “Állapotfüggő” oldalak “statikus statikus oldalakként” való kezelése”

Jellemző: fiókoldal, kosár, pénztár oldal van gyorsítótárazva.WooCommerce A tisztviselők ismételten hangsúlyozták. A kosár/pénztár/számla nem kerülhet gyorsítótárba.

B. A többnyelvű/több pénznemű/regionális változatok nem kerülnek megfelelően gyorsítótárba

Ha webhelye eltérő tartalmat jelenít meg cookie, lekérdezési paraméterek és földrajzi elhelyezkedés alapján, akkor a gyorsítótárnak figyelembe kell vennie a “variáns dimenziókat”. Ellenkező esetben az A régióban lévő felhasználók által létrehozott gyorsítótárakat a B régióban lévő felhasználók újra felhasználhatják.

C. Front-end optimalizálás (JS/CSS) átírása funkcionális anomáliákhoz vezetve

Különösen a JS tömörítés, az összevonás és a késleltetett végrehajtás.A JS fájl tömörítésének elkerülése。

2. Az indítás előtti regressziós tesztelés ellenőrzőlistája

• A bejelentkezés/kilépés normális
• Az űrlapok (kapcsolatfelvételi űrlap, feliratkozás, bejelentkezés) megfelelően működnek.
• E-kereskedelmi folyamat: vásárlás hozzáadása → kupon → szállítás/adók → fizetés → megrendelés oldal
• A többnyelvűség váltás stabilitása (tartalom, URL-ek, hreflang, pénznem a váltás után)
• Mobil menük, felugró ablakok, görgetés, lusta betöltés megfelelően működik
• Kövesse nyomon, hogy a szkriptek még mindig aktiválódnak-e (GA, Meta Pixel, transzformációs események).

gyakori problémák

Q1：Miért lassú a tengerentúli hozzáférés annak ellenére, hogy telepítettem a caching plugint?

Ennek leggyakoribb oka az, hogy csak a “duplikált renderelést a forrásnál” oldotta meg, de a “kontinensek közötti hálózati késleltetést” nem.
A gyorsítótárazási bővítmények lehetővé teszik a szerver számára, hogy gyorsabban kiadja a tartalmat (TTFB lefelé), de a statikus erőforrásokat (képek, CSS, JS, betűtípusok) és a globális linkek RTT-jét még mindig meg kell oldani. CDN a távolság lerövidítésére.
👉 Tehát a helyes útvonal:Először stabilizálja a forrásállomás gyorsítótárát.Aztán CDN a globális terjesztéshez.。

2. kérdés: Miért nem frissül a tartalom, miután megváltoztattam a gyorsítótárazást követően?

Mert a “régi gyorsítótárat” látod. Megoldási ötlet:

• Hozzon létre egy tisztítási stratégiát: tisztítsa meg a megfelelő gyorsítótárat a cikkek/oldalak frissítése után (az egész webhelyre kiterjedő tisztítás helyett).
• Bemelegítéssel/kúszókkal kapcsolatos forgatókönyvek esetén: tisztítson meg, majd melegítsen be, különben az első látogatás lassú lesz.
• CDN esetében: figyelembe kell venni, hogy az CDN élei a régi erőforrásokat is gyorsítótárba helyezhetik.

3. kérdés: Telepíthetem egyszerre a WP Rocket + WP Super Cache-t?

Nem ajánlott. Egyszerre egy oldal gyorsítótárazó plugin a legstabilabb. Meg lehet érteni az “egy a gyorsítótárazásra és egy az optimalizálásra” gondolatot “munkamegosztásként”, de a valóságban gyakran érintik az oldalt gyorsítótárazást/erőforrás átírást, és nagy a konfliktus valószínűsége. Sokkal inkább ajánlott egy “fő caching plugin” kiválasztása, más igények egy egyértelműbb egyetlen eszközzel való kitöltése.

4. kérdés: Nem veszélyes a gyorsítótárazást használni az e-kereskedelmi oldalakon?

Nem ez a veszélyes, hanem a “szabályok hiánya” a veszélyes.WooCommerce ajánlásokNagyon egyértelmű: a kosár / pénztár / fiók nem kerül gyorsítótárba, és a JS tömörítés elkerülhető.
Ezen kívül a WooCommerce azt is megemlíti, hogy kompatibilis a WP Super Cache natív kompatibilitás, és alapértelmezés szerint kerülje a kritikus oldalak gyorsítótárazását.
Tehát az e-kereskedelmi oldal gyorsítótárba helyezhető, de azt “élő változásként” kell tesztelni.

5. kérdés: A LiteSpeed Cache-t vagy a WP Rocket-et válasszam?

• Biztos, hogy a tárhely a LiteSpeed/OpenLiteSpeed?: Priority LiteSpeed Cache (ingyenes és erős, a szerverszintű LSCache alapvető előnyeivel)
• Nem vagy biztos a hosting stackben / nem akarsz kompromisszumot kötni / integrálni és spórolni szeretnél.: A WP Rocket stabilabb
• Ön egy tartalomszolgáltató webhely és érzékeny a költségvetésre: A WP Super Cache stabilabb és könnyebb.

Cache Plugin az CDN-vel

A caching plugin megoldja a “forrásállomások kevesebb számolása és alacsonyabb TTFB” problémát; az CDN megoldja a “statikus erőforrások és a globális felhasználókhoz közelebbi oldalak” problémát. A kettő kombinációja a globális hozzáférés közös optimális megoldása.

• A tartalmi állomások közös kombinációja:Page Cache + CDN statikus elosztás
• A dinamikus állomások gyakori kombinációi:Oldal gyorsítótár (szigorú kizárás-ellenőrzés) + Objektum gyorsítótár (igény szerint) + CDN statikus elosztás

👉 Olvassa:CDN Gyorsítás (globális csomópont és gyorsítótárazási politika)

Ajánlott kombinációk a weboldal gyorsítótárazásához

1. Tartalmi oldal / blog / dokumentum oldal

Célkitűzés: A TTFB csökkentése, az első képernyő stabilabbá tétele, a szervernyomás csökkentése, az CDN-vel való együttműködés a globális terjesztéshez.

1.1 A legproblémamentesebb üzleti mix

• WP Rocket (oldal gyorsítótár + előtöltés + front-end optimalizálás)
  • CDN (látogasson el az CDN oldalra)

Alkalmazható:

• “Alacsony beállítási költség, gyors eredmények, alacsony kockázat”.”
• Témák / pluginok rengeteg, szeretné csökkenteni a kompatibilitást dobálózás körül

Figyelemre méltó pontok:

• A front-end optimalizálás (különösen a JS késleltetés) fokozatosan engedélyezve van a funkcionális anomáliák elkerülése érdekében (menük, űrlapok, nyomon követés stb.).
• A gyakori felülvizsgálati/bejegyzési oldalaknak “tisztítási + bemelegítési” stratégiával kell rendelkezniük, különben az első látogatás a hideg oldalakon lassú lesz.

1.2 Szabad és stabil klasszikus kombinációk

• WP Super Cache (statikus HTML gyorsítótár): Statikus HTML generálása dinamikus oldalakból, elsősorban nem regisztrált felhasználók számára.
  • CDN

Alkalmazható:

• Költségvetési szempontból érzékeny, de stabil
• A látogatók alapvetően nem jelentkeznek be
• A tartalomfrissítések ellenőrzött üteme

Figyelemre méltó pontok:

• Ez az “oldal gyorsítótárazása először” kombinációja, ne várd el, hogy minden CSS/JS bonyolultságot megoldjon útközben!

---

2. Vállalati oldal / márkaoldal / céloldal

Célkitűzés: Legyen gyors, de ami még fontosabb, “ne törje meg a konverziós kapcsolatot az optimalizálás miatt”.

2.1 Robusztus és szabályozható (ajánlott globális elhelyezési/átalakítási állomások)

• WP Rocket
• + (opcionális) könnyített képoptimalizálás (van egy “Képoptimalizálás” oldal)
  • CDN

Miért jó az átalakító állomásoknak:

• A konvertáló oldalak félnek attól, hogy az “űrlapok/popupok/követési szkriptek elrontják az optimalizálást”.”
• A WP Rocket “integráltabb” abban az értelemben, hogy a rendszerben minden egyes elemet engedélyezhet és regresszív tesztelhet.

A vállalati honlap “on-line elve”:

• A teljesítményoptimalizálás “éles változást” jelent, ezért regressziós tesztelési ellenőrző listát kell készíteni.
• A JS késleltetést/összevonást/tömörítést/tömörítést érintő beállításokat az éles üzembe helyezés előtt ellenőrizni kell egy kiadás előtti környezetben!

---

3. WooCommerce e-kereskedelmi oldal (megrendelések + dinamikus oldal biztonsága)

Célkitűzés: Fontos, hogy gyorsak legyünk, de azt is biztosítani kell, hogy a kosár, a pénztár és a fiók oldalai teljesen korrektek legyenek.

A hivatalos WooCommerce bullet pontok a caching plugin nagyon világosak:Bevásárlókosár / Pénztár / Számla oldal Ne gyorsítótárasodjonA kompatibilitási problémák minimalizálása érdekében a JavaScript-fájlok tömörítését is ajánlott elkerülni.

3.1 Ingyenes és biztonságos útvonalak, amelyek inkább “kezdők számára kedvezőek”

• WP Super Cache + WooCommerce
  • CDN

Miért szerepel a “biztonságosabb kiindulópontként”:

• A WooCommerce hivatalosan megemlíti, hogy natívan kompatibilis a WP Super Cache-sel, és tájékoztatja a WP Super Cache-t, hogy alapértelmezés szerint nem gyorsítótárazza az olyan kulcsfontosságú oldalakat, mint a cart/checkout/accounts.
• Az e-kereskedelemben induló webhelyek számára a “balesetmentesség az első” fontosabb, mint az “extrém teljesítmény”.

3.2 Ha LiteSpeed tárhelyet használ (ingyenes, de erős)

• LiteSpeed Cache (LiteSpeed/OpenLiteSpeed hosztnak kell lennie, hogy kihasználhassa a core szerver gyorsítótárazásának előnyeit)
• + (opcionális) objektum gyorsítótárazás (Redis/Memcached, a tárhelykapacitástól és a webhely méretétől függően)
  • CDN

Alkalmazható:

• A hoszt stack egyértelmű, és Ön hajlandó gyorsítótárazási szabályokat és kizárási irányelveket létrehozni.
• A megrendelések és az áruk mennyisége nagy, és egy erősebb forrásállomás szükséges a nyomás elviseléséhez.

3.3 Tervezett csapatok/komplex e-kereskedelem (több modulból irányítható)

• W3 Total Cache (teljesítmény keretrendszer, több gyorsítótár réteg integrálva az CDN-vel)
  • Objektumok gyorsítótárazása (igény szerint)
  • CDN

Alkalmazható:

• A Dev/Ops segítségével a “Modul lépésről lépésre történő engedélyezés + nyomástesztelés + regressziós tesztelés” segítségével élesbe mehet.
• Szükség van a töredékek gyorsítótárazására / a stratégia összetettebb változataira (pl. eszköz/régió/nyelv szerinti finomított gyorsítótárazásra).

---

4. Tagsági oldal / közösség / online tanfolyamok (sok bejelentkezés, erős személyre szabás)

Célkitűzés: A nyilvános tartalmak gyorsan elérhetővé tétele, miközben biztosítja, hogy a “bejelentkezett felhasználók tartalma ne legyen felfűzve”.

4.1 Mentés, de szigorú kizárási stratégiákra van szükség

• WP Rocket
• + (opcionális) objektum gyorsítótárazás (ha sok a dinamikus lekérdezés)
  • CDN

Kulcspontok:

• Ki kell zárnia a gyorsítótárazási rendszerből a “felhasználó általi módosítás” oldalakat: Személyes központ, Megrendelések, Tanulmányok előrehaladása, Üzenetek, Bevásárlókosár stb.
• Az ilyen típusú webhelyek a legérzékenyebbek a “mások tartalmának megtekintésére/hibás engedélyekre”, és az oldalon fel kell tüntetni a kockázatokat.

4.2 LiteSpeed Hosting + Speciális irányelvek

• LiteSpeed Cache (szerver gyorsítótár + kifinomultabb irányelvek)
• + (igény szerinti) objektumok gyorsítótárazása
  • CDN

Kulcspontok:

• A tagsági oldalaknak inkább a “gyorsítótárba helyezhető test + nem gyorsítótárba helyezhető töredék” mentalitásra van szükségük.
• A bemelegítési és tisztítási stratégiákat finomabbá kell tenni, különben a “felhasználók a frissítés után is régi tartalmat látnak” nagyon gyakori lesz.

Webcache “Demining Casebook”

1. eset: Telepítettem a caching plugint, a sebesség szinte változatlan maradt

Jelenség:

• Helyi/regionális sebességek OK, tengerentúli (kontinensek közötti) sebességek még mindig lassúak.
• A TTFB javult, de az általános betöltési idők nem csökkentek jelentősen.

Gyakori okok:

• Csak a forrás gyorsítótárazása történik (TTFB), de a statikus erőforrások (képek/JS/CSS/CSS/betűtípusok) továbbra is a forrásból töltődnek be a kontinenseken keresztül.
• Harmadik féltől származó szkriptek (hirdetések, chat, statisztikák) lassítják a megjelenítést és az interakciót
• Lassú letöltések a nagy képméretek miatt (a gyorsítótárazás nem oldja meg az “első letöltés” méretének problémáját)

Megoldási ötlet:

• A cache plugin először a “forrás alulszámolását + találatokat” kezeli.”
• Statikus erőforrások CDN
• Image away képoptimalizálás
• Harmadik fél szkriptek késleltetési/felosztási stratégiák

Olvasás:

• CDN Gyorsítás: Globális csomópontok és gyorsítótárazási stratégiák
• Képoptimalizálás: formátum/tömörítés/lassú betöltés

---

2. eset: A gyorsítótárazási funkció engedélyezése után az oldal megváltozik, de a frontend nem frissül.

Jelenség:

• A tartalom/stílus frissült a backendben, de a régi verzió még mindig megjelenik a frontendben.
• Vagy csak egyes régiók frissülnek, míg mások változatlanok maradnak (ez a globális állomások esetében gyakori).

Gyakori okok:

• A lap gyorsítótár nem vagy nem megfelelő mértékben törlődött
• Bemelegítés / lánctalpas nem fut, a megtisztított gyorsítótár kihűl, ami lassú első látogatást eredményez, miközben Ön tévesen azt hiszi, hogy nincs frissítés.
• Ha engedélyezi az CDN szélső gyorsítótárazást, a szélső a régi erőforrásokat is megtarthatja.

Megoldási ötlet:

• Hozzon létre egy “tisztítási stratégiát a megjelenés/felújítás után”: tisztítsa meg a releváns oldalakat, ne az egész webhelyre kiterjedő kemény tisztítással.
• Hozzon létre egy bemelegítési stratégiát a fontos oldalakra (kezdőlap, fő céloldalak), hogy elkerülje a “tisztítás = lassítás” problémát.”
• CDN Réteg az élek tisztításához, ha szükséges

---

3. eset: Eltévesztett tartalom több nyelv/multipénz váltás után

Jelenség:

• A nyelvváltás után az oldal továbbra is az előző nyelvet jeleníti meg
• Vagy bizonyos régiókban a felhasználók rossz pénznemet/rossz tartalmat látnak.

Gyakori okok:

• A gyorsítótár nem tesz különbséget a “variáns dimenziók” (cookie / paraméterek / nyelvi előtagok / aldomainek) között.
• A gyorsítótár találata az A nyelvű oldal eredményeit adja a B nyelvű felhasználónak

Megoldási ötlet:

• A többnyelvű program definiálása: directories/subdomains/parameters/cookie
• “Változatos irányelvek” hozzáadása a gyorsítótárazási szabályokhoz vagy a kulcsfontosságú oldalak kizárása
• Egyes webhelyek fejlettebb “szelet és kocka” gyorsítótárazási ötleteket igényelnek (a W3TC jobban alkalmas a mérnöki ellenőrzésre).

---

4. eset: Problémák a bevásárlókosárral/pénztárral az e-kereskedelmi webhelyen, ahol engedélyezve van a gyorsítótárazás

Jelenség:

• Helytelen kosármennyiség, helytelen ár, a pénztár gomb nem működik
• Bejelentkezés és olyan tartalom megtekintése, amely nem az Öné (komolyan)

Gyakori okok:

• Az olyan kritikus oldalak, mint a Kosár/Pénztár/Pénztár/Mi fiókom, gyorsítótárba kerülnek.
• A JS minify/merge fizetés/dinamikus komponens inkompatibilitáshoz vezet

Megoldási ötlet:

• A WooCommerce hivatalos: a cart/checkout/accounts nem lehet cache-elni, és ajánlott elkerülni a JS fájl tömörítést.
• Először futtassa az “oldal gyorsítótár + kizárás” opciót, majd fontolja meg a front-end optimalizálást.
• Ha a WP Super Cache-t használja, a WooCommerce megemlíti, hogy az natívan kompatibilis, és alapértelmezés szerint elkerüli a kulcsfontosságú oldalak gyorsítótárazását.

---

5. eset: A menük/űrlapok/felugró ablakok nem működnek a “Delay JS/Merge Scripts” engedélyezése után.

Jelenség:

• A navigációs menü nem nyílik meg
• Az űrlap érvényesítés sikertelen vagy nem lehetett elküldeni
• Popup/Rollup kivétel
• A statisztikák/konverziós események nem váltanak ki (a legnagyobb fájdalom az induló oldalak esetében).

Gyakori okok:

• A Deferred JS megváltoztatja a szkriptek végrehajtásának időzítését: a szkriptek nem kerülnek végrehajtásra, amíg a felhasználó nem lép kapcsolatba velük, és egyes komponensek az “inicializálás az oldal betöltésekor” funkcióra támaszkodnak.”
• Az összevonás/tömörítés megváltoztathatja a szkriptek sorrendjét vagy megszakíthatja a függőségeket.

A WP Rocket hivatalosan a “halasztott JS-végrehajtást” nevezi az egyik legerősebb JS-optimalizálásnak: a szkripteket a felhasználói interakció utánra halasztja, hogy az oldal megjelenítését előnyben részesítse. Ez egy nagyszerű képesség, de egyben nagyobb kompatibilitási kockázatot is jelent.

Megoldási ötlet:

• Fokozatosan engedélyezze: gyorsítótár, majd képek, majd CSS, majd JS.
• Kizárások hozzáadása a kulcsfontosságú szkriptekhez (fizetések, űrlapok, menük, nyomon követés)
• Minden változtatáshoz regressziós tesztelési ellenőrzőlista készítése

---

6. eset: Csak a LiteSpeed Cache van telepítve, de nem úgy tűnik, hogy működik.

Jelenség:

• A LiteSpeed Cache be van kapcsolva, de a TTFB nem sokat csökken.
• A találatok sem nyilvánvalóak

Gyakori okok:

• Az Ön szervere nem LiteSpeed/OpenLiteSpeed, és nem tudja használni az LSCache alapvető képességeit.
• Vagy talán engedélyeztél egy csomó optimalizálást hozzá, de az “oldal gyorsítótárazási irányelve/előmelegítés/elhagyás” nem lett létrehozva!

Megoldási ötlet:

• Ellenőrizze először a host stacket: LiteSpeed/OpenLiteSpeed (ez előfeltétel)
• Visszahelyezve a hangsúlyt a “Page Cache Policy + Warm Up + Exclude + Clean Up” (Oldal gyorsítótár-politika + Warm Up + Exclude + Clean Up) -ra”
• Ha nem LiteSpeed tárhely: Fontolja meg a WP Rocket vagy a WP Super Cache használatát.