Performance Optimization
Best Practices for Speeding Up Your Websiteကျွန်တော်တို့ဆီမှာသာ စောင့်ရတာက အလေ့အကျင့်လိုဖြစ်နေလို့ သိပ်သတိမထားမိတာပါ။ နိုင်ငံတကာမှာ Website အသုံးပြု သူအများစုက၊ Website တစ်ခုကိုဖွင့်လိုက်တာနဲ့ (၂) စက္ကန့်အတွင်း စတင်အသုံးပြုနိုင်ဖို့ မျှော်လင့်ထားကြတယ်လို့ စစ်တမ်းများ အရ သိရပါတယ်။ အသုံးပြုသူများရဲ့ ထက်ဝက်လောက်က စောင့်ရတဲ့အချိန် (၃) စက္ကန့်ကို ကျော်သွားရင် ဆက်မစောင့်တော့ပဲ Website ကို အသုံးမပြုကြတော့ဘူးလို့လည်း အဲ့ဒီစစ်တမ်းတွေက ဆိုပါတယ်။
ကျွန်တော်တို့ရဲ့ Website တွေကို ဖွင့်လိုက်တာနဲ့ ဘယ်လောက်မြန်မြန် စတင်အသုံးပြုနိုင်မလဲဆိုတာ အသုံးပြုသူရဲ့ အင်တာနက် အဆက်အသွယ် အမြန်နှုန်းပေါ်မှာတော့ မူတည်ပါတယ်။ အသုံးပြုသူရဲ့ အင်တာနက်အမြန်နှုန်းကို ကျွန်တော်တို့ ပြုပြင်ပေးလို့ မရပေမယ့်၊ သင့်တင့်လျှောက်ပတ်တဲ့ မြန်နှုန်းရှိနေချိန်မှာ ကျွန်တော်တို့ Website တွေကို ဖွင့်လိုက်တာနဲ့ အချိန် (၂) စက္ကန့် (၃) စက္ကန့်အတွင်း စတင်အသုံးပြုနိုင်တဲ့အထိ လျှင်မြန်နေအောင် ဆောင်ရွက်ထားရမှာက ကျွန်တော်တို့ရဲ့တာဝန်ပဲဖြစ်ပါတယ်။
Website တစ်ခုရဲ့ အမြန်နှုန်းနဲ့ ပက်သက်ရင် ထည့်သွင်းစဉ်းစားရမယ့်အပိုင်း (၃) ပိုင်းရှိပါတယ်။ အသုံးပြုထားတဲ့ Server-side နည်းပညာရဲ့ အမြန်နှုန်း (Processing Performance) ကို ထည့်သွင်းစဉ်းစားရပါမယ်။ နောက်တစ်ချက်အနေနဲ့ Server နဲ့ Client အပြန်အလှန် ဆက်သွယ်မှုအတွက်ကြာချိန် (Communication Performance) ကို ထည့်သွင်းစဉ်းစားရပါမယ်။ နောက်တစ်ချက်ကတော့ Client ဖြစ်တဲ့ Web Browser က HTML/CSS/JavaScript, Image စတဲ့ Resource တွေလက်ခံရရှိ ပြီး ဖော်ပြပေးနိုင်တဲ့အမြန်နှုန်း (Rendering Performance) ကိုလည်း ထည့်သွင်းစဉ်းစားရပါမယ်။
အရေးအကြီးဆုံးကတော့ ဒုတိယအချက်ဖြစ်တဲ့ Server နဲ့ Client အပြန်အလှန်ဆက်သွယ်မှု Communication Performance ပဲ ဖြစ်ပါတယ်။ ဘာကြောင့်လဲဆိုတော့ Website တစ်ခု ဖွင့်လိုက်ချိန်ကနေ စတင်အသုံးပြုနိုင်ချိန်ထိ ကြာချိန်ရဲ့ ၉၀% လောက်က Server နဲ့ Client တို့ အချက်အလက်တွေ အပြန်အလှန်ပေးပို့နေခြင်း ဖြစ်ပါတယ်။ ဒါကြောင့် ဒီကဏ္ဍကို အထူးအလေးပေးပြီး Optimize လုပ်နိုင်မှ ကျွန်တော်တို့ Website တွေရဲ့ အမြန်နှုန်းက သိသာမြင်သာ တိုးတက်လာမှာ ဖြစ်ပါတယ်။
ဆိုလိုတာက Client Server Communication ကို ၅၀% ပိုမြန်လာအောင် Optimize လုပ်နိုင်ရင် ကျွန်တော်တို့ Website Load Time လည်း ၅၀% လောက် အမှန်တစ်ကယ် ပိုမြန်လာခြင်းပဲဖြစ်ပါတယ်။ အကယ်၍ Server-side နည်းပညာရဲ့ အမြန်နှုန်းကို ၅၀% ပိုမြန်လာအောင် Optimize လုပ်နိုင်ရင်တောင်မှ Website Load Time ကို ၂.၅% လောက်သာ တိုးတက်လာစေမှာဖြစ် ပါတယ်။ ဘာဖြစ်လို့လဲဆိုတော့ Server-side အလုပ်လုပ်ချိန်က Website Load Time ရဲ့ ၅% ခန့်သာ ရှိတဲ့အတွက်ဖြစ် ပါတယ်။ ဒါကြောင့် ကျွန်တော်တို့က Client Server Communication ပိုင်းကို အထူးအလေးပေး ဂရုပြုရမှာဖြစ်ပါတယ်။
ဒီလိုပြောလို့ Server-side Optimization က အရေးမကြီးဘူးဆိုတဲ့သဘောတော့ မဟုတ်ပါဘူး။ ကျွန်တော်တို့ Website တွေကို အသုံးပြုသူတွေသိပ်များလာလို့ Scale လုပ်ရတော့မယ်ဆိုရင်တော့ အဓိကအခန်းကဏ္ဍဖြစ်လာပါလိမ့်မယ်။ ဆိုလိုတာက Website Load Time Performance မှာ သိပ်မသိသာပေမယ့် Scaling မှာတော့ Server-side Optimization က အဓိကဖြစ်လာမှာ ဖြစ်ပါတယ်။ အဲ့ဒီအခါကျရင် အသုံးပြုထားတဲ့ နည်းပညာက Request တွေကို ဘယ်လိုစီမံသလဲ၊ ထိရောက်အောင် ဘယ်လို Optimize လုပ်ရမလဲ၊ Process တွေကို ဘယ်လိုစီမံလဲ၊ ထိရောက်အောင် ဘယ်လို Optimize လုပ်ရမလဲ၊ Runtime Performance ကရောဘယ်လိုလဲ၊ တစ်ခြားနည်းပညာတွေနဲ့ဘာကွာလဲ စသဖြင့် စဉ်းစားစရာတွေ အများကြီးရှိလာမှာပါ။ ဒီနေရာ မှာတော့ Scaling ထက် Page Load Performance ပိုင်းကိုသာ ထည့်သွင်းဆွေးနွေးသွားမှာ ဖြစ်ပါတယ်။
နောက်ကျန်နေတဲ့ တစ်ခုဖြစ်တဲ့ Browser တွေက Resources တွေကို ဖော်ပြပေးနိုင်စွမ်း Rendering Speed ကတော့ Performance မှာ အတိုင်းအတာတစ်ခုထိ အရေးပါပါတယ်။ အထူးသဖြင့် အင်တာနက်အဆက်အသွယ်မြန်တဲ့ အသုံးပြုသူတွေ အတွက်နဲ့ JavaScript အသားပေး Application တွေမှာ သိသာစေမှာဖြစ်ပါတယ်။ အင်တာနက်မြန်တော့ Resource တွေကို များများနဲ့မြန်မြန် ရရှိမှာပါ။ အဲ့ဒီအချိန်မှာ Browser က ရရှိလာတဲ့ Resource တွေကို မြန်မြန်ဆန်ဆန် Render လုပ်မပေး နိုင်ရင် ကျွန်တော်တို့ Application ရဲ့ Load Time က နှေးနေဦးမှာပါပဲ။ Browser တွေဘက်ကလဲ သူတို့ရဲ့ Rendering Engine တွေနဲ့ JavaScript Engine တွေကို အဆက်မပြတ် Improve လုပ်နေသလို၊ ကျွန်တော်တို့ဘက်ကလည်း Client-side Code တွေကို Optimize လုပ်ပေးထားရမှာဖြစ်ပါတယ်။
Web Performance Optimization နဲ့ပက်သက်ရင် ကိုးကားကြလေ့ရှိတဲ့ လမ်းညွှန်ချက်တစ်ချို့ရှိပါတယ်။ အဓိကကိုးကားကြ လေ့ရှိတာက Yahoo Performance Optimization Rules ဖြစ်ပြီး နောက်တစ်ခုကတော့ Google PageSpeed Best Practices တို့ပဲဖြစ်ပါတယ်။ Yahoo က သူ့ရဲ့ Rules တွေနဲ့ တိုက်ဆိုင်စစ်ဆေးနိုင်ဖို့ YSlow လို့ခေါ်တဲ့ Tool တစ်ခုကို ဖန်တီး ပေးထားသလို၊ Google ကလည်း PageSpeed ဆိုတဲ့ Tool ကို ဖန်တီးပေးထားပါတယ်။ ဒီ Tool တွေကိုတော့ ကိုယ်တိုင် လေ့လာ အသုံးပြုကြည့်ဖို့လိုပါမယ်။ ဒီနေရာမှာတော့ Yahoo Performance Rules တွေကို ကိုးကားပြီး သိရှိသင့်တဲ့ Practices တွေကို ဆက်လက်ဖော်ပြပေးသွားမှာဖြစ်ပါတယ်။
Yahoo!: http://developer.yahoo.com/performance/rules.html
Google: https://developers.google.com/speed/articles/
1: Minimize HTTP Requests
အခန်း (၁) မှာ HTTP အကြောင်းဖော်ပြခဲ့စဉ်က Cache အလုပ်လုပ်ပုံကို ထည့်သွင်းဖော်ပြခဲ့ပါတယ်။ Web Browser တွေဟာ Resource တစ်ခုကို တစ်ကြိမ်ရယူဖူးရင် နောင်ပြန်လည်အသုံးပြုနိုင်အောင် Cache လုပ်ထားတက်ကြပါတယ်။ ဒီတော့ နောက်တစ်ကြိမ် လိုအပ်လာတဲ့အခါ Server က ပေးပို့လာအောင် စောင့်စရာမလိုတော့ပဲ Cache ထဲကနေရယူပြီး ချက်ခြင်း ဖော်ပြနိုင်လို့ အများကြီးပိုမြန်သွားမှာ ဖြစ်ပါတယ်။
ဒါပေမယ့် Cache လုပ်ထားတဲ့ Resource ကိုပဲ အမြဲသုံးနေလို့တော့မဖြစ်ပါဘူး။ အကယ်၍များ အဲ့ဒီ Resource ကို Server မှာ Modified ပြုလုပ်ခဲ့ရင် အဲ့ဒီနောက်ဆုံး Update ကို ရယူဖို့ လိုအပ်ပါတယ်။ Modified မလုပ်ထားမှသာ Cache ကို အသုံးပြု ရမှာဖြစ်ပါတယ်။ ဒီတော့ Cache ရှိသည်ဖြစ်စေ၊ မရှိသည်ဖြစ်စေ Browser က Web Server ထံ Request ပေးပို့ဖို့ လိုအပ်ပါ တယ်။ ဒီတော့မှ Server က အဲ့ဒီ Resource ကို Modify လုပ်ထားခြင်းရှိမရှိ Browser ကို ပြန်လည်အသိပေးနိုင်မှာပါ။ ဒီတော့ Cache ကြောင့် Resource တွေကို ထပ်ခါထပ်ခါ ပြန်လည်ရယူနေဖို့ မလိုအပ်တော့ပေမယ့်၊ Request တွေကိုတော့ ထပ်ခါထပ်ခါ ပေးပို့ရမှာပါပဲ။
Web Document တစ်ခုပြည့်စုံဖို့အတွက် ချိတ်ဆက်ပါဝင်ရတဲ့ Resource တွေ အများကြီးရှိနိုင်ပါတယ်။ Image တွေရှိပါတယ်။ ချိတ်ဆက်ထားတဲ့ CSS Style တွေ JavaScript တွေရှိပါတယ်။ Document တစ်ခုမှာ ပုံ (၁၀) ပုံပါရင်၊ Resource (၁၀) ခုနဲ့ ချိတ်ဆက်ထားတယ်ဆိုတဲ့ သဘောပါပဲ။ Browser က Document ကို ဖော်ပြဖို့ ကြိုးစားတဲ့အခါ ချိတ်ဆက်ထားတဲ့ Resource တစ်ခုတိုင်းအတွက် Request တစ်ကြိမ် Server ထံ ပေးပို့ရမှာပဲ ဖြစ်ပါတယ်။ Website တစ်ခုရဲ့ Home Page ကို ဖော်ပြနိုင်ဖို့ အတွက် ပေးပို့ရတဲ့ Request တွေက အကြိမ် (၂၀) လည်းဖြစ်နိုင် ပါတယ်။ (၅၀) လည်းဖြစ်နိုင်ပါတယ်။ (၁၀၀) လည်းဖြစ်နိုင် ပါတယ်။ ချိတ်ဆက်ထားတဲ့ Resource များလေ၊ Website Load နှေးလေပဲဖြစ်ပါတယ်။ ဘာကြောင့်လည်းဆိုတော့ ဘယ် လောက်ပဲ Cache တွေလုပ်ထားထား၊ Resource တိုင်းအတွက် Request တွေပေးပို့ခြင်း၊ ပြန်လာတဲ့ Respond Header ကို စောင့်ဆိုင်းခြင်းတို့ကိုတော့ မဖြစ်မနေလုပ်ရမှာမို့ပဲ ဖြစ်ပါတယ်။ ကျွန်တော်တို့ကသာ ဒီလို Request တွေကို လျှော့ချနိုင်မယ် ဆိုရင် ကျွန်တော်တို့ Website ရဲ့ Load Time လည်း သိသိသာသာ တိုးတက်မြန်ဆန်လာမှာပဲဖြစ်ပါတယ်။
Request တွေကို လျှော့ချဖို့အတွက် ပထမဆုံးပြုလုပ်သင့်တဲ့ အလုပ်ကတော့ CSS Style File တွေနဲ့ JavaScript File တွေကို ပေါင်းစပ်လိုက်ခြင်းပဲဖြစ်ပါတယ်။ ဥပမာ - CSS Style File (၃) ခုချိတ်ဆက်ထားမယ့်အစား၊ အဲ့ဒီ File သုံးခုမှာ ပါဝင်တဲ့ Style တွေကို တစ်ခုတည်းအဖြစ်ပေါင်းစပ်လိုက်ရင် (၁) ခုတည်းသာ ချိတ်ဆက်ဖို့ လိုတော့မှာ ဖြစ်ပါတယ်။ ဒီတော့ Request (၃) ကြိမ် လုပ်ရမယ့်နေရာမှာ (၁) ကြိမ်ပဲလုပ်ရတော့လို့ ပိုမြန်သွားမှာဖြစ်ပါတယ်။
ဒုတိယနည်းလမ်းကတော့ CSS Sprites နည်းစနစ်ကို သုံးဖို့ပဲဖြစ်ပါတယ်။ Google, Facebook စတဲ့ Website များမှာ Icon လေးတွေ ဟိုနားဒီနား အများအပြားသုံးထားကြပါတယ်။ ဒါပေမယ့် Icon တစ်ခုကို Right Click နှိပ်ပြီး View Background Image Option ကနေ ဖွင့်ကြည့်လိုက်ရင် Icon တစ်ခုကို Image File တစ်ခုနှုန်းနဲ့ သုံးထားတာ မဟုတ်ပဲ၊ Image File တစ်ခုတည်းမှာ Icon တွေကို စုစည်းထားတာကို တွေ့ရမှာဖြစ်ပါတယ်။ ပြီးတော့မှ CSS Background Position ကိုသုံးပြီး ဖော်ပြစေလိုတဲ့ Icon ရှိရာအပိုင်းကိုသာ ဖော်ပြစေခြင်း ဖြစ်ပါတယ်။ အဲ့ဒါကို CSS Sprites လို့ခေါ်တာပါ။
ပုံ (၁၉-က) CSS Sprites Image
ပုံ (၁၉-က) မှာ 16x16 Size Icon သုံးခုကို Image တစ်ခုတည်းအဖြစ် ပေါင်းစပ်ထားတဲ့ နမူနာတစ်ခုကို ပေးထားပါတယ်။ အဲ့ဒီ Image ကိုသုံးပြီး အလယ်က Icon ကိုသာ ဖော်ပြစေလိုရင် အခုလိုရေးသားနိုင်ပါတယ်။
[ HTML ]
<span class="video"></span>
[ CSS ]
.video {
display: inline-block;
width: 16px;
height: 16px;
background: url(sprites.png) no-repeat 0 -16px;
}
Image ကို Element ရဲ့ Background အဖြစ်သတ်မှတ်ပြီး Background ရဲ့ Top Position ကို -16px လို့ သတ်မှတ်ပေး လိုက်ခြင်း ဖြစ်ပါတယ်။ Width နဲ့ Height လည်း သတ်မှတ်ထားသေးတဲ့အတွက် Image တစ်ခုလုံးကို မမြင်ရပဲ သက်ဆိုင်ရာ အပိုင်းလေးကိုသာ မြင်ရစေမှာဖြစ်ပါတယ်။ ဒီနည်းနဲ့ Image အများကြီး ထည့်သွင်းအသုံးပြုမယ့်အစား၊ Image တစ်ခုတည်းနဲ့ အစားထိုးလိုက်နိုင်လို့ Request တွေလည်း အများကြီး သက်သာသွားမှာပဲဖြစ်ပါတယ်။
နောက်တစ်နည်းအနေနဲ့ တစ်ချို့ Image တွေကို base64 Encode လုပ်ထားတဲ့ Data အဖြစ်ပြောင်းပြီး CSS နဲ့ HTML တွေထဲမှာ၊ Inline ထည့်သွင်းအသုံးပြုနိုင်ပါတယ်။ ဥပမာ -
<img src="data:image/png;base64,iVBORw0KGgoAAXa2Mj2FhZ2lmoAfMfVLQTxNoiFpaC ILa7vREC7+uMBBQMHl=">
Image တွေကို base64 Data ပြောင်းဖို့အတွက် dataurl.net လို Tool မျိုးကိုအသုံးပြုနိုင်ပါတယ်။ Image တွေကို External Resource အနေနဲ့ ချိတ်ဆက်ခြင်းမဟုတ်ပဲ၊ တစ်ခါတည်း ထည့်သွင်းနိုင်လို့ Request လုပ်နေစရာလည်း မလိုတော့ပါဘူး။
Request တွေ လျှောချခြင်းဟာ Page Load Speed အတွက် အထိရောက်ဆုံးနည်းစနစ်ဖြစ်လို့ ပထမဆုံး ဆောင်ရွက်သင့်တဲ့ ကိစ္စတစ်ခုဖြစ်ပါတယ်။ ဖော်ပြခဲ့တဲ့ နည်းလမ်းတွေကိုသုံးပြီး ကျွန်တော်တို့ရဲ့ Web Document တွေထဲမှာ External Resource တွေ ချိတ်ဆက်အသုံးပြုမှုကို လျှော့ချခြင်းဖြင့် Request လိုအပ်ချက်ကို လျှော့ချပေးနိုင်မှာပဲဖြစ်ပါတယ်။
2: Use CDN
Web Server တည်ရှိရာ Location နဲ့ Client တည်ရှိရာ Location တို့ရဲ့ အကွာအဝေးကလည်း Page Load Speed ကို သက်ရောက်စေပါတယ်။ ဒါကြောင့် Web Server တွေကို နေရာအနှံ့ ဖြန့်ကျက်ထားပြီး အသုံးပြုသူနဲ့ အနီးစပ်ဆုံး Server ကနေ Respond ပြန်ပေးနိုင်တဲ့ Content Delivery Network (CDN) တွေ တည်ဆောက်အသုံးပြုသင့်ပါတယ်။
ဒီလို CDN တွေတည်ဆောက်အသုံးပြုတယ်ဆိုတဲ့နေရာမှာ Static Content တွေအတွက်ကိုသာ စဉ်းစားသင့်ပါတယ်။ Static Content ဆိုတာ Image တွေ၊ CSS File တွေနဲ့ JavaScript File တွေကို ဆိုလိုတာပါ။ Server-side နည်းပညာကိုပါ ထည့်သွင်းစဉ်းစားပြီး Distributed Network တွေ ဖန်တီးလိုရင်တော့ Session State တွေ Synchronize လုပ်တဲ့ကိစ္စတွေ၊ Database Replication လုပ်တဲ့ကိစ္စတွေကိုပါ ထည့်သွင်းစဉ်းစားရတော့မှာမို့ လွယ်ကူတဲ့ကိစ္စတစ်ခု မဟုတ်တော့ပါဘူး။ Website တွေရဲ့ Load Time မှာ အလုပ်လုပ်ရာမှာ Static Content တွေ ရယူခြင်းက အဓိကဖြစ်လို့ Performance Optimization အတွက် စဉ်းစားတာဆိုရင် ခက်ခဲပြီးသိပ်မထိရောက်တဲ့ Application Architecture ပိုင်းကို မသွားတာပဲ ကောင်းပါတယ်။ အထက်မှာပြောခဲ့သလို့ Scaling အတွက် စဉ်းစားတဲ့အခါမှာသာ ထည့်သွင်းစဉ်းစားဖို့ လိုအပ်မှာဖြစ်ပါတယ်။
အမှန်တော့ ကနေ့ခေတ်မှာ CDN တစ်ခုကို အစအဆုံး ကိုယ်တိုင်တည်ဆောက်နေစရာတော့ မလိုပါဘူး။ CloudFlare, Akamai, EdgeCast စတဲ့ CDN Service Provider တွေရှိနေပါတယ်။ ဒီလိုဝန်ဆောင်မှုတွေက ကမ္ဘာ့အနှံ့ဖြန့်ကျက်ထားတဲ့ CDN Network တွေ အသင့် တည်ဆောက်ပေးထားပါတယ်။ အခြေခံအားဖြင့် ကျွန်တော်တို့ Application ရဲ့ Static Content တွေကို အဲ့ဒီလို ဖြန့်ကျက်တည်ရှိနေတဲ့ Server တွေမှာ Cache လုပ်ပေးထားခြင်းဖြစ်ပါတယ်။ Request တစ်ခုလက်ခံရရှိတဲ့အခါ CDN က အသုံးပြုသူနဲ့ အနီးစပ်ဆုံး Local Server Cache ထဲမှာ အဲ့ဒီ Resource ရှိမရှိစစ်ဆေးပြီး ရှိရင် တစ်ကယ့် Application Server ထံကို သွားမနေတော့ပဲ Cache Server ကနေ Respond ပြန်ပေးလိုက်မှာပါ။ အကယ်၍ Local Server Cache ထဲမှာ Resource ရှိမနေမှသာ Application အမှန်တစ်ကယ် တည်ရှိရာ Server ထံ Request ကို လက်ဆင့်ကမ်းပေးပို့လိုက်မှာ ဖြစ်ပါတယ်။ အဲ့ဒီလို့ လက်ဆင့်ကမ်းပေးပို့ပြီး ပြန်လည်ရရှိလာတဲ့ Resource ကို နောင်အသုံးပြုနိုင်အောင် Local Server Cache ထဲမှာလည်း သိမ်းဆည်းလိုက်မှာဖြစ်ပါတယ်။ ဒီနည်းနဲ့ Static Content တွေကို အသုံးပြုသူနဲ့ အနီးစပ်ဆုံး Server ကနေ Respond လုပ်နိုင်စေမှာပါ။ အဲ့ဒီလို ဝန်ဆောင်မှုကိုသုံးဖို့အတွက် Hardware တွေထပ်ဝယ်စရာမလိုသလို၊ Software တွေလည်း ထပ်ပြီး Install လုပ်နေစရာမလိုပါဘူး။ အခြေခံအားဖြင့် ကျွန်တော်တို့ Domain Name ရဲ့ Authoritative Name Server နေရာမှာ သက်ဆိုင်ရာ CDN Server Provider ရဲ့ Name Server လိပ်စာကို ထည့်သွင်းပေးထားယုံပဲ ဖြစ်ပါတယ်။
Google, Yahoo, Microsoft တို့လို့ လုပ်ငန်းကြီးတွေမှာတော့ သူတို့ကိုယ်ပိုင် CDN Network တွေ ရှိကြပါတယ်။ ပြီးတော့ သူတို့ရဲ့ CDN မှာ ရှိနေတဲ့ Static Content တွေကို မည်သူမဆို ရယူအသုံးပြုခွင့် ပေးထားတက်ကြပါတယ်။ ဥပမာ - jQuery လို Application တိုင်းမှာလိုအပ်တဲ့ File မျိုးတွေကို Google Ajax CDN, Microsoft Ajax CDN စတဲ့ CDN တွေကနေ ရယူ အသုံးပြုနိုင်ပါတယ်။ ဥပမာ၊ jQuery ကို ကိုယ်တိုင် Host လုပ်မယ့်အစား၊ Google Ajax CDN ကနေ အခုလို ချိတ်ဆက်ရယူ နိုင်ပါတယ်။
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
ဒီလိုချိတ်ဆက် ရယူခြင်းအားဖြင့် Google CDN က jQuery ကို အသုံးပြုသူနဲ့ အနီးစပ်ဆုံး Google Server ကနေ Respond လုပ်ပေးမှာဖြစ်လို့ ပိုမိုထိရောက် လျှင်မြန်စေမှာဖြစ်ပါတယ်။ ဒါကြောင့် CND Service တွေကို မသုံးနိုင်သေးရင်တောင်မှ ဒီလို အခမဲ့သုံးခွင့်ရနေတဲ့ Google CDN, Ajax CDN တွေကို အသုံးပြုသင့်ပါတယ်။ ဒီ CDN တွေကနေ jQuery တင်မကပါဘူး၊ jQuery UI, jQuery DataTable, BackboneJS, AngularJS, Dojo, Modernizr စသဖြင့် အသုံးများတဲ့ Popular Framework တွေကိုပါ ရယူအသုံးပြုနိုင်ပါတယ်။
Request တွေ လျှော့ချခြင်းပြီးရင်၊ CDN အသုံးပြုခြင်းဟာ Performance Optimization အတွက် အထိရောက်ဆုံးနည်းစနစ် တစ်ခုဖြစ်ပါတယ်။
3: Add an Expires Header
Performance Optimization မှာ Request တွေ လျှော့ချနိုင်ခြင်းဟာ အဓိကအကျဆုံးနဲ့ အထိရောက်ဆုံးဖြစ်ကြောင်း ဖော်ပြခဲ့ ပြီးပါပြီ။ Cache ရှိနေရင်တောင်မှ အနည်းဆုံး Request ပြုလုပ်ဖို့တော့ လိုမှာဖြစ်ကြောင်းကိုလည်း ဖော်ပြခဲ့ပါတယ်။ အမှန်တော့ Browser က Request ကို လုပ်မနေတော့ပဲ Cache ထဲကနေပဲ အမြဲသုံးအောင် စီမံထားလို့ရတဲ့နည်းလမ်းတွေ ရှိပါတယ်။ အဲ့ဒါ ကတော့ Expires (သို့မဟုတ်) Cache-Control Header ကို Respond နဲ့အတူ ပြန်လည်ပေးပို့ခြင်းပဲ ဖြစ်ပါတယ်။ ဥပမာ - ကျွန်တော်တို့ရဲ့ PHP Script မှာ အခုလို သတ်မှတ်ထားနိုင်ပါတယ် -
<?php
$seconds_to_cache = 3600;
$ts = gmdate("D, d M Y H:i:s", time() + $seconds_to_cache) . " GMT";
header("Expires: $ts");
header("Pragma: cache");
header("Cache-Control: max-age=$seconds_to_cache");
?>
အဓိပ္ပါယ်က ဒီ Document ဟာ နောက်စက္ကန့် ၃၆၀၀ (၁နာရီ) အတွင်း Expire ဖြစ်မှာ မဟုတ်လို့ Request လုပ်မနေပါနဲ့တော့။ Cache ရှိရင် Cache ကိုသာ သုံးပါတော့ဆိုတဲ့ အဓိပ္ပါယ်ဖြစ်ပါတယ်။ ဒီ Header ကို လက်ခံရရှိတာနဲ့ Browser က နောင်ကို အဲ့ဒီ Document တစ်နာရီအတွင်းအသုံးပြုဖို့လိုတိုင်း Request တောင်လုပ်မနေတော့ပဲ Cache ကိုပဲ အမြဲအသုံးပြုသွားမှာ ဖြစ်ပါတယ်။
ဒါ နည်းနည်းတော့ ပြဿနာရှိပါတယ်။ အကြောင်းအမျိုးမျိုးကြောင့် အဲ့ဒီ Document ကို Modify လုပ်ခဲ့ရင်တောင် Browser က ထပ်မံရယူမှာမဟုတ်တော့လို့ Cache လုပ်ထားတဲ့ Version အဟောင်းကိုသာ ရရှိနေမှာဖြစ်ပါတယ်။ ဒါကြောင့် သတိနဲ့ ချင့်ချိန်ပြီး သတ်မှတ်ဖို့တော့ လိုပါတယ်။
လက်တွေ့မှာ၊ Resource တစ်ခုခြင်းအတွက် PHP လို Application အဆင့်ကနေ သတ်မှတ်ပေးတာထက်စာရင်၊ Expires Parameter တွေမှာ Web Server မှာ တစ်ခါတည်း Setting လုပ်ထားခြင်းက ပိုမိုသင့်ပါတယ်။ အခန်း (၁၀) မှာ Apache Web Server Setting များ ဖော်ပြခဲ့စဉ်က mod_expires အကြောင်းလည်း ထည့်သွင်းဖော်ပြခဲ့ပါတယ်။ Apache မှာ mod_expires ကို Enable လုပ်ပြီး Expire Setting တွေကို အခုလို သတ်မှတ်ထားနိုင်ပါတယ်။
<IfModule mod_expires.c> ExpiresActive on ExpiresDefault "access plus 1 month" ExpiresByType text/html "access plus 0 seconds" ExpiresByType image/x-icon "access plus 1 week" ExpiresByType image/png "access plus 1 month" ExpiresByType image/jpg "access plus 1 month" </IfModule>
အဓိပ္ပါယ်က Content အားလုံးအတွက် (၁) လလို့ Default Expire Time ကို သတ်မှတ်ထားပြီး၊ HTML တွေကိုတော့ 0 Seconds လို့ ပြန်လည်သတ်မှတ် ထားခြင်းဖြစ်ပါတယ်။ ဘာကြောင့်လဲဆိုတော့၊ ပုံမှန်အားဖြင့် Image တို့၊ Style တို့လို Static Content တွေကိုသာ Expire သတ်မှတ်သင့်ပြီး HTML Document တွေကတော့ Dynamic Content တွေ ပါဝင်နိုင်လို့ Cache မလုပ်သင့်တဲ့အတွက် ဖြစ်ပါတယ်။ ကျန် Resource တွေကိုလည်း Content Type အလိုက် Expire Time တွေ ကိုယ်စီသတ်မှတ် ပေးထားပါတယ်။
ဒီနည်းနဲ့ လိုအပ်ချက်ပေါ်မူတည်ပြီး Request တောင် လုပ်နေဖို့မလိုတဲ့ Cache တွေကို Expire Header သုံးပြီး သတ်မှတ်ထား ခြင်းအားဖြင့် Application ရဲ့ Performance ကို မြှင့်တင်နိုင်ပါတယ်။
4: Compress Resources
နောက်တစ်နည်းကတော့ Respond ပြန်ပေးမယ့် Content တွေကို Compress လုပ်ပြီးမှ Respond ပြန်စေခြင်း ဖြစ်ပါတယ်။ Compress လုပ်လိုက်တာဟာ Image လို့ Binary တွေအတွက် သိပ်မသိသာပေမယ့်၊ HTML, CSS, JavaScript တို့လို Text Resources တွေရဲ့ Size ကို ၉၀% လောက်ထိ လျော့ကျသွားစေနိုင်ပါတယ်။
ဒီကိစ္စကိုလည်း Expire လိုပဲ Application အဆင့်ကနေ ပြုလုပ်နိုင်သလို Web Server မှာ Setting သတ်မှတ်ထားခြင်း အားဖြင့်လည်း ပြုလုပ်နိုင်ပါတယ်။ အရင်ကတော့ Compress လုပ်ထားတဲ့ Content ကို လက်ခံ အလုပ်လုပ်ပေးနိုင်ခြင်း မရှိတဲ့ Browser အဟောင်းတွေ ရှိခဲ့ပါတယ်။ ဒါပေမယ့် အခုချိန်မှာ Browser အားလုံးက Compression ကို Support လုပ်တဲ့အတွက် Apache Web Server မှာပဲ Compress လုပ်စေလိုတဲ့ Content တွေကို အခုလို သတ်မှတ်ထားနိုင်ပါတယ်။
<IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript AddOutputFilterByType DEFLATE image/x-icon </IfModule>
Compress လုပ်နေလို့လည်း သိပ်ထိရောက်မှာ မဟုတ်တဲ့ Image တွေကိုချန်ထားပြီး ကျန် Contents တွေကို Compress လုပ်ပြီး Transfer လုပ်ဖို့ သတ်မှတ်ထားခြင်းဖြစ်ပါတယ်။ mod_deflate တော့ Enable လုပ်ထားပေးဖို့လိုပါတယ်။ အခန်း (၁၀) မှာလဲ ဒီအကြောင်းကို ပြောခဲ့ပြီးဖြစ်ပါတယ်။
5: Styles on Top and Scripts on Bottom
HTML Standard က CSS Style တွေကို <head> Section အတွင်းမှာသာ ထည့်သွင်းရေးသားဖို့ လမ်းညွှန်ထားပါတယ်။ လက်တွေ့မှာလည်း CSS Style တွေကို <head> Section အတွင်းမှာသာ ထည့်သွင်းရေးသားသင့်ပါတယ်။ ဒီလို <head> အတွင်းမှာ ထည့်လိုက်ယုံနဲ့ Performance တော့ ပိုကောင်းမသွားပါဘူး။ ဒါပေမယ့် "ပိုမြန်တယ်လို့ထင်ရစေပါတယ်"။
ဘာဖြစ်လို့လဲဆိုတော့ Web Developer တွေအနေနဲ့ တစ်ချို့ JavaSript ကဲ့သို့ Content တွေကို Loading လုပ်နေစဉ်မှာ Progress Bar လုပ်ဆောင်ချက်မျိုးကို CSS နဲ့ ဖန်တီးသတ်မှတ်ထားနိုင်ပါတယ်။ Image တွေ Loading လုပ်နေစဉ်မှာ အလုပ်လုပ်နေကြောင်းကို CSS နဲ့ သက်ဆိုင်ရာ Image နေရာမှာ ဖော်ပြနေစေနိုင်ပါတယ်။ ဒီတော့ အသုံးပြုသူက File Size ပိုကြီးတဲ့ တစ်ကယ့် Content ကို မရသေးပေးမယ့်၊ အလုပ်လုပ်နေကြာင်း သိရှိရနိုင်တဲ့အတွက် ပိုအဆင်ပြေစေပါတယ်။ CSS တွေကို <head> အတွင်းမှာ ထားမှသာ Browser က သူ့ကိုအရင်ရယူပြီး Progress Bar သို့မဟုတ် Loading ပြုလုပ်နေကြောင်းကို တစ်ကယ့် Resource မရရှိခင် ကြိုတင်ဖော်ပြပေးနိုင်မှာပါ။ ဒါကြောင့် အခြေခံအားဖြင့် CSS တွေ အားလုံးကို <head> အတွင်းမှာ ထည့်သွင်းရေးသာတာ ပိုအကျိုးရှိပါတယ်။
ပုံမှန်အားဖြင့် Browser တွေက Request တွေကို တစ်ခုပြီးမှတစ်ခု လုပ်နေတာမဟုတ်ပါဘူး။ တက်နိုင်သမျှမြန်အောင် Parallel ပြုလုပ်ကြပါတယ်။ ပြဿနာက HTTP သတ်မှတ်ချက်အရ JavaScript တွေ Request ပြုလုပ်နေစဉ်မှာ အခြား Resource တွေကို Request မပြုလုပ်ဖို့ သတ်မှတ်ထားသလို Browser တွေကလည်း JavaScript တွေ ရယူနေစဉ် တစ်ခြား Parallel Request တွေကို မပြုလုပ်ပဲ စောင့်စိုင်းနေမှာဖြစ်ပါတယ်။ ဖြစ်နိုင်ရင် JavaScript တွေကို နောက်ဆုံးမှ ရယူတာ အကောင်းဆုံးပါပဲ။ ဒါကြောင့် အတက်နိုင်ဆုံး JavaScript ချိတ်ဆက်မှုတွေကို Document ရဲ့ အောက်ဆုံး၊ နောက်ဆုံးမှာပဲ ပြုလုပ်သင့်ပါတယ်။
ဒီနည်းနဲ့ Website Performance ကို အနည်းငယ် မြင့်တက်သွားစေမှာ ဖြစ်ပါတယ်။
6: Other Practices
အခြားဖြည့်စွက်မှတ်သားသင့်တဲ့ နည်းစနစ်တွေကို ဆက်လက်ဖော်ပြပေးပါမယ်။Expires အကြောင်းဖော်ပြခဲ့စဉ်က CSS, JavaScript တို့လို Static Content တွေကို Cache လုပ်သင့်ပြီး HTML လို့ Dynamic Content တွေ ပါဝင်နေနိုင်တဲ့ Resource တွေကို Cache မလုပ်သင့်ကြောင်း ဖော်ပြခဲ့ပါတယ်။ ဒီတော့ ကျွန်တော်တို့ ကလည်း CSS တွေ JavaScript တွေကို HTML ထဲမှာ ရောမရေးပဲ သီးခြားခွဲခြား ရေးသားထားရမှာပါ။ ဒီတော့မှ Cache စီမံတဲ့အခါ ပိုမိုထိရောက်စေမှာဖြစ်ပါတယ်။
နောက်တစ်ချက်အနေနဲ့ CSS File တွေ ချိတ်ဆက်ထည့်သွင်းတဲ့အခါ Element ကိုပဲ အသုံးပြု ချိတ်ဆက်သင့် ပါတယ်။ @import ဆိုတဲ့ရေးထုံးနဲ့လည်း ချိတ်ဆက်နိုင်ပေမယ့် မသုံးသင့်ပါဘူး။ ကျွန်တော်တို့ အခန်း (၃) မှာ CSS လေ့လာခဲ့ စဉ်ကလည်း ဒီရေးထုံးကို ထည့်သွင်းမဖော်ပြခဲ့ပါဘူး။ ဘာဖြစ်လို့လဲဆိုတော့ Internet Explorer က @import နဲ့ ချိတ်ဆက် ထားတဲ့ CSS တွေကို ဘယ်နေရာမှာပဲ ရေးထားထား၊ နောက်ဆုံးမှသာ ရယူပေးမှာဖြစ်တဲ့အတွက်ကြောင့် ဖြစ်ပါတယ်။ ဒါကြောင့် @import ရေးထုံးကို CSS မှာ ရှောင်ဖို့လိုပါတယ်။
ပြီးတော့ CSS နဲ့ JavaScript တွေကို Minify လုပ်ပေးရပါမယ်။ Minify လုပ်တယ်ဆိုတာ မလိုအပ်တဲ့ White Space တွေကို ဖယ်ထုတ်ခြင်း၊ အချို့ JavaScript Variable တွေနဲ့ Function Name တွေကို တိုအောင်ပြောင်းပေးခြင်း စသဖြင့် ပြုလုပ်ပြီး File Size လျှော့ချခြင်းဖြစ်ပါတယ်။ ဒီအလုပ်ကို ကိုယ်တိုင်လုပ်ဖို့မလိုပါဘူး။ cssminifier.com, jscompress.com, refresh-sf.com တို့လို Tool မျိုးကို အသုံးချနိုင်ပါတယ်။ ဒီလို Minify လုပ်ခြင်းအားဖြင့် CSS နဲ့ JavaScript တွေရဲ့ File Size ကို ၂၀% ကနေ ၂၅% လောက်ထိ လျော့ကျသွားစေနိုင်ပါတယ်။ File Size လျော့သွားတဲ့အတွက် Client Server ဆက်သွယ် ပေးပို့ရာမှာ ပိုမို လျှင်မြန်သွားစေမှာပဲ ဖြစ်ပါတယ်။
Web Page တစ်ခုရဲ့ Overall Content Size မှာ နေရာအများစုယူထားကြတာက Image တွေဖြစ်ပါတယ်။ ဒါကြောင့် Image တွေကိုလည်း အတက်နိုင်ဆုံး File Size သေးငယ်အောင် Optimize လုပ်ဖို့လိုပါတယ်။ ပြဿနာက Image တွေမှာ File Size သေးရင် Quality ညံ့သွားပြီး၊ Quality ကောင်းကောင်းလိုချင်ရင် File Size ကြီးသွားတက်ပါတယ်။ ဒီနှစ်ခုကြားထဲမှာ မျှတဖို့ လိုပါတယ်။ Yahoo! Tool တစ်ခုဖြစ်တဲ့ smushit.com က ပေးလိုက်တဲ့ ပုံကို Quality မကျစေပဲ File Size ကို အတက်နိုင်ဆုံး လျော့ကျသွားအောင် Optimize လုပ်ပေးနိုင်လို့ အဲ့ဒီလို Tool မျိုးကိုလည်း အသုံးပြုဖို့လိုအပ်ပါတယ်။
ဖြည့်စွက်သတိပြုသင့်တာကတော့ CSS, JavaScript, Image စသဖြင့် Resource တွေရဲ့ File Size ဟာ ဖြစ်နိုင်ရင် 25KB ကို မကျော်သင့်ပါဘူး။ တစ်ခြားကြောင့်မဟုတ်ပါဘူး၊ iPhone က File Size 25 KB ကျော်တဲ့ Resource တွေကို Cache မလုပ်တဲ့ အတွက် ဖြစ်ပါတယ်။ အဓိကစဉ်းစားရမယ့်အချက် မဟုတ်ပေမယ့် ဖြစ်နိုင်ရင်တော့ File Size တွေကို 25 KB အောက်မှာပဲ ရှိနေ စေသင့်ပါတယ်။
Conclusion
အင်တာနက်အသုံးပြုသူအများစုက Website တွေကို ဖွင့်လိုက်ရင် (၂) စက္ကန့်အတွင်း စတင်အသုံးပြုနိုင်ဖို့ မျှော်လင့်ကြကြောင်း ဖော်ပြခဲ့ပါတယ်။ အချက်အလက်အနေနဲ့သာ ဖော်ပြခြင်းဖြစ်ပါတယ်။ လက်တွေ့မှာတော့ (၂) စက္ကန့်တွေ (၁၀) စက္ကန့်တွေကို ကြည့်မနေပဲ အရနိုင်ဆုံး အမြန်နှုန်းရရှိအောင် Optimize လုပ်ပေးရမှာဖြစ်ပါတယ်။ အခုဖော်ပြခဲ့တဲ့ နည်းစနစ်တွေကို လေ့လာ ကြည့်ရင် Website တစ်ခုရဲ့ အမြန်နှုန်းကိုမြှင့်တင်ဖို့ ဆောင်ရွက်ရခြင်းဟာ ဒီလောက် မလွယ်ကူပေမယ့် အခက်ကြီးတော့လည်း မဟုတ်တာကို တွေ့ရမှာဖြစ်ပါတယ်။
နောက်ဆုံးတစ်ချက်အနေနဲ့ Firebug လို Browser DevTool တွေကို အသုံးပြုပြီးတော့လည်း Web Page တစ်ခုဖော်ပြဖို့ အတွက် ပြုလုပ်လိုက်ရတဲ့ Request တွေ၊ Request တစ်ခုချင်းရဲ့ ကြာချိန်တွေကို လေ့လာပြီး ဘယ် Resource တွေနဲ့ Request တွေကတော့ Website ကို အဓိကနှေးနေစေလဲဆိုတဲ့ အချက်အလက်တွေကို လေ့လာနိုင်ကြောင်း ဖော်ပြလိုက်ပါတယ်။
Firebug အသုံးပြုပုံကိုတော့ အခန်း (၂၀) Tools and Utilities မှာ ဆက်လက်ဖော်ပြပေးပါမယ်။