Modern Rendering Architectures

အကောင်းဆုံး နှစ်ခုကို ပေါင်းစပ်ခြင်း

အရင် သင်ခန်းစာတွေမှာ Server-Side Rendering (SSR) က ပထမဆုံး Load ဖြစ်ချိန် (FCP/LCP) မြန်တာ၊ Client-Side Rendering (CSR) က Load ဖြစ်ပြီးရင် Interactivity (အသွားအလာ) မြန်တာ စတဲ့ ကိုယ်ပိုင် အားသာချက်၊ အားနည်းချက်တွေ အကြောင်းကို လေ့လာခဲ့ပါတယ်။ ယနေ့ခေတ် နည်းပညာ အသစ်တွေကတော့ ဒီနှစ်ခုလုံးရဲ့ အားသာချက်တွေကို ပေါင်းစပ်ပြီး အားနည်းချက် ကင်းကင်းနဲ့ ရရှိနိုင်ဖို့ ကြိုးစားလာကြပါတယ်။

Islands Architecture (ကျွန်းစုများ တည်ဆောက်ပုံ)

ဘာလဲ? ဒါက Webpage တွေကို တည်ဆောက်တဲ့ ခေတ်မီ နည်းလမ်း တစ်ခုပါ။ ပုံသေ (Static) ဖြစ်ပြီး အပြန်အလှန် တုံ့ပြန်မှု မရှိတဲ့ အကြောင်းအရာတွေ (ဥပမာ - စာသားတွေ၊ ရိုးရိုး ပုံတွေ) ကို Server ကနေ သီးသန့် HTML အဖြစ် ချက်ချင်း ပို့လွှတ်ပါတယ်။ ဒါပေမဲ့ အပြန်အလှန် တုံ့ပြန်နိုင်တဲ့ အစိတ်အပိုင်းလေးတွေ (Interactive Components) (ဥပမာ - ရုပ်ပုံ အကူးအပြောင်း Carousel၊ Search Widget၊ နှိပ်လို့ရတဲ့ Buttons တွေ) ကိုတော့ သီးခြား “ကျွန်း” (Islands) လေးတွေ အဖြစ် သဘောထားပြီး၊ သူတို့လေးတွေ အတွက်သာ JavaScript ကို သီးသန့် ခွဲထုတ် အသုံးပြုတာပါ။ (Astro Framework က ဒီစနစ်ကို အဓိက အသုံးပြုပါတယ်)။
ဘာကြောင့် မြန်တာလဲ? စာမျက်နှာရဲ့ အစိတ်အပိုင်း အများစုက JavaScript လုံးဝ မလိုအပ်တဲ့၊ ချက်ချင်း Load ဖြစ်တဲ့ Static HTML တွေ ဖြစ်နေလို့ပါ။ Browser အနေနဲ့ Page ကြီး တစ်ခုလုံးကို JavaScript တွေနဲ့ လိုက်အသက်သွင်း (Hydrate) နေစရာ မလိုတော့ဘဲ၊ အဲ့ဒီ ကျွန်းလေးတွေကိုပဲ ရွေးပြီး “Hydrate” လုပ်ပေးရုံပါပဲ。 ဒါကြောင့် စစချင်း Load လုပ်ရမယ့် JavaScript ပမာဏ သိသိသာသာ နည်းသွားပြီး၊ Time to Interactive (TTI) ကို အလွန် မြန်ဆန်လာစေပါတယ်။
ဥပမာ နှိုင်းယှဉ်ချက်: စက္ကူ ကတ်ထူပြားနဲ့ လုပ်ထားတဲ့ မြေပုံကြီး တစ်ခုကို မြင်ယောင်ကြည့်ပါ။ မြေပုံရဲ့ အစိတ်အပိုင်း အများစုက ကြည့်ဖို့ သက်သက်ပါပဲ။ ဒါပေမဲ့ အဲ့ဒီ မြေပုံပေါ်မှာ မီးလင်းတဲ့၊ အသံထွက်တဲ့ ခလုတ် အနည်းငယ် (“ကျွန်း” တွေ) ပါဝင်ပါတယ်။ သင်က မြေပုံ တစ်ခုလုံးကို လျှပ်စစ် ပါဝါ ပေးစရာ မလိုဘဲ၊ တကယ် အလုပ်လုပ်တဲ့ ခလုတ်လေးတွေ အတွက်သာ ဘက်ထရီ အသေးလေးတွေ တပ်ဆင် ပေးလိုက်သလိုပါပဲ။

Partial Hydration (တစ်စိတ်တစ်ပိုင်း အသက်သွင်းခြင်း)

