ပြီးခဲ့သော ၂၀၁၇ ခုနှစ်၊ ဖေဖော်ဝါရီလ ၂ ရက်နေ့က Ann Taylor သည် CodeInWP တွင် 12 Things We Need to See From WordPress Page Builders in 2017 + Who Already Gets It Right ဆောင်းပါးကို ရေးသားခဲ့ပါသည်။ ကျွန်ုပ်တို့သည် Page Builder Sandwich ကို တစ်နှစ်ကျော်ကြာ စဉ်ဆက်မပြတ် တိုးတက်ကောင်းမွန်အောင် လုပ်ဆောင်နေခဲ့သည်ဖြစ်ရာ သုတေသနများပြုလုပ်ခြင်း၊ သုံးစွဲသူများ၏ အသံကို နားထောင်ခြင်းများ ပြုလုပ်ခဲ့သောကြောင့် Page Builder Sandwich အနေဖြင့် CodeInWP ၏ “Who Got it Right” ဆောင်းပါးတွင် ပါဝင်လာလိမ့်မည်ဟု ထင်မှတ်ခဲ့ကြပါသည်။ သို့သော် စွမ်းဆောင်ရည်ပိုင်းဆိုင်ရာကြောင့် ကျွန်ုပ်တို့ မပါဝင်ခဲ့ရပါ။

ထို့ကြောင့် ကျွန်ုပ်တို့က Ann အား ထိုအကြောင်းကို မေးမြန်းခဲ့ရာ သူမက ယခုလို ပြန်လည်ဖြေကြားခဲ့ပါသည် –

…ကျွန်မ အခမဲ့ဗားရှင်းကို အနည်းငယ် စမ်းသပ်ကြည့်ခဲ့ပါတယ်။ မော်ဂျူးတွေ အများကြီးပါဝင်ပြီး အလွန်အလိုလိုသိနိုင်တဲ့ UI၊ ကောင်းမွန်တဲ့ WYSIWYG အတွေ့အကြုံနဲ့ အရာအားလုံးကို အလွယ်တကူ ဆွဲရွှေ့နိုင်တာကြောင့် အလားအလာအများကြီး ရှိတာကို တွေ့ရပါတယ်။ ဒါပေမဲ့ စာမျက်နှာပေါ်မှာ မော်ဂျူး ၁၀ ခုလောက် ရှိလာတဲ့အခါ တည်းဖြတ်မှုအမြန်နှုန်း နှေးကွေးသွားတဲ့အတွက် ဆက်လက်အလုပ်လုပ်ဖို့ ခက်ခဲလာခဲ့ပါတယ်…

ထို့ကြောင့် သူမ၏ အဆိုအရ Page Builder Sandwich တွင် စွမ်းဆောင်ရည်ပိုင်းဆိုင်ရာ ပြဿနာများ ရှိနေပါသည်။ ကျွန်ုပ်တို့သည် သုံးသပ်ချက်များကို အမြဲနားထောင်လေ့ရှိသည့်အတွက် ၎င်းကို စစ်ဆေးကြည့်ရှုခဲ့ကြပါသည်။

စွမ်းဆောင်ရည်ကို စမ်းသပ်စစ်ဆေးခြင်း

ကျွန်ုပ်တို့အနေဖြင့် PBS ၏ စွမ်းဆောင်ရည်ကို စစ်ဆေးရန် နည်းလမ်းတစ်ခု လိုအပ်ခဲ့ပါသည်။ PBS သည် ဘရောက်ဆာပေါ်တွင် Javascript ဖြင့် အဓိက အလုပ်လုပ်သောကြောင့် Chrome ၏ Timeline profiler သည် ဤလုပ်ငန်းအတွက် အသင့်တော်ဆုံး ကိရိယာဖြစ်ခဲ့ပါသည်။ Timeline profiler သည် runtime ကာလအတွင်း ဝဘ်စာမျက်နှာတစ်ခုတွင် မည်သည့်လုပ်ဆောင်ချက်များ ဖြစ်ပျက်နေသည်ကို ခွဲခြားသတ်မှတ် တိုင်းတာပေးနိုင်သောကြောင့် အမြန်နှုန်းနှောင့်နှေးစေသော အချက်များကို ရှာဖွေဖော်ထုတ်ရန် အလွန်ပင် ပြီးပြည့်စုံပါသည်။

