W3 Total Cache Minify Plugin Settings: Embedding Type ကို ဘယ်လိုရွေးချယ်ရမလဲ။ ကျွန်တော့်ရဲ့ ပြဿနာဖြေရှင်းခြင်းအတွေ့အကြုံနဲ့ အသက်ကယ်အကြံဉာဏ်

W3 Total Cache Minify အတွက် မှန်ကန်သော embedding အမျိုးအစားကို ရွေးချယ်ရန် အခက်အခဲရှိနေပါသလား။ ဤဆောင်းပါးသည် ဝဘ်မာစတာတစ်ဦး၏ လက်တွေ့အတွေ့အကြုံကို မျှဝေထားပြီး ဝဘ်ဆိုက်ပုံစံ မကိုက်ညီမှုများနှင့် loading crash များကို ရှောင်ရှားရန် မှန်ကန်သော Minify embedding အမျိုးအစားကို တိကျစွာ ရွေးချယ်နည်း အဆင့်ဆင့် လမ်းညွှန်ချက်တစ်ခုကို ပေးပါသည်။ ၎င်းတွင် အစပြုသူများပင် အလွယ်တကူ အသုံးချနိုင်သော အမှားအယွင်းကင်းသော setup ဖြေရှင်းချက်တစ်ခုလည်း ပါဝင်သည်။WordPress ပျက်ကျခြင်းမရှိဘဲ အရှိန်မြှင့်ပါ!

ဝက်ဘ်ဆိုက်တစ်ခုကို optimize လုပ်နေတုန်း W3 Total Cache မှာ Minify setting တွေကို ဖွင့်လိုက်တော့ အံ့သြသွားတယ်။ embedded type အတွက် dropdown menu မှာ option လေးခုရှိတယ်- Default (Block), Use JS for Non-Blocking, Use "Asynchronous" for Non-Blocking နဲ့ Use "Delayed" for Non-Blocking။

ငါခဏလောက်စဉ်းစားမိတယ်၊ ဒါတွေအားလုံးက ဘာအကြောင်းလဲ။

ကျွန်တော့်ကို ယုံပါ၊ သင်တစ်ယောက်တည်း မဟုတ်ပါဘူး။ ဒီရွေးချယ်စရာလေးခုက WordPress ကို နှစ်ပေါင်းများစွာ အသုံးပြုနေသူတစ်ယောက်ကိုတောင် ဇဝေဇဝါဖြစ်စေနိုင်ပါတယ်။ ဒီဆောင်းပါးက ကျွန်တော်ကြုံတွေ့ခဲ့ရတဲ့ အခက်အခဲတွေနဲ့ တိုက်ရိုက်သင်ယူခဲ့ရတဲ့ သင်ခန်းစာတွေကို တင်ပြထားပါတယ်။ စာရွက်စာတမ်းတွေကို တိုင်ပင်စရာမလိုပါဘူး။ ကျွန်တော့်ရဲ့ ညွှန်ကြားချက်တွေကို လိုက်နာပါ။

ဒီ embedding အမျိုးအစားလေးမျိုးက ဘာတွေလဲ။

W3 Total Cache Minify Plugin Settings: Embedding Type ကို ဘယ်လိုရွေးချယ်ရမလဲ။ ကျွန်တော့်ရဲ့ ပြဿနာဖြေရှင်းခြင်းအတွေ့အကြုံနဲ့ အသက်ကယ်အကြံဉာဏ်

ဒီရွေးချယ်စရာလေးခုက ဘယ်လိုဇာတ်ကောင်မျိုးလဲဆိုတာကို အရင်ဆုံး ပြောကြရအောင်။

