ဟို့စ်တင်နှင့် စွမ်းဆောင်ရည်
WordPress ကို မြန်ဆန်စေရန် ကျွန်ုပ်တို့ ပြုလုပ်ပုံ- LiteSpeed Enterprise၊ LSCache နှင့် ဆိုက်တစ်ခုချင်းစီအတွက် Redis
အမြန်ဆန်ဆုံး WordPress တောင်းဆိုချက်သည် မည်သည့်အခါမျှ အလုပ်လုပ်ဆောင်စရာမလိုသော တောင်းဆိုချက်ဖြစ်သည် — PHP သို့မဟုတ် MySQL ကို စတင်အသုံးမပြုမီ ကျွန်ုပ်တို့၏ stack သည် ဝင်ရောက်ကြည့်ရှုမှု အများစုကို cache မှ မည်သို့တုံ့ပြန်ဖြေကြားပေးပုံနှင့် Core Web Vitals အတွက် ၎င်းသည် မည်သည့်အဓိပ္ပာယ်ရှိသည်ကို ဖော်ပြထားပါသည်။
အမြန်ဆုံးတောင်းဆိုချက်သည် ဘယ်သောအခါမျှ လုပ်ဆောင်ခြင်းမရှိသော တောင်းဆိုချက်ဖြစ်သည်
ပုံမှန် WordPress တောင်းဆိုမှုတစ်ခုသည် အရင်းအမြစ်များစွာ သုံးစွဲရပါသည်။ ဝဘ်ဆာဗာသည် PHP သို့ လွှဲပြောင်းပေးပြီး၊ PHP သည် WordPress ကို စတင်လည်ပတ်စေကာ၊ ပလပ်အင်များကို ဖွင့်လှစ်ပြီး၊ MySQL သို့ အကြိမ်များစွာ မေးမြန်းစုံစမ်းကာ၊ HTML ကို စုစည်းတည်ဆောက်ပြီးမှသာ ဘိုက်များကို ပြန်လည်ပေးပို့ပါသည်။ အသုံးပြုသူများသော ဆိုက်တစ်ခုတွင် ထိုလုပ်ငန်းစဉ်တစ်ခုလုံးသည် လာရောက်ကြည့်ရှုသူတိုင်းအတွက် ဖြစ်ပေါ်ပြီး၊ ၎င်းသည် သင်၏ time-to-first-byte အများစု ကုန်ဆုံးသွားသည့်နေရာ ဖြစ်ပါသည်။
ကျွန်ုပ်တို့၏ အဖြေမှာ ဝင်ရောက်ကြည့်ရှုမှု အများစုအတွက် အဆိုပါလုပ်ငန်းစဉ်များ လုံးဝမဖြစ်ပေါ်စေရန် သေချာစေခြင်း ဖြစ်ပါသည်။ ကျွန်ုပ်တို့ လက်ခံဝန်ဆောင်မှုပေးထားသော ဝဘ်ဆိုက်များအနှံ့ (PBN ဆိုက်ပေါင်း ၁၀၀,၀၀၀ ကျော်နှင့် အဓိက စီမံခန့်ခွဲပေးထားသော WordPress အပါအဝင်) တွင် front-end စာမျက်နှာ ကြည့်ရှုမှုအများစုကို PHP ကို ခေါ်ယူရန်မလိုဘဲ သို့မဟုတ် ဒေတာဘေ့စ်ကို ထိတွေ့ရန်မလိုဘဲ cache မှ ကြိုတင်ဖန်တီးထားသော စာမျက်နှာအပြည့်အစုံအဖြစ် တိုက်ရိုက်ဝန်ဆောင်မှုပေးပါသည်။ ဤပို့စ်၏ ကျန်ရှိသောအပိုင်းသည် ယင်းအခြေအနေကို ဖြစ်ပေါ်စေသော အလွှာများသည် မည်သို့အတူတကွ အံဝင်ခွင်ကျဖြစ်နေပုံနှင့် တစ်ခုချင်းစီသည် ၎င်းတို့၏နေရာတွင် မည်သို့အရေးပါပုံတို့အကြောင်း ဖြစ်ပါသည်။
အဓိကနားလည်ထားရမည့်အချက်မှာ ၎င်းတို့သည် သင်ရွေးချယ်ရမည့် အချင်းချင်းယှဉ်ပြိုင်နေသော cache များ မဟုတ်ကြပါ။ စာမျက်နှာအပြည့် cache၊ object cache နှင့် CDN edge တို့သည် မတူညီသော တောင်းဆိုမှုအမျိုးအစားတစ်ခုစီကို လက်ခံဆောင်ရွက်ပေးကြပြီး၊ ၎င်းတို့၏တန်ဖိုးမှာ တစ်ခုနှင့်တစ်ခု အပြန်အလှန် ချိတ်ဆက်လွှဲပြောင်းပေးသည့်ပုံစံတွင် ရှိပါသည်။
LiteSpeed Enterprise + LSCache: စာမျက်နှာအပြည့်အလွှာ
ဆိုဒ်တိုင်းသည် ဆာဗာအဆင့် LSCache ပါရှိသော LiteSpeed Enterprise ပေါ်တွင် လည်ပတ်ပါသည်။ ရှေ့ပြေးတုံ့ပြန်မှုသည် သိမ်းဆည်းနိုင်သည့်အခါ ဝဘ်ဆာဗာသည် ၎င်းကို LiteSpeed ယာယီသိမ်းဆည်းမှုထိန်းချုပ်ရေးနှင့် tag ခေါင်းစဉ်များဖြင့် သတ်မှတ်ပေးပြီး၊ နောက်တစ်ကြိမ်ဝင်ရောက်သည့်အခါ LiteSpeed က စာမျက်နှာအပြည့်အစုံကို တိုက်ရိုက်ဝန်ဆောင်မှုပေးပါသည် — မည်သည့် PHP လုပ်ငန်းစဉ်မျှမထုတ်လုပ်ပါ၊ မည်သည့် MySQL မေးမြန်းမှုမျှမလုပ်ဆောင်ပါ။ ၎င်းသည် အက်ပ်တစ်ခုလုံးစတင်လည်ပတ်ခြင်းကို အဓိကလမ်းကြောင်းမှ ဖယ်ရှားပေးသောကြောင့် WordPress TTFB အပေါ် တစ်ခုတည်းသော အကြီးမားဆုံး အကျိုးသက်ရောက်မှုဖြစ်ပါသည်။
LSCache သည် PHP ပလပ်အင်တစ်ခုအတွင်း၌ မဟုတ်ဘဲ ဝဘ်ဆာဗာအတွင်း၌ တည်ရှိနေသောကြောင့် ၎င်းသည် တောင်းဆိုမှုသက်တမ်းစက်ဝန်းတွင် ပိုမိုစောစီးစွာ စတင်အလုပ်လုပ်ပြီး ဆာဗာမှ ချက်ချင်းရှင်းထုတ်နိုင်သော ပုံစံဖြင့် စာမျက်နှာများကို ထိန်းမ်းထားပေးပါသည်။ ကက်ရှ်ခရောလာသည် လူကြိုက်များသော စာမျက်နှာများကို အမြဲအဆင်သင့်ဖြစ်စေရန် ထိန်းသိမ်းပေးထားသောကြောင့် ကက်ရှ်ရှင်းထုတ်ပြီးနောက် ပထမဆုံးဝင်ရောက်ကြည့်ရှုသူသည် စာမျက်နှာကို ပြန်လည်ထုတ်လုပ်ရသည့် ကြန့်ကြာမှုကို ခံစားရမည်မဟုတ်ပါ။ ရလဒ်အနေဖြင့် ကက်ရှ်သည် PHP ၏ နောက်ကွယ်တွင် ရှိနေဆဲဖြစ်သော သာမန်စနစ်တစ်ခုပေါ်တွင် ပလပ်အင်သက်သက်သာ တပ်ဆင်ထားသည့် ကက်ရှ်ထက် သိသာစွာ နည်းပါးပြီး ပိုမိုတည်ငြိမ်သော TTFB ကို ရရှိစေပါသည်။
ကျွန်ုပ်တို့၏ repo အဆင့် ကက်ရှ်ပလပ်ဂင်ကို ဆိုက်တိုင်းတွင် ကြိုတင်ထည့်သွင်းပေးထားပြီး အလိုအလျောက် အပ်ဒိတ်လုပ်ပေးကာ WordPress ကို LSCache နှင့် အဆင်သင့်မှန်ကန်စွာ ချိတ်ဆက်ပေးပါသည်။ LiteSpeed မဟုတ်သော မူရင်းဆာဗာများတွင် စာမျက်နှာအပြည့်ဆိုင်ရာ ခေါင်းစီးများကို မထုတ်ပေးဘဲ ဝင်ရောက်မနှောင့်ယှက်သော်လည်း အရာဝတ္ထုကက်ရှ်နှင့် ချွင်းချက်စည်းမျဉ်းများသည် ဆက်လက်အလုပ်လုပ်နေမည်ဖြစ်သောကြောင့် ရွှေ့ပြောင်းထားသောဆိုက်သည် မည်သည့်အခါမျှ ပျက်စီးနေသော၊ တစ်ဝက်တစ်ပျက် ပြင်ဆင်သတ်မှတ်ထားသောအခြေအနေတွင် ကျန်ရစ်မည်မဟုတ်ပါ။
အကြောင်းအရာဟောင်းများ မပြသဘဲ မြန်ဆန်နေစေခြင်း- ESI နှင့် စမတ်ကျသော အလိုအလျောက် ရှင်းလင်းမှု
ပြင်းထန်သော စာမျက်နှာအပြည့် ကက်ရှ်ပြုလုပ်ခြင်းတွင် ဂန္ထဝင်ကျရှုံးမှုပုံစံ နှစ်မျိုးရှိသည်- အကောင့်ဝင်ထားသော အသုံးပြုသူတစ်ဦးအား အခြားသူတစ်ဦး၏ စာမျက်နှာကို ပြသခြင်းနှင့် မည်သူ့ကိုမဆို ပြောင်းလဲသင့်သည့် စာမျက်နှာတစ်ခုကို ပြသခြင်းတို့ ဖြစ်သည်။ နှစ်ခုစလုံးကို ကက်ရှ်ပြုလုပ်ခြင်းအား လျှော့ချခြင်းဖြင့် မဟုတ်ဘဲ ကက်ရှ်အလွှာတွင် ဖြေရှင်းပါသည်။
ESI (Edge Side Includes) သည် တိုက်ရိုက်ပြသရန် လိုအပ်သော အစိတ်အပိုင်းများအတွက် နေရာချန်လှပ်ထားစဉ် စာမျက်နှာကို ကက်ရှ်ပြုလုပ်ခွင့် ပြုပါသည်။ WooCommerce စတိုးတစ်ခုတွင် ကတ်တလောက်၊ ထုတ်ကုန်နှင့် အမျိုးအစား စာမျက်နှာများကို အမြန်ဆုံး TTFB ရရှိစေရန် စာမျက်နှာအပြည့် ကက်ရှ်အဖြစ် ပေးပို့ထားပြီး ESI သည် တောင်းဆိုမှုတစ်ခုစီအတွက် တွန်းလှည်းအပိုင်းအစ၊ မီနီတွန်းလှည်း စုစုပေါင်းများနှင့် အကောင့်အခြေအနေကို ပြသပေးပါသည်။ တွန်းလှည်း၊ ငွေရှင်းခြင်း၊ ကျွန်ုပ်၏အကောင့်နှင့် မည်သည့် nonce သို့မဟုတ် ဆက်ရှင် စာမျက်နှာများကိုမဆို မူရင်းအတိုင်း ချန်လှပ်ထားပါသည်။ ဈေးဝယ်သူများသည် ၎င်းတို့၏ ကိုယ်ပိုင်ခြင်းတောင်းနှင့် အလုပ်လုပ်သော ငွေရှင်းခြင်းကို အမြဲတွေ့မြင်ရပြီး လူတိုင်းသည် စတိုးမျက်နှာစာကို ကက်ရှ်မှ ရရှိနေဆဲဖြစ်ပါသည်။
လတ်ဆတ်မှုကို စမတ်ကျသော အလိုအလျောက် ရှင်းလင်းမှု (smart auto-purge) ဖြင့် ကိုင်တွယ်ဆောင်ရွက်ပါသည်။ အကြောင်းအရာ၊ ထုတ်ကုန်များ၊ ဈေးနှုန်းများ သို့မဟုတ် မှာယူမှုများ ပြောင်းလဲသည့်အခါ ရှင်းလင်းရေး ချိတ်ဆက်မှုများ (purge hooks) သည် အလိုအလျောက် အလုပ်လုပ်သောကြောင့် သက်ဆိုင်ရာ ကက်ရှ်သိမ်းဆည်းထားသော စာမျက်နှာများသည် အချိန်သတ်မှတ်ချက်ကို စောင့်ဆိုင်းရခြင်းမရှိဘဲ ချက်ချင်း ပြန်လည်လန်းဆန်းသွားမည်ဖြစ်ပြီး၊ ဒက်ရှ်ဘုတ်မှဖြစ်စေ သို့မဟုတ် WordPress အတွင်းမှဖြစ်စေ လိုအပ်သလို ရှင်းလင်းနိုင်ပါသည်။ တက်ဂ်အခြေပြု ရှင်းလင်းမှုဆိုသည်မှာ ပို့စ်တစ်ခုကို တည်းဖြတ်ခြင်းသည် ကက်ရှ်တစ်ခုလုံးကို မဟုတ်ဘဲ ထိုပို့စ်နှင့် ၎င်း၏ မော်ကွန်းများကိုသာ ရှင်းလင်းပေးခြင်းဖြစ်သောကြောင့် တည်းဖြတ်မှုတစ်ခုတည်းဖြင့် ဝဘ်ဆိုက်တစ်ခုလုံးကို အစမှ ပြန်လည်စတင်စေခြင်း (cold-start) မဖြစ်စေပါ။
ဆိုဒ်တစ်ခုချင်းစီအတွက် Redis အရာဝတ္ထု ကက်ရှ်- စာမျက်နှာအပြည့် မဖြစ်နိုင်သောအရာများအတွက်
တောင်းဆိုမှုတိုင်းသည် တည်ငြိမ်သော စာမျက်နှာအပြည့် မဖြစ်နိုင်ပါ။ လော့ဂ်အင်ဝင်ထားသော ဆက်ရှင်များ၊ WordPress စီမံခန့်ခွဲမှုအပိုင်း၊ WooCommerce ဈေးဝယ်လှည်းများ၊ ရှာဖွေမှုများနှင့် ESI မှ အပြောင်းအလဲရှိစေရန် ချန်ထားခဲ့သော အပိုင်းအစများသည် PHP ကို မဖြစ်မနေ အလုပ်လုပ်စေရပါမည်။ ၎င်းတို့အတွက် ရည်မှန်းချက်မှာ 'အက်ပ်ပလီကေးရှင်းကို ကျော်သွားရန်' မှ 'ဒေတာဘေ့စ်ကို ကျော်သွားရန်' သို့ ပြောင်းလဲသွားပါသည်။
ဝက်ဘ်ဆိုက်တစ်ခုစီသည် သီးသန့် Redis object cache ကို ရရှိမည်ဖြစ်သည်။ WordPress သည် ထပ်ခါတလဲလဲ ဒေတာဘေ့စ်ဖတ်ရှုမှု ရလဒ်များဖြစ်သော — ရွေးချယ်မှုများ၊ transients များ၊ ပို့စ်နှင့် စကားလုံးရှာဖွေမှုများ၊ WooCommerce ကုန်ပစ္စည်းနှင့် session ဒေတာများကို — မမ်မိုရီထဲတွင် cache ပြုလုပ်ထားသောကြောင့် တူညီသော query ကို ဝင်ရောက်ကြည့်ရှုမှုတိုင်းအတွက် MySQL သို့ ပြေးစရာမလိုတော့ပါ။ ဤအကျိုးသက်ရောက်မှုကို စာမျက်နှာအပြည့် cache မှ မကူညီနိုင်သည့်နေရာများတွင် အထင်ရှားဆုံး တွေ့မြင်နိုင်ပါသည်- ပိုမိုမြန်ဆန်သော ဒက်ရှ်ဘုတ်များ၊ ပိုမိုမြန်ဆန်သော ဈေးဝယ်လှည်းများနှင့် လာရောက်ကြည့်ရှုမှုများချိန်တွင် အဆမတန် နည်းပါးသွားသော ဒေတာဘေ့စ်ဝန်ထုပ်ဝန်ပိုးတို့ ဖြစ်ပါသည်။
အရာဝတ္ထု ယာယီသိမ်းဆည်းမှု (object cache) သည် မျှဝေသုံးစွဲခြင်းမဟုတ်ဘဲ ဝဘ်ဆိုက်တစ်ခုချင်းစီအလိုက် သီးသန့်ဖြစ်သောကြောင့် စွမ်းဆောင်ရည်နှင့် သီးခြားခွဲထုတ်မှု နှစ်ခုစလုံးအတွက် အရေးပါပါသည်။ ဝဘ်ဆိုက်တစ်ခုချင်းစီအလိုက် ဒေတာဘေ့စ်ကန့်သတ်မှုနှင့် ပေါင်းစပ်ထားသောကြောင့် ဝဘ်ဆိုက်တစ်ခု၏ ဝန်များသော သို့မဟုတ် မှားယွင်းစွာ ရေးသားထားသော မေးမြန်းချက်များသည် ဘေးနားရှိ အခြားဝဘ်ဆိုက်များအတွက် ဒေတာဘေ့စ်ကို ထိခိုက်စေနိုင်မည် မဟုတ်ပါ။ အလွှာပေါင်းစုံ ဖွဲ့စည်းတည်ဆောက်ပုံတစ်ခုလုံး ချိတ်ဆက်အလုပ်လုပ်ပုံကို ကျွန်ုပ်တို့၏ ကက်ရှ်ပြုလုပ်ခြင်း အင်္ဂါရပ်စာမျက်နှာတွင် လည်းကောင်း၊ သီးခြားခွဲထုတ်မှုအောက်ရှိ အသုံးပြုသူများအကြား နယ်နိမိတ်များကိုလည်းကောင်း ဆက်လက်ဖတ်ရှုနိုင်ပါသည်။
အစွန်းနှင့် ၎င်းအောက်ရှိ ပို့ဆောင်ရေးစနစ်
မူရင်းဆာဗာတွင်ရှိသော cache သည် ကွန်ရက်ကို ဖြတ်သန်းနေရဆဲဖြစ်ပါသည်။ ဆာဗာ၏ရှေ့တွင် CDN edge တည်ရှိသောကြောင့် တည်ငြိမ်သော အရင်းအမြစ်များနှင့် cache ပြုလုပ်နိုင်သော စာမျက်နှာများကို လာရောက်ကြည့်ရှုသူနှင့် နီးစပ်သော တည်ရှိမှုအမှတ် (PoP) မှ ပေးပို့ပြီး၊ ဝန်ပိနေချိန်တွင်ပင် မူရင်းဆာဗာသည် သက်သာလျက်ရှိပါသည်။ ကျွန်ုပ်တို့၏ footprint-free ဟိုစတင်းလိုင်းအတွက် ထို edge ပင်လျှင် ပံ့ပိုးပေးသူ အများအပြားတွင် ဖြန့်ကျက်ထားသော multi-CDN pool တစ်ခုဖြစ်ပြီး၊ ၎င်းသည် စွမ်းဆောင်ရည်အတွက်သာမက footprint ပန်းတိုင်အတွက်ပါ အထောက်အကူပြုပါသည်၊ အများသုံး WordPress တွင်မူ ၎င်းသည် မူရင်းဆာဗာများကို အနားပေးထားသည့် မြန်ဆန်ပြီး စနစ်ကျသော အလွှာတစ်ခုမျှသာ ဖြစ်ပါသည်။
အတွင်းပိုင်းတွင် အခြေခံအချက်များကို လျှော့ပေါ့ထားခြင်းမရှိပါ။ ဆိုက်များကို HTTP/3 ပါဝင်သော NVMe သိုလှောင်ခန်းပေါ်တွင် လည်ပတ်ထားသောကြောင့် cache မှ ပေးပို့သော ဘိုက်များသည် cache miss ဖြစ်ပေါ်မှုတိုင်း၏နောက်ကွယ်တွင် မြန်ဆန်သော သိုလှောင်ခန်းနှင့်အတူ ခေတ်မီပြီး multiplex လုပ်ထားသော ပို့ဆောင်မှုစနစ်ဖြင့် ရောက်ရှိလာပါသည်။ ဤအလွှာများထဲမှ မည်သည့်အရာမျှ ထပ်ဆောင်းဝယ်ယူရသော အပိုဝန်ဆောင်မှု မဟုတ်ပါ- LiteSpeed၊ LSCache၊ ဆိုက်တစ်ခုချင်းစီအတွက် Redis၊ NVMe နှင့် HTTP/3 တို့သည် ပိုမိုဈေးကြီးသော အဆင့်အတွက်သာ မဟုတ်ဘဲ အစီအစဉ်တိုင်း၏ အခြေခံစံနှုန်း ဖြစ်ပါသည်။
Core Web Vitals ကို အမှန်တကယ်ပြောင်းလဲစေသောအရာ
Core Web Vitals နှင့်ပတ်သက်၍ hosting ကို ချဲ့ကားရောင်းချလေ့ရှိသောကြောင့် တိကျသေချာမှုရှိရန် လိုအပ်ပါသည်။ TTFB သည် ဆာဗာမှ ထိန်းချုပ်ထားသော အစိတ်အပိုင်းဖြစ်ပြီး အထက်ဖော်ပြပါ caching stack သည် ၎င်းကို လျှော့ချပေးသည့် အရာဖြစ်သည် — edge မှ HTTP/3 ဖြင့် ပေးပို့သော cache ပြုလုပ်ထားသည့် စာမျက်နှာအပြည့်အစုံသည် TTFB အတွက် အနိမ့်ဆုံးဖြစ်နိုင်သည့် အတိုင်းအတာဖြစ်သည်။ TTFB သည် Largest Contentful Paint ၏ ရှေ့ပြေးဖြစ်သောကြောင့် မြန်ဆန်သော origin သည် နောက်ဆက်တွဲ metric တိုင်းအတွက် အခြားနည်းဖြင့် မရနိုင်သော ကနဦး အားသာချက်ကို ပေးပါသည်။
သို့သော် LCP၊ CLS နှင့် INP တို့ကို စာမျက်နှာကိုယ်တိုင်က ဘရောင်ဇာအတွင်း၌သာ အဓိကဆုံးဖြတ်ပါသည်- အကောင်းဆုံးဖြစ်အောင် ပြုပြင်မထားသော hero ပုံရိပ်၊ ပြသမှုကို ပိတ်ဆို့နေသော CSS နှင့် JavaScript၊ ဖောင့်များနှင့် ကြော်ငြာများ တက်လာချိန်တွင် ရွေ့လျားသွားသော အဆင်အပြင်၊ ပလပ်အင်များမှ လေးလံသော main-thread လုပ်ဆောင်ချက်တို့ ဖြစ်ကြသည်။ မည်သည့်ဆာဗာ ကက်ရှ်ပမာဏကမျှ 2 MB ရှိသော hero ပုံ သို့မဟုတ် JavaScript မဂ္ဂါဘိုက်များစွာ ပို့ဆောင်ပေးနေသည့် သင်းမ်တစ်ခုကို မဖြေရှင်းပေးနိုင်ပါ။ ရိုးသားသော ဟိုစတင်းသည် ဆာဗာ၏ ပါဝင်ပံ့ပိုးမှုကို ထိရောက်စွာ အခမဲ့ဖြစ်စေပြီး တည်ငြိမ်စေပါသည်၊ ထို့နောက်တွင် front end ကို ပေါ့ပါးနေစေရန် ထိန်းသိမ်းရမည်မှာ ဝဘ်ဆိုက်၏ တာဝန်သာ ဖြစ်ပါသည်။
ထိုကဲ့သို့ လုပ်ငန်းခွဲဝေမှုသည် အသုံးဝင်သော စိတ်ကူးပုံစံတစ်ခု ဖြစ်ပါသည်။ တောင်းဆိုချက်သည် ဘရောက်ဇာထံသို့ လျင်မြန်စွာ ရောက်ရှိစေရန်နှင့် သုံးစွဲမှုပမာဏများပြားနေချိန်တွင်လည်း ဆက်လက်မြန်ဆန်နေစေရန် ကျွန်ုပ်တို့ အာမခံပါသည်၊ သင်သည် ပေးပို့သည့်ဒေတာပမာဏ (payload) ကို သေးငယ်ပြီး တည်ငြိမ်အောင် ထိန်းသိမ်းထားရန်သာ လိုအပ်ပါသည်။ အဆိုပါနှစ်ခု ဆုံစည်းသည့်နေရာဖြစ်သော — cache warm-up ပြုလုပ်ခြင်း၊ edge မှတစ်ဆင့် ပေးပို့ခြင်းနှင့် dynamic စာမျက်နှာများ ရပ်တန့်မသွားစေရန် ဒေတာဘေ့စ်၏ တုံ့ပြန်မှုကို ကောင်းမွန်စွာ ထိန်းသိမ်းခြင်းတို့သည် ကျွန်ုပ်တို့၏ စနစ်တည်ဆောက်ပုံ (stack) ကို အတိအကျ ချိန်ညှိထားသည့်နေရာဖြစ်ပြီး၊ ၎င်းသည်ပင် ဤပလက်ဖောင်းပေါ်ရှိ စီမံခန့်ခွဲပေးထားသော WordPress ကို ယေဘုယျ host ပေါ်ရှိ ဝက်ဘ်ဆိုက်တစ်ခုတည်းထက် ပိုမိုမြန်ဆန်စေသည့် အကြောင်းရင်းဖြစ်ပါသည်။
မကြာခဏမေးလေ့ရှိသော မေးခွန်းများ
ကျွန်ုပ်အတွက် WP Rocket ကဲ့သို့ ကက်ရှ်ပလပ်ဂင် လိုအပ်နေသေးပါသလား။
မဟုတ်ပါ။ စာမျက်နှာအပြည့် ကက်ရှ်ပြုလုပ်ခြင်းကို ဝဘ်ဆာဗာတွင် LiteSpeed ၏ LSCache မှ ကိုင်တွယ်ဆောင်ရွက်ပေးပြီး ကြိုတင်ထည့်သွင်းထားကာ အလိုအလျောက်အပ်ဒိတ်ဖြစ်သော ကျွန်ုပ်တို့၏ကိုယ်ပိုင် ကက်ရှ်ပလပ်ဂင်သည် WordPress ကို ၎င်းနှင့် ကောင်းမွန်စွာချိတ်ဆက်ပေးကာ ၎င်းနောက်ကွယ်တွင် ဆိုက်တစ်ခုချင်းစီအတွက် Redis အော့ဘ်ဂျက်ကက်ရှ် ပါရှိပါသည်။ နောက်ထပ် ဒုတိယမြောက် စာမျက်နှာအပြည့် ကက်ရှ်ပလပ်ဂင်တစ်ခုကို ထပ်မံထည့်သွင်းခြင်းသည် အထောက်အကူပြုမည့်အစား ဆာဗာအဆင့် ကက်ရှ်နှင့် ပဋိပက္ခဖြစ်တတ်သောကြောင့် ၎င်းကို လိုအပ်ခြင်းမရှိသည့်အပြင် အကြံမပြုပါ။
ကက်ရှ်ပြုလုပ်ခြင်းက ကျွန်ုပ်၏ WooCommerce တွန်းလှည်း သို့မဟုတ် လော့ဂ်အင်ဝင်ထားသော စာမျက်နှာများကို ပျက်စီးစေမည်လား။
မဟုတ်ပါ။ Cart၊ checkout၊ my-account နှင့် မည်သည့် nonce သို့မဟုတ် session စာမျက်နှာများကိုမဆို မူရင်းအတိုင်း cache မှ ချန်လှပ်ထားပြီး ESI သည် အခြား cache ပြုလုပ်ထားသော စာမျက်နှာများတွင် ဈေးဝယ်လှည်းအပိုင်းအစနှင့် စုစုပေါင်းပမာဏများကို တိုက်ရိုက်ပြသပေးပါသည်။ စတိုးမျက်နှာစာသည် cache မှ ဆက်လက်ဖွင့်နေချိန်တွင်ပင် ဝယ်ယူသူများသည် ၎င်းတို့၏ကိုယ်ပိုင်ခြင်းတောင်းနှင့် အလုပ်လုပ်ဆောင်နေသော ငွေချေစနစ်ကို အမြဲတစေ မြင်တွေ့ရမည်ဖြစ်ပါသည်။
ကျွန်ုပ်သည် ထုတ်ဝေခြင်း သို့မဟုတ် တည်းဖြတ်ခြင်း ပြုလုပ်သောအခါ cache သည် မည်သို့ လတ်ဆတ်နေမည်နည်း။
စမတ်ကျသော အလိုအလျောက်ရှင်းလင်းမှုစနစ်သည် သက်ဆိုင်ရာ WordPress ဟွတ်ခ်များပေါ်တွင် အလုပ်လုပ်သောကြောင့် အကြောင်းအရာကို ထုတ်ဝေခြင်း၊ တည်းဖြတ်ခြင်း သို့မဟုတ် ထုတ်ကုန်၊ ဈေးနှုန်း သို့မဟုတ် အမှာစာကို ပြောင်းလဲခြင်းသည် ကက်ရှ်တစ်ခုလုံးကို မဟုတ်ဘဲ သက်ရောက်မှုရှိသော စာမျက်နှာများနှင့် ၎င်းတို့၏ မော်ကွန်းတိုက်များကိုသာ ရှင်းလင်းပေးပြီး ခရော်လာက ၎င်းတို့ကို ပြန်လည်နွေးထွေးစေပါသည်။ ထိန်းချုပ်ခုံမှ သို့မဟုတ် WordPress အတွင်းမှလည်း သင်လိုအပ်သလို ရှင်းလင်းနိုင်ပါသည်။
ဟို့စ်တင်တစ်ခုတည်းက ကျွန်ုပ်အတွက် ပြီးပြည့်စုံသော Core Web Vitals ကို ပေးနိုင်ပါသလား။
၎င်းသည် သင့်အား အကောင်းဆုံးဖြစ်နိုင်သော TTFB ကို ပေးစွမ်းပြီး ယင်းသည် ဆာဗာ၏ ပံ့ပိုးမှုဖြစ်သလို Largest Contentful Paint အတွက် ကောင်းမွန်သော အစပြုမှုတစ်ခုလည်း ဖြစ်ပါသည်။ သို့သော် LCP၊ CLS နှင့် INP တို့ကို စာမျက်နှာကိုယ်တိုင်ကသာ အဓိကဆုံးဖြတ်ပါသည် — ပုံအရွယ်အစားများ၊ ပုံဖော်ခြင်းကို ဟန့်တားသော အရင်းအမြစ်များ၊ အခင်းအကျင်း တည်ငြိမ်မှုနှင့် အဓိက သရက်ဒ် JavaScript တို့ ဖြစ်ကြပါသည်။ ကျွန်ုပ်တို့၏ စနစ်အတွဲအစပ်သည် ဆာဗာ၏ လုပ်ဆောင်ချက်ကို လျင်မြန်ပြီး တည်ငြိမ်စေပါသည်၊ ဖရန့်အန်းဒ် ဒေတာပမာဏကို ပေါ့ပါးစွာ ထိန်းသိမ်းထားခြင်းက ကျန်ရှိသော ကွာဟချက်ကို ဖြည့်ဆည်းပေးခြင်း ဖြစ်ပါသည်။
ဆက်စပ်သော
၁၄ ရက်ကြာ အခမဲ့ စမ်းသပ်သုံးစွဲကြည့်ပါ
သင့်ပထမဆုံး ဝဘ်ဆိုက်များကို ၁၄ ရက်ကြာ အခမဲ့ စတင်လိုက်ပါ — ကတ်မလိုပါ။ ရှိပြီးသား ကွန်ရက်တစ်ခုကို ရွှေ့ပြောင်းမလား။ ကန့်သတ်ချက်မရှိဘဲ ရွှေ့ပြောင်းခြင်းများ အခမဲ့ဖြစ်သည်။
အခမဲ့ စတင်ပါ