Browser Caching ကို အကျိုးရှိရှိအသုံးချခြင်း

💡 ရည်ရွယ်ချက်

Browser Caching ဆိုတာ ဘာလဲ၊ ဘယ်လို အလုပ်လုပ်သလဲ ဆိုတာကို နားလည်ပြီး၊ HTTP Headers တွေကနေတစ်ဆင့် Cache ကို ဘယ်လို ထိန်းချုပ်မလဲ ဆိုတာနဲ့၊ Cache Busting လို အခြေခံ နည်းလမ်းတွေကို သိရှိနားလည်စေရန် ဖြစ်ပါတယ်။

Browser Caching ဆိုတာဘာလဲ? (နောက်တစ်ခေါက် ပိုမြန်ဖို့ ဖိုင်တွေကို မှတ်ထားခြင်း)

• Browser တစ်ခုက Website တစ်ခုကို ဝင်ကြည့်တဲ့အခါ၊ အဲ့ဒီ Website မှာ ပါဝင်တဲ့ ပုံတွေ၊ CSS နဲ့ JavaScript လိုမျိုး ဖိုင်တချို့ရဲ့ မိတ္တူ (Copy) တွေကို အသုံးပြုသူ (User) ရဲ့ ကွန်ပျူတာ (သို့) ဖုန်းထဲမှာ ခေတ္တ သိမ်းဆည်းထားလေ့ ရှိပါတယ်။ ဒါကို “Caching” (ကြားခံ သိမ်းဆည်းခြင်း) လို့ ခေါ်ပါတယ်။
• နောက်တစ်ကြိမ် User က အဲ့ဒီ Page ကို ပြန်ဝင်ကြည့်တဲ့အခါ (ဒါမှမဟုတ် အဲ့ဒီဖိုင်တွေ အသုံးပြုထားတဲ့ တခြား Page တစ်ခုကို သွားကြည့်တဲ့အခါ)၊ Browser က အဝေးကြီးမှာ ရှိတဲ့ Server ဆီကနေ အစကနေ ပြန် Download မဆွဲတော့ဘဲ၊ သူ့ရဲ့ Local Cache (ဖုန်းထဲ) ကနေပဲ တိုက်ရိုက် ယူသုံးလိုက်ပါတယ်။ ဒါက Page ပွင့်တာကို အလွန် မြန်ဆန်သွားစေသလို Data သုံးစွဲမှုကိုလည်း အများကြီး သက်သာစေပါတယ်။
• ဥပမာ: သင်က စာကြည့်တိုက် တစ်ခုကနေ စာအုပ် တစ်အုပ်ကို သွားငှားတယ် ဆိုပါစို့။ ပထမ တစ်ခေါက်တော့ ပင်မ စာကြည့်တိုက် အထိ သွားရတာ အချိန်ယူရပါမယ်။ ဒါပေမဲ့ သင့်အိမ်အနီးက စာကြည့်တိုက်ခွဲလေး (Browser Cache) မှာ အဲ့ဒီစာအုပ်ရဲ့ မိတ္တူတစ်ခုကို ထားခွင့်ပေးလိုက်ရင်၊ နောက်တစ်ခေါက် အဲ့ဒီစာအုပ်ကို ထပ်ဖတ်ချင်တဲ့အခါ အနီးက စာကြည့်တိုက်ခွဲလေးဆီပဲ သွားလိုက်ရုံနဲ့ ချက်ချင်း ရနိုင်တာကြောင့် အများကြီး ပိုမြန်သွားသလိုမျိုးပါပဲ။

Browser ကို ဘာတွေ သိမ်းရမလဲ ပြောပြခြင်း (HTTP Caching Headers)

သင့် Web Server က ဖိုင်တွေကို Browser ဆီ ပို့ပေးတဲ့အခါ “HTTP Headers” ဆိုတဲ့ ညွှန်ကြားချက်တွေကိုပါ ပူးတွဲ ပို့ပေးလေ့ ရှိပါတယ်။ ဒီ Headers တွေထဲက တချို့က Browser ကို “ဒီဖိုင်တွေကို ဘယ်လို Cache လုပ်ရမလဲ (ဘယ်လောက်ကြာကြာ သိမ်းထားရမလဲ)” ဆိုတာကို လမ်းညွှန်ပေးပါတယ်။

