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 aberya sa 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, na tinitiyak ang isang maayos at mabilis na karanasan sa WordPress !

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.

Ang default blocking ang pinakadirektang paraan. Kapag nakatagpo ang browser ng script, humihinto ito, dina-download at isinasagawa nang buo ang script, at pagkatapos ay ipinagpapatuloy ang pag-render ng pahina. Mukhang maaasahan, 'di ba? Ngunit ang kapalit nito ay maaantala ang iyong unang pag-load ng pahina; kailangang hintayin ng mga user na matapos tumakbo ang script bago nila makita ang anuman.

Medyo interesante ang paggamit ng JavaScript para sa non-blocking . Sa halip na direktang magsulat ng mga tag na `<script>` sa pahina, naglalabas muna ito ng isang maliit na script, at pagkatapos ay dynamic na inilalagay ang mga kinakailangang script sa pahina sa pamamagitan ng JavaScript pagkatapos tumakbo ang pahina. Sa ganitong paraan, maaaring unang mag-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.

Ang paggamit ng "asynchronous" para sa non-blocking execution ay nangangahulugan lamang ng pagdaragdag ng `async` attribute sa `<script>` tag. Ang script ay magda-download nang asynchronous sa background at agad na isasagawa pagkatapos makumpleto, nang hindi na hinihintay ito ng page. Gayunpaman, ang disbentaha ay ang pagkakasunod-sunod ng pagpapatupad ay ganap na hindi makontrol; anumang download ang unang isasagawa, anuman ang pagkakasunod-sunod na iyong tinukoy sa code.

Ang paggamit ng "delay" para sa non-blocking execution ay nakakamit sa pamamagitan 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 kung paano mo ito isinulat. Ito ay medyo madaling gamitin, dahil hindi nito hinaharangan ang unang screen o ginagambala ang pagkakasunud-sunod ng script.

Alin ang dapat kong piliin?

Sa madaling salita, ang apat na opsyong ito ay parang isang multiple-choice na tanong: gusto mo ba ng bilis, o gusto mo ng sunod-sunod na sagot?

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 pahusayin ang bilis sa unang pag-screen at ang iyong mga script ay walang malalakas na dependency tulad ng "A must execute before B," unahin ang paggamit ng "defer" para sa non-blocking execution . Ito na halos ang mainam na solusyon na kasalukuyang magagamit, dahil iniiwasan nito ang pagharang sa pag-render habang pinapanatili ang pagkakasunud-sunod ng pagpapatupad.

Kung mapapansin mong may ilang function pa rin na nagkakaproblema kahit sinubukan mo nang i-defer, isaalang-alang ang paggamit ng JavaScript para sa non-blocking . Mas agresibo ang pamamaraang ito, ngunit medyo mas malala ang compatibility nito.

Ang paggamit ng "async" para sa non-blocking ang opsyong hindi ko inirerekomenda. Dahil ang pagkakasunod-sunod ng pagpapatupad ay ganap na magulo, madaling mag-crash maliban na lang kung sigurado kang tatakbo 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:

Pumunta sa mga pangkalahatang setting ng W3 Total Cache plugin , hanapin ang opsyong "Compression" , at alisan ito ng tsek. Pagkatapos, i-click ang maliit na arrow sa ibaba ng "Save Settings" sa kanang sulok sa itaas, at piliin ang " Save Settings and Clear Cache ." Mahalaga ang hakbang na ito; kahit hindi nililinis 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.