ဟိုတင်နှင့် စွမ်းဆောင်ရည်
WordPress ကို မည်သို့ အမြန်ဆုံးဖြစ်အောင် ပြုလုပ်သနည်း - LiteSpeed Enterprise၊ LSCache နှင့် ဆိုက်တစ်ခုချင်းအလိုက် Redis
အမြန်ဆုံး WordPress တောင်းဆိုမှုဆိုသည်မှာ ဘယ်သောအခါမှ မလုပ်ဆောင်ရသည့် တောင်းဆိုမှုပင် ဖြစ်သည် — ဤတွင် ကျွန်ုပ်တို့၏ စတတ်ခ် (stack) သည် PHP သို့မဟုတ် MySQL မခေါ်ဆိုမီ လည်ပတ်မှုအများစုကို ကက်ရှ် (cache) မှ မည်သို့ဖြေကြားပေးပုံနှင့် Core Web Vitals အတွက် ၎င်း၏အဓိပ္ပာယ်ကို ဖော်ပြထားပါသည်။
ဘယ်တော့မှ မလုပ်ဆောင်ရတဲ့ တောင်းဆိုချက်က အမြန်ဆုံး တောင်းဆိုချက်ပါပဲ
ပုံမှန် WordPress တောင်းဆိုချက်တစ်ခုသည် ကုန်ကျစရိတ်များပါသည်။ Web server သည် PHP သို့ လွှဲပြောင်းပေးသည်၊ PHP က WordPress ကို စတင်သည်၊ ပလပ်အင်များကို ရန်းနင်းသည်၊ MySQL ကို အကြိမ်ပေါင်းများစွာ မေးမြန်းသည်၊ HTML ကို စုစည်းသည်၊ ထို့နောက်မှသာ ဘိုက်များကို ပြန်လည်ပေးပို့သည်။ အလုပ်ရှုပ်သော ဆိုက်တစ်ခုတွင် ထိုလုပ်ငန်းစဉ်တစ်ခုလုံးသည် လာရောက်ကြည့်ရှုသူတိုင်းအတွက် ဖြစ်ပျက်နေပြီး ယင်းသည် သင်၏ time-to-first-byte ကုန်ဆုံးသွားသည့် နေရာပင်ဖြစ်သည်။
ကျွန်ုပ်တို့၏ အဖြေမှာ လာရောက်ကြည့်ရှုမှု အများစုအတွက် ယင်းတို့အနက် မည်သည်မျှ လုံးဝ မဖြစ်ပွားစေရန် သေချာစေခြင်း ဖြစ်ပါသည်။ ကျွန်ုပ်တို့ ဟို့စ်လုပ်ပေးထားသော ဝဘ်ဆိုက်များ (PBN ဆိုက်ပေါင်း ၁၀၀,၀၀၀ ကျော်အပြင် အဓိက မန်နိဂျ် လုပ်ထားသော WordPress အပါအဝင်) အနက် ဖရန့်အင်း စာမျက်နှာ ကြည့်ရှုမှု အများစုကို PHP ကို မခေါ်ယူဘဲ သို့မဟုတ် ဒေတာဘေ့စ်ကို မထိဘဲ ကက်ရှ်မှ စာမျက်နှာအပြည့် ကြိုတင်-ရင်ဒါလုပ်ထားသည့်အတိုင်း တိုက်ရိုက် ဝန်ဆောင်မှုပေးပါသည်။ ဤပို့စ်၏ ကျန်ရှိသော အပိုင်းသည် ထိုသို့ ဖြစ်မြောက်စေသည့် အလွှာများ မည်သို့ ပေါင်းစပ်ပါဝင်သည်၊ တစ်ခုစီသည် မည်သည့်နေရာတွင် ၎င်း၏ နေရာကို ရယူထားသည် ဆိုသည်တို့အကြောင်း ဖြစ်ပါသည်။
အရေးကြီးသော မှတ်သားစရာမှာ ၎င်းတို့သည် သင်ရွေးချယ်ရမည့် ယှဉ်ပြိုင်နေသော ကက်ရှ်များ မဟုတ်ကြပါ။ စာမျက်နှာအပြည့် ကက်ရှ်၊ အော့ဘ်ဂျက် ကက်ရှ်နှင့် CDN အစွန်း (edge) တို့သည် တောင်းဆိုမှု အမျိုးအစား တစ်ခုစီကို အသီးသီး ဖမ်းယူကြပြီး ၎င်းတို့အချင်းချင်း မည်ကဲ့သို့ လွှဲပြောင်းပေးကြသည်ဆိုသည့်အပေါ်တွင် တန်ဖိုးရှိနေခြင်း ဖြစ်ပါသည်။
LiteSpeed Enterprise + LSCache: စာမျက်နှာအပြည့်အလွှာ
ဝဘ်ဆိုက်တိုင်းကို Server အဆင့် LSCache ပါဝင်သော LiteSpeed Enterprise ပေါ်တွင် လည်ပတ်ပေးထားပါသည်။ Front-end တုံ့ပြန်မှုတစ်ခုကို Cache သိမ်းဆည်းနိုင်သည့်အခါ Web Server က ယင်းကို LiteSpeed cache-control နှင့် Tag ခေါင်းစီးများ တပ်ဆင်ပေးပြီး LiteSpeed သည် နောက်တစ်ကြိမ် လာရောက်ကြည့်ရှုသည့်အခါ PHP Process စတင်ရန်မလိုဘဲ၊ MySQL Query မေးမြန်းရန်မလိုဘဲ စာမျက်နှာအပြည့်အစုံကို တိုက်ရိုက် ပေးပို့ပေးပါသည်။ ယင်းက App စတင်သည့် လုပ်ငန်းစဉ်တစ်ခုလုံးကို အဓိက လမ်းကြောင်းပေါ်မှ ဖယ်ရှားပေးသောကြောင့် WordPress TTFB အတွက် အထိရောက်ဆုံးသော လုပ်ဆောင်ချက် ဖြစ်ပါသည်။
LSCache သည် PHP ပလပ်အင်တစ်ခုအတွင်း၌ မဟုတ်ဘဲ ဝဘ်ဆာဗာအတွင်း၌ တည်ရှိသောကြောင့် တောင်းဆိုမှုဘဝစက်ဝန်း၏ အစောပိုင်းအဆင့်တွင် စတင်အလုပ်လုပ်ပြီး ဆာဗာမှ ချက်ချင်းထုတ်လွှင့်နိုင်သည့် ပုံစံဖြင့် စာမျက်နှာများကို သိမ်းဆည်းပေးပါသည်။ ကက်ရှ် ကရောလာ (cache crawler) တစ်ခုက ရေပန်းစားသော စာမျက်နှာများကို အသင့်အနေအထားဖြစ်အောင် အမြဲလုပ်ဆောင်ပေးထားသဖြင့် စာမျက်နှာများကို ရှင်းလင်းပြီးနောက် ပထမဆုံးဝင်ရောက်လာသည့်ဧည့်သည်သည် စာမျက်နှာကို ပြန်လည်ထုတ်လုပ်ပေးရခြင်းအတွက် စောင့်ဆိုင်းပေးရမည်မဟုတ်ပါ။ ရလဒ်အနေဖြင့် ကက်ရှ်သည် PHP နောက်ကွယ်တွင်သာ ဆက်လက်ရှိနေဆဲဖြစ်သော အထွေထွေစတတ်ခ်တစ်ခုတွင် တပ်ဆင်ထားသည့် ပလပ်အင်သက်သက် ကက်ရှ်နှင့်ယှဉ်လျှင် TTFB ကို သိသိသာသာ ပို၍နည်းပါးပြီး ပိုမိုတည်ငြိမ်စေပါသည်။
ကျွန်ုပ်တို့၏ repo-grade cache plugin သည် site တိုင်းတွင် ကြိုတင်ထည့်သွင်းပေးထားပြီး အလိုအလျောက် အပ်ဒိတ်လုပ်ပေးကာ WordPress ကို LSCache သို့ အသုံးပြုရလွယ်ကူစွာ စနစ်တကျ ချိတ်ဆက်ပေးပါသည်။ LiteSpeed မဟုတ်သော origin ပေါ်တွင် full-page header များကို ထုတ်လွှတ်မည်မဟုတ်ဘဲ အနှောင့်အယှက်မဖြစ်စေဘဲ ဖယ်ရှားပေးမည်ဖြစ်ပြီး object cache နှင့် exclusion rule များသည်လည်း ၎င်းတို့၏ လုပ်ဆောင်ချက်များကို ဆက်လက်လုပ်ဆောင်နေမည် ဖြစ်သည် — ထို့ကြောင့် ပြောင်းရွှေ့ထားသော site တစ်ခုသည် တစ်ဝက်တစ်ပျက် စနစ်တကျမရှိဘဲ ပျက်စီးနေသည့် အခြေအနေတွင် မည်သည့်အခါမျှ ကျန်ရှိနေမည် မဟုတ်ပါ။
မြန်ဆန်မှုကို ထိန်းသိမ်းပြီး အဟောင်းများ မပြသခြင်း - ESI နှင့် စမတ်ကျသော အလိုအလျောက် သန့်စင်ခြင်း
ပြင်းထန်သော စာမျက်နှာအပြည့် ကက်ရှ်ပြုလုပ်ခြင်းတွင် ဂန္ထဝင် ချို့ယွင်းချက် အမျိုးအစား နှစ်ခုရှိသည်- ဝင်ရောက်ထားသည့် အသုံးပြုသူတစ်ဦးကို အခြားသူတစ်ဦး၏ စာမျက်နှာကို ပြသခြင်းနှင့် ပြောင်းလဲသင့်သည့် စာမျက်နှာကို မည်သူ့ကိုမဆို ပြသခြင်းတို့ ဖြစ်သည်။ နှစ်ခုစလုံးကို ကက်ရှ်ပြုလုပ်မှုကို လျှော့ချခြင်းဖြင့် မဟုတ်ဘဲ ကက်ရှ်ပြုလုပ်သည့် အလွှာတွင် ဖြေရှင်းပေးသည်။
ESI (Edge Side Includes) သည် တိုက်ရိုက် ရယူရန် လိုအပ်သော အစိတ်အပိုင်းများအတွက် ချန်လှပ်ထားစဉ် အခြား စာမျက်နှာကို ကက်ရှ်ပြုလုပ်ရန် လုပ်ဆောင်ပေးသည်။ WooCommerce စတိုးတွင် အမျိုးအစားခွဲ စာရင်း၊ ထုတ်ကုန်နှင့် ကက်တလောက် စာမျက်နှာများကို အမြန်ဆုံး TTFB ရရှိရန်အတွက် စာမျက်နှာအပြည့် ကက်ရှ်အဖြစ် ဝန်ဆောင်မှုပေးထားပြီး ESI က တောင်းဆိုမှုအလိုက် စျေးဝယ်လှည်း အစိတ်အပိုင်း၊ စျေးဝယ်လှည်း အကျဉ်းချုပ် စုစုပေါင်းနှင့် အကောင့် အခြေအနေတို့ကို ဖော်ပြပေးသည်။ စျေးဝယ်လှည်း၊ ငွေပေးချေမှု၊ ကျွန်ုပ်၏ အကောင့်နှင့် nonce သို့မဟုတ် စက်ရှင် စာမျက်နှာများကို မူလအတိုင်း ကင်းလွတ်ခွင့်ပြုထားသည်။ စျေးဝယ်သူများသည် ၎င်းတို့၏ စျေးဝယ်လှည်းနှင့် လုပ်ဆောင်နေသော ငွေပေးချေမှု စာမျက်နှာကို အမြဲတမ်း မြင်တွေ့ရပြီး အခြားသူများမှာမူ ကက်ရှ်မှ စတိုးမျက်နှာစာကို ရရှိနေမည်ဖြစ်သည်။
လတ်ဆတ်မှုအပိုင်းကို အလိုအလျောက် သန့်စင်ပေးသည့် smart auto-purge စနစ်ဖြင့် စီမံဆောင်ရွက်ပေးပါသည်။ အကြောင်းအရာများ၊ ထုတ်ကုန်များ၊ ဈေးနှုန်းများ သို့မဟုတ် အော်ဒါများ ပြောင်းလဲသည့်အခါ တိုက်ရိုက်သန့်စင်ပေးသည့် စနစ်များ အလိုအလျောက် အလုပ်လုပ်သောကြောင့် သက်ဆိုင်ရာ ကက်ရှ်မျက်နှာပြင်များသည် အချိန်သတ်မှတ်ချက်အတိုင်း မဟုတ်ဘဲ ချက်ချင်းဆိုသလို အသစ်ဖြစ်သွားမည်ဖြစ်ပြီး၊ ထိန်းချုပ်ပလတ်ဖောင်း သို့မဟုတ် WordPress အတွင်းမှလည်း လိုအပ်သလို သန့်စင်နိုင်ပါသည်။ တက်ဂ်အခြေပြု သန့်စင်သည့်စနစ်ကြောင့် ပို့စ်တစ်ခုကို ပြင်ဆင်လိုက်ပါက ထိုပို့စ်နှင့် ယင်း၏ မှတ်တမ်းဟောင်းများကိုသာ သန့်စင်ပေးမည်ဖြစ်ပြီး ကက်ရှ်တစ်ခုလုံးကို ပျက်ပြယ်စေမည် မဟုတ်သည့်အတွက် ပြင်ဆင်မှုတစ်ခုတည်းကြောင့် ဝဘ်ဆိုက်တစ်ခုလုံး နှေးကွေးသွားခြင်းမျိုး ဖြစ်ပေါ်မည် မဟုတ်ပါ။
ဆိုဒ်တစ်လင်းစီအလိုက် Redis အော့ဘ်ဂျက် ကက်ရှ်- စာမျက်နှာအပြည့် မဖြစ်နိုင်သည်များအတွက်
တောင်းဆိုမှုတိုင်းသည် တည်ငြိမ်ပြီး စာမျက်နှာအပြည့်အစုံ ဖြစ်နိုင်သည်မဟုတ်ပါ။ အကောင့်ဝင်ထားသော ဆက်ရှင်များ၊ WordPress အက်ဒမန်၊ WooCommerce တွန်းလှည်းများ၊ ရှာဖွေမှုနှင့် ESI ချန်ထားခဲ့သည့် တက်ကြွသောအပိုင်းအစများ အားလုံးသည် PHP ဖြင့် လုပ်ဆောင်ရပါမည်။ ၎င်းတို့အတွက်၊ ရည်မှန်းချက်သည် 'အပလီကေးရှင်းကို ကျော်သွားရန်' မှ 'ဒေတာဘေ့စ်ကို ကျော်သွားရန်' သို့ ပြောင်းလဲသွားပါသည်။
ဆိုဒ်တစ်ခုချင်းစီအတွက် သီးသန့် Redis object cache ရရှိမည်ဖြစ်သည်။ WordPress သည် ထပ်ခါတလဲလဲ ဖတ်ရှုရသော ဒေတာဘေ့စ် ရလဒ်များ ဖြစ်သည့် — အဓိက ဆက်တင်များ၊ transients၊ post နှင့် term ရှာဖွေမှုများ၊ WooCommerce ထုတ်ကုန်နှင့် session ဒေတာများ — ကို မမ်မိုရီထဲတွင် cache လုပ်ထားပေးသဖြင့်၊ အသုံးပြုသူ ဝင်ရောက်တိုင်း MySQL သို့ တူညီသော မေးမြန်းမှုကို ထပ်မံ လုပ်ဆောင်ရန် မလိုတော့ပါ။ ဤအကျိုးသက်ရောက်မှုကို စာမျက်နှာတစ်ခုလုံး cache လုပ်၍ မရနိုင်သော နေရာများတွင် အထင်ရှားဆုံး တွေ့မြင်နိုင်သည်- ပိုမိုမြန်ဆန်သော ဒက်ရှ်ဘုတ်များ၊ ပိုမိုမြန်ဆန်သော ဈေးဝယ်လှည်းများနှင့် အသုံးပြုသူ များပြားချိန်တွင် ဒေတာဘေ့စ် ဝန်ပိမှုကို အလွန် လျှော့ချပေးခြင်းတို့ ဖြစ်သည်။
အရာဝတ္ထု သိုလှောင်ကိရှ် (object cache) သည် ဝဘ်ဆိုက်တစ်ခုစီအတွက် သီးသန့်ဖြစ်ပြီး မျှဝေသုံးစွဲခြင်း မရှိပါ။ ထိုအချက်သည် စွမ်းဆောင်ရည်နှင့် သီးခြားခွဲထုတ်ထားမှု နှစ်ခုလုံးအတွက် အရေးပါသည်။ ဝဘ်ဆိုက်တစ်ခုစီအလိုက် ဒေတာဘေ့စ် ထိန်းချုပ်ကန့်သတ်မှုစနစ်နှင့် ပေါင်းစပ်လိုက်သောအခါ ဝဘ်ဆိုက်တစ်ခု၏ ဝန်လေးသော သို့မဟုတ် မသပ်ရပ်သော စုံစမ်းမေးမြန်းမှုများ (queries) သည် အနီးအနားရှိ အခြားဝဘ်ဆိုက်များအတွက် ဒေတာဘေ့စ်သုံးစွဲနိုင်မှုကို ပြတ်တောက်မသွားစေနိုင်ပါ။ အလွှာပေါင်းစုံ တည်ဆောက်ပုံတစ်ခုလုံး မည်သို့ ချိတ်ဆက်လုပ်ဆောင်သည်ကို ကျွန်ုပ်တို့၏ caching အင်္ဂါရပ် စာမျက်နှာတွင် လည်းကောင်း၊ သီးခြားခွဲထုတ်ထားမှုအောက်ရှိ အသုံးပြုသူ အပိုင်းအခြားများအကြောင်းကို isolation တွင်လည်းကောင်း ဆက်လက်ဖတ်ရှုနိုင်ပါသည်။
အစွန်းနှင့် ယင်း၏အောက်ရှိ တိုက်ရိုက်သယ်ယူပို့ဆောင်ရေး
မူလဆာဗာပေါ်တွင် ရှိနေသည့် ကက်ရှ် (Cache) သည် ကွန်ရက်ကို ဖြတ်သန်းသွားရဆဲ ဖြစ်သည်။ ဆာဗာရှေ့တွင် CDN အစွန်း (edge) ရှိသောကြောင့် တည်ငြားသော ဖိုင်များနှင့် ကက်ရှ်လုပ်နိုင်သော စာမျက်နှာများကို လာရောက်ကြည့်ရှုသူနှင့် နီးစပ်သည့် pop (point of presence) တစ်ခုမှ ဝန်ဆောင်မှုပေးပြီး၊ ဝန်ပိနေချိန်တွင်ပင် မူလဆာဗာသည် တိတ်ဆိတ်ငြိမ်သက်နေမည် ဖြစ်သည်။ ကျွန်ုပ်တို့၏ footprint-free ဟိုစတင်းလိုင်းအတွက်မူ အဆိုပါ အစွန်း (edge) သည် ဝန်ဆောင်မှုပေးသူ အများအပြားတွင် ပျံ့နှံ့နေသည့် multi-CDN ပူလ် (pool) တစ်ခု ဖြစ်ပြီး စွမ်းဆောင်ရည်အတွက်သာမက footprint ရည်မှန်းချက်ကိုလည်း ဖြည့်ဆည်းပေးပါသည်။ mainstream WordPress တွင်မူ ၎င်းသည် မူလဆာဗာများကို အလုပ်မရှုပ်စေဘဲ အမြန်နှုန်းကောင်းမွန်ကာ ပုံမှန်အတိုင်း လုပ်ဆောင်ပေးသည့် အလွှာတစ်ခုသာ ဖြစ်ပါသည်။
အောက်ခြေတွင် မူလအခြေခံများကို လျစ်လျူမရှုထားပါ။ ဝဘ်ဆိုက်များသည် HTTP/3 ပါရှိသော NVMe သိုလှောင်မှုပေါ်တွင် လုပ်ဆောင်သောကြောင့် cache ပို့လိုက်သည့် ဒေတာဘိုက်များသည် ခေတ်မီပြီး ပိုမိုမြန်ဆန်သော transport မှတဆင့် ရောက်ရှိလာမည်ဖြစ်ကာ cache မမိသည့်အခါမျိုးတွင်လည်း မြန်ဆန်သော သိုလှောင်မှုဖြင့် ကျောထောက်နောက်ခံပြုပေးထားပါသည်။ ဤအလွှာများထဲမှ တစ်ခုမျှ အပိုဝန်ဆောင်မှု (add-on) မဟုတ်ပါ၊ LiteSpeed၊ LSCache၊ ဆိုက်တစ်ခုချင်းအလိုက် သုံးရသည့် Redis၊ NVMe နှင့် HTTP/3 တို့သည် ပုံမှန်တိုးမြှင့်ရောင်းချသည့် အဆင့်တစ်ခုမဟုတ်ဘဲ ပလန်တိုင်း၏ အခြေခံစံနှုန်းများ ဖြစ်ကြပါသည်။
Core Web Vitals ကို တကယ်တမ်း ရွေ့လျားစေသောအရာများ
တိကျဖို့ ထိုက်တန်ပါတယ်၊ ဘာဖြစ်လို့လဲဆိုတော့ hosting ဟာ Core Web Vitals နဲ့ပတ်သက်ပြီး အမြဲလိုလို အလွန်အကျွံ ကတိပေးတတ်ကြလို့ပါ။ TTFB ဟာ ဆာဗာပိုင်ဆိုင်တဲ့ ညီမျှခြင်းရဲ့ အစိတ်အပိုင်းဖြစ်ပြီး အထက်က caching stack က အဲဒါကို ကျဆင်းစေတာဖြစ်ပါတယ် - edge ကနေ HTTP/3 နဲ့ ပို့ပေးတဲ့ cached လုပ်ထားတဲ့ စာမျက်နှာအပြည့်အစုံဟာ TTFB ရောက်ရှိနိုင်တဲ့ အနိမ့်ဆုံးအဆင့်နီးပါး ဖြစ်ပါတယ်။ TTFB ဟာ Largest Contentful Paint ရဲ့ အဓိကဦးဆောင်မှုဖြစ်တဲ့အတွက် မြန်ဆန်တဲ့ origin က အခြားနည်းနဲ့ လုံးဝမရနိုင်တဲ့ အစပျိုး အားသာချက်တစ်ခုကို downstream metric တိုင်းကို ပေးစွမ်းပါတယ်။
သို့သော် LCP၊ CLS နှင့် INP တို့ကို စာမျက်နှာကိုယ်တိုင်က ဘရောက်ဇာထဲတွင် အများစု ဆုံးဖြတ်ခြင်းဖြစ်သည်- အကောင်းဆုံးဖြစ်အောင် ပြင်ဆင်မထားသော hero ပုံရိပ်၊ render-blocking ဖြစ်နေသော CSS နှင့် JavaScript၊ ဖောင့်များနှင့် ကြော်ငြာများ လုဒ်တက်လာစဉ် ရွေ့လျားသွားသော ဘောင်အပြင်အဆင်၊ နှင့် ပလပ်အင်များထံမှ လေးလံသော main-thread လုပ်ဆောင်ချက်တို့ကြောင့် ဖြစ်သည်။ မည်သည့် ဆာဗာ ကက်ရှ်လုပ်ဆောင်ချက်မျှ 2 MB ရှိသော hero ပုံ သို့မဟုတ် မီဂါဘိုက်များစွာရှိသော JavaScript ပါဝင်သည့် သီးမ်တစ်ခုကို ဖြေရှင်းမပေးနိုင်ပါ။ ရိုးသားသော ဟို့စ်တင်သည် ဆာဗာ၏ ပံ့ပိုးမှုကို ထိရောက်စွာ အခမဲ့ဖြစ်စေပြီး အမြဲတစဉ် တစ်ပြေးညီဖြစ်စေသည်၊ ထို့နောက် ဖရန့်အန်းကို ပေါ့ပါးနေစေရန်မှာ ဝဘ်ဆိုက်ပေါ်တွင်သာ မူတည်သည်။
လုပ်ငန်းခွင် တာဝန်ခွဲဝေမှုဆိုသည်မှာ အသုံးဝင်သော စိတ်ကူးပုံစံတစ်ခု ဖြစ်သည်။ တောင်းဆိုချက်များ ဘရောက်ဆာထံသို့ လျှင်မြန်စွာ ရောက်ရှိရန်နှင့် လာရောက်ကြည့်ရှုသူ အများအပြားရှိချိန်တွင်ပင် ဆက်လက် မြန်ဆန်နေစေရန် ကျွန်ုပ်တို့ အာမခံပါသည်၊ သင်ကမူ ပေးပို့ဒေတာပမာဏကို သေးငယ်ပြီး တည်ငြိမ်နေစေရန် ထိန်းသိမ်းပေးရမည် ဖြစ်သည်။ ထိုနှစ်ခု ဆုံတွေ့သည့်နေရာများဖြစ်သော — cache warm-up၊ edge delivery နှင့် dynamic စာမျက်နှာများ ကြန့်ကြာမှု မရှိစေရန် ဒေတာဘေ့စ်ကို လျှင်မြန်စွာ တုံ့ပြန်မှုရှိစေခြင်း — တို့သည် ကျွန်ုပ်တို့၏ စနစ်ကို အတိအကျ ပိုမိုကောင်းမွန်အောင် ပြင်ဆင်ထားသည့် နေရာများဖြစ်ပြီး၊ ယင်းအချက်ကပင် ဤပလပ်ဖောင်းပေါ်ရှိ managed WordPress ကို အထွေထွေ ဟို့စ်တစ်ခုပေါ်ရှိ တူညီသော ဝဘ်ဆိုက်ထက် ပိုမိုမြန်ဆန်စေခြင်း ဖြစ်သည်။
မကြာခဏ မေးလေ့ရှိသော မေးခွန်းများ
WP Rocket ကဲ့သို့သော ကက်ချင်ပလပ်အင်တစ်ခုကို ကျွန်ုပ် ဆက်လက်လိုအပ်နေသေးပါသလား။
မဟုတ်ပါ။ စာမျက်နှာအပြည့် ကက်ရှ်လုပ်ခြင်း (Full-page caching) ကို ဝဘ်ဆာဗာရှိ LiteSpeed ၏ LSCache ဖြင့် လုပ်ဆောင်ပေးပြီး ကြိုတင်ထည့်သွင်းထားကာ အလိုအလျောက် အပ်ဒိတ်လုပ်ပေးသော ကျွန်ုပ်တို့၏ ကက်ရှ် ပလပ်အင်သည် WordPress ကို ယင်းနှင့် မှန်ကန်စွာ ချိတ်ဆက်ပေးကာ ၎င်း၏နောက်ကွယ်တွင် ဆိုက်တစ်ခုချင်းစီအတွက် Redis အޮဗ်ဂျက် ကက်ရှ် ပါရှိပါသည်။ ထပ်ဆင့်စာမျက်နှာအပြည့် ကက်ရှ် ပလပ်အင်တစ်ခုကို ထပ်တင်ခြင်းသည် အကူအညီဖြစ်စေမည့်အစား ဆာဗာအဆင့် ကက်ရှ်နှင့်သာ များသောအားဖြင့် ဆန့်ကျင်ဘက်ဖြစ်စေသောကြောင့် မလိုအပ်ပါ၊ မလည်း အကြံမပြုပါ။
Caching သည် ကျွန်ုပ်၏ WooCommerce cart သို့မဟုတ် ဝင်ရောက်ထားသော စာမျက်နှာများကို ပျက်စီးစေနိုင်ပါသလား။
မရှိပါ။ Cart၊ checkout၊ my-account နှင့် nonce သို့မဟုတ် session စာမျက်နှာများကို သီးခြားပြင်ဆင်ရန်မလိုဘဲ cache မှ ချန်လှပ်ထားပြီး ဖြစ်ကာ၊ ESI က အခြား cache လုပ်ထားသော စာမျက်နှာများပေါ်တွင် စျေးဝယ်ခြင်းတောင်း အစိတ်အပိုင်းနှင့် စုစုပေါင်းပမာဏများကို အချိန်နှင့်အမျှ အသစ်ဖြစ်နေစေပါသည်။ စတိုးဆိုင်မျက်နှာစာကို cache မှ ဒေါင်းလုဒ်လုပ်နေစဉ်မှာပင် ဝယ်ယူသူများသည် မိမိတို့၏ စျေးဝယ်ခြင်းတောင်းနှင့် အလုပ်လုပ်နေသော checkout ကို အမြဲတမ်း မြင်တွေ့ရမည်ဖြစ်ပါသည်။
ကျွန်ုပ်ထုတ်ဝေသောအခါ သို့မဟုတ် ပြင်ဆင်သောအခါတွင် ကက်ရှ် (cache) သည် မည်သို့ အသစ်ဖြစ်နေဆဲ ဖြစ်ပါသနည်း။
Smart auto-purge သည် သက်ဆိုင်ရာ WordPress hooks များတွင် အလုပ်လုပ်သောကြောင့် ပါဝင်သည့် စာမျက်နှာများနှင့် ၎င်းတို့၏ စာရင်းဇယားများကိုသာ (ကက်ရှ်တစ်ခုလုံးကို မဟုတ်ဘဲ) ရှင်းလင်းပေးပြီး crawler တစ်ခုက ၎င်းတို့ကို ပြန်လည် နွေးထွေးစေသည်။ သို့မှသာ အကြောင်းအရာအသစ်တင်ခြင်း၊ တည်းဖြတ်ခြင်း သို့မဟုတ် ပစ္စည်း၊ ဈေးနှုန်း သို့မဟုတ် အော်ဒါပြောင်းလဲခြင်းတို့ ပြုလုပ်ရာတွင် သက်ရောက်မှုရှိသော စာမျက်နှာများနှင့် ၎င်းတို့၏ စာရင်းဇယားများကိုသာ ရှင်းလင်းပေးမည်ဖြစ်ပြီး ကက်ရှ်တစ်ခုလုံးကို မထိခိုက်စေပါ။ ဒက်ရှ်ဘုတ်မှ သို့မဟုတ် WordPress အတွင်းမှနေ၍လည်း လိုအပ်သလို ရှင်းလင်းနိုင်ပါသည်။
ဟosting တစ်ခုတည်းဖြင့် ကျွန်ုပ်အတွက် ပြီးပြည့်စုံသော Core Web Vitals ကို ပေးစွမ်းနိုင်ပါသလား။
၎င်းသည် သင့်အား ဖြစ်နိုင်သမျှ အကောင်းဆုံး TTFB ကို ပေးစွမ်းပြီး၊ ၎င်းသည် ဆာဗာ၏ လုပ်ဆောင်ချက်ဖြစ်ကာ Largest Contentful Paint အတွက် ဦးဆောင်မှုကို ပေးစွမ်းသည်။ သို့သော် LCP၊ CLS နှင့် INP တို့ကို စာမျက်နှာကိုယ်တိုင်ကသာ အဓိက ဆုံးဖြတ်ပေးသည် — ပုံအရွယ်အစားများ၊ render-blocking လုပ်နေသော အရင်းအမြစ်များ၊ layout တည်ငြိမ်မှုနှင့် main-thread JavaScript တို့ ဖြစ်ကြသည်။ ကျွန်ုပ်တို့၏ stack သည် ဆာဗာ၏ ပံ့ပိုးမှုကို မြန်ဆန်ပြီး တသမတ်တည်းဖြစ်စေသည်၊ front-end payload ကို ပေါ့ပါးအောင် ထိန်းသိမ်းခြင်းကသာ ကျန်ရှိနေသည့် ကွာဟချက်ကို ဖြည့်ဆည်းပေးမည်ဖြစ်သည်။
ဆက်စပ်နေသော
၁၄ ရက် အခမဲ့ စမ်းသုံးကြည့်ပါ
သင့်ရဲ့ ပထမဆုံးဆိုဒ်များကို ၁၄ ရက်ကြာ အခမဲ့ တည်ဆောက်ပါ — ငွေပေးချေကတ် မလိုပါ။ ရှိပြီးသား ကွန်ရက်တစ်ခုကို ရွှေ့ပြောင်းနေပါသလား။ သင့်ရဲ့ ပထမဆုံး ရွှေ့ပြောင်းမှုကို ကျွန်ုပ်တို့ ကျခံပေးပါမယ်။
အခမဲ့ စတင်ပါ