W3 Total Cache Minify bővítmény beállításai: Hogyan válasszuk ki a beágyazási típust? Hibaelhárítási tapasztalataim és életmentő tanácsaim

Nehezen tudja kiválasztani a megfelelő beágyazási típust a W3 Total Cache Minify-hoz? Ez a cikk egy webmester valós tapasztalatait osztja meg, és lépésről lépésre bemutatja a megfelelő Minify beágyazási típus pontos kiválasztását, elkerülve a weboldal stílusbeli hibáit és a betöltési összeomlásokat. Tartalmaz egy bolondbiztos beállítási megoldást is, amelyet még a kezdők is könnyen alkalmazhatnak.WordPress Gyorsíts ütközés nélkül!

Egy weboldalt optimalizáltam, és amikor megnyitottam a Minify beállításokat a W3 Total Cache-ben, teljesen ledöbbentem. A beágyazott típus legördülő menüjében négy lehetőség volt: Alapértelmezett (Blokkolás), JS használata nem blokkoláshoz, "Aszinkron" használata nem blokkoláshoz, és "Késleltetett" használata nem blokkoláshoz.

Egy pillanatra elgondolkodtam, hogy miről is van szó mindezen?

Hidd el, nem vagy egyedül. Ez a négy lehetőség valószínűleg még egy kezdőt is összezavar, nemhogy olyat, aki évek óta használja a WordPress-t. Ez a cikk bemutatja azokat a buktatókat, amelyekkel én találkoztam, és a tanulságokat, amelyeket közvetlenül leszűrtem. Nem kell a dokumentációt átnézned; csak kövesd az utasításaimat.

Pontosan melyek ezek a négy beágyazási típus?

Először is beszéljünk arról, hogy milyen karakterek ezek a négy lehetőség.

Alapértelmezett (blokkolt)Ezt hívják alapértelmezett blokkolásnak. Ez a legegyszerűbb megközelítés: a böngésző leáll, amikor egy szkripttel találkozik, letölti és teljesen végrehajtja azt, majd folytatja az oldal renderelését. Megbízhatóan hangzik, ugye? De a kompromisszum az, hogy a kezdeti oldalbetöltés blokkolva lesz; a felhasználóknak meg kell várniuk, amíg a szkript futása befejeződik, mielőtt bármit is látnának.

JS használata nem blokkoláshozEz elég érdekes. Ahelyett, hogy közvetlenül a `<script>` tageket írná az oldalra, először egy kis szkriptet ír ki, majd dinamikusan befecskendezi a betöltendő szkripteket JavaScripten keresztül az oldal futása után. Így az oldal először renderelhető, és a szkriptek fokozatosan töltődnek be. Nagyszerűen hangzik, ugye? A probléma azonban az, hogy ez a dinamikus befecskendezési folyamat megzavarhatja a szkriptek eredeti végrehajtási sorrendjét. Ha az oldalon található egyes szkriptek nagymértékben támaszkodnak a végrehajtási sorrendre, problémák merülhetnek fel.

Használjon "aszinkron" értéket nem blokkoló eseténEz magában foglalja az `async` attribútum hozzáadását a `<script>` taghez. A szkript aszinkron módon töltődik le a háttérben, és a letöltés után azonnal végrehajtódik, anélkül, hogy az oldal várna rá. A hátránya azonban, hogy a végrehajtási sorrend teljesen kontrollálhatatlan; amelyik szkript hamarabb fejezi be a letöltést, az hajtódik végre először, függetlenül a kódban megadott sorrendtől.

A "késleltetés" használata nem blokkoláshozEzt jelenti a `defer` attribútum hozzáadása. A szkript megvárja, amíg a teljes oldal elemzésre kerül, mielőtt végrehajtódna, és ami fontos, megőrzi az eredeti sorrendet, ahogyan írtuk. Ez meglehetősen felhasználóbarát, mivel nem blokkolja az első képernyőt, és nem zavarja meg a sorrendet.

Melyiket válasszam?

Egyszerűen fogalmazva, ez a négy lehetőség olyan, mint egy feleletválasztós kérdés:Sebességre vagy rendre vágysz?

A javaslatom a következő:

Ha a weboldalad kicsi, kevés szkriptet tartalmaz, és nincsenek rendkívül magas követelményeid a betöltési sebességgel szemben, akkor az alapértelmezett (blokkolt) beállítás használata a legegyszerűbb megoldás. Bár ez valamivel lassabb, nem okoz semmilyen problémát.

Ha javítani szeretnéd az első képernyős megjelenés sebességét, és a szkripteidnek nincsenek erős függőségei, például az „A-nak a B előtt kell végrehajtódnia”, akkor rangsorold...A "késleltetés" használata nem blokkoláshoz(elhalasztás). Ez jelenleg szinte a legideálisabb megoldás, mivel sem a renderelést nem blokkolja, sem a sorrendet nem zavarja meg.

Ha a defer (elhalasztás) funkció használata után is problémákat tapasztalsz bizonyos függvényekkel, akkor fontold meg...JS használata nem blokkoláshozEz a megoldás radikálisabb, de a kompatibilitása valamivel rosszabb.

