W3 Total Cache Minify plugina seaded: kuidas valida manustamise tüüpi? Minu tõrkeotsingu kogemus ja elupäästvad nõuanded

Kas teil on raskusi W3 Total Cache Minify jaoks õige manustamistüübi valimisega? See artikkel jagab veebimeistri reaalset kogemust ja pakub samm-sammult juhiseid õige Minify manustamistüübi täpseks valimiseks, vältides veebisaidi stiiliga seotud vigu ja laadimiskrahhe. See sisaldab ka lollikindlat seadistuslahendust, mida isegi algajad saavad hõlpsalt rakendada.WordPress Kiirenda ilma kukkumiseta!

Optimeerisin veebisaiti ja kui avasin W3 Total Cache'is Minify sätted, olin täiesti jahmunud. Manustatud tüübi rippmenüüs oli neli valikut: Vaikimisi (blokeeri), Kasuta JS-i mitteblokeeriva tüübi jaoks, Kasuta "asünkroonset" mitteblokeeriva tüübi jaoks ja Kasuta "viivitatud" mitteblokeeriva tüübi jaoks.

Mõtlesin hetkeks, mis see kõik on?

Usu mind, sa pole üksi. Need neli valikut jätavad tõenäoliselt hämmeldunuks isegi algaja, rääkimata kellestki, kes on WordPressi aastaid kasutanud. See artikkel tutvustab lõkse, millega olen kokku puutunud, ja õppetunde, mida olen neist otse õppinud. Sa ei pea dokumentatsiooniga tutvuma; järgi lihtsalt minu juhiseid.

Mis need neli manustamistüüpi täpselt on?

Räägime kõigepealt sellest, millised tegelased need neli varianti on.

Vaikimisi (blokeeritud)Seda nimetatakse vaikimisi blokeerimiseks. See on kõige lihtsam lähenemisviis: brauser peatub skripti leidmisel, laadib selle alla ja käivitab selle täielikult ning jätkab seejärel lehe renderdamist. Kõlab usaldusväärselt, eks? Kuid kompromiss on see, et teie esialgne lehe laadimine blokeeritakse; kasutajad peavad enne midagi nägemist ootama, kuni skript on töö lõpetanud.

JS-i kasutamine mitteblokeerimiseksSee on üsna huvitav. Selle asemel, et otse lehele `<script>` silte kirjutada, väljastab see esmalt väikese skripti ja seejärel süstib dünaamiliselt skriptid, mis tuleb pärast lehe käivitamist JavaScripti kaudu lehele laadida. Nii saab lehte esmalt renderdada ja skripte saab laadida järk-järgult. Kõlab suurepäraselt, eks? Probleem on aga selles, et see dünaamiline süstimisprotsess võib häirida skriptide algset täitmisjärjekorda. Kui mõned teie lehel olevad skriptid sõltuvad suuresti täitmisjärjekorrast, võivad tekkida probleemid.

Mitteblokeerivate puhul kasutage "asünkroonset"See hõlmab atribuudi `async` lisamist sildile `<script>`. Skript laaditakse alla asünkroonselt taustal ja käivitub kohe pärast allalaadimist, ilma et leht seda ootaks. Negatiivne külg on aga see, et käivitusjärjekord on täiesti kontrollimatu; see skript, mis allalaadimise esimesena lõpetab, käivitub esimesena, olenemata koodis määratud järjekorrast.

"Viivituse" kasutamine mitteblokeerimise korralSeda tähendabki atribuudi `defer` lisamine. Skript ootab enne käivitamist, kuni kogu leht on parsitud, ja mis oluline, see säilitab algse järjekorra, mille te selle kirjutasite. See on üsna kasutajasõbralik, kuna see ei blokeeri esimest ekraani ega häiri järjekorda.

Millise peaksin valima?

Lihtsamalt öeldes on need neli valikut nagu valikvastustega küsimus:Kas sa tahad kiirust või korda?

Minu ettepanek on järgmine:

Kui teie veebisait on väike, sellel on vähe skripte ja teil pole laadimiskiirusele ülimalt kõrgeid nõudeid, on vaikesätete (blokeeritud) kasutamine lihtsaim valik. Kuigi see on veidi aeglasem, ei tekita see probleeme.

Kui soovite parandada esimese ekraani kiirust ja teie skriptidel pole tugevaid sõltuvusi, näiteks "A peab käivituma enne B-d", siis seadke prioriteediks..."Viivituse" kasutamine mitteblokeerimise korral(edasilükkamine). See on praegu peaaegu kõige ideaalsem lahendus, kuna see ei blokeeri renderdamist ega häiri järjekorda.

Kui proovite edasilükkamist ja leiate ikkagi, et mõnel funktsioonil on probleeme, siis kaaluge...JS-i kasutamine mitteblokeerimiseksSee lahendus on radikaalsem, kuid selle ühilduvus on veidi halvem.

