Skip to content
GitHub

How Browsers Show Pages & Reducing Delays

Code မှ Webpage အဖြစ်သို့ ပြောင်းလဲပုံ (The Critical Rendering Path)

Section titled “Code မှ Webpage အဖြစ်သို့ ပြောင်းလဲပုံ (The Critical Rendering Path)”

Browser တစ်ခုဟာ ကိုယ်ရေးထားတဲ့ Code တွေကို မျက်စိနဲ့ မြင်ရတဲ့ Website တစ်ခု ဖြစ်လာအောင် အောက်ပါ အဆင့် ၇ ဆင့်နဲ့ အလုပ်လုပ်ပါတယ်။

  1. HTML မှ DOM Tree သို့: Browser က အရင်ဆုံး HTML Code တွေကို ဖတ်ပြီး၊ Website ပေါ်မှာ ပါဝင်မယ့် အစိတ်အပိုင်း အားလုံး (Elements) ရဲ့ အကြမ်းဖျင်း မြေပုံကြမ်း (Document Object Model - DOM) ကြီး တစ်ခုကို တည်ဆောက်ပါတယ်။
  2. CSS မှ CSSOM Tree သို့: ပြီးရင် CSS Code (Stylesheets တွေရော၊ Inline Styles တွေရော) ကို ဖတ်ပြီး၊ အဲ့ဒီ Element တစ်ခုချင်းစီ ဘယ်လို ပုံပန်းသဏ္ဌာန် ရှိရမလဲ ဆိုတဲ့ ဒီဇိုင်းမြေပုံ (CSS Object Model - CSSOM) ကို ထပ်မံ တည်ဆောက်ပါတယ်။
  3. JavaScript အလုပ်လုပ်ခြင်း: JavaScript က HTML (DOM) ကိုရော၊ CSS (CSSOM) ကိုပါ ဝင်ရောက် ပြောင်းလဲနိုင်စွမ်း ရှိပါတယ်။ ဒါကြောင့် JavaScript တွေကို သေချာ စနစ်တကျ မခေါ်ယူဘူး (Load မလုပ်ဘူး) ဆိုရင်၊ သူက အပေါ်က HTML တွေ ဖတ်နေတဲ့ လုပ်ငန်းစဉ်ကြီး တစ်ခုလုံးကို ဝင်ရောက် ပိတ်ဆို့ပြီး ခေတ္တ ရပ်တန့် (Block) သွားစေနိုင်ပါတယ်။
  4. Render Tree တည်ဆောက်ခြင်း: Browser က ဖန်တီးထားတဲ့ DOM (မြေပုံကြမ်း) နဲ့ CSSOM (ဒီဇိုင်းမြေပုံ) နှစ်ခုကို ပေါင်းစပ်ပြီး၊ မျက်နှာပြင်ပေါ်မှာ တကယ် ပေါ်လာမယ့် အရာတွေနဲ့ သူတို့ရဲ့ သက်ဆိုင်ရာ Styles တွေချည်း သီးသန့် ပါဝင်တဲ့ Render Tree ကြီးကို နောက်ဆုံး ဖန်တီးပါတယ်။ (မှတ်ချက် - display: none; ပေးထားတဲ့ အရာတွေက ဒီ Render Tree ထဲမှာ မပါတော့ပါဘူး)။
  5. Layout (သို့မဟုတ် Reflow): Browser က Render Tree ထဲမှာ ပါတဲ့ Element တစ်ခုချင်းစီရဲ့ တိကျတဲ့ အရွယ်အစား (Width/Height) နဲ့ နေရာ (Position) ကို တွက်ချက်ပါတယ်။ (ဥပမာ - ဒီ Box က အကျယ် 300px ရှိမယ်၊ အပေါ်ကနေ 50px အကွာမှာ နေမယ် စသဖြင့် တွက်ချက်တာပါ)။
  6. Paint: Browser က Element တစ်ခုချင်းစီအတွက် အရောင်တွေ၊ အရိပ်တွေ (Pixels) ကို Screen ပေါ်မှာ အလွှာ (Layers) လေးတွေ အဖြစ် စတင် ရေးဆွဲပါတယ်။
  7. Composite: နောက်ဆုံးမှာတော့ Browser က ဆွဲပြီးသား Layers တွေ အားလုံးကို ထပ်တူ ပေါင်းစပ်ပြီး (Composite) နောက်ဆုံး ပေါ်လာမယ့် စာမျက်နှာကို Screen ပေါ်မှာ အပြည့်အဝ ပြသပေးလိုက်ပါတယ်။
