„W3 Total Cache Minify“ papildinio nustatymai: kaip pasirinkti įterpimo tipą? Mano trikčių šalinimo patirtis ir gelbėjimo patarimai

Sunku išsirinkti tinkamą „W3 Total Cache Minify“ įterpimo tipą? Šiame straipsnyje dalijamasi realia žiniatinklio valdytojo patirtimi ir pateikiamas nuoseklus vadovas, kaip tiksliai pasirinkti tinkamą „Minify“ įterpimo tipą, išvengiant svetainės stiliaus neatitikimų ir įkėlimo strigčių. Jame taip pat pateikiamas patikimas sąrankos sprendimas, kurį gali lengvai pritaikyti net pradedantieji.WordPress Įsibėgėk be avarijų!

Optimizavau svetainę ir atidaręs „Minify“ nustatymus „W3 Total Cache“ programoje, buvau visiškai apstulbęs. Įterptojo tipo išskleidžiamajame meniu buvo keturios parinktys: „Numatytasis (blokuoti)“, „Naudoti JS neblokuojančiai“ „Naudoti „asinchroninį“ neblokuojančiai“ ir „Naudoti „atidėtą“ neblokuojančiai“.

Akimirką pagalvojau, apie ką visa tai?

Patikėkite, nesate vieni. Šie keturi variantai tikriausiai suglumins net pradedantįjį, jau nekalbant apie tą, kuris „WordPress“ naudoja jau daugelį metų. Šiame straipsnyje pateikiami mano susidūrę sunkumai ir pamokos, kurias išmokau tiesiogiai. Jums nereikia skaityti dokumentacijos; tiesiog vykdykite mano nurodymus.

Kas tiksliai yra šie keturi įterpimo tipai?

Pirmiausia pakalbėkime apie tai, kokie yra šie keturi variantai.

Numatytasis (blokuotas)Tai vadinama numatytuoju blokavimu. Tai pats paprasčiausias būdas: naršyklė sustoja, kai aptinka scenarijų, jį atsisiunčia ir visiškai vykdo, o tada tęsia puslapio generavimą. Skamba patikimai, tiesa? Tačiau kompromisas yra tas, kad pradinis puslapio įkėlimas bus blokuojamas; vartotojai turės palaukti, kol scenarijus baigs veikti, kad galėtų ką nors pamatyti.

JS naudojimas neblokavimuiTai gana įdomu. Užuot tiesiogiai rašęs `<script>` žymas puslapyje, jis pirmiausia išveda nedidelį skriptą, o tada dinamiškai įterpia skriptus, kuriuos reikia įkelti į puslapį naudojant „JavaScript“, kai puslapis veikia. Tokiu būdu puslapis gali būti atvaizduojamas pirmiausia, o skriptai gali būti įkeliami palaipsniui. Skamba puikiai, tiesa? Tačiau problema ta, kad šis dinaminis įterpimo procesas gali sutrikdyti pradinę skriptų vykdymo tvarką. Jei kai kurie jūsų puslapio skriptai labai priklauso nuo vykdymo tvarkos, gali kilti problemų.

Neblokuojantiems būdams naudokite „asinchroninį“Tai reiškia, kad prie žymės „<script>“ reikia pridėti atributą „async“. Scenarijus bus atsisiųstas asinchroniškai fone ir vykdomas iškart po atsisiuntimo, puslapiui nelaukiant. Tačiau trūkumas yra tas, kad vykdymo tvarka yra visiškai nekontroliuojama; scenarijus, kuris baigia atsisiuntimą anksčiau, vykdomas anksčiau, neatsižvelgiant į kode nurodytą tvarką.

Naudojant „vėlavimą“ neblokuojantŠtai ką reiškia pridėti „defer“ atributą. Scenarijus lauks, kol bus išanalizuotas visas puslapis, prieš jį vykdant, ir, svarbiausia, išlaikys pradinę jūsų parašytą tvarką. Tai gana patogu vartotojui, nes tai nei blokuoja pirmąjį ekraną, nei sutrikdo tvarkos.

Kurį turėčiau pasirinkti?

Paprastai tariant, šie keturi atsakymai yra tarsi klausimas su keliais atsakymų variantais:Ar norite greičio, ar tvarkos?

Mano pasiūlymas yra toks:

Jei jūsų svetainė maža, joje yra mažai skriptų ir nekeliate itin aukštų reikalavimų įkėlimo greičiui, paprasčiausias pasirinkimas yra naudoti numatytąjį (blokuotą) nustatymą. Nors jis yra šiek tiek lėtesnis, problemų nesukels.

Jei norite pagerinti pirmojo ekrano greitį ir jūsų scenarijai neturi stiprių priklausomybių, tokių kaip „A turi būti vykdomas prieš B“, teikite pirmenybę...Naudojant „vėlavimą“ neblokuojant(atidėti). Šiuo metu tai beveik idealiausias sprendimas, nes jis nei blokuoja atvaizdavimą, nei sutrikdo tvarkos.

Jei bandysite atidėti ir vis tiek pastebėsite, kad kai kurios funkcijos turi problemų, apsvarstykite...JS naudojimas neblokavimuiŠis sprendimas yra radikalesnis, tačiau jo suderinamumas yra šiek tiek blogesnis.

Neblokuojantiems būdams naudokite „asinchroninį“(asinchroninis) yra parinktis, kurią mažiausiai rekomenduoju. Kadangi vykdymo tvarka yra visiškai sujaukta, programa lengvai užstrigs, nebent esate visiškai tikri, kad visi jūsų scenarijai veikia nepriklausomai.