Mitteblokeerivate puhul kasutage "asünkroonset"(asünkroonne) on valik, mida ma kõige vähem soovitan. Kuna täitmisjärjekord on täiesti sassis, on lihtne krahhi sattuda, kui te pole täiesti kindel, et kõik teie skriptid töötavad iseseisvalt.

Kaks suurt lõksu, millesse ma langesin

Jutt on odav. Olen kirja pannud kaks viga, mille tegin; saate neid oma kogemuste põhjal kontrollida, et näha, kas saate neid vältida.

Esimene lõks: kohandatud WordPressi teemasid ei saa reaalajas eelvaadata.

Mõnda aega ei värskendunud eelvaade teema kohandamisel pärast salvestamise klõpsamist. Tegin mõned muudatused, värskendasin lehte ja see oli ikka sama.

Pärast mõningast uurimist avastasin, et süüdlane oli Minify tihendusfunktsioon. Lahendus on lihtne:

Juurdepääs W3 Total Cache pistikprogrammile常规设置,keera üles"kokkusurumine"Tühjendage see valik. Seejärel klõpsake paremas ülanurgas valiku „Salvesta sätted” all oleval väikesel noolel ja valige „...”.Salvesta sätted ja tühjenda vahemäluSee samm on ülioluline; kui te vahemälu ei tühjenda, näete ikka vana versiooni.

Kui olete lõpetanud, minge tagasi teema kohandamise juurde ja reaalajas eelvaade naaseb normaalseks.

Teine probleem: Astra teema otsingukast ei reageeri klõpsamisel.

Puutusin selle probleemiga kokku juba mõnda aega tagasi. Kasutasin Astra teemat ja ühel päeval avastasin ootamatult, et otsinguväli ei reageerinud, olenemata sellest, kuidas ma sellel klõpsasin. Alguses arvasin, et probleem on teemas endas, aga hiljem avastasin, et selle põhjustasid W3TC Minify seaded.

Lahendus on järgmine:

Mine W3 Total Cache → Üldised seaded → Täiustatud tihendusseaded → JS → Minify Engine'i seaded → Locale'i seaded ja muuda manustamise tüüp üheks järgmistest kahest:

1. Varem saavutati mitteblokeerimine JavaScripti abil.
2. Pärast seda kasutage JS-i mitteblokeerimiseks

Samamoodi võimaldab vahemälu tühjendamine ja lehe värskendamine otsinguväljal korralikult töötada.

Mis puutub sellesse, miks just need kaks valikut teiste asemel valiti, siis olen teinud veidi uurimistööd. Lihtsamalt öeldes on Astra teema esiotsa komponendid skripti täitmise ajastuse suhtes üsna tundlikud ja teatud mitteblokeerivad meetodid võivad põhjustada sündmuste sidumise nurjumise. Režiimi „mitteblokeeriv JS-iga” kasutamine tagab, et skript käivitatakse alles pärast lehe laadimise lõppu, vältides samal ajal asünkroonse režiimi puhul täheldatud korratut täitmist.

Külastatavate kohtade nimekiri

Lõpuks on siin kontrollnimekiri, mida saate otse järgida:

Esimene samm on oma eesmärgi selgitamine. Kas soovite kiireimat esialgset lehe laadimist või eelistate stabiilsust ja veatut toimimist? See määrab, millist manustamistüüpi peaksite kasutama.

Teine samm ei ole kõike korraga muuta. Esiteks leidke testimiseks vähem oluline leht, jälgige seda päev või kaks ja reklaamige see kogu saidile ainult siis, kui olete kindel, et probleeme pole.

Kolmandaks, tühjendage vahemälu pärast iga muudatust. W3TC vahemälumehhanism takistab teil uusimate muudatuste nägemist, seega on samm „tühjendage vahemälu ja testige uuesti” hädavajalik.

Neljandaks, kasuta oma brauseri arendustööriistu või tööriistu nagu PageSpeed ​​​​Insights, et võrrelda laadimiskiirust enne ja pärast. Lase andmetel enda eest rääkida, mitte ainult oma kõhutundel.

kirjuta lõppu

Ausalt öeldes, kui ma seda manustatud tüübiseadet esimest korda nägin, olin pikaks ajaks jahmunud. Vaikimisi blokeerimisrežiim tundus liiga aeglane, samas kui asünkroonne režiim ei garanteerinud järjekorda ja edasilükkamine võis põhjustada ühilduvusprobleeme. Ma ei olnud kindel, millist valikut valida.

Aga hiljem sain aru, et see on kompromiss. Sa ei saa valida nii kiireimat kui ka stabiilseimat lahendust; alati tuleb üks ohverdada. Minu kogemus on see, et kõigepealt tuleks kasutada edasilükkamist, mis on praegu kõige turvalisem blokeerimata lahendus, ja seejärel probleemide ilmnemisel kasutada tagasihelistamist.

Kui teil tekib sarnaseid probleeme või kui teil on pärast minu meetodi järgimist endiselt muid probleeme, arutage seda julgelt. Veebisaidi loomine on katse-eksituse meetod; keegi pole erand.

Tänan teid minu artikli lugemise eest. Näeme järgmine kord.