ကျွန်ုပ်တို့သည် အခြေခံအကျဆုံး အဆင့်များကို အရင်ဆုံး စမ်းသပ်သင့်သည်ဟု ယူဆခဲ့ပါသည် – ၎င်းမှာ မောက်စ်ကို အစိတ်အပိုင်းများနှင့် အတန်းများစွာပေါ်တွင် ဖြတ်သန်းရွှေ့လျားစေခြင်း ဖြစ်ပါသည်။ ရိုးရှင်းပါသည် မဟုတ်လား။ ဤမျှရိုးရှင်းသော အရာတစ်ခုဖြင့် စွမ်းဆောင်ရည်ပြဿနာများနှင့် မကြုံတွေ့နိုင်ဟု ကျွန်ုပ်တို့ ယုံကြည်စိတ်ချခဲ့ပါသည်။ ကံမကောင်းစွာဖြင့် ကျွန်ုပ်တို့ မှားယွင်းခဲ့ပါသည်။

ကျွန်ုပ်တို့သည် record ခလုတ်ကို နှိပ်ပြီး မျက်နှာပြင်ပေါ်တွင် မောက်စ်ကို ၂ စက္ကန့်ခန့် ရွှေ့လျားစေခဲ့ပြီးနောက် stop ခလုတ်ကို နှိပ်ခဲ့ပါသည်။ profiler မှ ထွက်ပေါ်လာသော timeline မှာ အောက်ပါအတိုင်း ဖြစ်ပါသည် –

ကြည့်ပါဦး။ စွမ်းဆောင်ရည်ကို နှောင့်နှေးစေသော အတားအဆီးများ ပြည့်နှက်နေပါသည်!

ဂရပ်ဖ်ထဲတွင် ဖြစ်ပျက်နေသည့် အရာများစွာရှိသော်လည်း အထင်ရှားဆုံး ပြဿနာမှာ ခရမ်းရောင်ဧရိယာများ အလွန်များပြားနေခြင်းဖြစ်ပါသည် (ယင်းသို့ မဖြစ်သင့်ပါ)။ ထို့အပြင် ဤခရမ်းရောင်ဧရိယာများသည် အလွန်ကျယ်ပြန့်နေသည်ကို သိသာစွာ တွေ့မြင်ရပြီး အားလုံးနီးပါးသည် ဂရပ်ဖ်၏ အထွတ်အထိပ်သို့ ရောက်ရှိနေပုံရပါသည်။ ဂရပ်ဖ်သည် အမြဲတစေ ပြည့်နေပြီး ခရမ်းရောင်ဧရိယာများသည် သုညအထိ လျော့ကျသွားခြင်း မရှိသလောက်ဖြစ်နေသည်ကိုလည်း သတိပြုမိပါလိမ့်မည်။ ဘရောက်ဆာသည် တစ်ခုခုကို အမြဲတမ်း အလုပ်များစွာ လုပ်ဆောင်နေရပြီး အနားယူချိန် မရှိသလောက် ဖြစ်နေပုံရပါသည်။

ဒါပေမဲ့ ဒီခရမ်းရောင်ဧရိယာတွေအားလုံးက တကယ်တော့ ဘာကို ဆိုလိုတာပါလဲ။

ယင်းတို့ကို reflows ဟု ခေါ်ဆိုကြောင်း profiler က ဖော်ပြပေးခဲ့ပါသည်။ reflow ဆိုသည်မှာ မည်သည့်အရာဖြစ်ကြောင်းကို Google Developer ဝဘ်ဆိုက်:

Reflow ဆိုသည်မှာ စာရွက်စာတမ်း (document) အတွင်းရှိ အစိတ်အပိုင်းများ၏ တည်နေရာများနှင့် ဂျီဩမေတြီများကို ပြန်လည်တွက်ချက်ရန်အတွက် ဝဘ်ဘရောက်ဆာ၏ လုပ်ဆောင်ချက်အမည် ဖြစ်သည်.. reflow သည် ဘရောက်ဆာအတွင်း အသုံးပြုသူ၏ လုပ်ဆောင်ချက်ကို ရပ်တန့်စေသော (user-blocking) လုပ်ငန်းစဉ်တစ်ခု ဖြစ်သည်။