မူရင်း (ပိတ်ဆို့ထားသည်)ဒါကို Default blocking လို့ခေါ်ပါတယ်။ အရိုးရှင်းဆုံးနည်းလမ်းပါ။ browser က script တစ်ခုကိုတွေ့တဲ့အခါ ရပ်သွားပြီး download လုပ်ပြီး လုံးဝ execute လုပ်ပါတယ်၊ ပြီးရင် page ကို ဆက်လက် render လုပ်ပါတယ်။ ယုံကြည်စိတ်ချရတယ်လို့ ထင်ရတယ် မဟုတ်လား။ ဒါပေမယ့် အပေးအယူကတော့ သင့်ရဲ့ ပထမဆုံး page load ကို ပိတ်ဆို့ထားမှာပါ။ user တွေက ဘာမှမမြင်ခင် script ပြီးတဲ့အထိ စောင့်ရပါလိမ့်မယ်။

ပိတ်ဆို့ခြင်းမရှိစေရန် JS ကိုအသုံးပြုခြင်းဒါက အတော်လေး စိတ်ဝင်စားစရာပါ။ စာမျက်နှာပေါ်မှာ `<script>` tags တွေကို တိုက်ရိုက်ရေးမယ့်အစား၊ script သေးသေးလေးတစ်ခုကို အရင် output ထုတ်ပြီး စာမျက်နှာ run ပြီးနောက် JavaScript မှတစ်ဆင့် စာမျက်နှာထဲသို့ load လုပ်ရမယ့် script တွေကို dynamically inject လုပ်ပါတယ်။ ဒီနည်းနဲ့ စာမျက်နှာကို အရင် render လုပ်နိုင်ပြီး script တွေကို တဖြည်းဖြည်း load လုပ်နိုင်ပါတယ်။ အရမ်းကောင်းတယ်လို့ ထင်ရတယ် မဟုတ်လား။ ဒါပေမယ့် ပြဿနာက ဒီ dynamic injection လုပ်ငန်းစဉ်က script တွေရဲ့ မူရင်း execution order ကို အနှောင့်အယှက်ဖြစ်စေနိုင်ပါတယ်။ သင့်စာမျက်နှာပေါ်က script အချို့ဟာ execution order ပေါ်မှာ အများကြီး မူတည်နေရင် ပြဿနာတွေ ပေါ်ပေါက်လာနိုင်ပါတယ်။

ပိတ်ဆို့ခြင်းမပြုရန်အတွက် "asynchronous" ကိုသုံးပါ၎င်းတွင် `<script>` tag တွင် `async` attribute ကိုထည့်သွင်းခြင်းပါဝင်သည်။ script သည် နောက်ခံတွင် asynchronously download လုပ်မည်ဖြစ်ပြီး download လုပ်ပြီးနောက် စာမျက်နှာကိုမစောင့်ဘဲ ချက်ချင်း execute လုပ်မည်ဖြစ်သည်။ သို့သော်၊ အားနည်းချက်မှာ execution order ကို လုံးဝထိန်းချုပ်၍မရခြင်းဖြစ်သည်။ ကုဒ်တွင် သတ်မှတ်ထားသော order မည်သို့ပင်ရှိစေကာမူ မည်သည့် script သည် ဦးစွာ download လုပ်ပြီးစီးသည်ဖြစ်စေ ဦးစွာ execute လုပ်မည်ဖြစ်သည်။

ပိတ်ဆို့ခြင်းမပြုလုပ်ရန် "delay" ကိုအသုံးပြုခြင်း`defer` attribute ကိုထည့်လိုက်ခြင်းအားဖြင့် ဒါကဘာကိုဆိုလိုတာလဲ။ script ဟာ execute မလုပ်ခင် စာမျက်နှာတစ်ခုလုံးကို parse လုပ်ပြီးတဲ့အထိ စောင့်ပေးမှာဖြစ်ပြီး အရေးကြီးတာက သင်ရေးထားတဲ့ မူလအစီအစဉ်ကို ထိန်းသိမ်းထားပေးမှာပါ။ ဒါက အသုံးပြုရလွယ်ကူပါတယ်၊ ဘာလို့လဲဆိုတော့ ပထမဆုံး screen ကို မပိတ်ဆို့သလို အစီအစဉ်ကိုလည်း မနှောင့်ယှက်ပါဘူး။