• Cache-Control: ယနေ့ခေတ်မှာ အရေးအကြီးဆုံးနဲ့ အသုံးအများဆုံး Caching Header ပါ။

  • public: ဒီဖိုင်ကို ဘယ် Browser တွေကမဆို၊ CDNs (ကြားခံ ဆာဗာ) တွေကပါ သိမ်းထားခွင့် ရှိတယ် (Public ဖြစ်တယ်) လို့ ဆိုလိုပါတယ်။
  • private: ဒီဖိုင်က User တစ်ယောက်တည်း အတွက် သီးသန့် (Private) ဖြစ်လို့၊ သူနဲ့ သက်ဆိုင်တဲ့ Browser ကပဲ သိမ်းထားသင့်ပြီး၊ ကြားခံ Cache တွေ (ဥပမာ - CDNs) မှာ လုံးဝ မသိမ်းသင့်ဘူးလို့ ဆိုလိုပါတယ်။ (ဥပမာ - User ရဲ့ Profile ပုံ)။
  • no-store: “ဒီဖိုင်ကို လုံးဝ (လုံးဝ) မသိမ်းပါနဲ့” လို့ Browser ကို အပြတ် ပြောတာပါ။ (ဥပမာ - လုံခြုံရေး အရမ်း အရေးကြီးတဲ့ Banking Data တွေ)။
  • no-cache: ဒီနာမည်က နည်းနည်း နားလည်မှု လွဲစေနိုင်ပါတယ်။ သူက “မသိမ်းပါနဲ့” လို့ ပြောတာ မဟုတ်ပါဘူး။ Browser အနေနဲ့ ဖိုင်ကို Cache လုပ်ထားခွင့် ရှိပေမဲ့၊ အဲ့ဒီ Cache ထဲက ဖိုင်ကို ပြန်မသုံးခင်မှာ “Server ဆီကို Latest Version ဟုတ်မဟုတ် အရင်လှမ်းမေး၊ အတည်ပြု (Check) ပြီးမှသာ သုံးရမယ်” လို့ ဆိုလိုပါတယ်။ (HTML ဖိုင်တွေလိုမျိုး အမြဲတမ်း Latest Version ကိုပဲ လိုချင်ရင် သင့်တော်ပါတယ်)။
  • max-age=<seconds>: Browser အနေနဲ့ Cache ထဲက ဖိုင်ကို Server ဆီ ပြန်မမေးတော့ဘဲ၊ ဘယ်လောက် အချိန်ကြာတဲ့အထိ ယုံယုံကြည်ကြည် သုံးလို့ရလဲ ဆိုတာကို စက္ကန့်နဲ့ သတ်မှတ်ပေးတာပါ။
    • ဥပမာ: Cache-Control: public, max-age=31536000 (၁ နှစ်တိတိ ကြာအောင် သိမ်းထားနိုင်သည်)။ ပုံတွေ၊ CSS၊ JS လိုမျိုး မကြာခဏ မပြောင်းလဲတတ်တဲ့ (Static Assets) တွေအတွက် အကောင်းဆုံးပါပဲ။

• Expires: Cache ထဲက ဖိုင်ဟာ ဘယ်နေ့ ဘယ်အချိန် (ရက်စွဲ အတိအကျ) မှာ သက်တမ်း ကုန်မလဲ ဆိုတာကို သတ်မှတ်ပေးတဲ့ Header အဟောင်း တစ်ခုပါ။ ယခု နောက်ပိုင်းမှာတော့ Cache-Control: max-age ကိုပဲ ပိုပြီး ယေဘုယျအားဖြင့် အသုံးပြုကြပါတယ်။

• Validation Headers (ETag နှင့် Last-Modified):

  • max-age သက်တမ်း ကုန်သွားတဲ့အခါ၊ ဒါမှမဟုတ် no-cache လို့ သတ်မှတ်ထားတဲ့အခါ၊ Browser က Server ကို “ငါ့ဆီက ဖိုင်က Latest ဖြစ်သေးရဲ့လား” လို့ လှမ်းမေး (Validate လုပ်) ပါတယ်။
  • ETag: ဖိုင်ရဲ့ “လက်ဗွေရာ (Fingerprint)” ဒါမှမဟုတ် Version နံပါတ်လိုမျိုးပါ။ Server ပေါ်က ETag နဲ့ Browser Cache ထဲက ETag တူနေသေးရင် (ဖိုင်က မပြောင်းလဲသေးဘူးဆိုရင်)၊ Server က ဖိုင်ကြီး တစ်ခုလုံးကို ပြန်မပို့တော့ဘဲ “304 Not Modified” လို့ပဲ အကြောင်းပြန်လိုက်ပါတယ်။ အဲ့ဒီအခါ Browser က သူ့ Cache ထဲက ဖိုင်ကိုပဲ ဆက်သုံးလိုက်ပါတယ်။
  • Last-Modified: ဖိုင်ကို နောက်ဆုံး ပြင်ဆင်ခဲ့တဲ့ (ပြောင်းလဲခဲ့တဲ့) ရက်စွဲပါ။ ETag လိုပါပဲ၊ Browser က ဒီရက်စွဲကို ပို့ပြီး မေးတဲ့အခါ၊ ဖိုင်က မပြောင်းလဲသေးရင် Server က “304 Not Modified” လို့ပဲ ပြန်ဖြေပါတယ်။