ဆိုလိုသည်မှာ PBS တွင် သင်၏ မောက်စ်ကို ရွှေ့လျားလိုက်ခြင်းသည် reflows အမြောက်အမြားကို ဖြစ်ပေါ်စေပါသည်။ ပိုဆိုးသည်မှာ reflow တစ်ခုစီတိုင်းသည် ၎င်း၏ တွက်ချက်မှုများကို အပြီးသတ်နိုင်ရန်အတွက် ဘရောက်ဆာကို ခေတ္တခဏ ရပ်တန့်သွားစေခြင်း ဖြစ်ပါသည်။ reflow ပိုများလေလေ ဘရောက်ဆာ ရပ်တန့်မှု ပိုများလေလေဖြစ်ပြီး အသုံးပြုရသည့် အတွေ့အကြုံမှာ ပိုမိုထစ်ငေါ့တုန်ခါ (janky) လာလေလေ ဖြစ်ပါသည်။ ရိုးရှင်းစွာ ပြောရလျှင် ခရမ်းရောင်ဧရိယာ များများ = ဆိုးရွားခြင်း ဖြစ်ပါသည်။

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

ကျွန်ုပ်တို့၏ Reflow / Jank ပြဿနာကို ဖြေရှင်းခြင်း

အခြားမည်သည့်အရာကိုမျှ မလုပ်ဆောင်မီ ပထမဦးစွာ ဤ reflow ကို အဓိကဖြစ်စေသည့် အကြောင်းရင်းကို သိရှိနိုင်ရန် သုတေသနအချို့ ပြုလုပ်ရန် လိုအပ်ခဲ့ပါသည်။ သိသာထင်ရှားသည်မှာ Javascript ရှိ အသုံးများသော လုပ်ဆောင်ချက် အများအပြားသည် ဘရောက်ဆာကို reflow ဖြစ်ပေါ်စေရန် လှုံ့ဆော်ပေးနိုင်ကြောင်း ကျွန်ုပ်တို့ တွေ့ရှိခဲ့ရပါသည်။

DOM element တစ်ခု၏ အနံ၊ အမြင့် သို့မဟုတ် တည်နေရာကို ရယူရန် သင်အသုံးပြုနိုင်သည့် မည်သည့် function မဆိုနီးပါးသည် reflow ကို ဖြစ်ပေါ်စေနိုင်ပါသည်။ Paul Irish သည် ဤသို့ဖြစ်စေနိုင်သော Javascript ရှိ properties နှင့် functions များ အားလုံး၏ ပြည့်စုံသော စာရင်းတစ်ခုကို ရေးသားဖော်ပြခဲ့ပါသည်။ သတင်းဆိုးမှာ Page Builder Sandwich သည် reflow ကို ဖြစ်စေသည့် အောက်ပါ properties နှင့် functions အများအပြားကို အသုံးပြုထားခြင်း ဖြစ်ပါသည် –

• elem.getBoundingClientRect()
• window.getComputedStyle()
• window.scrollY
• နှင့် အခြားအရာများစွာ…

ဖြေရှင်းနည်း ၁- ကုန်ကျစရိတ်များသော Reflow လုပ်ဆောင်ချက်များကို Cache ပြုလုပ်ခြင်း

အရှင်းလင်းဆုံး ဖြေရှင်းချက်မှာ ထို properties နှင့် functions များကို လုံးဝအသုံးမပြုခြင်း ဖြစ်ပါသည်။ သို့သော် PBS သည် ၎င်းတို့အပေါ် အလွန်အမင်း မှီခိုနေရပြီး ၎င်းတို့မပါဘဲ လုပ်ဆောင်ရန် မဖြစ်နိုင်ပါ။

