ວິທີທີ່ພວກເຮົາເພີ່ມປະສິດທິພາບຂອງປລັກອິນຂຶ້ນ 200%

ວັນທີ 2 ກຸມພາ 2017 ຜ່ານມາ, Ann Taylor ໄດ້ຂຽນບົດຄວາມ 12 Things We Need to See From WordPress Page Builders in 2017 + Who Already Gets It Right ໃນ CodeInWP. ພວກເຮົາໄດ້ປັບປຸງ Page Builder Sandwich ຢ່າງຕໍ່ເນື່ອງມາເປັນເວລາດົນກວ່າໜຶ່ງປີແລ້ວ: ພວກເຮົາເຮັດການຄົ້ນຄວ້າ, ຮັບຟັງລູກຄ້າຂອງພວກເຮົາ, ດັ່ງນັ້ນພວກເຮົາຈຶ່ງຄິດວ່າ Page Builder Sandwich ຈະຕິດຢູ່ໃນບົດຄວາມ “Who Got it Right” ຂອງ CodeInWP. ແຕ່ພວກເຮົາບໍ່ຕິດ, ເນື່ອງຈາກປະສິດທິພາບການເຮັດວຽກ. 

ດັ່ງນັ້ນ ພວກເຮົາຈຶ່ງໄດ້ຖາມ Ann ກ່ຽວກັບເລື່ອງນີ້, ແລະ ນາງໄດ້ຕອບວ່າ:

…ຂ້ອຍໄດ້ລອງຫຼິ້ນລຸ້ນຟຣີໜ້ອຍໜຶ່ງ. ມັນເບິ່ງຄືວ່າມີອະນາຄົດຫຼາຍ: ມີໂມດູນຫຼາຍ, UI ທີ່ໃຊ້ງານງ່າຍພໍສົມຄວນ, ປະສົບການ WYSIWYG ທີ່ດີເລີດ, ທຸກຢ່າງຖືກລາກໄປມາໄດ້ງ່າຍດາຍ. ຢ່າງໃດກໍຕາມ, ເມື່ອຂ້ອຍມີປະມານ 10 ໂມດູນໃນໜ້າ, ມັນເລີ່ມຍາກທີ່ຈະເຮັດວຽກຕໍ່ໄປໄດ້ ເນື່ອງຈາກຄວາມໄວໃນການແກ້ໄຂຊ້າ…

ສະນັ້ນ ຕາມທີ່ນາງບອກ, Page Builder Sandwich ມີບັນຫາເລື່ອງປະສິດທິພາບ. ແລະ ເນື່ອງຈາກພວກເຮົາຮັບຟັງຄໍາຕິຊົມສະເໝີ, ພວກເຮົາຈຶ່ງໄດ້ກວດສອບເລື່ອງນີ້.

ການທົດສອບປະສິດທິພາບ

ພວກເຮົາຕ້ອງການວິທີການເພື່ອກວດສອບປະສິດທິພາບຂອງ PBS; ເນື່ອງຈາກ PBS ສ່ວນຫຼາຍເຮັດວຽກຢູ່ເທິງບຣາວເຊີຜ່ານ Javascript, Chrome’s Timeline profiler ຈຶ່ງເປັນເຄື່ອງມືທີ່ເໝາະສົມສໍາລັບວຽກນີ້. Timeline profiler ສາມາດລະບຸ ແລະ ວັດແທກຂະບວນການທີ່ກໍາລັງເກີດຂຶ້ນໃນໜ້າເວັບລະຫວ່າງການເຮັດວຽກ, ເຊິ່ງເໝາະສົມທີ່ສຸດສໍາລັບການຄົ້ນຫາຈຸດຕິດຂັດຂອງຄວາມໄວ.