browser rendering process

Render-Blocking Resource များကို ရှာဖွေခြင်းနှင့် လျှော့ချခြင်း

Section titled “Render-Blocking Resource များကို ရှာဖွေခြင်းနှင့် လျှော့ချခြင်း”
  • Render-blocking Resources ဆိုတာ Browser ရဲ့ အပေါ်က Rendering လုပ်ငန်းစဉ် အဆင့်ဆင့်ကို ဝင်ရောက် ပိတ်ဆို့ပြီး နှောင့်နှေးသွားစေတဲ့ အရာတွေကို ခေါ်တာပါ။
    • <head> ထဲမှာ ထည့်သွင်းထားတဲ့ ပြင်ပ CSS ဖိုင်များ (<link rel="stylesheet" href="...">) ဟာ ပုံမှန်အားဖြင့် Render-blocking ဖြစ်ပါတယ်။ (ဆိုလိုတာက Browser ဟာ ဒီ CSS ဖိုင်တွေကို အရင်ဆုံး Download ဆွဲ၊ အကုန် ဖတ်ပြီးမှသာ ကျန်တဲ့ အလုပ်တွေကို ဆက်လုပ်လို့ပါ)။
    • <head> ထဲမှာ async ဒါမှမဟုတ် defer မပါဘဲ ထည့်ထားတဲ့ ပြင်ပ JavaScript ဖိုင်များ (<script src="...">) ကလည်း Render-blocking အကြီးအကျယ် ဖြစ်စေပါတယ်။
    • ဒီလို ပိတ်ဆို့ ကြန့်ကြာမှုတွေက FCP (တစ်ခုခု စပေါ်တဲ့အချိန်)၊ LCP (အဓိက အရာ ပေါ်လာတဲ့အချိန်) နဲ့ Page လုံးဝ ပွင့်လာတဲ့ အချိန် (Load Time) တွေကို သိသိသာသာ နှေးကွေးသွားစေပါတယ်။

ဖြေရှင်းရန် အဓိက နည်းလမ်းများ (Quick Recap):

  • JavaScript အတွက်:
    • async ဒါမှမဟုတ် defer Attributes တွေကို အသုံးပြုပါ။
    • ချက်ချင်း မလိုအပ်တဲ့ Scripts တွေကို <body> ရဲ့ အဆုံး (အောက်ဆုံး) ကို ရွှေ့ပါ။
    • အလွန် သေးငယ်ပြီး ချက်ချင်း အရေးကြီးတဲ့ Scripts လေးတွေကိုတော့ ဖိုင်ခွဲမနေဘဲ HTML ထဲမှာ (Inline) တိုက်ရိုက် ထည့်ရေးပါ။ (သတိထားပြီး သုံးပါ)။
  • CSS အတွက်:
    • Critical CSS (အပေါ်ဆုံး မြင်ကွင်းအတွက် လိုအပ်တဲ့ CSS) ကို HTML ထဲမှာ (Inline) တိုက်ရိုက် ထည့်ရေးပါ။
    • သိပ်အရေးမကြီးတဲ့ CSS တွေကို Asynchronously Load လုပ်ပါ။
    • CSS ဖိုင်အရွယ်အစား (Size) ကို တတ်နိုင်သမျှ သေးငယ်အောင် လျှော့ချပါ။

Browser ကို ကြိုတင် အချက်ပြခြင်း (Resource Hints)

Section titled “Browser ကို ကြိုတင် အချက်ပြခြင်း (Resource Hints)”