ကျွန်ုပ်တို့အတွက် ကျန်ရှိသော ဖြေရှင်းချက်မှာ အဆိုပါ functions များကို ခေါ်ယူအသုံးပြုမှု အရေအတွက်ကို တတ်နိုင်သမျှ လျှော့ချရန် ဖြစ်ပါသည်။ ဤနေရာတွင် ခက်ခဲသောအချက်မှာ ကျွန်ုပ်တို့သည် ထို properties နှင့် functions များကို PBS ၏ အစိတ်အပိုင်းအသီးသီးတွင် အကြိမ်ပေါင်းများစွာ အသုံးပြုထားပြီး အများစုမှာ တူညီသော DOM element တစ်ခုတည်းပေါ်တွင် အကြိမ်များစွာ အသုံးပြုထားခြင်း ဖြစ်ပါသည်။ ၎င်းကို ဖြေရှင်းရန်အတွက် ပြဿနာဖြစ်စေသော property/function တစ်ခုစီအတွက် ကျွန်ုပ်တို့ကိုယ်ပိုင် caching စနစ်တစ်ခုကို ဖန်တီးခဲ့ပါသည်။

ဥပမာအားဖြင့် getBoundingClientRect function သည် DOM element တစ်ခု၏ လက်ရှိ top၊ left၊ width၊ height၊ right နှင့် bottom pixel တိုင်းတာချက်များကို ပေးပါသည်။ PBS တွင် element outlines များကို မည်သည့်နေရာတွင် ရေးဆွဲရမည်ကို တွက်ချက်ရန်အတွက် ဤ function ကို အချိန်တိုင်း အသုံးပြုပါသည်။ ဤအတွက် ကျွန်ုပ်တို့ ဖန်တီးခဲ့သော caching function မှာ အောက်ပါအတိုင်း ဖြစ်ပါသည် –

// Cache: Our client rects are kept here, we can use this to clear them later.
var elemsWithBoundingRects = [];

window.pbsGetBoundingClientRect = function( element ) {

	// Check if we already got the client rect before.
	if ( ! element._boundingClientRect ) {

		// If not, get it then store it for future use.
		element._boundingClientRect = element.getBoundingClientRect();
		elemsWithBoundingRects.push( element );
	}
	return element._boundingClientRect;
};
​

getBoundingClientRect ကို တိုက်ရိုက်ခေါ်ယူမည့်အစား ယခုအခါ pbsGetBoundingClientRect ကို အသုံးပြုခဲ့ပါသည်။ ယခုအခါ client rect ကို မေးမြန်းတိုင်း နောင်တွင် ကိုးကားအသုံးပြုနိုင်ရန်အတွက် ထိုတန်ဖိုးကို သိမ်းဆည်းထားပြီး reflow ဖြစ်ပေါ်စေသည့် အကြိမ်အရေအတွက်ကို ကန့်သတ်ပေးပါသည်။

သိမ်းဆည်းထားသော client rects များ မမှန်ကန်တော့သည့်အခါ (invalidated ဖြစ်သည့်အခါ) cache ကို ရှင်းလင်းရန် နည်းလမ်းတစ်ခုလည်း လိုအပ်ခဲ့ပါသည်။ အသုံးပြုသူသည် စာမျက်နှာကို scroll လုပ်သောအခါ သို့မဟုတ် မျက်နှာပြင်ပေါ်တွင် elements များကို ထည့်သွင်းခြင်း/ပြောင်းလဲခြင်း/ဖယ်ရှားခြင်းများ ပြုလုပ်သောအခါ သိမ်းဆည်းထားသော client rect တန်ဖိုးများသည် ပြောင်းလဲသွားပါသည်။ ထို့ကြောင့် client rect တန်ဖိုးအသစ်များ လိုအပ်သည့်အခါတိုင်း ကျွန်ုပ်တို့ ခေါ်ယူနိုင်သော cache ရှင်းလင်းသည့် function တစ်ခုကို ဖန်တီးခဲ့ပါသည် –

var clearClientRects = function() {
	var i;
	for ( i = 0; i < elemsWithBoundingRects.length; i++ ) {
		if ( elemsWithBoundingRects[ i ] ) {
			elemsWithBoundingRects[ i ]._boundingClientRect = null;
		}
	}
	elemsWithBoundingRects = [];
};​