ພວກເຮົາຄິດວ່າພວກເຮົາຄວນທົດສອບຂັ້ນຕອນທີ່ງ່າຍທີ່ສຸດກ່ອນ – ຄືການເລື່ອນເມົ້າຜ່ານຫຼາຍໆ ອົງປະກອບ ແລະ ແຖວ. ງ່າຍແມ່ນບໍ່? ພວກເຮົາໝັ້ນໃຈວ່າພວກເຮົາຈະບໍ່ພົບບັນຫາປະສິດທິພາບກັບສິ່ງທີ່ງ່າຍໆ ແບບນີ້. ແຕ່ໜ້າເສຍດາຍ, ພວກເຮົາຄິດຜິດ.

ເມື່ອພວກເຮົາກົດປຸ່ມບັນທຶກ, ພວກເຮົາໄດ້ເລື່ອນເມົ້າປະມານ 2 ວິນາທີເທິງໜ້າຈໍ, ຈາກນັ້ນກົດປຸ່ມຢຸດ.  ນີ້ຄືຜົນລວມຂອງ timeline ຈາກ profiler:

ແລະ ແລ້ວກໍເຫັນ. ມັນເຕັມໄປດ້ວຍຈຸດຕິດຂັດຂອງປະສິດທິພາບ!

ມີຫຼາຍສິ່ງເກີດຂຶ້ນໃນກຣາຟ, ແຕ່ບັນຫາທີ່ເຫັນໄດ້ຊັດເຈນທີ່ສຸດຄືມີພື້ນທີ່ສີມ່ວງຫຼາຍ (ເຊິ່ງບໍ່ຄວນຈະເປັນແບບນັ້ນ). ຍິ່ງໄປກວ່ານັ້ນ, ພື້ນທີ່ສີມ່ວງເຫຼົ່ານີ້ກວ້າງຫຼາຍຢ່າງເຫັນໄດ້ຊັດ, ແລະ ທັງໝົດເບິ່ງຄືວ່າຈະຂຶ້ນຮອດຈຸດສູງສຸດຂອງກຣາຟ. ທ່ານຍັງຈະສັງເກດເຫັນອີກວ່າກຣາຟເຕັມຕະຫຼອດເວລາ, ແລະ ພື້ນທີ່ສີມ່ວງແທບຈະບໍ່ເຄີຍຫຼຸດລົງຮອດສູນເລີຍ. ມັນເບິ່ງຄືວ່າບຣາວເຊີກໍາລັງຫຍຸ້ງຢູ່ກັບການເຮັດບາງຢ່າງຕະຫຼອດເວລາ, ແລະ ແທບບໍ່ໄດ້ພັກຜ່ອນເລີຍ.

ແຕ່ພື້ນທີ່ສີມ່ວງທັງໝົດເຫຼົ່ານັ້ນໝາຍເຖິງຫຍັງແທ້ໆ?

ຕົວ profiler ໄດ້ບອກພວກເຮົາວ່າພວກມັນຖືກເອີ້ນວ່າ reflows. ນີ້ຄືຄໍານິຍາມຂອງ reflow ຈາກ ເວັບໄຊ Google Developer:

Reflow ແມ່ນຊື່ຂອງຂະບວນການຂອງເວັບບຣາວເຊີສໍາລັບການຄິດໄລ່ຕໍາແໜ່ງ ແລະ ຮູບຮ່າງເລຂາຄະນິດຂອງອົງປະກອບຕ່າງໆ ໃນເອກະສານຄືນໃໝ່.. reflow ແມ່ນການດໍາເນີນງານທີ່ຂັດຂວາງການເຮັດວຽກຂອງຜູ້ໃຊ້ໃນບຣາວເຊີ.

ດັ່ງນັ້ນ ນີ້ໝາຍຄວາມວ່າການເລື່ອນເມົ້າໄປມາໃນ PBS ຈະກະຕຸ້ນໃຫ້ເກີດ reflow ຈໍານວນມະຫາສານ. ສິ່ງທີ່ຮ້າຍແຮງກວ່ານັ້ນແມ່ນ ແຕ່ລະ reflow ຈະຢຸດບຣາວເຊີຊົ່ວຄາວເພື່ອໃຫ້ມັນສາມາດຄິດໄລ່ສໍາເລັດ. reflow ຫຼາຍຂຶ້ນໝາຍເຖິງການຢຸດຊົ່ວຄາວຂອງບຣາວເຊີຫຼາຍຂຶ້ນ, ແລະ ປະສົບການການໃຊ້ງານກໍຈະຍິ່ງກະຕຸກ. ເວົ້າງ່າຍໆ ກໍຄື, ພື້ນທີ່ສີມ່ວງຫຼາຍ = ບໍ່ດີ.

