နားလည်ထားရမယ့် အချက်
ဒီ lesson ကတော့ theory အသစ်မဟုတ်ပါဘူး — လက်တွေ့ လေ့ကျင့်ခန်းပါ။ Advanced chapter ရဲ့ CSR, SSR, SSG, hybrid rendering ကို marketing homepage, user dashboard, blog, live chat feature ဆိုတဲ့ page လေးခုမှာ အသုံးချကြည့်ဖို့ပါ။
ဆုံးဖြတ်ချက်တိုင်းဟာ မေးခွန်း လေးခုတည်းအပေါ် မူတည်ပါတယ် — ဖုံးကွယ်နေတဲ့ ပဉ္စမ factor မရှိပါဘူး၊ အဖြေတွေ ပေါင်းစပ်မှုကသာ strategy ကို ညွှန်ပြပေးတာပါ၊ တစ်ခုတည်းက မဟုတ်ပါဘူး။
- ဒီ page ကို search engine မှာ rank ကောင်းကောင်း ရအောင် လိုအပ်သလား (SEO)?
- Content ကို visitor တစ်ယောက်ချင်းစီအတွက် ကွဲပြားအောင် ပြရသလား (personalization)?
- Real-time data လိုအပ်သလား?
- Underlying content က ဘယ်လောက်ကြာကြာ ပြောင်းလဲသလဲ?
အနိုင်ရမယ့် strategy တစ်ခုတည်း မရှိပါဘူး
Dashboard တစ်ခုနဲ့ marketing page တစ်ခုဟာ application တစ်ခုတည်းထဲမှာ ရှိနေရင်တောင် rendering strategy မတူတာ နှစ်ခုကို ကျိုးကြောင်းညီညီ သုံးနိုင်ပါတယ် — requirement ကွဲပြားလို့သာ ဖြစ်ပြီး strategy တစ်ခုက ပိုကောင်းလို့ မဟုတ်ပါဘူး။
RENDERING STRATEGY LAB - ANSWER KEY
-----------------------------------
Marketing homepage (SEO, stable content) --> SSG
User dashboard (per-user, private data) --> SSR
Blog (SEO, updates often) --> Hybrid (SSG + ISR)
Live chat (needs realtime data) --> CSR + live connectionလက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
ဒီနေရာမှာ page တစ်ခုချင်းစီကို ဘယ်လို ဆင်ခြင်နိုင်လဲဆိုတာ worked answer key တစ်ခုအနေနဲ့ ပြထားပါတယ် — ကိုယ့် note တွေနဲ့ နှိုင်းယှဉ်ကြည့်ပါ၊ ကူးရေးရုံပဲ မလုပ်ပါနဲ့။
| Page | အကြံပြု strategy & အကြောင်းပြချက် |
|---|---|
| Marketing homepage | SSG — public ဖြစ်ပြီး SEO အရေးကြီးပြီး content ကလည်း build time မှာ တစ်ခါတည်း pre-render လုပ်နိုင်လောက်အောင် တည်ငြိမ်ပါတယ်။ |
| User dashboard | SSR (သို့) auth နောက်ကွယ်က CSR — content ကို visitor တစ်ယောက်ချင်းစီအတွက် personalize လုပ်ရလို့ အားလုံးအတွက် တစ်ခါတည်း pre-build လုပ်လို့ မရပါဘူး။ |
| Blog | Hybrid (SSG + schedule/on-demand revalidation) — SEO လိုအပ်ပေမယ့် post အသစ်တွေက မကြာခဏ ထွက်နေလို့ တစ်ခါတည်း build လုပ်ထားရင် data အဟောင်း ဖြစ်သွားနိုင်ပါတယ်။ |
| Live chat | CSR + persistent live connection (SSR/SSG page shell ထဲမှာ ရှိနေတတ်) — pre-rendering approach ဘယ်ဟာမှ live feed ကို up-to-date ဖြစ်နေအောင် ထိန်းမထားနိုင်ပါဘူး။ |
ပုံစံကို သတိပြုကြည့်ပါ — real-time data ရှိရင် အမြဲအရင်ဆုံး အနိုင်ရပါတယ်၊ ပြီးရင် personalization ရှိရင် static generation ကို ဖယ်ချပါတယ်၊ ဒီနှစ်ခုလုံး မရှိတဲ့ page တွေအတွက်သာ SEO နဲ့ update frequency ကို ချိန်ဆပြီး SSG နဲ့ hybrid ကြား ရွေးရပါတယ်။
အတူတူ စမ်းရေးကြည့်မယ်
function recommendRenderingStrategy(page) {
const { name, needsSEO, changesPerUser, needsRealtimeData, updateFrequency } = page;
if (needsRealtimeData) {
return {
name,
strategy: "CSR (or hybrid shell + live connection)",
reason: "Needs live, second-by-second data that no pre-rendered page can stay fresh for."
};
}
if (changesPerUser) {
return {
name,
strategy: "SSR (or CSR behind auth)",
reason: "Content is personalized per visitor, so it cannot be pre-built once for everyone."
};
}
if (needsSEO && updateFrequency === "rarely") {
return {
name,
strategy: "SSG",
reason: "Public and SEO-sensitive, but stable enough to pre-render at build time."
};
}
if (needsSEO && updateFrequency !== "rarely") {
return {
name,
strategy: "Hybrid (SSG + incremental revalidation) or SSR",
reason: "Needs SEO, but content changes too often for a one-time build to stay accurate."
};
}
return {
name,
strategy: "CSR",
reason: "No SEO requirement and nothing personalized, so client-side rendering is simplest."
};
}
const pages = [
{
name: "Marketing homepage",
needsSEO: true,
changesPerUser: false,
needsRealtimeData: false,
updateFrequency: "rarely"
},
{
name: "User dashboard",
needsSEO: false,
changesPerUser: true,
needsRealtimeData: false,
updateFrequency: "often"
},
{
name: "Blog",
needsSEO: true,
changesPerUser: false,
needsRealtimeData: false,
updateFrequency: "occasionally"
},
{
name: "Live chat",
needsSEO: false,
changesPerUser: true,
needsRealtimeData: true,
updateFrequency: "constantly"
}
];
for (const page of pages) {
const result = recommendRenderingStrategy(page);
console.log(`${result.name} -> ${result.strategy}\n reason: ${result.reason}`);
}Marketing homepage -> SSG
အကြောင်းပြချက်: Public ဖြစ်ပြီး SEO အရေးကြီးပေမယ့် build time မှာ pre-render လုပ်နိုင်လောက်အောင် တည်ငြိမ်ပါတယ်။
User dashboard -> SSR (or CSR behind auth)
အကြောင်းပြချက်: Content ကို visitor တစ်ယောက်ချင်းစီအတွက် personalize လုပ်ရလို့ အားလုံးအတွက် တစ်ခါတည်း pre-build လုပ်လို့ မရပါဘူး။
Blog -> Hybrid (SSG + incremental revalidation) or SSR
အကြောင်းပြချက်: SEO လိုအပ်ပေမယ့် content က တစ်ခါတည်း build လုပ်ထားရင် data တိကျအောင် ထိန်းထားနိုင်ဖို့ မကြာခဏလွန်း ပြောင်းလဲနေပါတယ်။
Live chat -> CSR (or hybrid shell + live connection)
အကြောင်းပြချက်: Pre-render လုပ်ထားတဲ့ page ဘယ်ဟာမှ fresh မနေနိုင်လောက်အောင် second-by-second data ရှင်သန်နေတာကို လိုအပ်ပါတယ်။၅ မိနစ် စမ်းကြည့်
Practical အပိုင်းက worked answer key ကို မဖတ်ခင် ဒီ page လေးခုစီအတွက် CSR၊ SSR၊ SSG၊ hybrid approach ထဲက ဘယ်ဟာအကိုက်ညီဆုံးလဲဆိုတာ ကိုယ်တိုင် ဆုံးဖြတ်ပြီး အကြောင်းပြချက်ကို ချရေးထားပါ —
၁။ Small business အတွက် marketing homepage တစ်ခု — page အနည်းငယ်ပဲ ရှိပြီး ရှားရှားပါးပါး ပြောင်းလဲတယ်။
၂။ Login screen နောက်ကွယ်က user dashboard တစ်ခု — visitor တစ်ယောက်ချင်းစီရဲ့ personalize လုပ်ထားတဲ့ data ကို ပြပေးတယ်။
၃။ Public archive ပါတဲ့ blog တစ်ခု — post အသစ်တွေကို အပတ်စဉ် (သို့) နှစ်ပတ်တစ်ခါလောက် ထုတ်ပေးတယ်။
၄။ Message ပို့လိုက်တာနဲ့ ချက်ချင်း ပေါ်ရမယ့် live chat feature တစ်ခု။
Page တစ်ခုချင်းစီအတွက် မေးခွန်း လေးခုတည်းကို ဆင်ခြင်ပါ — search engine မှာ rank လိုသလား၊ content ကို visitor အလိုက် ကွဲပြားအောင် ပြရသလား၊ real-time data လိုအပ်သလား၊ content က ဘယ်လောက်ကြာကြာ ပြောင်းလဲသလဲ။ လေးခုစလုံးအတွက် ကိုယ်ပိုင်အဖြေနဲ့ အကြောင်းပြချက်ကို ချရေးပြီးမှသာ practical အပိုင်းက answer key ကို စစ်ကြည့်ပါ။
သတိလေးတစ်ချက်
Page ရဲ့ SEO၊ personalization၊ freshness လိုအပ်ချက်အစစ်နဲ့ တွဲစဉ်းစားမယ့်အစား လူကြိုက်များနေလို့ rendering strategy ရွေးမိတာ။
Application တစ်ခုလုံးမှာ rendering strategy တစ်ခုတည်း သုံးရမယ်လို့ ထင်တာ — တကယ်တော့ page တစ်ခုချင်းစီအလိုက် CSR/SSR/SSG/hybrid ရောစပ်သုံးတာက ပုံမှန်ဖြစ်ပြီး ပိုသင့်တော်လေ့ ရှိပါတယ်။
web.dev -- Rendering on the Web — How the Web Works