ကျွန်ုပ်တို့ ပုံမှန်အသုံးပြုလေ့ရှိသော ကုန်ကျစရိတ်များသည့် အခြား function calls များအတွက်လည်း အလားတူ caching စနစ်ကို လုပ်ဆောင်ခဲ့ပါသည်။

ဖြေရှင်းနည်း ၂- FastDom ကို အသုံးပြု၍ ဖတ်ခြင်းနှင့် ရေးခြင်းများကို စုစည်းပေးခြင်း

ဖြေရှင်းနည်း ၁ ကို အကောင်အထည်ဖော်ခြင်းက PBS ၏ စွမ်းဆောင်ရည်ကို မြှင့်တင်ပေးခဲ့သော်လည်း ၎င်းသည် လုံလောက်မှု မရှိသေးပါ။

Google တွင် ထပ်မံရှာဖွေကြည့်သောအခါ Wilson Page ၏ ‘layout thrashing’ ကို တားဆီးခြင်း ဆိုင်ရာ ဆောင်းပါးတစ်ပုဒ်ကို တွေ့ရှိခဲ့ပါသည်။ Wilson က ယခုလို ဆိုပါသည် –

Layout Thrashing (reflow) ဆိုသည်မှာ JavaScript သည် DOM ထံမှ အကြိမ်များစွာ ပြင်းထန်စွာ ရေးသားပြီးနောက် ဖတ်ယူခြင်းကြောင့် document reflows များ ဖြစ်ပေါ်လာခြင်း ဖြစ်သည်။

ជាក់ស្តែងအားဖြင့် reflow ကို ဖြစ်စေသော သီးခြား properties နှင့် functions များ ခေါ်ယူမှုကို ကန့်သတ်ရုံဖြင့် မလုံလောက်ပါ။ DOM ပေါ်တွင် “ဖတ်ခြင်း (reads)” နှင့် “ရေးခြင်း (writes)” များကို ဆက်တိုက်အကြိမ်ကြိမ် လုပ်ဆောင်သောအခါ ၎င်းသည် ဘရောက်ဆာ reflow ကိုလည်း ဖြစ်ပေါ်စေပါသည်။ Wilson ၏ ဝဘ်ဆိုက်မှ တိုက်ရိုက်ဖော်ပြထားသော ပုံမှန်အခြေအနေတစ်ခုမှာ အောက်ပါအတိုင်း ဖြစ်ပါသည် –

// Read
var h1 = element1.clientHeight;

// Write (invalidates layout)
element1.style.height = (h1 * 2) + 'px';

// Read (triggers reflow)
var h2 = element2.clientHeight;

// Write (invalidates layout)
element2.style.height = (h2 * 2) + 'px';

// Read (triggers reflow)
var h3 = element3.clientHeight;

// Write (invalidates layout)
element3.style.height = (h3 * 2) + 'px';

// Document reflows at end of frame​

ရေးသားမှုတစ်ခု ပြုလုပ်ပြီးနောက် စာမျက်နှာတစ်ခုလုံး၏ အတိုင်းအတာများ မမှန်ကန်တော့သည့်အတွက် အထက်ပါနမူနာသည် reflow ၃ ကြိမ် ဖြစ်ပေါ်စေပါသည်။ ဤအတွက် အကြံပြုထားသော ပြင်ဆင်ချက်မှာ အရာအားလုံးသည် ဘရောက်ဆာ reflow ၁ ကြိမ်သာ ဖြစ်ပေါ်စေရန်အတွက် ဖတ်ခြင်းများနှင့် ရေးခြင်းများအားလုံးကို အတူတကွ စုစည်းပေးနိုင်ရန် ကုဒ်ကို ပြန်လည်စီစဉ်ခြင်း ဖြစ်ပါသည် –

// Read
var h1 = element1.clientHeight;
var h2 = element2.clientHeight;
var h3 = element3.clientHeight;

// Write (invalidates layout)
element1.style.height = (h1 * 2) + 'px';
element2.style.height = (h2 * 2) + 'px';
element3.style.height = (h3 * 2) + 'px';