ສະຫຼຸບແລ້ວ Ann ເວົ້າຖືກ: ພວກເຮົາມີຈຸດຕິດຂັດດ້ານປະສິດທິພາບອັນໃຫຍ່ຫຼວງແທ້ໆ, ດັ່ງນັ້ນທີມງານຂອງພວກເຮົາຈຶ່ງເລີ່ມລົງມືແກ້ໄຂມັນທັນທີ.

ການແກ້ໄຂບັນຫາ Reflow / ອາການກະຕຸກຂອງພວກເຮົາ

ກ່ອນສິ່ງອື່ນໃດ, ພວກເຮົາຈໍາເປັນຕ້ອງເຮັດການຄົ້ນຄວ້າບາງຢ່າງເພື່ອຊອກຮູ້ວ່າອັນໃດເປັນສາເຫດທີ່ເຮັດໃຫ້ເກີດ reflow ນີ້ຕັ້ງແຕ່ທໍາອິດ. ພວກເຮົາພົບວ່າຕາມຄວາມຈິງແລ້ວ, ຫຼາຍສິ່ງທົ່ວໄປໃນ Javascript ສາມາດກະຕຸ້ນໃຫ້ບຣາວເຊີເກີດ reflow ໄດ້.

ເກືອບທຸກຟັງຊັນທີ່ທ່ານສາມາດໃຊ້ເພື່ອດຶງເອົາຄວາມກວ້າງ, ຄວາມສູງ ຫຼື ຕໍາແໜ່ງຂອງອົງປະກອບ DOM ສາມາດກະຕຸ້ນໃຫ້ເກີດ reflow ໄດ້. Paul Irish ໄດ້ຂຽນລາຍການຢ່າງລະອຽດ ກ່ຽວກັບ property ແລະ ຟັງຊັນທັງໝົດໃນ Javascript ທີ່ສາມາດເຮັດໃຫ້ເກີດສິ່ງນີ້ໄດ້. ຂ່າວຮ້າຍກໍຄື Page Builder Sandwich ໃຊ້ property ແລະ ຟັງຊັນເຫຼົ່ານີ້ຫຼາຍຢ່າງ, ເຊິ່ງທັງໝົດລ້ວນແຕ່ເຮັດໃຫ້ເກີດ reflow:

• elem.getBoundingClientRect()
• window.getComputedStyle()
• window.scrollY
• ແລະ ອື່ນໆ ອີກຫຼາຍຢ່າງ…

ການແກ້ໄຂ #1: ການແຄຊ (Caching) ຂະບວນການ Reflow ທີ່ສິ້ນເປືອງຊັບພະຍາກອນ

ວິທີແກ້ໄຂທີ່ຊັດເຈນທີ່ສຸດຄືການ ບໍ່ໃຊ້ property ແລະ ຟັງຊັນເຫຼົ່ານັ້ນ. ແນວໃດກໍຕາມ, PBS ແມ່ນເພິ່ງພາສິ່ງເຫຼົ່ານັ້ນຢ່າງຫຼວງຫຼາຍ ແລະ ພວກເຮົາບໍ່ສາມາດຂາດພວກມັນໄດ້.

