ဝဘ်ဆိုဒ်ကို ပိုမြန်အောင် ပြုလုပ်နည်း- လက်တွေ့ စစ်ဆေးစာရင်း

ဝဘ်ဆိုဒ်ကို ပိုမြန်အောင် ပြုလုပ်ရန် ပထမဦးစွာ PageSpeed Insights ဖြင့် တိုင်းတာပါ၊ ထို့နောက် ၎င်းညွှန်ပြသော အကြီးဆုံး အကြောင်းရင်းကို ပြင်ပါ- များသောအားဖြင့် အရွယ်ကြီးလွန်းသော ပုံများ၊ JavaScript အများအပြား၊ လေးလံသော font များ သို့မဟုတ် third-party script များ။ Google ၏ Core Web Vitals "ကောင်း" ပစ်မှတ်များကို ရည်ရွယ်ပါ- အဓိကအကြောင်းအရာ 2.5 စက္ကန့်အတွင်း မြင်ရမည်၊ တို့ခြင်းတုံ့ပြန်ချက်များ 200 မီလီစက္ကန့်အတွင်း၊ layout ခုန်တက်မှု နည်းနည်းသာ ရှိရမည်။ ဆိုဒ်အများစုသည် ပြန်ရေးခြင်းမဟုတ်ဘဲ ပြောင်းလဲမှု အနည်းငယ်ဖြင့် ရောက်နိုင်သည်။

မပြောင်းမီ တိုင်းတာပါ

ခန့်မှန်းခြင်းသည် အချိန်ဖြုန်းသည်။ အခမဲ့ tool နှစ်ခုက လူအများစုကို ဖုံးလွှမ်းသည်-

• PageSpeed Insights (pagespeed.web.dev)- live URL ကို ကူးထည့်ပါ။ ၎င်းက (ဝင်ရောက်မှု လုံလောက်ပါက) အမှန်တကယ် Chrome အသုံးပြုသူများထံမှ field data နှင့် simulate လုပ်ထားသော load မှ lab data၊ နှင့် တိကျသော ပြဿနာများ စာရင်းကို ပြသည်။
• Lighthouse Chrome DevTools တွင်- preview အပါအဝင် ဖွင့်နိုင်သော စာမျက်နှာတိုင်းတွင် lab test တူတူ။ mobile mode ဖြင့် စမ်းပါ၊ ပြဿနာများ ပေါ်လွင်သည်မှာ နှေးသော network ရှိ ဖုန်းများတွင် ဖြစ်သည်။

အရေးကြီးသော ကိန်းဂဏန်းများမှာ Google ၏ Core Web Vitals ဖြစ်သည်။ ၂၀၂၆ စက်တင်ဘာလအထိ web.dev ရှိ Google ၏ စာရွက်စာတမ်းက စာမျက်နှာ load များ၏ 75th percentile တွင် တိုင်းတာသော "ကောင်း" အတိုင်းအတာများကို ပေးသည်-

INP သည် ၂၀၂၄ တွင် အဟောင်း First Input Delay မက်ထရစ်ကို အစားထိုးခဲ့သည်။ tool တစ်ခုက FID ကို ဆက်ပြနေပါက ၎င်းသည် ဟောင်းနေပြီ ဖြစ်သည်။

စတင်ကိန်းဂဏန်းများကို မှတ်ထားပါ။ ပြင်ဆင်ချက်တိုင်းပြီးနောက် ထပ်စမ်းပြီး ဘာကူညီခဲ့သည်ကို သိပါ။

အချိန် ဘယ်နေရာ ကုန်သလဲ- ရွေးချယ်စရာများနှင့် အပေးအယူများ

အဖြစ်များသော အကြောင်းရင်း တစ်ခုစီတွင် ပြင်ဆင်နည်း ရှိပြီး ပြင်ဆင်ချက်တိုင်းတွင် ကုန်ကျစရိတ် ရှိသည်။ အပေါ်ဆုံးမှ စတင်ပါ- ၎င်းတို့သည် အပေါက်ဆုံးနှင့် အဖြစ်အများဆုံး ဖြစ်သည်။

