W3 Total Cache Minify spraudņa iestatījumi: kā izvēlēties iegulšanas veidu? Mana problēmu novēršanas pieredze un padomi, kas glābs dzīvību.

Vai jums ir grūtības izvēlēties pareizo iegulšanas veidu W3 Total Cache Minify? Šajā rakstā ir sniegta tīmekļa pārziņa reālā pieredze un soli pa solim sniegta rokasgrāmata, lai precīzi izvēlētos pareizo Minify iegulšanas veidu, izvairoties no vietnes stila neatbilstībām un ielādes avārijām. Tajā ir iekļauts arī drošs iestatīšanas risinājums, ko pat iesācēji var viegli lietot.WordPress Paātrini bez avārijas!

Es optimizēju tīmekļa vietni un, atverot W3 Total Cache Minify iestatījumus, biju pilnīgā apstulbumā. Iegultā tipa nolaižamajā izvēlnē bija četras opcijas: Noklusējums (bloķēt), Izmantot JS nebloķēšanai, Izmantot "Asinhroni" nebloķēšanai un Izmantot "Aizkavētu" nebloķēšanai.

Es uz brīdi padomāju, par ko tas viss ir?

Ticiet man, jūs neesat viens. Šīs četras iespējas, visticamāk, atstās apjukumu pat iesācējam, nemaz nerunājot par kādu, kurš WordPress lieto jau gadiem ilgi. Šajā rakstā ir aprakstītas kļūmes, ar kurām esmu saskāries, un mācības, ko esmu guvis, tieši jums. Jums nav jāiepazīstas ar dokumentāciju; vienkārši izpildiet manus norādījumus.

Kas īsti ir šie četri iegulšanas veidi?

Vispirms parunāsim par to, kāda veida raksturs ir šīm četrām iespējām.

Noklusējums (bloķēt)To sauc par noklusējuma bloķēšanu. Tā ir visvienkāršākā pieeja: pārlūkprogramma apstājas, kad tā sastopas ar skriptu, lejupielādē un pilnībā izpilda to un pēc tam turpina lapas renderēšanu. Izklausās uzticami, vai ne? Taču kompromiss ir tāds, ka jūsu sākotnējā lapas ielāde tiks bloķēta; lietotājiem būs jāgaida, līdz skripts pabeigs darboties, pirms viņi varēs kaut ko redzēt.

JS izmantošana nebloķēšanaiTas ir diezgan interesanti. Tā vietā, lai tieši lapā rakstītu `<script>` tagus, tas vispirms izvada nelielu skriptu un pēc tam dinamiski ievada skriptus, kas jāielādē lapā, izmantojot JavaScript, pēc lapas palaišanas. Tādā veidā lapa var tikt renderēta vispirms, un skripti var ielādēties pakāpeniski. Izklausās lieliski, vai ne? Tomēr problēma ir tā, ka šis dinamiskais ievades process var izjaukt skriptu sākotnējo izpildes secību. Ja daži skripti jūsu lapā ir ļoti atkarīgi no izpildes secības, var rasties problēmas.

Nebloķēšanai izmantojiet "asinhrono"Tas ietver atribūta `async` pievienošanu tagam `<script>`. Skripts tiks lejupielādēts asinhroni fonā un izpildīts tūlīt pēc lejupielādes, lapai to negaidot. Tomēr trūkums ir tas, ka izpildes secību nevar kontrolēt; pirmais tiek izpildīts tas skripts, kurš pirmais pabeidz lejupielādi, neatkarīgi no kodā norādītās secības.

Izmantojot "kavēšanos" nebloķēšanaiLūk, ko nozīmē pievienot atribūtu `defer`. Skripts gaidīs, līdz visa lapa ir parsēta, pirms tiek izpildīts, un, kas ir svarīgi, tas saglabās sākotnējo secību, kādā jūs to uzrakstījāt. Tas ir diezgan lietotājam draudzīgi, jo tas nebloķē pirmo ekrānu, ne arī izjauc secību.

Kuru man vajadzētu izvēlēties?

Vienkārši sakot, šīs četras iespējas ir kā jautājums ar atbilžu variantiem:Vai vēlaties ātrumu vai kārtību?

Mans ieteikums ir šāds:

Ja jūsu vietne ir maza, tajā ir maz skriptu un jums nav ārkārtīgi augstas ielādes ātruma prasības, vienkāršākais variants ir izmantot noklusējuma (bloķēto) iestatījumu. Lai gan tas ir nedaudz lēnāks, tas neradīs nekādas problēmas.

Ja vēlaties uzlabot pirmā ekrāna ielādes ātrumu un jūsu skriptiem nav spēcīgu atkarību, piemēram, "A ir jāizpilda pirms B", prioritizējiet...Izmantojot "kavēšanos" nebloķēšanai(atlikt). Šis šobrīd ir gandrīz ideālākais risinājums, jo tas ne bloķē renderēšanu, ne izjauc secību.

Ja mēģināt atlikt un joprojām konstatējat, ka dažām funkcijām ir problēmas, tad apsveriet...JS izmantošana nebloķēšanaiŠis risinājums ir radikālāks, taču tā saderība ir nedaudz sliktāka.

Nebloķēšanai izmantojiet "asinhrono"(async) ir opcija, ko es vismazāk ieteiktu. Tā kā izpildes secība ir pilnīgi sajaukta, ir viegli avarēt, ja vien neesat pilnīgi pārliecināts, ka visi jūsu skripti darbojas neatkarīgi.

Divas lielas kļūdas, kurās es iekritu

