Mga Setting ng W3 Total Cache Minify Plugin: Paano Pumili ng Uri ng Pag-embed? Ang Aking Karanasan sa Pag-troubleshoot at Payo sa Pagliligtas-buhay

Nahihirapan ka bang pumili ng tamang uri ng pag-embed para sa W3 Total Cache Minify? Ibinabahagi ng artikulong ito ang karanasan ng isang webmaster sa totoong buhay at nagbibigay ng sunud-sunod na gabay upang tumpak na mapili ang tamang uri ng pag-embed ng Minify, na maiiwasan ang mga hindi pagkakapare-pareho ng istilo ng website at mga pag-crash ng paglo-load. Kasama rin dito ang isang hindi malilimutang solusyon sa pag-setup na madaling mailapat kahit ng mga baguhan.WordPress Bilisan nang hindi nagkaka-crash!

Nag-o-optimize ako ng website at nang buksan ko ang Minify settings sa W3 Total Cache, talagang natulala ako. Ang dropdown menu para sa embedded type ay may apat na opsyon: Default (Block), Use JS for Non-Blocking, Use "Asynchronous" for Non-Blocking, at Use "Delayed" for Non-Blocking.

Napaisip ako sandali, ano ba ang ibig sabihin ng lahat ng ito?

Maniwala ka sa akin, hindi ka nag-iisa. Ang apat na opsyong ito ay malamang na mag-iiwan kahit sa isang baguhan na nalilito, lalo na sa isang taong gumagamit ng WordPress sa loob ng maraming taon. Inilalahad ng artikulong ito ang mga patibong na aking naranasan at ang mga aral na aking natutunan, direkta sa iyo. Hindi mo kailangang sumangguni sa dokumentasyon; sundin lamang ang aking mga tagubilin.

Ano nga ba ang apat na uri ng pag-embed na ito?

Pag-usapan muna natin kung anong uri ng karakter ang apat na opsyong ito.

Default (bloke)Ito ay tinatawag na Default blocking. Ito ang pinakadiretso na paraan: humihinto ang browser kapag nakakita ito ng script, dina-download at pinapatakbo ito nang buo, at pagkatapos ay ipinagpapatuloy ang pag-render ng pahina. Mukhang maaasahan, hindi ba? Ngunit ang kapalit nito ay ang iyong unang pag-load ng pahina ay haharangan; kailangang maghintay ang mga user na matapos tumakbo ang script bago nila makita ang anuman.

Paggamit ng JS para sa hindi pagharangMedyo interesante ito. Sa halip na direktang magsulat ng mga tag na `<script>` sa pahina, una itong naglalabas ng isang maliit na script, at pagkatapos ay dynamic na inilalagay ang mga script na kailangang i-load sa pahina sa pamamagitan ng JavaScript pagkatapos tumakbo ang pahina. Sa ganitong paraan, maaaring unang ma-render ang pahina, at unti-unting maglo-load ang mga script. Maganda pakinggan, 'di ba? Gayunpaman, ang problema ay ang dynamic injection process na ito ay maaaring makagambala sa orihinal na pagkakasunud-sunod ng pagpapatupad ng mga script. Kung ang ilang script sa iyong pahina ay lubos na umaasa sa pagkakasunud-sunod ng pagpapatupad, maaaring lumitaw ang mga problema.

Gamitin ang "asynchronous" para sa hindi pagharangKabilang dito ang pagdaragdag ng katangiang `async` sa tag na `<script>`. Ang script ay magda-download nang asynchronous sa background at agad na isasagawa pagkatapos mag-download, nang hindi na hinihintay pa ito ng page. Gayunpaman, ang downside ay ang pagkakasunod-sunod ng pagpapatupad ay ganap na hindi makontrol; alinmang script ang unang matapos mag-download ang siyang unang isasagawa, anuman ang pagkakasunod-sunod na iyong tinukoy sa code.

Paggamit ng "delay" para sa hindi pagharangIto ang ibig sabihin ng pagdaragdag ng katangiang `defer`. Maghihintay ang script hanggang sa ma-parse ang buong pahina bago isagawa, at higit sa lahat, mapapanatili nito ang orihinal na pagkakasunud-sunod na isinulat mo. Ito ay medyo madaling gamitin, dahil hindi nito hinaharangan ang unang screen o ginagambala ang pagkakasunud-sunod.

Alin ang dapat kong piliin?

Sa madaling salita, ang apat na opsyon na ito ay parang isang multiple-choice na tanong:Gusto mo ba ng bilis o kaayusan?

Ang aking mungkahi ay ang mga sumusunod:

Kung maliit ang iyong website, kakaunti ang mga script, at wala kang masyadong mataas na kinakailangan para sa bilis ng paglo-load, ang paggamit ng default (blocked) setting ang pinakamadaling opsyon. Bagama't medyo mabagal ito, hindi ito magdudulot ng anumang problema.

Kung gusto mong pabilisin ang unang pag-screen at ang iyong mga script ay walang malalakas na dependency tulad ng "A must execute before B", unahin...Paggamit ng "delay" para sa hindi pagharang(ipagpaliban). Ito na halos ang pinaka-ideal na solusyon sa kasalukuyan, dahil hindi nito hinaharangan ang pag-render o ginagambala ang pagkakasunud-sunod.

Kung susubukan mong ipagpaliban at matuklasan mo pa rin na may ilang mga function na may problema, isaalang-alang...Paggamit ng JS para sa hindi pagharangMas radikal ang solusyon na ito, ngunit bahagyang mas malala ang pagiging tugma nito.