ວິທີແກ້ໄຂທີ່ເຫຼືອຢູ່ສໍາລັບພວກເຮົາແມ່ນການຫຼຸດການຮຽກໃຊ້ງານຟັງຊັນເຫຼົ່ານັ້ນໃຫ້ນ້ອຍລົງເທົ່າທີ່ຈະເປັນໄປໄດ້. ສິ່ງທີ່ຍາກໃນທີ່ນີ້ແມ່ນພວກເຮົາໄດ້ໃຊ້ property ແລະ ຟັງຊັນເຫຼົ່ານັ້ນຫຼາຍຄັ້ງໃນພາກສ່ວນຕ່າງໆ ຂອງ PBS, ແລະ ສ່ວນຫຼາຍແລ້ວ, ພວກເຮົາໃຊ້ມັນກັບອົງປະກອບ DOM ດຽວກັນຫຼາຍໆ ຄັ້ງ. ເພື່ອແກ້ໄຂເລື່ອງນີ້, ພວກເຮົາຈຶ່ງໄດ້ສ້າງກົນໄກການແຄຊຂອງພວກເຮົາເອງສໍາລັບແຕ່ລະ property/ຟັງຊັນ ທີ່ມີບັນຫາ.

ຕົວຢ່າງ, ຟັງຊັນ getBoundingClientRect  ຈະໃຫ້ຄ່າວັດແທກພິກເຊວດ້ານເທິງ, ດ້ານຊ້າຍ, ຄວາມກວ້າງ, ຄວາມສູງ, ດ້ານຂວາ ແລະ ດ້ານລຸ່ມໃນປັດຈຸບັນຂອງອົງປະກອບ DOM. ພວກເຮົາໃຊ້ຟັງຊັນນີ້ຕະຫຼອດເວລາເພື່ອຄິດໄລ່ຕໍາແໜ່ງທີ່ຈະແຕ້ມເສັ້ນຂອບຂອງອົງປະກອບໃນ PBS. ນີ້ຄືຟັງຊັນແຄຊທີ່ພວກເຮົາສ້າງຂຶ້ນສໍາລັບສິ່ງນີ້:

// ແຄຊ: client rects ຂອງພວກເຮົາຖືກເກັບໄວ້ທີ່ນີ້, ພວກເຮົາສາມາດໃຊ້ມັນເພື່ອລຶບລ້າງພາຍຫຼັງ.
var elemsWithBoundingRects = [];

window.pbsGetBoundingClientRect = function( element ) {

	// ກວດສອບວ່າພວກເຮົາເຄີຍດຶງ client rect ມາກ່ອນແລ້ວຫຼືບໍ່.
	if ( ! element._boundingClientRect ) {

		// ຖ້າຍັງບໍ່ເຄີຍ, ໃຫ້ດຶງມັນມາແລ້ວເກັບໄວ້ສໍາລັບການໃຊ້ງານໃນອະນາຄົດ.
		element._boundingClientRect = element.getBoundingClientRect();
		elemsWithBoundingRects.push( element );
	}
	return element._boundingClientRect;
};
​

ແທນທີ່ຈະຮຽກໃຊ້ getBoundingClientRect , ຕອນນີ້ພວກເຮົາໃຊ້ pbsGetBoundingClientRect . ຕອນນີ້ທຸກຄັ້ງທີ່ມີການສອບຖາມ client rect, ພວກເຮົາຈະເກັບຄ່ານັ້ນໄວ້ສໍາລັບການອ້າງອີງໃນອະນາຄົດ, ເຊິ່ງຊ່ວຍຈໍາກັດຈໍານວນການກະຕຸ້ນໃຫ້ເກີດ reflow.

ພວກເຮົາຍັງຕ້ອງການວິທີລຶບລ້າງແຄຊເມື່ອ client rects ທີ່ເກັບໄວ້ບໍ່ສາມາດໃຊ້ງານໄດ້ອີກຕໍ່ໄປ. ຄ່າຂອງ client rect ທີ່ບັນທຶກໄວ້ຈະປ່ຽນແປງເມື່ອຜູ້ໃຊ້ເລື່ອນໜ້າເວັບ ຫຼື ເພີ່ມ/ປ່ຽນແປງ/ລຶບອົງປະກອບໃນໜ້າຈໍ. ດັ່ງນັ້ນພວກເຮົາຈຶ່ງໄດ້ສ້າງຟັງຊັນລຶບລ້າງແຄຊທີ່ພວກເຮົາສາມາດຮຽກໃຊ້ໄດ້ທຸກຄັ້ງທີ່ພວກເຮົາຕ້ອງການຄ່າ client rect ໃໝ່:

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