ဘယ်ဟာကို ရွေးသင့်လဲ။

ရိုးရှင်းစွာပြောရလျှင် ဤရွေးချယ်စရာလေးခုသည် ရွေးချယ်မှုများစွာပါဝင်သော မေးခွန်းတစ်ခုနှင့်တူသည်။မြန်နှုန်းကို လိုချင်သလား၊ အမိန့်ကို လိုချင်သလား။

ကျွန်တော့်ရဲ့ အကြံပြုချက်ကတော့ အောက်ပါအတိုင်းပါ။

သင့်ဝက်ဘ်ဆိုက်သည် သေးငယ်ပြီး script အနည်းငယ်သာရှိပြီး loading speed အတွက် အလွန်မြင့်မားသော လိုအပ်ချက်များ မရှိပါက default (blocked) setting ကိုအသုံးပြုခြင်းသည် အလွယ်ကူဆုံးရွေးချယ်မှုဖြစ်သည်။ အနည်းငယ်နှေးကွေးသော်လည်း ပြဿနာတစ်စုံတစ်ရာ မဖြစ်စေပါ။

ပထမဆုံး မျက်နှာပြင်အမြန်နှုန်းကို မြှင့်တင်ချင်တယ်ဆိုရင်၊ ပြီးတော့ သင့်ရဲ့ script တွေမှာ "A must execute before B" လိုမျိုး ခိုင်မာတဲ့ dependencies တွေ မရှိဘူးဆိုရင်တော့၊ ဦးစားပေးပါ...ပိတ်ဆို့ခြင်းမပြုလုပ်ရန် "delay" ကိုအသုံးပြုခြင်း(ရွှေ့ဆိုင်း)။ ၎င်းသည် တင်ဆက်မှုကို မပိတ်ဆို့သလို အစီအစဉ်ကိုလည်း အနှောင့်အယှက်မဖြစ်စေသောကြောင့် လက်ရှိတွင် အကောင်းဆုံးဖြေရှင်းချက်နီးပါးဖြစ်သည်။

ရွှေ့ဆိုင်းဖို့ကြိုးစားပေမယ့် လုပ်ဆောင်ချက်အချို့မှာ ပြဿနာတွေတွေ့နေရရင် စဉ်းစားကြည့်ပါ...ပိတ်ဆို့ခြင်းမရှိစေရန် JS ကိုအသုံးပြုခြင်းဒီဖြေရှင်းချက်က ပိုပြီးအစွန်းရောက်ပေမယ့် လိုက်ဖက်ညီမှုက အနည်းငယ် ပိုဆိုးပါတယ်။

ပိတ်ဆို့ခြင်းမပြုရန်အတွက် "asynchronous" ကိုသုံးပါ(async) က ကျွန်တော် အနည်းဆုံး အကြံပြုထားတဲ့ option ပါ။ execution order က လုံးဝ ရှုပ်ထွေးနေတဲ့အတွက် သင့်ရဲ့ script တွေ အားလုံး သီးခြားစီ run နေတယ်လို့ လုံးဝ သေချာမသိရင် crash ဖြစ်ဖို့ လွယ်ပါတယ်။

ကျွန်တော် ကျရောက်ခဲ့တဲ့ ကြီးမားတဲ့ ကပ်ဘေးနှစ်ခု

စကားပြောတာက အသုံးမဝင်ဘူး။ ကျွန်တော်လုပ်မိတဲ့ အမှားနှစ်ခုကို ရေးမှတ်ထားပါတယ်။ ရှောင်ရှားနိုင်မလားဆိုတာ ကိုယ့်ရဲ့အတွေ့အကြုံနဲ့ တိုက်ဆိုင်စစ်ဆေးနိုင်ပါတယ်။