ပုံများ

ပုံများသည် အဖြစ်အများဆုံး ပြဿနာ ဖြစ်ပြီး ပြင်ရလွယ်ဆုံးလည်း ဖြစ်သည်။ 800 pixel အကျယ်တွင် ပြထားသော 4,000-pixel ဓာတ်ပုံသည် ဧည့်သည်တိုင်း မြင်ရသည်ထက် ငါးဆ ပိုဒေါင်းလုဒ် လုပ်စေသည်။

• ပုံများကို ပြသသော အရွယ်အတိုင်း ပေးပါ၊ ဖုန်းနှင့် desktop အတွက် responsive srcset အရွယ်များဖြင့်။
• ခေတ်မီ format (WebP သို့မဟုတ် AVIF) နှင့် ကောင်းမွန်သော ချုံ့မှု သုံးပါ။
• ပုံတိုင်းတွင် width နှင့် height သတ်မှတ်ပါ၊ browser က နေရာ ကြိုယူထားနိုင်အောင်။ ဤတစ်ခုတည်းက layout shift အများစုကို ပြင်သည်။
• fold အောက်ရှိ ပုံများကို loading="lazy" ဖြင့် lazy-load လုပ်ပါ။
• စာမျက်နှာထိပ်ရှိ အဓိကပုံကို ဘယ်တော့မှ lazy-load မလုပ်ပါနှင့်။ Google ၏ LCP လမ်းညွှန်ချက်က ဤအချက်ကို ရိုးရိုးသားသား ပြောသည်- LCP ပုံကို lazy-load လုပ်ခြင်းက ၎င်းကို အမြဲနောက်ကျစေသည်။ အစား fetchpriority="high" ပေးပါ။

JavaScript

AI ဖြင့် တည်ဆောက်သော ဆိုဒ်များစွာသည် single-page app (SPA) များဖြစ်သည်- browser က JavaScript bundle ကို ဒေါင်းပြီးမှ စာမျက်နှာကို ဆွဲသည်။ bundle ကြီးလေ အဖြူရောင် မျက်နှာပြင် ကြာလေ ဖြစ်သည်။ ပြင်ဆင်ချက်များကို ကြိုးစားမှု အစီအစဉ်အလိုက်-

1. မသုံးသော အရာများ ဖယ်ပါ။ dependency စာရင်းတောင်းပြီး တစ်ကြိမ်ထည့်ထားပြီး မေ့သွားသော library များကို ဖြတ်ပါ- ရက်တစ်ရက်အတွက် date library၊ icon ငါးခုအတွက် icon pack အပြည့်။
2. Route အလိုက် ခွဲပါ။ admin dashboard ၏ code ကို ဖွင့်သောအခါမှသာ load လုပ်ပါ၊ home page တွင် မဟုတ်ပါ။
3. ပြည်သူ့စာမျက်နှာများကို prerender လုပ်ပါ။ အမှန်တကယ် HTML အဖြစ် ပို့သော marketing စာမျက်နှာသည် JavaScript run မလုပ်မီ ပေါ်လာသည်။ ၎င်းက search engine များကိုလည်း ကူညီသည်၊ AI ဖြင့် တည်ဆောက်ထားသော ဝဘ်ဆိုဒ်များအတွက် SEO ကို ကြည့်ပါ။

INP နှေးခြင်းသည် များသောအားဖြင့် စာမျက်နှာကို ပိတ်ဆို့သော task ရှည်တစ်ခုကို ဆိုလိုသည်- ရိုက်တိုင်း စာရင်းကြီးကို စစ်ထုတ်ခြင်း၊ သို့မဟုတ် cell တစ်ခု ပြောင်းသည့်အခါ table တစ်ခုလုံးကို ပြန် render လုပ်ခြင်း။ Chrome DevTools ၏ Performance panel က မည်သည်ကို ပြသည်။