HTTP Headers ဥပမာ

HTTP/1.1 200 OK
Content-Type: text/css
Cache-Control: public, max-age=604800
ETag: "abc123xyz"

Cache Busting: Version အသစ်ကို ချက်ချင်း ရောက်အောင် လုပ်ခြင်း

• ပြဿနာ: သင်က CSS သို့မဟုတ် JS ဖိုင်တစ်ခုကို max-age အကြာကြီး (ဥပမာ - ၁ နှစ်) ပေးပြီး သိမ်းခိုင်းထားတယ် ဆိုပါစို့။ အကယ်၍ အဲ့ဒီဖိုင်ကို သင်က Server မှာ ပြင်ဆင် (Update) လိုက်ရင်တောင်၊ Version အဟောင်းကြီး Cache ထဲမှာ ရောက်နေတဲ့ User တွေကတော့ ဖိုင်အသစ်ကို ချက်ချင်း မြင်ရမှာ မဟုတ်ဘဲ အချိန် အတော်ကြာတဲ့အထိ (၁ နှစ် ပြည့်တဲ့အထိ) Version အဟောင်းကြီးကိုပဲ ဆက်မြင်နေရပါလိမ့်မယ်။
• ဖြေရှင်းချက်: ဒါကို ဖြေရှင်းဖို့ “Cache Busting” လို့ ခေါ်တဲ့ ဖိုင်နာမည် ပြောင်းလဲခြင်း နည်းလမ်းကို သုံးပါတယ်။ ဖိုင်ရဲ့ အထဲက Content ပြောင်းသွားတိုင်း၊ ဖိုင်နာမည်ကိုပါ လိုက်ပြောင်းတာ ဒါမှမဟုတ် URL နောက်မှာ Version နံပါတ် တစ်ခုခု (Query String) ထပ်ထည့်ပေးလိုက်တာမျိုးပါ။
  • ဥပမာ:
    • အဟောင်း: style.css
    • အသစ်: style.v2.css သို့မဟုတ် style.css?v=1.2.3 သို့မဟုတ် style-a1b2c3d4.css
• ဖိုင်နာမည် မတူတော့တဲ့အတွက် Browser က ဒါကို “ဖိုင်အသစ် တစ်ခု” လို့ပဲ မြင်ပြီး၊ Cache ထဲက Version အဟောင်းကို ကျော်ကာ ဖိုင်အသစ်ကို ချက်ချင်း Download ဆွဲပါလိမ့်မယ်။
• Webpack, Vite, Parcel လို Build Tools တွေက ဖိုင်နာမည်တွေမှာ Hash (a1b2c3d4) တွေ ထည့်ပေးပြီး ဒါကို အလိုအလျောက် ဖြေရှင်းပေးလေ့ ရှိပါတယ်။

Service Workers နှင့် Caching (အကျဉ်းချုပ်)

• Service Workers ဆိုတာ Web Page နဲ့ သီးခြားစီ နောက်ကွယ် (Background) မှာ ပြေးလွှား အလုပ်လုပ်နေတဲ့ JavaScript ဖိုင်တွေပါ။
• သူတို့က Browser ထွက်သွားတဲ့ Network Requests တွေကို ကြားဖြတ် ဖမ်းယူပြီး၊ Cache API ကို သုံးကာ Caching လုပ်ငန်းစဉ်ကြီး တစ်ခုလုံးကို ကိုယ်တိုင် အသေးစိတ် (Fine-grained) ထိန်းချုပ် ရေးသားလို့ ရပါတယ်။
• အင်တာနက် မရှိချိန် (Offline) မှာ အသုံးပြုနိုင်အောင် ဖန်တီးတာတွေ၊ HTTP Headers တွေထက် ပိုမို ရှုပ်ထွေးတဲ့ Caching Strategies တွေ တည်ဆောက်တာတွေ အတွက် အသုံးပြုပါတယ်။
• (ဒါက အနည်းငယ် အဆင့်မြင့်တဲ့ အကြောင်းအရာ ဖြစ်လို့၊ ယေဘုယျ သဘောတရားကို သိထားရုံနဲ့ လုံလောက်ပါတယ်)။