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 tudod 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, biztosítva a zökkenőmentes és gyors WordPress élményt!

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.

Az alapértelmezett blokkolás a legegyszerűbb megközelítés. Amikor a böngésző szkriptet talál, leáll, letölti és teljesen végrehajtja a szkriptet, majd folytatja az oldal renderelését. Megbízhatóan hangzik, ugye? De a kompromisszum az, hogy az oldal kezdeti betöltése késik; a felhasználóknak meg kell várniuk, amíg a szkript futása befejeződik, mielőtt bármit is látnának.

A JavaScript használata a blokkolásmentes működéshez meglehetősen érdekes. Ahelyett, hogy közvetlenül a `<script>` tageket írná az oldalra, először egy kis szkriptet ír ki, majd dinamikusan befecskendezi a szükséges szkripteket az oldalba JavaScript segítségével, miután az oldal fut. Így az oldal először renderelődhet, é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.

Az „aszinkron” nem blokkoló végrehajtáshoz való használata egyszerűen annyit jelent, hogy hozzáadjuk az `async` attribútumot a `<script>` taghez. A szkript aszinkron módon töltődik le a háttérben, és a befejezés után azonnal végrehajtódik, anélkül, hogy az oldalnak várnia kellene rá. A hátránya azonban, hogy a végrehajtási sorrend teljesen kontrollálhatatlan; az elsőként letöltött fájlok futnak le, függetlenül a kódban megadott sorrendtől.

A nem blokkoló végrehajtáshoz a „delay” használata a `defer` attribútum hozzáadásával érhető el. A szkript megvárja, amíg a teljes oldal elemzésre kerül a végrehajtás előtt, és ami a legfontosabb, megőrzi az eredeti írási sorrendet. Ez meglehetősen felhasználóbarát, mivel nem blokkolja az első képernyőt, és nem zavarja meg a szkript sorrendjét.

Melyiket válasszam?

Egyszerűen fogalmazva, ez a négy lehetőség olyan, mint egy feleletválasztós kérdés: gyorsaságot akarsz, vagy a sorrendet?

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íté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égrehajtania” elv, akkor a nem blokkoló végrehajtáshoz a „defer” metódust részesítsd előnyben . Ez a jelenleg elérhető megoldás szinte az ideális, mivel elkerüli a renderelés blokkolását, miközben megőrzi a végrehajtás sorrendjét.

Ha azt tapasztalod, hogy egyes függvények a defer (halasztás) használata után is problémákat okoznak, akkor érdemes lehet JavaScriptet használni a blokkolásmentesítéshez . Ez a megközelítés agresszívabb, de a kompatibilitása valamivel rosszabb.

A blokkolásmentes futtatáshoz az „async” opciót a legkevésbé ajánlom. Mivel a végrehajtási sorrend teljesen elrontott, könnyen összeomolhat a rendszer, hacsak nem vagy teljesen biztos benne, hogy a szkriptek 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ű:

Lépj a W3 Total Cache bővítmény általános beállításaihoz , keresd meg a „Tömörítés” opciót, és vedd ki a pipát belőle. Ezután kattints a jobb felső sarokban található „Beállítások mentése” alatti kis nyílra, és válaszd a „ Beállítások mentése és a gyorsítótár törlése ” lehetőséget. Ez a lépés kulcsfontosságú; a gyorsítótár törlése nélkül 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.