// Document reflows at end of frame​

အထက်ပါ ကုဒ်အပိုင်းအစသည် ပြဿနာကို ဖြေရှင်းရလွယ်ကူသယောင် ထင်ရစေပါသည်။ သို့သော် လက်တွေ့တွင် PBS ၏ သက်တမ်းကာလတစ်လျှောက်တွင် reflow ဖြစ်စေသောအရာများကို ဖတ်ခြင်းနှင့် ရေးခြင်းသည် နေရာအမျိုးမျိုးနှင့် အချိန်အမျိုးမျိုးတွင် ဖြစ်ပွားလေ့ရှိပါသည်။ Javascript ကုဒ်လိုင်းပေါင်း ထောင်ပေါင်းများစွာကို ပြန်လည်စီစဉ်ဖွဲ့စည်းရန်မှာ မဖြစ်နိုင်ပါ။

ကျွန်ုပ်တို့အတွက် ကံကောင်းသည်မှာ Wilson သည် သူ၏ ဆောင်းပါးတွင် ဖြေရှင်းချက်တစ်ခုကိုလည်း ဖော်ပြပေးခဲ့ပါသည်။ သူသည် ထိုသို့ ဖတ်ခြင်းများနှင့် ရေးခြင်းများကို စုစည်းပေးရာတွင် ကူညီရန်အတွက် FastDom ဟုခေါ်သော အသုံးဝင်သည့် ဇာတ်ညွှန်း (utility script) အသေးစားတစ်ခုကို ဖန်တီးခဲ့ပါသည်။

FastDom ကို အသုံးပြုထားပြီး အထက်ပါ ကျွန်ုပ်တို့၏ ဖြေရှင်းနည်း ၁ ကိုလည်း ထည့်သွင်းထားသော Page Builder Sandwich မှ ကုဒ်အချို့မှာ အောက်ပါအတိုင်း ဖြစ်ပါသည် –

// Bunch together the reads from other threads.
fastdom.measure( function() {

	// Use our cached client rect.
	var rect = window.pbsGetBoundingClientRect( elem );

	// Bunch together the writes from other threads.
	fastdom.mutate( function() {
		elem.style.top = ( rect.top + window.pbsScrollY() ) + 'px';
		elem.style.height = rect.height + 'px';
		elem.style.left = rect.left + 'px';
		elem.style.width = rect.width + 'px';
	}.bind( this ) );
}.bind( this ) );​

FastDom ပြုလုပ်ပေးသည့် အရာမှာ fastdom.measure ခေါ်ယူမှုများ အားလုံးနှင့် fastdom.mutate ခေါ်ယူမှုများ အားလုံးကို အုပ်စုဖွဲ့ကာ ၎င်းတို့ကို တပြိုင်နက်တည်းမဟုတ်ဘဲ သီးခြားစီ (asynchronously) လုပ်ဆောင်စေခြင်းဖြင့် ဘရောက်ဆာအတွင်းရှိ reflows များအားလုံးကို လျှော့ချရန် ဖတ်ခြင်းများနှင့် ရေးခြင်းများအားလုံးကို ထိရောက်စွာ စုစည်းပေးခြင်း ဖြစ်ပါသည်။

ဖြေရှင်းနည်း ၃- Style Object များကို ဝင်ရောက်ရယူခြင်းသည် ကုန်ကျစရိတ်များပြားခြင်း

jsPerf ၏ အကူအညီဖြင့် အချို့သော style-getting functions များသည် အခြားအရာများထက် ပိုမိုမြန်ဆန်ကြောင်းကိုလည်း ကျွန်ုပ်တို့ တွေ့ရှိခဲ့ပါသည်။

PBS တွင် element တစ်ခု၏ သီးခြား style တစ်ခု၏ လက်ရှိတန်ဖိုးကို ရယူရန် မကြာခဏ လိုအပ်လေ့ရှိပါသည်။ ဥပမာအားဖြင့် top margin ကို ရယူရန် ပုံမှန်အားဖြင့် ဤအရာကို အသုံးပြုပါသည် –

var styles = window.getComputedStyle( elem );
var marginTop = styles.marginTop;​

