Nastavitve vtičnika W3 Total Cache Minify: Kako izbrati vrsto vdelave? Moje izkušnje z odpravljanjem težav in nasveti za reševanje življenj

Se težko odločite za pravo vrsto vdelave za W3 Total Cache Minify? Ta članek deli izkušnje spletnega skrbnika iz resničnega sveta in ponuja podroben vodnik za natančno izbiro prave vrste vdelave Minify, s čimer se izognete napakam pri slogu spletnega mesta in zrušitvam pri nalaganju. Vključuje tudi brezhibno rešitev za nastavitev, ki jo lahko preprosto uporabijo tudi začetniki, kar zagotavlja nemoteno in hitro izkušnjo z WordPressom !

Optimiziral sem spletno stran in ko sem odprl nastavitve Minify v W3 Total Cache, sem bil popolnoma osupel. Spustni meni za vgrajeni tip je imel štiri možnosti: Privzeto (Blokiraj), Uporabi JS za neblokiranje, Uporabi »Asinhrono« za neblokiranje in Uporabi »Zakasnjeno« za neblokiranje.

Za trenutek sem pomislil, za kaj gre pri vsem tem?

Verjemite mi, niste sami. Te štiri možnosti bodo verjetno zmedle celo začetnika, kaj šele nekoga, ki WordPress uporablja že leta. Ta članek predstavlja pasti, na katere sem naletel, in lekcije, ki sem se jih neposredno naučil. Ni vam treba pregledati dokumentacije; samo sledite mojim navodilom.

Kaj točno so te štiri vrste vdelave?

Najprej se pogovorimo o tem, kakšen značaj imajo te štiri možnosti.

Privzeto blokiranje je najpreprostejši pristop. Ko brskalnik naleti na skript, se ustavi, prenese in v celoti izvede skript ter nato nadaljuje z upodabljanjem strani. Sliši se zanesljivo, kajne? Vendar je kompromis v tem, da se bo začetno nalaganje strani zakasnilo; uporabniki bodo morali počakati, da se skripta zaključi, preden bodo lahko karkoli videli.

Uporaba JavaScripta za neblokiranje je precej zanimiva. Namesto neposrednega pisanja oznak `<script>` na strani, najprej izpiše majhen skript, nato pa dinamično vbrizga potrebne skripte na stran prek JavaScripta, ko se stran zažene. Na ta način se lahko stran najprej upodobi, skripti pa se nalagajo postopoma. Sliši se odlično, kajne? Vendar je težava v tem, da lahko ta dinamični postopek vbrizgavanja moti prvotni vrstni red izvajanja skriptov. Če so nekateri skripti na vaši strani močno odvisni od vrstnega reda izvajanja, lahko pride do težav.

Uporaba »asinhronega« za neblokirajoče izvajanje preprosto vključuje dodajanje atributa `async` oznaki `<script>`. Skript se bo asinhrono prenesel v ozadju in se izvedel takoj po zaključku, ne da bi stran čakala nanj. Vendar je pomanjkljivost, da je vrstni red izvajanja popolnoma nenadzorovan; izvede se tisti, ki se najprej prenese, ne glede na vrstni red, ki ga določite v kodi.

Uporaba atributa »delay« za neblokirajoče izvajanje se doseže z dodajanjem atributa `defer`. Skript bo pred izvajanjem počakal, da bo celotna stran razčlenjena, in kar je ključno, ohranil bo prvotni vrstni red, v katerem ste ga napisali. To je precej uporabniku prijazno, saj ne blokira prvega zaslona niti ne moti vrstnega reda skripte.

Katerega naj izberem?

Preprosto povedano, te štiri možnosti so kot vprašanje z več možnimi odgovori: ali želite hitrost ali želite red?

Moj predlog je naslednji:

Če je vaše spletno mesto majhno, ima malo skriptov in nimate izjemno visokih zahtev glede hitrosti nalaganja, je uporaba privzete (blokirane) nastavitve najlažja možnost. Čeprav je nekoliko počasnejša, ne bo povzročala težav.

Če želite izboljšati hitrost prikaza prvega zaslona in vaši skripti nimajo močnih odvisnosti, kot je »A se mora izvesti pred B«, dajte prednost uporabi »defer« za neblokirajoče izvajanje . To je skoraj idealna rešitev, ki je trenutno na voljo, saj se izogne ​​blokiranju upodabljanja, hkrati pa ohranja vrstni red izvajanja.

Če po poskusu uporabe funkcije defer ugotovite, da imajo nekatere funkcije še vedno težave, razmislite o uporabi JavaScripta za neblokiranje . Ta pristop je bolj agresiven, vendar je njegova združljivost nekoliko slabša.

Uporaba »async« za neblokiranje je možnost, ki jo najmanj priporočam. Ker je vrstni red izvajanja popolnoma zmeden, se lahko program sesuje, razen če ste popolnoma prepričani, da se vaši skripti izvajajo neodvisno.