ပထမဆုံး အားနည်းချက်- Custom WordPress themes များကို real time တွင် preview လုပ်၍မရပါ။

ခဏတာတော့ theme တစ်ခုကို စိတ်ကြိုက်ပြင်ဆင်တဲ့အခါ save ကိုနှိပ်ပြီးနောက် preview က refresh မလုပ်ပါဘူး။ ကျွန်တော် အပြောင်းအလဲတချို့လုပ်ပြီး စာမျက်နှာကို refresh လုပ်ကြည့်တော့ အရင်အတိုင်းပဲ ဖြစ်နေပါတယ်။

စုံစမ်းစစ်ဆေးမှုအချို့ပြုလုပ်ပြီးနောက် Minify ရဲ့ compression function က အဓိကတရားခံဖြစ်ကြောင်း တွေ့ရှိခဲ့ပါတယ်။ ဖြေရှင်းချက်ကတော့ ရိုးရှင်းပါတယ်။

W3 Total Cache ပလပ်အင်ကို အသုံးပြုပါအထွေထွေဆက်တင်များ,ပြန်ရသည်"ဖိသိပ်ခြင်း"ထိုရွေးချယ်မှုကို အမှန်ခြစ်ဖြုတ်ပါ။ ထို့နောက် အပေါ်ညာဘက်ထောင့်ရှိ "ဆက်တင်များကို သိမ်းဆည်းပါ" အောက်ရှိ မြှားငယ်လေးကို နှိပ်ပြီး "..." ကို ရွေးချယ်ပါ။ဆက်တင်များကို သိမ်းဆည်းပြီး ကက်ရှ်ကို ရှင်းပါဒီအဆင့်က အရေးကြီးပါတယ်။ cache ကို မရှင်းလင်းရင်တောင် ဗားရှင်းအဟောင်းကိုပဲ မြင်နေရဦးမှာပါ။

ပြီးသွားရင် theme customization ကို ပြန်သွားပါ၊ live preview က ပုံမှန်အတိုင်း ပြန်ဖြစ်သွားပါလိမ့်မယ်။

ဒုတိယပြဿနာ- Astra theme search box က နှိပ်လိုက်တဲ့အခါ တုံ့ပြန်မှုမရှိဘူး။

ဒီပြဿနာကို ကျွန်တော် အတော်ကြာ ကြုံခဲ့ရပါတယ်။ Astra theme သုံးနေတုန်း တစ်နေ့မှာ search box က ဘယ်လိုနှိပ်နှိပ် search box က တုံ့ပြန်မှု မရှိဘူးဆိုတာကို ရုတ်တရက် တွေ့ရှိခဲ့ပါတယ်။ အစကတော့ theme မှာ ပြဿနာရှိလို့ ထင်ခဲ့ပေမယ့် နောက်ပိုင်းမှာ W3TC ရဲ့ Minify setting ကြောင့် ဖြစ်တယ်ဆိုတာ သိလိုက်ရပါတယ်။

ဖြေရှင်းချက်မှာ အောက်ပါအတိုင်းဖြစ်သည်။

W3 Total Cache → General Settings → Advanced Compression Settings → JS → Minify Engine Settings → Locale Settings သို့သွားပြီး embedding အမျိုးအစားကို အောက်ပါနှစ်ခုအနက် တစ်ခုခုသို့ ပြောင်းပါ။

  1. ယခင်က JavaScript ကို အသုံးပြု၍ ပိတ်ဆို့ခြင်းမပြုခြင်းကို ပြုလုပ်ခဲ့သည်။
  2. ထို့နောက် ပိတ်ဆို့ခြင်းမပြုလုပ်ရန် JS ကိုသုံးပါ။

အလားတူပင်၊ cache ကိုရှင်းလင်းခြင်းနှင့် စာမျက်နှာကို refresh လုပ်ခြင်းသည် ရှာဖွေရေးအကွက်ကို ကောင်းမွန်စွာအလုပ်လုပ်စေမည်ဖြစ်သည်။