ພວກເຮົາຍັງໄດ້ໃຊ້ກົນໄກການແຄຊແບບດຽວກັນນີ້ສໍາລັບການຮຽກໃຊ້ຟັງຊັນອື່ນໆ ທີ່ສິ້ນເປືອງຊັບພະຍາກອນທີ່ພວກເຮົາໃຊ້ເປັນປະຈໍາ.

ການແກ້ໄຂ #2: ການລວມກຸ່ມການອ່ານ & ການຂຽນເຂົ້າກັນໂດຍໃຊ້ FastDom

ການຈັດຕັ້ງປະຕິບັດການແກ້ໄຂ #1 ໄດ້ເພີ່ມປະສິດທິພາບຂອງ PBS, ແຕ່ມັນຍັງບໍ່ພຽງພໍ.

ເມື່ອຄົ້ນຫາໃນ Google ເພີ່ມເຕີມ, ພວກເຮົາໄດ້ພົບບົດຄວາມໂດຍ Wilson Page ກ່ຽວກັບ Preventing ‘layout thrashing’. Wilson ໄດ້ກ່າວໄວ້ວ່າ:

Layout Thrashing (reflow) ເກີດຂຶ້ນເມື່ອ JavaScript ທໍາການຂຽນ ແລ້ວອ່ານ ຈາກ DOM ຢ່າງຕໍ່ເນື່ອງຫຼາຍຄັ້ງ ເຮັດໃຫ້ເກີດ reflow ໃນເອກະສານ.

ປາກົດວ່າ, ມັນບໍ່ພຽງພໍທີ່ຈະຈໍາກັດການຮຽກໃຊ້ property ແລະ ຟັງຊັນສະເພາະທີ່ກະຕຸ້ນ reflow ເທົ່ານັ້ນ. ເມື່ອທ່ານເຮັດການ “ອ່ານ” ແລະ “ຂຽນ” ຕິດຕໍ່ກັນຫຼາຍໆ ຄັ້ງເທິງ DOM, ມັນຍັງກະຕຸ້ນໃຫ້ເກີດ browser reflow ອີກດ້ວຍ. ນີ້ຄືສະຖານະການຕົວຢ່າງທົ່ວໄປ, ໂດຍກົງຈາກເວັບໄຊຂອງ Wilson:

// ອ່ານ (Read)
var h1 = element1.clientHeight;

// ຂຽນ (Write) (ເຮັດໃຫ້ເລເອົາຕ໌ໃຊ້ການບໍ່ໄດ້)
element1.style.height = (h1 * 2) + 'px';

// ອ່ານ (Read) (ກະຕຸ້ນ reflow)
var h2 = element2.clientHeight;

// ຂຽນ (Write) (ເຮັດໃຫ້ເລເອົາຕ໌ໃຊ້ການບໍ່ໄດ້)
element2.style.height = (h2 * 2) + 'px';

// ອ່ານ (Read) (ກະຕຸ້ນ reflow)
var h3 = element3.clientHeight;

// ຂຽນ (Write) (ເຮັດໃຫ້ເລເອົາຕ໌ໃຊ້ການບໍ່ໄດ້)
element3.style.height = (h3 * 2) + 'px';

// ເອກະສານເກີດ reflow ໃນຕອນທ້າຍຂອງເຟຣມ​

ຕົວຢ່າງຂ້າງເທິງຈະກະຕຸ້ນໃຫ້ເກີດ 3 reflows ເນື່ອງຈາກຂະໜາດຂອງໜ້າທັງໝົດຈະກາຍເປັນໂມຄະຫຼັງຈາກການຂຽນ. ວິທີແກ້ໄຂທີ່ແນະນໍາສໍາລັບເລື່ອງນີ້ແມ່ນການຈັດລໍາດັບໂຄ້ດໃໝ່ເພື່ອລວມການອ່ານ ແລະ ການຂຽນທັງໝົດເຂົ້າກັນ ເພື່ອໃຫ້ທັງໝົດກະຕຸ້ນໃຫ້ເກີດ browser reflow ພຽງແຕ່ 1 ຄັ້ງເທົ່ານັ້ນ:

// ອ່ານ (Read)
var h1 = element1.clientHeight;
var h2 = element2.clientHeight;
var h3 = element3.clientHeight;

// ຂຽນ (Write) (ເຮັດໃຫ້ເລເອົາຕ໌ໃຊ້ການບໍ່ໄດ້)
element1.style.height = (h1 * 2) + 'px';
element2.style.height = (h2 * 2) + 'px';
element3.style.height = (h3 * 2) + 'px';

// ເອກະສານເກີດ reflow ໃນຕອນທ້າຍຂອງເຟຣມ​

snippet ໂຄ້ດຂ້າງເທິງເຮັດໃຫ້ການແກ້ໄຂບັນຫາເບິ່ງຄືວ່າງ່າຍ. ແຕ່ໃນຄວາມເປັນຈິງ, ໃນ PBS, ການອ່ານ ແລະ ການຂຽນສິ່ງທີ່ກະຕຸ້ນໃຫ້ເກີດ reflow ເກີດຂຶ້ນໃນຫຼາຍບ່ອນ ແລະ ຫຼາຍຊ່ວງເວລາໃນລະຫວ່າງ life-cycle ຂອງ PBS. ການຈັດລະບຽບໂຄ້ດ Javascript ຫຼາຍພັນແຖວຄືນໃໝ່ຈຶ່ງບໍ່ແມ່ນເລື່ອງທີ່ເຮັດໄດ້ງ່າຍເລີຍ.

ໂຊກດີສໍາລັບພວກເຮົາ, Wilson ຍັງໄດ້ໃຫ້ວິທີແກ້ໄຂໄວ້ໃນບົດຄວາມຂອງລາວ. ລາວໄດ້ສ້າງສະຄຣິບ utility ຂະໜາດນ້ອຍເພື່ອຊ່ວຍໃນການລວມການອ່ານ ແລະ ການຂຽນເຫຼົ່ານັ້ນເຂົ້າກັນ, ເຊິ່ງມີຊື່ວ່າ FastDom.

ນີ້ຄືໂຄ້ດບາງສ່ວນຈາກ Page Builder Sandwich ທີ່ໃຊ້ FastDom ແລະ ຍັງລວມເອົາວິທີແກ້ໄຂ #1 ຂອງພວກເຮົາຂ້າງເທິງນໍາດ້ວຍ:

// ລວມການອ່ານຈາກ thread ອື່ນໆ ເຂົ້າກັນ.
fastdom.measure( function() {

	// ໃຊ້ client rect ທີ່ແຄຊໄວ້ຂອງພວກເຮົາ.
	var rect = window.pbsGetBoundingClientRect( elem );

	// ລວມການຂຽນຈາກ thread ອື່ນໆ ເຂົ້າກັນ.
	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  ທັງໝົດເຂົ້າກັນ ແລ້ວປະມວນຜົນແບບ asynchronous, ເຊິ່ງເປັນການລວມການອ່ານ ແລະ ການຂຽນທັງໝົດເຂົ້າກັນຢ່າງມີປະສິດທິຜົນ ເພື່ອຫຼຸດຜ່ອນ reflow ທັງໝົດໃນບຣາວເຊີ.

ການແກ້ໄຂ #3: ການເຂົ້າເຖິງ Style Objects ແມ່ນສິ້ນເປືອງຊັບພະຍາກອນຫຼາຍ

ພວກເຮົາຍັງພົບອີກວ່າ ດ້ວຍການຊ່ວຍເຫຼືອຂອງ jsPerf, ບາງຟັງຊັນໃນການດຶງຄ່າຮູບແບບ ແມ່ນໄວກວ່າຟັງຊັນອື່ນໆ.

ໃນ PBS, ພວກເຮົາປົກກະຕິແລ້ວຕ້ອງດຶງເອົາຄ່າປັດຈຸບັນຂອງຮູບແບບສະເພາະຂອງອົງປະກອບໃດໜຶ່ງ. ຕົວຢ່າງ, ໂດຍທົ່ວໄປແລ້ວພວກເຮົາໃຊ້ສິ່ງນີ້ເພື່ອດຶງເອົາ top margin:

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

ແຕ່, ພວກເຮົາພົບວ່າການເຮັດແບບນີ້ແມ່ນໄວກວ່າຫຼາຍ:

var marginTop = elem.style.marginTop;​

ຢ່າງໃດກໍຕາມ, elem.style.marginTop  ແລະ getComputedStyle  ແມ່ນມີຄວາມແຕກຕ່າງກັນຫຼາຍ. ແບບທໍາອິດຈະໃຫ້ສະເພາະ inline styling ຂອງອົງປະກອບເທົ່ານັ້ນ, ແລະ ບໍ່ໄດ້ຄໍານຶງເຖິງ stylesheet ໃດໆ; ສ່ວນແບບທີສອງຈະຄໍານຶງເຖິງທັງ inline styles ແລະ stylesheets.

ຍິ່ງໄປກວ່ານັ້ນ, ເຖິງແມ່ນວ່າຜົນລັບຂອງ getComputedStyle  ຈະຖືກແຄຊໄວ້ແລ້ວ, ມັນກໍຍັງຊ້າຫຼາຍຢູ່ດີ. ປາກົດວ່າ, ການເຂົ້າເຖິງຕົວ style object ເອງນັ້ນແຫຼະຄືຂະບວນການທີ່ຊ້າ.

ໂຊກດີສໍາລັບພວກເຮົາ, PBS ໄດ້ເພີ່ມ inline styles ໃສ່ອົງປະກອບຕ່າງໆ, ແລະ ເນື່ອງຈາກ inline styles ມີລໍາດັບຄວາມສໍາຄັນສູງກວ່າ (ສ່ວນໃຫຍ່) stylesheets, ດັ່ງນັ້ນຈຶ່ງມີບາງກໍລະນີທີ່ການດຶງຄ່າ inline style ພຽງຢ່າງດຽວກໍພຽງພໍແລ້ວ. ສະນັ້ນ ຖ້າພວກເຮົາລວມທັງສອງວິທີຂ້າງເທິງເຂົ້າກັນ, ພວກເຮົາຈະໄດ້ໂຄ້ດທີ່ເຮັດວຽກໄດ້ໄວກວ່າຫຼາຍ:

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

ຜົນລັບຂອງການປັບປຸງໂຄ້ດ

ການແກ້ໄຂທັງ 3 ຂໍ້ຂ້າງເທິງຂອງພວກເຮົາຕ້ອງໃຊ້ການຄົ້ນຄວ້າ, ການທົດສອບ ແລະ ການຈັດຕັ້ງປະຕິບັດຕົວຈິງຢ່າງຫຼວງຫຼາຍ (ແລະ ເຮັດໃຫ້ຟີເຈີ Fonts ຂອງພວກເຮົາຖືກເລື່ອນການປ່ອຍອອກໄປ), ແຕ່ໃນທີ່ສຸດມັນກໍຄຸ້ມຄ່າທັງໝົດ.

ກັບໄປທີ່ການທົດສອບເບື້ອງຕົ້ນຂອງພວກເຮົາກ່ຽວກັບການເລື່ອນເມົ້າຜ່ານໜ້າຈໍເປັນເວລາ 2 ວິນາທີ. ນີ້ຄື timeline ເກົ່າທີ່ບໍ່ໜ້າເບິ່ງ/ກະຕຸກ:

ແລະ ນີ້ຄືລັກສະນະຂອງ timeline ໃໝ່ຂອງພວກເຮົາຫຼັງຈາກການປັບປຸງປະສິດທິພາບ:

ດັ່ງທີ່ທ່ານເຫັນ, ມີພາກສ່ວນສີມ່ວງໜ້ອຍລົງໃນກຣາຟ. ແລະ ມີຄວາມແຕກຕ່າງທີ່ເຫັນໄດ້ຊັດເຈນໃນຈໍານວນຂະບວນການທີ່ຖືກປະມວນຜົນໂດຍບຣາວເຊີ. ຮູບສີ່ແຈສາກຢູ່ດ້ານລຸ່ມກໍບາງລົງເຊັ່ນກັນ, ເຊິ່ງໝາຍຄວາມວ່າຂະບວນການຕ່າງໆ ແມ່ນເຮັດວຽກໄດ້ໄວກວ່າເກົ່າ.

ຖ້າທ່ານປຽບທຽບຈໍານວນພື້ນທີ່ສີມ່ວງທີ່ສູງ/ກວ້າງໃນກຣາຟເກົ່າ ແລະ ໃໝ່, ພວກເຮົາກໍາລັງເຫັນປະສິດທິພາບທີ່ເພີ່ມຂຶ້ນເຖິງ 200% ຢ່າງຫຼວງຫຼາຍ! ພວກເຮົາຍັງເຫັນການເພີ່ມຂຶ້ນຂອງປະສິດທິພາບໃນທຸກໆ ດ້ານອີກດ້ວຍ. ບໍ່ຮ້າຍເລີຍແທ້ໆ!

ສິ່ງທີ່ໄດ້ຮຽນຮູ້ & ບົດຮຽນ

ເວົ້າຕາມຄວາມສັດຈິງ, ພວກເຮົາບໍ່ຄິດວ່າ PBS ມີບັນຫາດ້ານປະສິດທິພາບມາກ່ອນຈົນກວ່າ Ann ຈະຍົກເລື່ອງນີ້ຂຶ້ນມາ. ສ່ວນໃຫຍ່ແມ່ນຍ້ອນພວກເຮົາໃຊ້ເຄື່ອງຄອມພິວເຕີສໍາລັບການພັດທະນາໂດຍສະເພາະ ແລະ ຈຸດຕິດຂັດຂອງປະສິດທິພາບກໍບໍ່ໄດ້ເຫັນໄດ້ຊັດເຈນປານໃດ. ເມື່ອເບິ່ງຍ້ອນຫຼັງ, ການກວດສອບປະສິດທິພາບຄວນຈະເປັນໜຶ່ງໃນບູລິມະສິດສູງສຸດ. ແຕ່ຢ່າງໜ້ອຍໃນຕອນນີ້, ນັບຕັ້ງແຕ່ເວີຊັນ 4.3 ມັນກໍໄດ້ຮັບການແກ້ໄຂແລ້ວ.

ສໍາລັບຜູ້ທີ່ຕ້ອງການປັບປຸງປະສິດທິພາບປລັກອິນ WordPress ຂອງຕົນເອງ, ໂດຍສະເພາະຖ້າທ່ານໃຊ້ Javascript ຢ່າງໜັກໜ່ວງ, ນີ້ຄືສິ່ງທີ່ຂ້າພະເຈົ້າໄດ້ຮຽນຮູ້ຈາກປະສົບການນີ້:

1. ຈໍາກັດ/ແຄຊ ການຮຽກໃຊ້ property/ຟັງຊັນ ທີ່ກະຕຸ້ນໃຫ້ເກີດ reflow. ໃຊ້ສິ່ງນີ້ເປັນຄູ່ມື: What forces layout/reflow. The comprehensive list.
2. ລວມກຸ່ມການ “ອ່ານ” ແລະ “ຂຽນ” ໃສ່ DOM styles ເຂົ້າກັນ. ໃຊ້ FastDom ເພື່ອເຮັດສິ່ງນີ້ແທນທ່ານ.
3. ໃຊ້ Chrome’s Timeline profiler, ແລະ ກວດສອບໃຫ້ແນ່ໃຈວ່າທ່ານມີ reflow (ພາກສ່ວນສີມ່ວງ) ໜ້ອຍທີ່ສຸດເທົ່າທີ່ຈະເປັນໄປໄດ້.