CSR၊ SSR နှင့် SSG

နားလည်ထားရမယ့် အချက်

ဘရောက်ဇာတစ်ခုက ဘာမှမပြခင် web page တိုင်းမှာ HTML ရှိဖို့ လိုအပ်ပါတယ်။ CSR၊ SSR နှင့် SSG နောက်ကွယ်က design မေးခွန်းအစစ်က ပြောရတာ ရိုးရှင်းပေမယ့် အကျိုးသက်ရောက်မှု အစစ်အမှန်ရှိပါတယ် — ဒီ HTML ကို ဘယ်နေရာမှာ၊ ဘယ်အချိန်မှာ တကယ် ဖန်တီးလဲ ဆိုတာပါပဲ။

JavaScript run ပြီးနောက် browser ထဲမှာ ဆောက်လား၊ request တစ်ခုချင်းစီအတွက် server ပေါ်မှာ ဆောက်လား၊ ဒါမှမဟုတ် build step တစ်ခုအတွင်း ကြိုတင်ပြီး တစ်ကြိမ်တည်း ဆောက်ထားလား ဆိုတာပေါ်မူတည်ပြီး အဖြေတစ်ခုစီက rendering strategy မတူညီတာတွေကို ဖန်တီးပေးပါတယ်၊ တစ်ခုစီမှာ သူ့အားသာချက် ကိုယ်ပိုင်ရှိကြပါတယ်။

Client-Side Rendering (CSR) က browser ကို HTML shell အလွတ်နီးပါး တစ်ခုနဲ့ JavaScript file တွေကို ပို့ပေးပါတယ်။ Browser က ဒီ JavaScript ကို download လုပ်ပြီး run လုပ်ကာ လိုအပ်တဲ့ data တွေကို fetch လုပ်ပြီးမှ မြင်ရတဲ့ page ကို client ဘက်မှာပဲ အပြည့်အဝ ဆောက်ပေးပါတယ်။

CSR က interactive interface တွေအတွက် အထူးသင့်တော်ပါတယ် — app တစ်ခါ load ဖြစ်သွားရင် view တစ်ခုကနေတစ်ခု ပြောင်းတာ page အပြည့် reload မလုပ်ဘဲ ချက်ချင်းလို ခံစားရနိုင်ပါတယ်။ ဒါပေမယ့် initial load မှာ လုပ်စရာ ပိုများတယ်၊ page က JavaScript အောင်မြင်စွာ run ဖို့ မှီခိုနေရတယ်၊ ပြီးတော့ search engine တွေ ဒါမှမဟုတ် စက်နှေးတွေအတွက် ပြီးစီးတဲ့ content ကို မြင်ဖို့ အထူးဂရုစိုက်ရနိုင်ပါတယ်။

Server-Side Rendering (SSR) ကတော့ အစီအစဉ် ပြောင်းပြန်ပါတယ် — server က request တစ်ခုချင်းစီအတွက် HTML အစစ်ကို ဆောက်ပြီး ပြသရန် အသင့်ဖြစ်နေတဲ့ page ကို browser ဆီ ပို့ပေးပါတယ်၊ ပြီးရင် JavaScript က interactivity ကို ပူးတွဲပေးဖို့ hydrate လုပ်နိုင်ပါတယ်။

SSR က ပထမဆုံး load မှာ content ကို ပိုမြန်စွာ ပြသနိုင်ပြီး request တစ်ခုချင်းစီအလိုက် dynamic data ကို ချက်ချင်း ထင်ဟပ်ပြနိုင်ပါတယ်၊ ဒါပေမယ့် request တစ်ခုချင်းစီအတွက် server အလုပ် ပိုများလာပြီး caching complexity အနည်းငယ် တိုးလာနိုင်ပါတယ်။

Static Site Generation (SSG) က HTML ကို build step တစ်ခုအတွင်း ကြိုတင်ပြီး တစ်ကြိမ်တည်း ဖန်တီးပြီးမှ ဒီ static file တွေကို CDN ကနေ ပေးပို့ပါတယ်။ documentation၊ blog နဲ့ marketing page တွေလို visitor တစ်ဦးချင်းစီအလိုက် မပြောင်းတဲ့ content အတွက် သင့်တော်ပါတယ်၊ ဒါပေမယ့် dynamic behavior ကို browser ထဲမှာ ထပ်ပိုပြီး layer တင်ထားနိုင်တုန်းပါပဲ။

CSR

Client-Side Rendering — app load ပြီးနောက် browser က JavaScript ကို download လုပ်ပြီး client ဘက်မှာ မြင်ရသော page ကို ဆောက်ခြင်း။

SSR

Server-Side Rendering — server က request တစ်ခုချင်းစီအတွက် HTML ကို ဆောက်ပြီး ပြသရန်အသင့် page ကို browser ဆီ ပို့ခြင်း။

SSG

Static Site Generation — HTML ကို build step အတွင်း ကြိုတင်ပြီး တစ်ကြိမ်တည်း ဖန်တီးကာ static file အနေနဲ့ serve လုပ်ခြင်း။

CSR, SSR, AND SSG: WHERE HTML IS BUILT
--------------------------------------
CSR, SSR, AND SSG: WHERE HTML IS BUILT
---------------------------------------
CSR (Client-Side Rendering)
  Browser gets shell + JS files
       |
       v
  JavaScript runs in browser
       |
       v
  Browser fetches data
       |
       v
  UI rendered on the client

SSR (Server-Side Rendering)
  Browser sends request
       |
       v
  Server renders HTML per request
       |
       v
  HTML response sent to browser
       |
       v
  JavaScript may hydrate the page