Font များ

font family နှင့် weight တိုင်းသည် ဖိုင်တစ်ခု ထပ်ဖြစ်သည်။ family နှစ်ခုနှင့် weight သုံးခု သို့မဟုတ် လေးခု လုံလောက်ပြီ။ fold အပေါ်တွင် သုံးသော font ကို preload လုပ်ပါ၊ စာသား ချက်ချင်းပေါ်စေရန် font-display: swap သုံးပါ၊ ပြင်ပ font ဝန်ဆောင်မှုသည် သင့်ဧည့်သည်များအတွက် နှေးလျှင် font ကို ကိုယ်တိုင် host လုပ်ပါ။

Third-party script များ

chat widget၊ analytics၊ heatmap၊ ad pixel၊ embed ဗီဒီယိုနှင့် social feed များအားလုံးသည် အခြား server များမှ code ကို load လုပ်သည်။ တစ်ခုစီက သေးငယ်ဟု ထင်ရသော်လည်း ပေါင်းလိုက်လျှင် မကြာခဏ စာမျက်နှာ၏ အနှေးဆုံးအပိုင်း ဖြစ်သည်။ သင်တကယ် ကြည့်သော အရာများကိုသာ ထားပါ။ ကျန်များကို စာမျက်နှာ အပြန်အလှန် ဆက်သွယ်နိုင်ပြီးနောက် load လုပ်ပါ၊ လေးလံသော embed များ (YouTube player၊ မြေပုံ) ကို နှိပ်မှ အမှန်တကယ်ကို load လုပ်သော ပေါ့ပါးသည့် preview ဖြင့် အစားထိုးပါ။

Server တုံ့ပြန်ချိန်

Time to first byte (TTFB)- server က ဖြေဆိုစတင်ရန် ဘယ်လောကြာသလဲ- သည် အခြား မက်ထရစ်အားလုံးအောက်တွင် တည်ရှိသည်။ CDN (ဧည့်သည်များနှင့် နီးသော server ကွန်ရက်၊ CDN ဆိုသည်မှာ ဘာလဲ ကို ကြည့်ပါ) မှ ပေးသော static စာမျက်နှာများသည် နေရာအနှံ့ မြန်သည်။ တောင်းဆိုချက်တိုင်းတွင် server က တည်ဆောက်သော စာမျက်နှာများသည် ထို server နှင့် ၎င်း၏ database ပေါ် မူတည်သည်။ ထပ်ခါထပ်ခါ လုပ်ရသော အလုပ်ကို caching လုပ်ခြင်းနှင့် နှေးသော query များအတွက် database index ထည့်ခြင်းတို့သည် အများအသုံးပြု ပြင်ဆင်ချက်များ ဖြစ်သည်။

အလုပ်ဖြစ်သော prompt များ

တိကျပါ- စာမျက်နှာ၊ မက်ထရစ်နှင့် ကန့်သတ်ချက်ကို အမည်ပေးပါ။ ရှိပါက PageSpeed Insights တွေ့ရှိချက်များကို ကူးထည့်ပါ။

PageSpeed Insights က home page အတွက် mobile တွင် LCP 4.8 s ဟု ပြသပြီး LCP element မှာ hero ပုံဖြစ်သည်။ hero ပုံကို ပြန်ချိန်ညှိပြီး WebP သို့ ပြောင်း၊ responsive အရွယ်များ ပေး၊ width နှင့် height သတ်မှတ်၊ fetchpriority="high" ပေးပြီး lazy-load မလုပ်ရန် သေချာပါစေ။ fold အောက်ရှိ ပုံအားလုံးကို lazy-load လုပ်ပါ။ ဒီဇိုင်းကို မပြောင်းပါနှင့်။