Į du didelius spąstus patekau

Plepėti – pigu. Užsirašiau dvi savo padarytas klaidas; galite jas palyginti su savo patirtimi ir pažiūrėti, ar galite jų išvengti.

Pirmas trūkumas: tinkintų „WordPress“ temų negalima peržiūrėti realiuoju laiku.

Kurį laiką, tinkinant temą, spustelėjus „Išsaugoti“, peržiūra neatsinaujindavo. Atlikdavau keletą pakeitimų, atnaujindavau puslapį ir jis vis tiek būdavo toks pat.

Po šiek tiek tyrimo atradau, kad kaltininkė buvo „Minify“ glaudinimo funkcija. Sprendimas paprastas:

Pasiekite „W3 Total Cache“ papildinį常规设置, pakilk„suspaudimas“Atžymėkite šią parinktį. Tada spustelėkite mažą rodyklę po „Išsaugoti nustatymus“ viršutiniame dešiniajame kampe ir pasirinkite „...“Išsaugoti nustatymus ir išvalyti talpykląŠis žingsnis yra labai svarbus; jei neišvalysite talpyklos, vis tiek matysite senąją versiją.

Baigę grįžkite prie temos pritaikymo ir tiesioginė peržiūra vėl bus įprasta.

Antra problema: „Astra“ temos paieškos laukelis nereaguoja spustelėjus.

Su šia problema susidūriau gana senokai. Naudojau „Astra“ temą ir vieną dieną staiga pastebėjau, kad paieškos laukelis nereagavo, kad ir kaip jį spustelėčiau. Iš pradžių maniau, kad tai pačios temos problema, bet vėliau išsiaiškinau, kad ją sukėlė W3TC „Minify“ nustatymai.

Sprendimas yra toks:

Eikite į „W3 Total Cache“ → „Bendrieji nustatymai“ → „Išplėstiniai glaudinimo nustatymai“ → „JS“ → „Minify Engine“ nustatymai → „Locale“ nustatymai ir pakeiskite įterpimo tipą į vieną iš šių dviejų:

1. Anksčiau neblokavimas buvo pasiektas naudojant „JavaScript“.
2. Po to naudokite JS neblokavimui

Panašiai, išvalius talpyklą ir atnaujinus puslapį, paieškos laukelis veiks tinkamai.

Kodėl buvo pasirinktos šios dvi parinktys, o ne kitos, atlikau tam tikrą tyrimą. Paprastai tariant, „Astra“ temos priekiniai komponentai yra gana jautrūs scenarijaus vykdymo laikui, o tam tikri neblokuojantys metodai gali sukelti įvykių susiejimo gedimą. Naudojant režimą „neblokuojantis su JS“, užtikrinama, kad scenarijus būtų vykdomas tik po to, kai puslapis būtų įkeltas, išvengiant netvarkingo vykdymo, pastebimo naudojant asinchroninį režimą.

Lankomų vietų sąrašas

Galiausiai, pateikiame kontrolinį sąrašą, kuriuo galite tiesiogiai vadovautis:

Pirmas žingsnis – išsiaiškinti savo tikslą. Ar norite greičiausio pradinio puslapio įkėlimo, ar teikiate pirmenybę stabilumui ir veikimui be klaidų? Tai nulems, kurį įterpimo tipą turėtumėte naudoti.

Antras žingsnis – nekeisti visko iš karto. Pirmiausia raskite mažiau svarbų puslapį, kurį išbandysite, stebėkite jį dieną ar dvi ir įtraukite jį į visą svetainę tik tada, jei esate tikri, kad nėra jokių problemų.

Trečia, visada išvalykite talpyklą po kiekvieno pakeitimo. „W3TC“ talpyklos mechanizmas neleis matyti naujausių pakeitimų, todėl žingsnis „išvalyti talpyklą ir išbandyti dar kartą“ yra absoliučiai būtinas.

Ketvirta, naudokite naršyklės kūrimo įrankius arba tokius įrankius kaip „PageSpeed ​​​​Insights“, kad palygintumėte įkėlimo greitį prieš ir po. Leiskite duomenims kalbėti patiems už save, o ne tik savo nuojautai.

parašyk pabaigoje

Jei atvirai, kai pirmą kartą pamačiau šį įterptąjį teksto nustatymą, ilgai buvau apstulbęs. Numatytasis blokavimo režimas atrodė per lėtas, o asinchroninis režimas negarantavo tvarkos, o atidėjimas galėjo sukelti suderinamumo problemų. Nebuvau tikras, kurią parinktį pasirinkti.

Tačiau vėliau supratau, kad tai kompromisas. Neįmanoma turėti ir greičiausio, ir stabiliausio; visada reikia paaukoti vieną. Mano patirtis rodo, kad pirmiausia reikia naudoti atidėjimą, kuris šiuo metu yra saugiausias neblokuojantis sprendimas, o tada, jei iškyla problemų, naudoti grįžtamąjį iškvietimą.

Jei susiduriate su panašiomis problemomis arba vis dar turite kitų problemų, net jei ir pritaikėte mano metodą, nedvejodami aptarkite tai. Svetainių kūrimas yra bandymų ir klaidų procesas; niekas nėra išimtis.

Ačiū, kad perskaitėte mano straipsnį. Iki kito karto.