SSG (Static Site Generation)
  Build time: HTML generated once
       |
       v
  Static files pushed to a CDN
       |
       v
  User requests the page
       |
       v
  CDN serves the pre-built HTML

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Rendering strategy ရွေးချယ်တာကို အဆောက်အအုံတစ်ခုအတွက် foundation ရွေးချယ်သလိုပဲ စဉ်းစားပါ။ ဘယ် technology က trend ဖြစ်နေလဲဆိုတာ မဟုတ်ဘဲ page က တကယ် ဘာလိုအပ်လဲဆိုတာကို အရင်မေးပါ။

• ဒီ page က ထုတ်ဝေတာနဲ့ တပြိုင်နက် search result တွေမှာ ရာထူးကောင်းကောင်း ရဖို့ လိုသလား၊ ဒါမှမဟုတ် crawler လုံးဝ မဝင်ရောက်တဲ့ login နောက်ကွယ်မှာ ရှိသလား။
• ဒါက data ကို စက္ကန့်တိုင်း ပြောင်းလဲသလား၊ တစ်ရက်တစ်ခါ ပြောင်းလဲသလား၊ ဒါမှမဟုတ် ထုတ်ဝေပြီးနောက် လုံးဝ မပြောင်းလဲဘူးလား။
• visitor တိုင်းက content တူတူ မြင်ရသလား၊ ဒါမှမဟုတ် user တစ်ဦးချင်းစီအလိုက် personalize လုပ်ထားသလား။

ရှားရှားပါးပါး ပြောင်းလဲတတ်တဲ့ marketing homepage တစ်ခုဟာ SSG အတွက် ရွေးစရာကောင်းတစ်ခု ဖြစ်ပါတယ် — တစ်ကြိမ်တည်း build လုပ်ပြီး CDN ကနေ serve လုပ်လိုက်ရင် traffic များများနဲ့တောင် မြန်ဆန်နေဆဲဖြစ်ပါတယ်။

login ဝင်ထားတဲ့ user တစ်ဦးချင်းစီအတွက် live account data ပြသတဲ့ dashboard တစ်ခုက များသောအားဖြင့် SSR ဒါမှမဟုတ် CSR ဘက်ကို ယိမ်းပါတယ်၊ ဘာလို့လဲဆိုတော့ content က ဘယ်သူမေးနေလဲဆိုတာပေါ် မူတည်ပြီး fresh ဖြစ်နေဖို့ လိုအပ်လို့ပါ။

design editor ဒါမှမဟုတ် spreadsheet လို highly interactive tool တစ်ခုက CSR ဘက်ကို မကြာခဏ ယိမ်းပါတယ်၊ ဘာလို့လဲဆိုတော့ load ပြီးနောက်ပိုင်း interactivity က ပထမဆုံး paint ထက် ပိုအရေးကြီးလို့ပါ။

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

• CSR၊ SSR နှင့် SSG တို့သည် HTML ကို ဘယ်နေရာ ဘယ်အချိန်မှာ ဖန်တီးသနည်း ဆိုတဲ့ မေးခွန်းတစ်ခုတည်းကို မတူညီစွာ ဖြေဆိုကြသည်။
• CSR သည် load ပြီးနောက် interactivity ကို ဦးစားပေးပြီး၊ SSR သည် မြန်ဆန်လတ်ဆတ်သော ပထမဆုံး content ကို ဦးစားပေးကာ၊ SSG သည် မပြောင်းလဲသော content အတွက် မြန်ဆန်ပြီး ကုန်ကျစရိတ်သက်သာမှုကို ဦးစားပေးသည်။
• page တစ်ခုအတွက် မှန်ကန်သော strategy သည် တကယ့် requirement ပေါ်မူတည်သော အစပျိုးမှတ် ဆုံးဖြတ်ချက်တစ်ခုသာဖြစ်ပြီး သေချာသတ်မှတ်ထားသော စည်းမျဉ်း မဟုတ်ပါ။

အတူတူ စမ်းရေးကြည့်မယ်

function recommendRenderingStrategy({ needsSEO, needsRealtimeData, contentChangesPerUser, updateFrequency }) {
  const isFrequentlyDynamic =
    needsRealtimeData || updateFrequency === "seconds" || updateFrequency === "minutes";

  if (contentChangesPerUser || isFrequentlyDynamic) {
    // Content differs per visitor or changes very often: a build-time
    // snapshot can't capture it, so pick based on whether search engines
    // need to see the fully rendered content immediately.
    return needsSEO ? "SSR" : "CSR";
  }

  // Same content for every visitor, and it doesn't change constantly.
  return "SSG";
}

const pages = [
  {
    name: "Marketing homepage",
    needsSEO: true,
    needsRealtimeData: false,
    contentChangesPerUser: false,
    updateFrequency: "never",
  },
  {
    name: "Logged-in user dashboard",
    needsSEO: false,
    needsRealtimeData: true,
    contentChangesPerUser: true,
    updateFrequency: "seconds",
  },
  {
    name: "Live sports scores page",
    needsSEO: true,
    needsRealtimeData: true,
    contentChangesPerUser: false,
    updateFrequency: "seconds",
  },
];

for (const page of pages) {
  const recommendation = recommendRenderingStrategy(page);
  console.log(`${page.name}: ${recommendation} (starting point, not an absolute rule)`);
}

ဒါကို run လိုက်ရင် page တစ်ခုချင်းစီအတွက် အကြံပြုချက်ကို ပရင့်ထုတ်ပါတယ်: Marketing homepage -> SSG, Logged-in user dashboard -> CSR, Live sports scores page -> SSR — တစ်ခုစီကို absolute rule မဟုတ်ဘဲ အစပျိုးမှတ်တစ်ခုအဖြစ်သာ ခေါင်းစဉ်တပ်ထားပါတယ်။

web.dev — Rendering on the Web — How the Web Works