ဤအက်ပ်၏ dependency များကို စစ်ဆေးပါ။ package တစ်ခုစီ၊ ၎င်းကို အသုံးပြုသည့်နေရာနှင့် bundle ကို ခန့်မှန်းခြေ ဘယ်လောထည့်သလဲ စာရင်းပြုစုပါ။ မသုံးသောများကို ဖယ်ပြီး /admin နှင့် /settings route များကို သွားရောက်သည့်အခါသာ load ဖြစ်သော သီးခြား chunk များအဖြစ် ခွဲပါ။

/products ရှိ ရှာဖွေရေးအကွက်သည် နှေးနေဟု ခံစားရသည်။ filter ကို debounce လုပ်ပါ၊ ရိုက်တိုင်း စာရင်းတစ်ခုလုံးကို ပြန် render မလုပ်ပါနှင့်၊ စာရင်းတွင် ပစ္စည်း ၂၀၀ ကျော်ရှိပါက pagination သို့မဟုတ် virtualise လုပ်ပါ။

အဆင့်လိုက်

1. တိုက်ရိုက်စာမျက်နှာကို စမ်းပါ PageSpeed Insights တွင် mobile ဖြင့်။ LCP၊ INP နှင့် CLS၊ ထို့နောက် ဖော်ပြထားသော အခက်ဆုံး ပြဿနာ သုံးခုကို မှတ်ပါ။
2. ပုံများကို ဦးစွာ ပြင်ပါ- အရွယ်၊ format၊ width နှင့် height၊ fold အောက် lazy loading၊ hero အတွက် priority။
3. မသုံးသော third-party script များကို ဖြတ်ပါ၊ ကျန်များကို နောက်ကျစေပါ။
4. Font များကို ဒီဇိုင်းလိုအပ်သည်အထိ ချုံ့ပါ။
5. JavaScript ကို ကျုံ့ပါ: မသုံးသော package များ ဖယ်၊ route အလိုက် ခွဲ။
6. ပြည်သူ့စာမျက်နှာများ client-rendered ဖြစ်နေပြီး LCP နှေးနေဆဲဆိုလျှင် prerender လုပ်ပါ။
7. Server ကို စစ်ပါ: caching၊ database index၊ ရှားရှားပြောင်းလဲသော content အတွက် static hosting။
8. ပြန်ထုတ်ဝေပြီး ပြန်စမ်းပါ။ PageSpeed Insights ရှိ field data သည် အမှန်တကယ် ဝင်ရောက်မှုများ ဝင်လာသည်နှင့်အမျှ နောက်အပတ်များတွင် update ဖြစ်သည်၊ ထို့ကြောင့် အစောပိုင်း ရလဒ်များကို lab data ဖြင့် ဆုံးဖြတ်ပါ။

အဖြစ်များသော အမှားများ

• မြန်သော laptop တစ်ခုတည်းတွင်သာ စမ်းခြင်း။ သင့်ဧည့်သည်များသည် အလယ်အလတ် ဖုန်းများနှင့် ကွက်ကွက်ကလက် mobile data တွင် ရှိသည်။ mobile mode ဖြင့် စမ်းပါ။
• ပြီးပြည့်စုံသော ၁၀၀ ကို လိုက်ခြင်း။ lab ရမှတ်က လမ်းညွှန်သာ ဖြစ်သည်။ Core Web Vitals သည် ကောင်းသောအကွာအဝေးတွင် ရောက်ပြီးနောက် အကြောင်းအရာနှင့် အသုံးပြုရလွယ်ကူမှုက နောက်ဆုံး အမှတ်အနည်းငယ်ထက် ပိုအရေးကြီးသည်။
• အရာအားလုံးကို lazy-load လုပ်ခြင်း၊ hero ပုံအပါအဝင်။ ၎င်းက LCP ကို ပိုဆိုးစေသည်။
• အပေါ်တွင် speed plugin သို့မဟုတ် library ထပ်ထည့်ခြင်း။ အလေးချိန် ဖယ်ခြင်းက ၎င်းကို စီမံရန် code ထည့်ခြင်းထက် အမြဲ ပိုကောင်းသည်။
• preview ကို optimise လုပ်ပြီး live ဆိုဒ်ကို မလုပ်ခြင်း။ development preview များသည် optimise မလုပ်ထားသော build များ run သည်။ ထုတ်ဝေထားသော URL ကို တိုင်းပါ။
• speed ကို တစ်ကြိမ်တည်း ပြင်ခြင်း။ widget၊ ပုံနှင့် feature အသစ်တိုင်းက အလေးချိန် ထပ်ထည့်သည်။ ကြီးမားသော ပြောင်းလဲမှုများ၏ နောက်တွင် ပြန်စမ်းပါ။