ဘာကြောင့် ဒီ option နှစ်ခုကို တခြား option တွေအစား ရွေးချယ်ခဲ့တာလဲဆိုတာနဲ့ ပတ်သက်ပြီး ကျွန်တော် သုတေသနလုပ်ထားပါတယ်။ ရိုးရှင်းစွာပြောရရင် Astra theme ရဲ့ front-end components တွေဟာ script execution ရဲ့ အချိန်ကိုက်မှုအပေါ် အတော်လေး sensitive ဖြစ်ပြီး non-blocking method အချို့က event binding ကို fail ဖြစ်စေနိုင်ပါတယ်။ "non-blocking with JS" mode ကိုအသုံးပြုခြင်းအားဖြင့် page loading ပြီးမှသာ script ဟာ execute လုပ်မှာဖြစ်ပြီး async မှာတွေ့ရတဲ့ disordered execution ကို ရှောင်ရှားနိုင်မှာပါ။

သွားရောက်လည်ပတ်ရမည့်နေရာများစာရင်း

နောက်ဆုံးအနေနဲ့၊ သင်တိုက်ရိုက်လိုက်နာနိုင်တဲ့ စစ်ဆေးရမယ့်စာရင်းကို ဖော်ပြပေးလိုက်ပါတယ်-

ပထမခြေလှမ်းကတော့ သင့်ရည်မှန်းချက်ကို ရှင်းရှင်းလင်းလင်း သိအောင်လုပ်ပါ။ စာမျက်နှာအစပိုင်း အမြန်ဆုံးတင်ချင်သလား၊ ဒါမှမဟုတ် တည်ငြိမ်မှုနဲ့ အမှားအယွင်းကင်းတဲ့ လုပ်ဆောင်ချက်ကို ဦးစားပေးလား။ ဒါက သင်အသုံးပြုသင့်တဲ့ embedding အမျိုးအစားကို ဆုံးဖြတ်ပေးပါလိမ့်မယ်။

ဒုတိယအဆင့်ကတော့ အားလုံးကို တစ်ပြိုင်နက်တည်း မပြောင်းလဲဖို့ပါပဲ။ ပထမဦးစွာ စမ်းသပ်ဖို့ အရေးမကြီးတဲ့ စာမျက်နှာတစ်ခုကို ရှာပြီး တစ်ရက် ဒါမှမဟုတ် နှစ်ရက်လောက် စောင့်ကြည့်ပြီး ပြဿနာမရှိဘူးလို့ သေချာမှသာ ဝက်ဘ်ဆိုက်တစ်ခုလုံးကို မြှင့်တင်ပါ။

တတိယအချက်အနေနဲ့ ပြုပြင်မွမ်းမံမှုတစ်ခုပြီးတိုင်း cache ကို အမြဲရှင်းလင်းပါ။ W3TC ရဲ့ caching ယန္တရားက နောက်ဆုံးပေါ်ပြောင်းလဲမှုတွေကို မမြင်ရအောင် တားဆီးပေးမှာဖြစ်လို့ "cache ကိုရှင်းလင်းပြီး ထပ်မံစမ်းသပ်ပါ" ဆိုတဲ့ အဆင့်ဟာ လုံးဝအရေးကြီးပါတယ်။

စတုတ္ထအချက်အနေနဲ့ သင့်ဘရောက်ဆာရဲ့ developer tools တွေ ဒါမှမဟုတ် PageSpeed ​​​​Insights လိုမျိုး tools တွေကို အသုံးပြုပြီး loading speed ကို နှိုင်းယှဉ်ကြည့်ပါ။ သင့်ရဲ့ ခံစားချက်တွေကိုသာမက data တွေကပါ ပြောပြပါစေ။

အဆုံးမှာရေးပါ