ဘာလဲ? ဒါက Islands Architecture နဲ့ နီးနီးစပ်စပ် တူတဲ့ သဘောတရား တစ်ခုပါ။ Application တစ်ခုလုံးကို တစ်ပြိုင်နက်တည်း “Hydrate” (JS နဲ့ အသက်သွင်းတာ) မလုပ်တော့ဘဲ၊ Partial Hydration က မတူညီတဲ့ Components တွေကို အချိန်မတူဘဲ၊ ဒါမှမဟုတ် လိုအပ်မှသာ (ဥပမာ - မြင်ကွင်းထဲ ရောက်လာမှသာ) Interactive ဖြစ်အောင် လုပ်ဆောင်ပေးပါတယ်။
ဥပမာ: Webpage တစ်ခုရဲ့ အပေါ်ဆုံးက Header (Menu) က ချက်ချင်း Interactive ဖြစ်သွားနိုင်ပေမဲ့၊ စာမျက်နှာ အောက်ခြေက ရှုပ်ထွေးတဲ့ Comment Section ကိုတော့ User က အောက်ကို Scroll ဆွဲချပြီး အဲ့ဒီနေရာ ရောက်မှသာ (Lazy Load) သူ့ရဲ့ JavaScript ကို Load လုပ်ပြီး Interactive ဖြစ်အောင် အသက်သွင်းပေးတာမျိုးပါ။
ဘာကြောင့် မြန်တာလဲ? ဒါက Browser လုပ်ရမယ့် အလုပ်တွေကို အချိန်ခွဲဝေ ပေးလိုက်ပြီး အရေးအကြီးဆုံး (အပေါ်ဆုံး) အစိတ်အပိုင်းတွေကို အရင်ဆုံး တုံ့ပြန်မှု ကောင်းအောင် ဦးစားပေးလိုက်တာကြောင့် ဖြစ်ပါတယ်။

Edge Computing နှင့် Edge Functions

ဘာလဲ? ဒါက Server-side မှာ လုပ်ရမယ့် အလုပ်တချို့ကို ပင်မ Server အကြီးကြီး (Origin Server) တစ်ခုတည်းကနေ ဒိုင်ခံ မလုပ်တော့ဘဲ၊ “Edge” (အစွန်း) လို့ ခေါ်တဲ့၊ User နဲ့ ပထဝီဝင် အရ အနီးဆုံး နေရာမှာ ရှိနေတဲ့ CDN Servers လေးတွေဆီ ရွှေ့ပြောင်း လုပ်ဆောင်စေတာပါ။
ဘယ်လို အလုပ်လုပ်လဲ? CDN ရဲ့ Edge Servers တွေက အရင်ကလို ရိုးရိုး Static ဖိုင်တွေကို Cache လုပ်ထားရုံ သာမကဘဲ၊ Backend Code အသေးစားလေးတွေ (Edge Functions) ကိုပါ ကိုယ်တိုင် Run နိုင်လာပါတယ်။ သူတို့က Content ကို User ရဲ့ နိုင်ငံ/ဘာသာစကား အလိုက် ပြောင်းလဲပေးတာ (Personalize Content)၊ A/B Testing လုပ်တာ၊ ဒါမှမဟုတ် သင့် Original Server ဆီ Request မရောက်ခင်မှာ Database ကနေ Data အမြန် ဆွဲထုတ်ပေးတာမျိုးတွေ လုပ်ဆောင်နိုင်ပါတယ်။ (Vercel Edge Functions, Cloudflare Workers တို့ဟာ နာမည်ကြီး ဥပမာတွေပါ)။
ဘာကြောင့် မြန်တာလဲ? ဒါက Dynamic Content တွေအတွက်ပါ User နဲ့ Server ကြား အပြန်အလှန် သွားရတဲ့ အချိန် (Round-trip Time) ကို သိသိသာသာ လျှော့ချပေးနိုင်ပြီး၊ User အလိုက် ပြောင်းလဲနေတဲ့ (Personalized) Pages တွေအတွက်တောင် Time To First Byte (TTFB) ကို အလွန် မြန်ဆန်သွားစေပါတယ်။
ဥပမာ နှိုင်းယှဉ်ချက်: ယနေ့ ပရိုမိုးရှင်း (Promotion) ကို သိဖို့ နိုင်ငံခြားက Pizza ရုံးချုပ်ကြီး (Origin Server) ဆီ လှမ်းပြီး ဖုန်းဆက် မေးမြန်းနေမယ့်အစား၊ ကိုယ့်မြို့ထိပ်က Pizza ဆိုင်ခွဲလေး (Edge Server) ကပဲ ပရိုမိုးရှင်း အကြောင်း ချက်ချင်း တိုက်ရိုက် ပြောပြပြီး၊ အော်ဒါ (Order) ပါ တစ်ခါတည်း လက်ခံလိုက်သလိုပါပဲ။