HTML ရဲ့ <head> ထဲက <link rel="..."> Tags တွေမှာ အောက်ပါ Attributes တွေကို ထည့်သွင်းခြင်းအားဖြင့်၊ Browser ကို “ဒီဖိုင်တွေကတော့ နောက်ကျရင် လိုအပ်လာလိမ့်မယ်နော်” လို့ ကြိုတင် အချက်ပြ ညွှန်ကြား (Hint ပေး) လို့ ရပါတယ်။ ဒီလို လုပ်တာက Browser ကို အလုပ်တွေ ပိုမြန်မြန်ဆန်ဆန်နဲ့ ကြိုတင် ပြင်ဆင်နိုင်အောင် ကူညီပေးပါတယ်။

  • <link rel="dns-prefetch" href="//example.com">
  • မကြာခင်မှာ ဖိုင်တွေ လှမ်းတောင်းဖို့ လိုအပ်လာနိုင်တဲ့ တခြား Website (Domain) တစ်ခုအတွက် DNS Lookup (IP Address ရှာဖွေခြင်း) ကို အခုကတည်းက ကြိုလုပ်ထားဖို့ Browser ကို ပြောတာပါ။ (ဖုန်းမဆက်ခင် ဖုန်းနံပါတ် စာအုပ်ထဲ ကြိုရှာထားခိုင်းသလိုပါပဲ)။
  • <link rel="preconnect" href="https://example.com">
  • dns-prefetch ထက် ပိုသွားပါတယ်။ DNS Lookup လုပ်ရုံတင်မကဘဲ၊ သတ်မှတ်ထားတဲ့ Domain ဆီကို TCP Handshake နဲ့ TLS Negotiation (Security) အပါအဝင် Connection အစအဆုံးကို ကြိုတင် တည်ဆောက်ထားခိုင်းတာပါ။
  • ချက်ချင်း အသုံးပြုရမယ့် အလွန် အရေးကြီးတဲ့ Third-party Services (ဥပမာ - Google Fonts လိုမျိုး) တွေအတွက်သာ သုံးပါ။ (မလိုအပ်ဘဲ အများကြီး သုံးရင်၊ တကယ် အရေးကြီးတဲ့ တခြား ဖိုင်တွေ Download ဆွဲတာကိုပါ လာပြီး နှေးသွားစေနိုင်လို့ပါ)။
  • <link rel="preload" href="/critical-script.js" as="script">
  • <link rel="preload" href="/main-image.webp" as="image">
  • “ဒီဖိုင်က လက်ရှိ စာမျက်နှာအတွက် အရမ်းကို အရေးကြီးတယ်၊ ဒါကြောင့် သူ့ကို ဦးစားပေး အမြင့်ဆုံးနဲ့ အခုချက်ချင်း Download ဆွဲပါ” လို့ Browser ကို အတိအလင်း အမိန့်ပေး ညွှန်ကြားတာပါ။ as Attribute က ဘယ်လို ဖိုင်အမျိုးအစားလဲ ဆိုတာကို ပြောပြတာပါ။
  • LCP ပုံတွေ၊ အရေးကြီးတဲ့ Fonts တွေ၊ အဓိက Scripts တွေလိုမျိုး မြန်မြန် လိုအပ်တဲ့ Resources တွေအတွက် အသုံးပြုပါတယ်။
  • သတိပြုရန်: အရာအားလုံးကို Preload လိုက်လုပ်နေရင်၊ Bandwidth တွေ လုကုန်ပြီး Performance ကို ပြောင်းပြန် ထိခိုက်စေပါတယ်။ တကယ်ကို အရေးကြီးဆုံးနဲ့ Browser က ချက်ချင်း မမြင်နိုင်တဲ့ (Hidden) အရာတွေ အတွက်သာ ရွေးချယ် အသုံးပြုပါ။
  • <link rel="prefetch" href="/next-page-styles.css" as="style">
  • နောက်လာမယ့် စာမျက်နှာ (ဥပမာ - User က နောက်ထပ် Page တစ်ခုကို သွားဖို့ သေချာသလောက် ရှိနေရင်) အတွက် လိုအပ်လာမယ့် Resource တစ်ခုကို အနိမ့်ဆုံး ဦးစားပေး (Low Priority) အဖြစ် အချက်ပြတာပါ။
  • Browser က လက်ရှိ အလုပ်တွေ အားလုံးပြီးလို့ အားလပ်ချိန် (Idle Time) ရမှသာ အဲ့ဒီဖိုင်ကို Download လုပ်သွားမှာ ဖြစ်ပါတယ်။