Speed စစ်ဆေးစာရင်း

• mobile တွင် LCP ≤ 2.5 s၊ INP ≤ 200 ms၊ CLS ≤ 0.1
• ပုံများကို ပြန်ချိန်ညှိ၊ ချုံ့၊ ခေတ်မီ format၊ width နှင့် height ပါ
• hero ပုံ lazy-load မလုပ်ထား၊ fold အောက် ပုံများ lazy-load လုပ်ထား
• မသုံးသော JavaScript library မရှိ၊ လေးလံသော route များ ခွဲထုတ်ထား
• font family နှစ်ခု သို့မဟုတ် ထို့အောက်၊ အဓိက font ကို preload လုပ်ထား
• အသုံးပြုသော third-party script များသာ၊ နောက်ကျမှ load
• ပြည်သူ့စာမျက်နှာများ နိုင်သလောက် prerender သို့မဟုတ် static
• ထုတ်ဝေပြီးနောက် တိုက်ရိုက် URL တွင် ပြန်စမ်းထား

Speed နှင့် mobile layout သည် အတူတူ လိုက်သည်၊ ဝဘ်ဆိုဒ်ကို mobile responsive ဖြစ်အောင် ပြုလုပ်နည်း ကို ကြည့်ပါ။ ထုတ်ဝေမီ အပြည့်အစုံ စစ်ဆေးမှုအတွက် AI prototype ကို production သို့ ယူသွားနည်း က ကျန်အရာများကို ဖုံးလွှမ်းသည်။

Mythex တွင် Speed

Mythex တွင် ဤပြောင်းလဲမှုများကို chat တွင် တောင်းဆိုခြင်း သို့မဟုတ် Pro တွင် code editor တွင် လုပ်နိုင်သည်။ Preview သည် development server run သဖြင့် ထုတ်ဝေထားသော URL ကို စစ်ပါ။ static front end များသည် ထုတ်ဝေသောအခါ static site အဖြစ် deploy လုပ်သည် (static websites)၊ ၎င်းက content စာမျက်နှာများနှင့် သင့်တော်သည်။ server ပါသော အက်ပ်များသည် zero သို့ scale လုပ်သည်- အလုပ်မရှိသောအခါ အိပ်ပြီး နောက်ဆက်တွဲ ဝင်ရောက်မှုတွင် နိုးသည်၊ ထို့ကြောင့် တိတ်ဆိတ်ပြီးနောက် ပထမတောင်းဆိုချက်က ပိုနှေးသည်၊ ချိတ်ထားသော database သည် အလုပ်မလုပ်သော မိနစ် ၅ ကြာလျှင် အိပ်သည် (hosting ကန့်သတ်ချက်များ)။ ပြည်သူ့စာမျက်နှာသည် ပထမ ဝင်ရောက်မှုတွင်သာ နှေးလျှင် ဖြစ်နိုင်သော အကြောင်းရင်း ဖြစ်သည်။ marketing စာမျက်နှာများကို static ထားခြင်းက ကူညီသည်။ ပြောင်းလဲပြီးနောက် ထပ်ထုတ်ဝေပြီး hard refresh လုပ်ပါ။

မေးခွန်းများ