Dve veliki pasti, v katere sem padel

Pogovor je poceni. Zapisal sem dve napaki, ki sem jo naredil; lahko ju preverite z lastnimi izkušnjami, da vidite, ali se jima lahko izognete.

Prva past: tem WordPress po meri ni mogoče predogledati v realnem času.

Nekaj ​​časa se je pri prilagajanju teme po kliku na shrani predogled ni osvežil. Naredil sem nekaj sprememb, osvežil stran in še vedno je bilo isto.

Po nekaj preiskave sem ugotovil, da je krivec funkcija stiskanja Minifyja. Rešitev je preprosta:

Pojdite v splošne nastavitve vtičnika W3 Total Cache , poiščite možnost »Stisnjenje« in jo počistite. Nato kliknite majhno puščico pod možnostjo »Shrani nastavitve« v zgornjem desnem kotu in izberite » Shrani nastavitve in počisti predpomnilnik «. Ta korak je ključnega pomena; brez brisanja predpomnilnika boste še vedno videli staro različico.

Ko končate, se vrnite na prilagajanje teme in predogled v živo se bo vrnil v normalno stanje.

Druga težava: Iskalno polje teme Astra se ne odziva, ko ga kliknete.

Pred časom sem naletel na to težavo. Uporabljal sem temo Astra in nekega dne sem nenadoma ugotovil, da se iskalno polje ne odziva, ne glede na to, kako sem ga kliknil. Sprva sem mislil, da je težava v sami temi, kasneje pa sem ugotovil, da jo povzročajo nastavitve Minify v W3TC.

Rešitev je naslednja:

Pojdite v W3 Total Cache → Splošne nastavitve → Napredne nastavitve stiskanja → JS → Nastavitve mehanizma za pomanjšanje → Nastavitve jezika in spremenite vrsto vdelave na eno od teh dveh:

1. Prej je bilo neblokiranje doseženo z uporabo JavaScripta.
2. Potem uporabite JS za neblokiranje

Podobno bo brisanje predpomnilnika in osvežitev strani omogočila pravilno delovanje iskalnega polja.

Glede tega, zakaj sta bili izbrani ti dve možnosti namesto drugih, sem opravil nekaj raziskav. Preprosto povedano, sprednje komponente teme Astra so precej občutljive na čas izvajanja skripta, nekatere metode brez blokiranja pa lahko povzročijo neuspeh vezave dogodkov. Uporaba načina »neblokiranje z JS« zagotavlja, da se skript izvede šele po končanem nalaganju strani, hkrati pa se izognemo neurejenemu izvajanju, ki ga opazimo pri asinhronosti.

Seznam krajev, ki jih je treba obiskati

Na koncu je tukaj kontrolni seznam, ki mu lahko neposredno sledite:

Prvi korak je razjasniti svoj cilj. Ali želite najhitrejše začetno nalaganje strani ali dajete prednost stabilnosti in delovanju brez napak? To bo določilo, katero vrsto vdelave bi morali uporabiti.

Drugi korak ni, da spremenite vse naenkrat. Najprej poiščite manj pomembno stran, ki jo boste preizkusili, jo opazujte dan ali dva in jo promovirajte na celotnem spletnem mestu le, če ste prepričani, da ni težav.

Tretjič, po vsaki spremembi vedno počistite predpomnilnik. Mehanizem predpomnjenja W3TC vam bo preprečil ogled najnovejših sprememb, zato je korak »počisti predpomnilnik in ponovno preizkusi« nujno potreben.

Četrtič, uporabite orodja za razvijalce v brskalniku ali orodja, kot je PageSpeed ​​​​Insights, da primerjate hitrost nalaganja pred in po. Naj podatki govorijo sami zase, ne le vaš občutek.

Napiši na koncu

Iskreno povedano, ko sem prvič videl to nastavitev vgrajenega tipa, sem bil dolgo časa osupel. Privzeti način blokiranja se mi je zdel prepočasen, medtem ko asinhroni način ni zagotavljal vrstnega reda, odlaganje pa bi lahko povzročilo težave z združljivostjo. Nisem bil prepričan, katero možnost izbrati.

Kasneje pa sem spoznal, da je to kompromis. Ne moreš imeti hkrati najhitrejšega in najstabilnejšega; vedno moraš žrtvovati enega. Moje izkušnje so, da najprej uporabim defer, ki je trenutno najvarnejša rešitev brez blokiranja, nato pa uporabim povratni klic, če se pojavijo težave.

Če naletite na podobne težave ali če imate po uporabi moje metode še vedno druge težave, se o tem pogovorite. Razvoj spletnih strani je postopek poskusov in napak; nihče ni izjema.

Hvala, ker ste prebrali moj članek. Se vidimo naslednjič.