သို့သော် ယခုလို လုပ်ဆောင်ခြင်းက ပိုမိုမြန်ဆန်ကြောင်း ကျွန်ုပ်တို့ တွေ့ရှိခဲ့ပါသည် –

var marginTop = elem.style.marginTop;​

သို့ရာတွင် elem.style.marginTop နှင့် getComputedStyle တို့သည် များစွာ ကွဲပြားခြားနားပါသည်။ ပထမတစ်ခုသည် element ၏ inline styling ကိုသာ ပေးစွမ်းပြီး မည်သည့် stylesheets များကိုမျှ ထည့်သွင်းစဉ်းစားခြင်း မရှိပါ၊ ဒုတိယတစ်ခုသည် inline styles များနှင့် stylesheets နှစ်ခုစလုံးကို ထည့်သွင်းစဉ်းစားပါသည်။

ထို့ထက်မက getComputedStyle ရလဒ်ကို cache ပြုလုပ်ထားသည့်တိုင် အလွန်နှေးကွေးနေဆဲ ဖြစ်ပါသည်။ အမှန်စင်စစ်တွင် style object ကိုယ်တိုင်ကို ဝင်ရောက်ရယူခြင်းသည် နှေးကွေးသော လုပ်ငန်းစဉ်ဖြစ်နေကြောင်း တွေ့ရှိရပါသည်။

ကျွန်ုပ်တို့အတွက် ကံကောင်းသည်မှာ PBS သည် inline styles များကို elements များသို့ ထည့်သွင်းပေးထားပြီး inline styles များသည် stylesheets များထက် (အချိန်အများစုတွင်) ဦးစားပေးမှု ပိုမိုရရှိသောကြောင့် inline style တန်ဖိုးကို ရယူခြင်းဖြင့် လုံလောက်မည့် အခြေအနေများ ရှိလာမည်ဖြစ်ပါသည်။ ထို့ကြောင့် အထက်ပါ နည်းလမ်းနှစ်ခုကို ပေါင်းစပ်လိုက်ပါက ပိုမိုမြန်ဆန်စွာ အလုပ်လုပ်သော ကုဒ်တစ်ခုကို ဖန်တီးနိုင်မည် ဖြစ်ပါသည် –

var marginTop = elem.style.marginTop;
if ( ! marginTop ) {
	var styles = window.getComputedStyle( elem );
	marginTop = styles.marginTop;
}​

ကုဒ်တိုးတက်ကောင်းမွန်အောင် ပြုလုပ်ခြင်း၏ ရလဒ်များ

ကျွန်ုပ်တို့၏ အထက်ပါ ဖြေရှင်းနည်း ၃ ခုသည် သုတေသနပြုခြင်း၊ စမ်းသပ်ခြင်းနှင့် လက်တွေ့အကောင်အထည်ဖော်ခြင်းများစွာ ပြုလုပ်ခဲ့ရပါသည် (ကျွန်ုပ်တို့၏ Fonts လုပ်ဆောင်ချက် ထွက်ရှိမှုကိုလည်း နှောင့်နှေးစေခဲ့ပါသည်)၊ သို့သော် နောက်ဆုံးတွင် အားလုံးသည် တန်ဖိုးရှိခဲ့ပါသည်။

မျက်နှာပြင်ပေါ်တွင် မောက်စ်ကို ၂ စက္ကန့်ကြာ ရွှေ့လျားစေသည့် ကျွန်ုပ်တို့၏ ကနဦးစမ်းသပ်မှုသို့ ပြန်သွားကြည့်ကြပါစို့။ ဤသည်မှာ ယခင်က ရုပ်ဆိုးပြီး ထစ်ငေါ့နေသော timeline ဖြစ်ပါသည် –

စွမ်းဆောင်ရည် တိုးတက်ကောင်းမွန်အောင် ပြုလုပ်ပြီးနောက် ကျွန်ုပ်တို့၏ timeline အသစ်သည် အောက်ပါအတိုင်း ဖြစ်ပါသည် –

