First Input Delay (FID) နှင့် Interaction to Next Paint (INP)
တုံ့ပြန်မှုကို တိုင်းတာခြင်း: ပထမဆုံး အသုံးပြုမှု (FID) မှသည် အတွေ့အကြုံ တစ်ခုလုံး (INP) သို့
Section titled “တုံ့ပြန်မှုကို တိုင်းတာခြင်း: ပထမဆုံး အသုံးပြုမှု (FID) မှသည် အတွေ့အကြုံ တစ်ခုလုံး (INP) သို့”First Input Delay (FID)
Section titled “First Input Delay (FID)”- ဘာကို တိုင်းတာတာလဲ: FID က သုံးစွဲသူ Website ကို ပထမဆုံး စတင် အသုံးပြုတဲ့အချိန် (ဥပမာ - Link တစ်ခုကို နှိပ်တာ၊ ခလုတ်ကို နှိပ်တာ) ကနေ၊ Browser က အဲ့ဒီ လုပ်ဆောင်ချက်ကို စတင် တုံ့ပြန် (Response) ပေးနိုင်တဲ့ အချိန်အထိ ကြာချိန်ကို တိုင်းတာပါတယ်။
- ဘာကြောင့် အရေးကြီးတာလဲ: ဒါဟာ Website ရဲ့ အသုံးပြုမှု မြန်နှုန်းအပေါ် သုံးစွဲသူရဲ့ ပထမဆုံး ခံစားချက် (First Impression) ဖြစ်ပါတယ်။ FID ကြာနေရင် Website က နှေးကွေးပြီး ထစ်ငေါ့နေတယ် (Laggy ဖြစ်တယ်) လို့ ခံစားရစေပါတယ်။
- FID မကောင်းရခြင်းရဲ့ အဓိက အကြောင်းရင်းများ: JavaScript တွေ အရမ်း အလုပ်လုပ်နေတာ ဒါမှမဟုတ် Browser ရဲ့ အဓိက အလုပ်လုပ်တဲ့ လမ်းကြောင်း (Main Thread) ကြီး ပိတ်ဆို့နေလို့ ချက်ချင်း တုံ့ပြန်မှု မပေးနိုင်တာတွေကြောင့် အဓိက ဖြစ်ရတာပါ။
FID စံနှုန်း သတ်မှတ်ချက်များ:
- Good (ကောင်း): 100 milliseconds သို့မဟုတ် ထို့ထက်နည်း။
- Needs Improvement (တိုးတက်ရန် လို): 100ms မှ 300ms ကြား။
- Poor (ညံ့): 300ms ထက် ပိုကြာခြင်း။
Interaction to Next Paint (INP) - တုံ့ပြန်မှု မြန်နှုန်းအတွက် စံနှုန်းအသစ်
Section titled “Interaction to Next Paint (INP) - တုံ့ပြန်မှု မြန်နှုန်းအတွက် စံနှုန်းအသစ်”- ဘာကို တိုင်းတာတာလဲ: INP ဆိုတာက သုံးစွဲသူတွေရဲ့ လုပ်ဆောင်ချက် (Interactions) တွေအပေါ် Website ရဲ့ တုံ့ပြန်နိုင်စွမ်းကို ခြုံငုံပြီး တိုင်းတာပေးတဲ့ စံနှုန်းသစ် တစ်ခုပါ။ Website ကို အသုံးပြုနေစဉ် တစ်လျှောက်လုံး (နှိပ်တာတွေ၊ Keyboard သုံးတာတွေ အားလုံး) ရဲ့ နှေးကွေးမှုတွေကို မှတ်တမ်းတင်ပြီး၊ အဆိုးရွားဆုံး ဖြစ်ရပ်တွေထဲကနေ တွက်ချက်ထားတဲ့ တန်ဖိုးတစ်ခုကို အစီရင်ခံပေးပါတယ်။
အလွယ်မှတ်ရန်: INP တန်ဖိုး နိမ့်လေ၊ စာမျက်နှာရဲ့ တုံ့ပြန်မှုက ပိုမြန်လေ၊ ပိုချောမွေ့လေ ဖြစ်ပါတယ်။
- INP က ဘာကြောင့် FID ထက် ပိုကောင်းတာလဲ? ယခင်က သုံးခဲ့တဲ့ FID က ပထမဆုံး အသုံးပြုမှု တစ်ခုတည်းကိုသာ တိုင်းတာခဲ့တာပါ။ INP ကတော့ အသုံးပြုသူရဲ့ လုပ်ဆောင်ချက်တိုင်းကို (အသုံးပြုလိုက်တဲ့ အချိန်ကနေ နောက်ထပ် ရုပ်ထွက် (Frame) အသစ် ပေါ်လာတဲ့ အချိန်အထိ အပြည့်အစုံ) ထည့်သွင်း စဉ်းစားပါတယ်။ ဒါကြောင့် စာမျက်နှာ တစ်ခုလုံးရဲ့ တကယ် လက်တွေ့ တုံ့ပြန်နိုင်စွမ်းကို ပိုမို မှန်ကန်စွာ သိရှိနိုင်တာ ဖြစ်ပါတယ်။
INP တွက်ချက်ပုံ အဆင့် ၃ ဆင့်
Section titled “INP တွက်ချက်ပုံ အဆင့် ၃ ဆင့်”၁။ Input Delay: Browser က တုံ့ပြန်မှု စတင်ဖို့ မဖြစ်နိုင်သေးဘဲ စောင့်ဆိုင်းနေရတဲ့ အချိန် (များသောအားဖြင့် Main Thread မှာ အခြား အလုပ်တွေ လုပ်နေလို့ နှောင့်နှေးနေတာပါ)။ ၂။ Processing Time: အဲ့ဒီ လုပ်ဆောင်ချက်အတွက် လိုအပ်တဲ့ JavaScript Code တွေကို Run ဖို့ ကြာတဲ့ အချိန်။ ၃။ Presentation Delay: JavaScript လုပ်ဆောင်ပြီးသွားတဲ့ နောက်မှာ၊ Browser က ပြောင်းလဲသွားတဲ့ ရုပ်ထွက် (Next Frame) ကို မျက်နှာပြင်ပေါ် ပြသပေးဖို့ ကြာတဲ့ အချိန်။
INP က ဒီသုံးခုရဲ့ ပေါင်းလဒ်ကို Action တစ်ခုချင်းစီအတွက် အတိအကျ တိုင်းတာပါတယ်။
INP မကောင်းရခြင်းရဲ့ အဓိက အကြောင်းရင်းများ
Section titled “INP မကောင်းရခြင်းရဲ့ အဓိက အကြောင်းရင်းများ”- Main Thread (အဓိက အလုပ်လုပ်သည့်နေရာ) အလုပ်များနေခြင်း: JavaScript ကုဒ်တွေ အလွန်အမင်း များပြားနေခြင်း သို့မဟုတ် အလွန် ရှုပ်ထွေးတဲ့ တွက်ချက်မှုတွေ ပါဝင်နေခြင်း။
- DOM အရွယ်အစား ကြီးမားလွန်းခြင်း: HTML Element တွေ အရမ်းများရင် Browser က Render လုပ်ရတဲ့ လုပ်ငန်းစဉ် (Rendering Pipeline) ကြီး တစ်ခုလုံးကို နှေးကွေးသွားစေပါတယ်။
- ထိရောက်မှုမရှိသော Event Handlers များ: JavaScript Code တွေက ရှုပ်ထွေးနေတာ ဒါမှမဟုတ် သေချာ Optimize လုပ်မထားတဲ့အခါ တုံ့ပြန်မှုတွေကို နှောင့်နှေးစေပါတယ်။
- Third-party Scripts များ: ပြင်ပကနေ ထည့်သွင်းထားတဲ့ Script တွေ (ဥပမာ - Ads, Analytics) က Main Thread ကို အလုပ်များစေပြီး ကိုယ့် Website ရဲ့ တုံ့ပြန်မှုကိုပါ လာပြီး ထိခိုက်စေနိုင်ပါတယ်။
INP စံနှုန်း သတ်မှတ်ချက်များ:
- Good (ကောင်း): 200 milliseconds သို့မဟုတ် ထို့ထက်နည်း။
- Needs Improvement (တိုးတက်ရန် လို): 200ms မှ 500ms ကြား။
- Poor (ညံ့): 500ms ထက် ပိုကြာခြင်း။
FID နှင့် INP မြှင့်တင်ရန် နည်းဗျူဟာများ
Section titled “FID နှင့် INP မြှင့်တင်ရန် နည်းဗျူဟာများ”ဒီ Metrics နှစ်ခုလုံးက Main Thread ရဲ့ တုံ့ပြန်နိုင်စွမ်း (Responsiveness) နဲ့ တိုက်ရိုက် ဆက်စပ်နေတာကြောင့်၊ သူတို့ကို ကောင်းမွန်အောင် လုပ်ဆောင်ရမယ့် နည်းလမ်းတွေက ဆင်တူပါတယ်။
၁။ အချိန်ကြာတဲ့ လုပ်ငန်းစဉ်များ (Long Tasks) ကို ခွဲခြားပါ
Section titled “၁။ အချိန်ကြာတဲ့ လုပ်ငန်းစဉ်များ (Long Tasks) ကို ခွဲခြားပါ”- 50 ms ထက် ပိုကြာအောင် အလုပ်လုပ်ရတဲ့ JavaScript ဟာ Main Thread ကို ပိတ်ဆို့ (Block) ထားနိုင်ပါတယ်။
- အကြာကြီး အလုပ်လုပ်နေရတဲ့ Code တွေကို
setTimeoutဒါမှမဟုတ်requestIdleCallbackလို နည်းလမ်းတွေ သုံးပြီး အပိုင်းလေးတွေ (Chunks) ဖြစ်အောင် ခွဲခြား လုပ်ဆောင်ခိုင်းပါ။
၂။ JavaScript ကို ပိုမို အားကောင်းအောင် လုပ်ပါ (Optimize Execution)
Section titled “၂။ JavaScript ကို ပိုမို အားကောင်းအောင် လုပ်ပါ (Optimize Execution)”- မလိုအပ်တဲ့ JavaScript ပမာဏကို လျှော့ချပါ။
- ချက်ချင်း မလိုအပ်တဲ့ JavaScript တွေကို နောက်မှ ဖွင့်ပါ (Defer / Async)။
- Web Workers တွေကို အသုံးပြုပြီး လေးလံတဲ့ အလုပ် (Background Tasks) တွေကို Main Thread ပြင်ပမှာ လုပ်ဆောင်ပါ။
- ကိုယ်ရေးထားတဲ့ Code ရဲ့ Algorithm နဲ့ Data Structures တွေကို ပိုမို မြန်ဆန် ထိရောက်အောင် ပြင်ဆင်ပါ။
၃။ Main Thread ရဲ့ ဝန် (Load) ကို လျှော့ချပါ
Section titled “၃။ Main Thread ရဲ့ ဝန် (Load) ကို လျှော့ချပါ”- Website ပုံစံတွေ ရုတ်တရက် အကြီးအကျယ် ပြောင်းလဲတာ (Layout Thrashing) နဲ့ အလွန် ရှုပ်ထွေးတဲ့ CSS တွက်ချက်မှုတွေကို တတ်နိုင်သမျှ လျှော့ချပါ။
- DOM အရွယ်အစားနဲ့ ရှုပ်ထွေးမှုကို လျှော့ချပါ။ (အသုံးမလိုတဲ့ HTML Tags တွေ အများကြီး မထပ်ပါနဲ့)။
၄။ Third-Party Scripts များကို သတိထားပါ
Section titled “၄။ Third-Party Scripts များကို သတိထားပါ”- ပြင်ပ Script တွေရဲ့ သက်ရောက်မှုကို အမြဲ စစ်ဆေးပါ။ ဖြစ်နိုင်ရင် Lazy-load လုပ်တာ ဒါမှမဟုတ် Facades (ပုံစံတူ အစားထိုး) တွေကို အသုံးပြုပါ။
INP အတွက် ပြဿနာများကို ရှာဖွေခြင်း (Debugging)
Section titled “INP အတွက် ပြဿနာများကို ရှာဖွေခြင်း (Debugging)”- Chrome DevTools (Performance Tab):
- “Record” လုပ်ပြီး Website ကို လက်တွေ့ အသုံးပြုကြည့်ပါ (Interactions တွေကို မှတ်တမ်းတင်ပါ)။
- Main Thread ထဲမှာ အနီရောင်နဲ့ ပြနေတဲ့ “Long Tasks” တွေကို ရှာဖွေပါ။
- “Interactions” Lane မှာ အပေါ်ကပြောခဲ့တဲ့ Input Delay, Processing Time, Presentation Delay သုံးခုလုံးကို အသေးစိတ် ခွဲခြား ကြည့်ရှုပါ။
- Field Data (RUM Tools / CrUX):
- တကယ့် အပြင်က သုံးစွဲသူ (Real Users) တွေ ဆီကနေ ရလာတဲ့ INP တန်ဖိုးတွေကို လေ့လာဖို့အတွက် ဒါတွေက အလွန် အရေးကြီးပါတယ်။ Lab မှာ စမ်းသပ်တာနဲ့ အပြင်လက်တွေ့က မတူညီနိုင်လို့ပါ။