Gamitin ang "asynchronous" para sa hindi pagharangAng (async) ang opsyong hindi ko inirerekomenda. Dahil ang pagkakasunod-sunod ng pagpapatupad ay ganap na magulo, madaling mag-crash maliban na lang kung talagang sigurado kang tumatakbo nang hiwalay ang iyong mga script.

Dalawang malaking patibong ang aking kinasangkutan

Mura lang ang daldal. Isinulat ko ang dalawang pagkakamaling nagawa ko; maaari mo itong suriin batay sa sarili mong karanasan para makita kung maiiwasan mo ang mga ito.

Ang unang patibong: Hindi maaaring i-preview ang mga custom na tema ng WordPress sa totoong oras.

Sa loob ng ilang panahon, kapag nagko-customize ng tema, pagkatapos i-click ang save, hindi nagre-refresh ang preview. Gumagawa ako ng ilang pagbabago, nire-refresh ang pahina, at pareho pa rin ito.

Pagkatapos ng ilang imbestigasyon, natuklasan ko na ang compression function ng Minify ang may kagagawan nito. Simple lang ang solusyon:

I-access ang W3 Total Cache plugin常规设置,itaas"kompresisyon"Alisin ang tsek sa opsyong iyon. Pagkatapos ay i-click ang maliit na arrow sa ibaba ng "I-save ang Mga Setting" sa kanang sulok sa itaas at piliin ang "..."I-save ang mga setting at i-clear ang cacheNapakahalaga ng hakbang na ito; kung hindi mo lilinisin ang cache, makikita mo pa rin ang lumang bersyon.

Pagkatapos mong gawin ito, bumalik sa pagpapasadya ng tema, at babalik sa normal ang live preview.

Ang pangalawang problema: Hindi tumutugon ang search box para sa tema ng Astra kapag na-click.

Naranasan ko na ang problemang ito matagal na ang nakalipas. Ginagamit ko ang tema ng Astra, at isang araw bigla kong nalaman na hindi tumutugon ang search box kahit anong paraan ko ito i-click. Noong una, inakala kong problema ito sa mismong tema, ngunit kalaunan ay natuklasan ko na ito ay sanhi ng mga setting ng Minify ng W3TC.

Ang solusyon ay ang mga sumusunod:

Pumunta sa W3 Total Cache → General Settings → Advanced Compression Settings → JS → Minify Engine Settings → Locale Settings, at baguhin ang uri ng pag-embed sa isa sa dalawang ito:

1. Dati, ang non-blocking ay nakakamit gamit ang JavaScript.
2. Pagkatapos, gamitin ang JS para sa hindi pagharang

Katulad nito, ang pag-clear ng cache at pag-refresh ng pahina ay magbibigay-daan sa search box na gumana nang maayos.

Kung bakit pinili ang dalawang opsyong ito sa halip na ang iba, nagsaliksik na ako. Sa madaling salita, ang mga front-end component ng Astra theme ay medyo sensitibo sa tiyempo ng pagpapatupad ng script, at ang ilang mga non-blocking method ay maaaring maging sanhi ng pagkabigo ng event binding. Tinitiyak ng paggamit ng "non-blocking with JS" mode na ang script ay isasagawa lamang pagkatapos ma-load ang pahina, habang iniiwasan ang hindi maayos na pagpapatupad na nakikita sa async.

Listahan ng mga lugar na dapat bisitahin

Panghuli, narito ang isang checklist na maaari mong direktang sundin:

Ang unang hakbang ay linawin ang iyong layunin. Gusto mo ba ng pinakamabilis na unang pag-load ng pahina, o inuuna mo ba ang katatagan at operasyon na walang error? Ito ang magtatakda kung aling uri ng pag-embed ang dapat mong gamitin.

Ang pangalawang hakbang ay huwag baguhin ang lahat nang sabay-sabay. Una, maghanap ng hindi gaanong mahalagang pahina para subukan ito, obserbahan ito nang isa o dalawang araw, at i-promote lamang ito sa buong site kung sigurado kang walang problema.

Pangatlo, palaging linisin ang cache pagkatapos ng bawat pagbabago. Pipigilan ka ng mekanismo ng pag-cache ng W3TC na makita ang mga pinakabagong pagbabago, kaya ang hakbang na "i-clear ang cache at subukan muli" ay talagang mahalaga.

Pang-apat, gamitin ang mga developer tool ng iyong browser o mga tool tulad ng PageSpeed ​​​​Insights upang ihambing ang bilis ng paglo-load bago at pagkatapos. Hayaang ang datos ang magsalita para sa sarili nito, hindi lamang ang iyong kutob.

Sumulat sa dulo

Sa totoo lang, noong una kong nakita ang setting na ito ng naka-embed na uri, matagal akong natigilan. Tila masyadong mabagal ang default na blocking mode, habang ang asynchronous mode ay hindi ginagarantiyahan ang pagkakasunud-sunod ng mga operasyon, at ang pagpapaliban ay maaaring magdulot ng mga isyu sa compatibility. Hindi ako sigurado kung aling opsyon ang pipiliin.

Pero kalaunan ay napagtanto ko na isa itong kompromiso. Hindi mo maaaring makuha ang parehong pinakamabilis at pinaka-stable; kailangan mong isakripisyo ang isa. Ang aking karanasan ay gamitin muna ang defer, na kasalukuyang pinakaligtas na solusyon para sa non-blocking, at pagkatapos ay gumamit ng callback kung may lumitaw na problema.

Kung makakaranas ka ng mga katulad na problema, o kung mayroon ka pa ring ibang mga isyu matapos sundin ang aking pamamaraan, huwag mag-atubiling pag-usapan ito. Ang pagbuo ng website ay tungkol sa pagsubok at pagkakamali; walang sinuman ang eksepsiyon.

Salamat sa pagbabasa ng aking artikulo. Sa susunod na lang ulit.