သင်တွေ့မြင်နိုင်သည့်အတိုင်း ဂရပ်ဖ်တွင် ခရမ်းရောင်အရာများ နည်းပါးသွားပါသည်။ ဘရောက်ဆာမှ လုပ်ဆောင်နေသော လုပ်ငန်းစဉ်ပမာဏတွင်လည်း သိသာထင်ရှားသော ကွာခြားချက်တစ်ခု ရှိပါသည်။ အောက်ခြေရှိ လေးထောင့်ပုံစံများသည်လည်း ပိုမိုပါးလွှာသွားပြီး လုပ်ငန်းစဉ်များသည် ယခင်ကထက် ပိုမိုမြန်ဆန်စွာ လုပ်ဆောင်နေပြီဖြစ်ကြောင်း ပြသနေပါသည်။

ဂရပ်ဖ်အဟောင်းနှင့် အသစ်ရှိ မြင့်မား/ကျယ်ပြန့်သော ခရမ်းရောင်ဧရိယာပမာဏကို နှိုင်းယှဉ်ကြည့်ပါက အလွန်ကြီးမားသော စွမ်းဆောင်ရည် ၂၀၀% တိုးတက်မှု ကို တွေ့မြင်နေရခြင်း ဖြစ်ပါသည်! ကဏ္ဍအားလုံးတွင်လည်း စွမ်းဆောင်ရည် တိုးတက်မှုများကို တွေ့မြင်နေရပါသည်။ လုံးဝ မဆိုးပါဘူး!

ရရှိခဲ့သော အချက်များနှင့် သင်ခန်းစာများ

ရိုးရိုးသားသားပြောရလျှင် Ann ထောက်ပြမပြောဆိုမီအထိ PBS တွင် စွမ်းဆောင်ရည်ပြဿနာများ ရှိနေသည်ဟု ကျွန်ုပ်တို့ မထင်ခဲ့ကြပါ။ အဓိကအားဖြင့် ကျွန်ုပ်တို့သည် ဖွံ့ဖြိုးတိုးတက်ရေးကို ဦးတည်ထားသော စက်များကို အသုံးပြုနေခဲ့ကြသောကြောင့် စွမ်းဆောင်ရည် နှောင့်နှေးမှုများသည် ထိုမျှလောက် မသိသာခဲ့သောကြောင့် ဖြစ်ပါသည်။ ပြန်လည်သုံးသပ်ကြည့်ပါက စွမ်းဆောင်ရည်ကို စစ်ဆေးခြင်းသည် ထိပ်တန်းဦးစားပေးများထဲမှ တစ်ခုဖြစ်သင့်ခဲ့ပါသည်။ သို့သော် အနည်းဆုံးတော့ ယခုအခါ ဗားရှင်း ၄.၃ အရ အားလုံးကို ဖြေရှင်းဆောင်ရွက်ပြီး ဖြစ်ပါသည်။

မိမိတို့၏ WordPress plugin စွမ်းဆောင်ရည်ကို အထူးသဖြင့် လေးလံသော Javascript ကို အသုံးပြုနေပါက မြှင့်တင်လိုသူများအတွက် ဤအတွေ့အကြုံမှ ကျွန်ုပ်ရရှိခဲ့သော သင်ခန်းစာများမှာ အောက်ပါအတိုင်း ဖြစ်ပါသည် –

1. Reflow ကို ဖြစ်ပေါ်စေသော properties/functions များကို ခေါ်ယူမှုများကို ကန့်သတ်ပါ/cache ပြုလုပ်ပါ။ လမ်းညွှန်အဖြစ် ဤအရာကို အသုံးပြုပါ – What forces layout/reflow. The comprehensive list.
2. DOM styles များသို့ “ဖတ်ခြင်း” နှင့် “ရေးခြင်း” များကို အတူတကွ စုစည်းပါ။ သင့်အတွက် ဤအရာကို လုပ်ဆောင်ပေးရန် FastDom ကို အသုံးပြုပါ။
3. Chrome ၏ Timeline profiler ကို အသုံးပြုပြီး သင့်ထံတွင် reflows (ခရမ်းရောင်အရာများ) တတ်နိုင်သမျှ နည်းပါးအောင် သေချာအောင် ပြုလုပ်ပါ။