Használjon "aszinkron" értéket nem blokkoló eseténAz (async) opciót a legkevésbé ajánlom. Mivel a végrehajtási sorrend teljesen el van rontva, könnyen összeomolhat, hacsak nem vagy teljesen biztos benne, hogy a szkriptek mind függetlenül futnak.

Két nagy buktató, amibe beleestem

A beszéd olcsó. Leírtam két hibát, amit elkövettem; összevetheted őket a saját tapasztalataiddal, hogy lásd, el tudod-e kerülni őket.

Az első buktató: Az egyéni WordPress témák nem tekinthetők meg valós időben.

Egy ideig egy téma testreszabásakor a mentés gombra kattintás után az előnézet nem frissült. Végeztem néhány módosítást, frissítettem az oldalt, és továbbra is ugyanaz maradt.

Némi nyomozás után rájöttem, hogy a Minify tömörítőfüggvénye a hibás. A megoldás egyszerű:

Hozzáférés a W3 Total Cache bővítményhez常规设置,felbukkan"tömörítés"Töröld a jelölést a jelölőnégyzetből. Ezután kattints a jobb felső sarokban található „Beállítások mentése” alatti kis nyílra, és válaszd a „...” lehetőséget.Beállítások mentése és gyorsítótár ürítéseEz a lépés kulcsfontosságú; ha nem törlöd a gyorsítótárat, továbbra is a régi verziót fogod látni.

Miután elkészültél, térj vissza a téma testreszabásához, és az élő előnézet visszaáll a normál állapotba.

A második probléma: Az Astra téma keresőmezője nem reagál kattintásra.

Egy ideje már találkoztam ezzel a problémával. Az Astra témát használtam, és egy nap hirtelen azt vettem észre, hogy a keresőmező nem reagált, hiába kattintottam rá. Először azt hittem, hogy magával a témával van a probléma, de később rájöttem, hogy a W3TC Minify beállításai okozták.

A megoldás a következő:

Lépj a W3 Total Cache → Általános beállítások → Speciális tömörítési beállítások → JS → Minify Engine beállítások → Területi beállítások menüpontra, és módosítsd a beágyazási típust a következő kettő közül az egyikre:

1. Korábban a blokkolásmentességet JavaScript használatával érték el.
2. Utána használj JS-t a blokkolásmentességhez

Hasonlóképpen, a gyorsítótár törlése és az oldal frissítése lehetővé teszi a keresőmező megfelelő működését.

Ami azt illeti, hogy miért pont ezt a két lehetőséget választottuk mások helyett, végeztem némi kutatást. Egyszerűen fogalmazva, az Astra téma front-end komponensei meglehetősen érzékenyek a szkript végrehajtásának időzítésére, és bizonyos nem blokkoló metódusok az eseménykötés sikertelenségét okozhatják. A „nem blokkoló JS-sel” mód használata biztosítja, hogy a szkript csak az oldal betöltésének befejezése után futjon le, miközben elkerüli az aszinkron módban látható rendezetlen végrehajtást.

Látogatandó helyek listája

Végül pedig itt egy ellenőrzőlista, amit közvetlenül követhetsz:

Az első lépés a célod tisztázása. A leggyorsabb kezdeti oldalbetöltést szeretnéd, vagy a stabilitást és a hibamentes működést helyezed előtérbe? Ez fogja meghatározni, hogy melyik beágyazási típust érdemes használnod.

A második lépés az, hogy ne egyszerre változtass mindent. Először is keress egy kevésbé fontos oldalt a teszteléshez, figyeld meg egy-két napig, és csak akkor tegyél közzé a teljes webhelyen, ha biztos vagy benne, hogy nincsenek problémák.

Harmadszor, minden módosítás után töröld a gyorsítótárat. A W3TC gyorsítótárazási mechanizmusa megakadályozza, hogy a legújabb változtatásokat lásd, ezért a „gyorsítótár törlése és újratesztelés” lépés elengedhetetlen.

Negyedszer, használd a böngésződ fejlesztői eszközeit vagy olyan eszközöket, mint a PageSpeed ​​​​Insights, hogy összehasonlítsd a betöltési sebességet előtte és utána. Hagyd, hogy az adatok magukért beszéljenek, ne csak a megérzéseidre hagyatkozz.

írd a végére

Őszintén szólva, amikor először megláttam ezt a beágyazott típusbeállítást, sokáig döbbenten álltam. Az alapértelmezett blokkoló mód túl lassúnak tűnt, az aszinkron mód pedig nem garantálta a sorrendet, a halasztás pedig kompatibilitási problémákat okozhatott. Nem voltam biztos benne, hogy melyik lehetőséget válasszam.

Később rájöttem, hogy ez kompromisszum. Nem lehet egyszerre a leggyorsabb és a legstabilabb megoldás; mindig fel kell áldozni az egyiket. Tapasztalatom szerint először a defer-t kell használni, ami jelenleg a legbiztonságosabb nem blokkoló megoldás, majd visszahívást, ha problémák merülnek fel.

Ha hasonló problémákba ütközöl, vagy ha a módszerem követése után is fennállnak további problémáid, nyugodtan beszélgess róla. A weboldalfejlesztés a próbálkozásokról és hibákról szól; senki sem kivétel.

Köszönöm, hogy elolvastad a cikkemet. Találkozunk legközelebb.