Runāt ir lēti. Esmu pierakstījis divas kļūdas, ko esmu pieļāvis; jūs varat tās salīdzināt ar savu pieredzi, lai redzētu, vai varat no tām izvairīties.

Pirmais trūkums: pielāgotas WordPress tēmas nevar priekšskatīt reāllaikā.

Kādu laiku, pielāgojot tēmu, pēc noklikšķināšanas uz “Saglabāt”, priekšskatījums netika atsvaidzināts. Es veicu dažas izmaiņas, atsvaidzināju lapu, un viss joprojām bija tāpat.

Pēc nelielas izpētes es atklāju, ka vainīgā bija Minify saspiešanas funkcija. Risinājums ir vienkāršs:

Piekļūstiet W3 Total Cache spraudnim常规设置,pagriezties"saspiešana"Noņemiet atzīmi no šīs opcijas. Pēc tam noklikšķiniet uz mazās bultiņas zem "Saglabāt iestatījumus" augšējā labajā stūrī un atlasiet "...".Saglabāt iestatījumus un notīrīt kešatmiņuŠis solis ir ļoti svarīgs; ja neiztīrīsiet kešatmiņu, joprojām redzēsiet veco versiju.

Kad esat pabeidzis, atgriezieties pie tēmas pielāgošanas, un tiešraides priekšskatījums atgriezīsies normālā stāvoklī.

Otra problēma: Astra tēmas meklēšanas lodziņš nereaģē, kad uz tā noklikšķina.

Es saskāros ar šo problēmu diezgan sen. Es izmantoju Astra tēmu, un kādu dienu pēkšņi atklāju, ka meklēšanas lodziņš nereaģēja neatkarīgi no tā, kā es uz tā noklikšķināju. Sākumā domāju, ka tā ir problēma ar pašu tēmu, bet vēlāk atklāju, ka to izraisīja W3TC Minify iestatījumi.

Risinājums ir šāds:

Dodieties uz W3 Total Cache → Vispārīgie iestatījumi → Papildu saspiešanas iestatījumi → JS → Minify Engine iestatījumi → Lokalizācijas iestatījumi un mainiet iegulšanas veidu uz vienu no šiem diviem:

1. Iepriekš nebloķēšana tika panākta, izmantojot JavaScript.
2. Pēc tam izmantojiet JS nebloķēšanai

Līdzīgi, kešatmiņas notīrīšana un lapas atsvaidzināšana nodrošinās meklēšanas lodziņa pareizu darbību.

Runājot par to, kāpēc tika izvēlētas šīs divas iespējas, nevis citas, esmu veicis nelielu izpēti. Vienkārši sakot, Astra tēmas front-end komponenti ir diezgan jutīgi pret skripta izpildes laiku, un noteiktas nebloķējošas metodes var izraisīt notikumu saistīšanas kļūmi. Izmantojot režīmu "nebloķēšana ar JS", tiek nodrošināts, ka skripts tiek izpildīts tikai pēc lapas ielādes pabeigšanas, vienlaikus izvairoties no nesakārtotas izpildes, kas redzama ar asinhrono režīmu.

Apmeklējamo vietu saraksts

Visbeidzot, šeit ir kontrolsaraksts, kuru varat tieši sekot:

Pirmais solis ir precizēt savu mērķi. Vai vēlaties ātrāko sākotnējo lapas ielādi vai arī prioritāte ir stabilitāte un darbība bez kļūdām? Tas noteiks, kuru iegulšanas veidu jums vajadzētu izmantot.

Otrais solis nav mainīt visu uzreiz. Vispirms atrodiet mazāk svarīgu lapu, lai to pārbaudītu, novērojiet to dienu vai divas un reklamējiet to visā vietnē tikai tad, ja esat pārliecināts, ka nav problēmu.

Treškārt, vienmēr notīriet kešatmiņu pēc katras modifikācijas. W3TC kešatmiņas mehānisms neļaus jums redzēt jaunākās izmaiņas, tāpēc darbība "notīrīt kešatmiņu un pārbaudīt vēlreiz" ir absolūti nepieciešama.

Ceturtkārt, izmantojiet pārlūkprogrammas izstrādātāja rīkus vai tādus rīkus kā PageSpeed ​​​​Insights, lai salīdzinātu ielādes ātrumu pirms un pēc. Ļaujiet datiem runāt pašiem par sevi, ne tikai savai intuīcijai.

Rakstiet beigās

Godīgi sakot, kad pirmo reizi ieraudzīju šo iegulto tipa iestatījumu, es ilgi biju apstulbis. Noklusējuma bloķēšanas režīms šķita pārāk lēns, savukārt asinhronais režīms negarantēja darbību secību, un atlikšana varētu radīt saderības problēmas. Es nebiju pārliecināts, kuru opciju izvēlēties.

Bet vēlāk es sapratu, ka tas ir kompromiss. Nevar būt gan ātrākais, gan stabilākais; vienmēr ir jāupurē viens. Mana pieredze liecina, ka vispirms jāizmanto atlikšana, kas pašlaik ir drošākais nebloķējošais risinājums, un pēc tam, ja rodas problēmas, jāizmanto atzvans.

Ja rodas līdzīgas problēmas vai ja pēc manas metodes ievērošanas joprojām ir citas problēmas, droši apspriediet tās. Tīmekļa vietņu izstrāde ir balstīta uz izmēģinājumiem un kļūdām; neviens nav izņēmums.

Paldies, ka izlasījāt manu rakstu. Uz tikšanos nākamreiz.