အမှန်အတိုင်းပြောရရင် ဒီ embedded type setting ကို ပထမဆုံးမြင်လိုက်ရတဲ့အချိန်မှာ အချိန်အတော်ကြာ အံ့အားသင့်သွားခဲ့တယ်။ default blocking mode က အရမ်းနှေးနေပုံရပြီး asynchronous mode ကတော့ အစီအစဉ်အတိုင်းဖြစ်မယ်လို့ အာမမခံနိုင်ပါဘူး။ ရွှေ့ဆိုင်းလိုက်ရင် compatibility ပြဿနာတွေ ဖြစ်လာနိုင်ပါတယ်။ ဘယ် option ကို ရွေးရမလဲဆိုတာ မသေချာဘူး။

ဒါပေမယ့် နောက်ပိုင်းမှာတော့ ဒါဟာ အပေးအယူလုပ်ရမယ့်ကိစ္စတစ်ခုဆိုတာ ကျွန်တော်သဘောပေါက်လာတယ်။ အမြန်ဆုံးနဲ့ အတည်ငြိမ်ဆုံး နှစ်ခုစလုံးကို ရနိုင်မှာမဟုတ်ဘူး။ အမြဲတမ်း တစ်ခုကိုတော့ စွန့်လွှတ်ရမှာပဲ။ ကျွန်တော့်အတွေ့အကြုံအရ defer ကို အရင်သုံးပါ၊ အဲဒါက လက်ရှိမှာ အလုံခြုံဆုံး non-blocking solution ပါ၊ ပြီးရင် ပြဿနာပေါ်လာရင် callback ကိုသုံးပါ။

အကယ်၍ သင်သည် အလားတူပြဿနာများနှင့် ကြုံတွေ့ရပါက သို့မဟုတ် ကျွန်ုပ်၏နည်းလမ်းကို လိုက်နာပြီးနောက် အခြားပြဿနာများ ရှိနေသေးပါက ဆွေးနွေးရန် တုံ့ဆိုင်းမနေပါနှင့်။ ဝဘ်ဆိုက်တည်ဆောက်ခြင်းသည် စမ်းသပ်ပြီး အမှားအယွင်းများသာဖြစ်သည်။ မည်သူမျှ ခြွင်းချက်မရှိပါ။

ကျွန်တော့်ရဲ့ဆောင်းပါးကို ဖတ်ရှုပေးတဲ့အတွက် ကျေးဇူးတင်ပါတယ်။ နောက်တစ်ကြိမ်မှာ ပြန်ဆုံကြမယ်။

မျှော်လင့်ခြင်း Chen Weiliang ဘလော့ဂ် ( https://www.chenweiliang.com/ "W3 Total Cache Minify Plugin Settings: How to Choose the Embedding Type? My Pitfalls and Lifesaving Tips" ဆောင်းပါးကို ကျွန်တော်မျှဝေခဲ့ပြီး သင့်အတွက် အထောက်အကူဖြစ်နိုင်ပါတယ်။

ဤဆောင်းပါး၏ link ကိုမျှဝေရန်ကြိုဆိုပါတယ်:https://www.chenweiliang.com/cwl-34003.html

နောက်ထပ်လျှို့ဝှက်လှည့်ကွက်များကိုသော့ဖွင့်ရန်🔑၊ ကျွန်ုပ်တို့၏ Telegram ချန်နယ်တွင် ပါဝင်ရန် ကြိုဆိုလိုက်ပါ။

ကြိုက်ရင် Share ပြီး Like လုပ်ပါ။ သင်၏ မျှဝေမှုများနှင့် ကြိုက်နှစ်သက်မှုများသည် ကျွန်ုပ်တို့၏ ဆက်လက်လှုံ့ဆော်မှုဖြစ်သည်။

 

မှတ်ချက်များ

သင့်အီးမေးလ်လိပ်စာကို ထုတ်ပြန်မည်မဟုတ်ပါ။ 用项已用用 * တံဆိပ်

ထိပ်တန်းမှလှိမ့်