കഴിഞ്ഞ 2017 ഫെബ്രുവരി 2-ന്, ആൻ ടെയ്‌ലർ CodeInWP-ൽ 12 Things We Need to See From WordPress Page Builders in 2017 + Who Already Gets It Right എന്ന ലേഖനം എഴുതി. ഞങ്ങൾ ഒരു വർഷത്തിലേറെയായി പേജ് ബിൽഡർ സാൻഡ്‌വിച്ച് (Page Builder Sandwich) നിരന്തരം മെച്ചപ്പെടുത്തിക്കൊണ്ടിരിക്കുകയാണ്: ഞങ്ങൾ ഗവേഷണങ്ങൾ നടത്തുകയും ഞങ്ങളുടെ ഉപഭോക്താക്കളെ ശ്രദ്ധിക്കുകയും ചെയ്യുന്നു, അതിനാൽ പേജ് ബിൽഡർ സാൻഡ്‌വിച്ച് CodeInWP-ന്റെ “Who Got it Right” എന്ന ലേഖനത്തിൽ ഇടംപിടിക്കുമെന്ന് ഞങ്ങൾ കരുതി. എന്നാൽ പ്രകടനക്ഷമതയിലെ (പെർഫോമൻസ്) പ്രശ്നങ്ങൾ കാരണം ഞങ്ങൾക്ക് അതിൽ ഇടം നേടാനായില്ല. 
അതിനാൽ ഞങ്ങൾ ഇതിനെക്കുറിച്ച് ആനിനോട് ചോദിച്ചു, അവർ മറുപടി നൽകി:
…ഞാൻ ഇതിന്റെ സൌജന്യ പതിപ്പ് അല്പം ഉപയോഗിച്ചു നോക്കി. ഇത് വളരെയധികം പ്രതീക്ഷ നൽകുന്നു: ധാരാളം മൊഡ്യൂളുകൾ, മികച്ച അവബോധജന്യമായ UI, മികച്ച WYSIWYG അനുഭവം, എല്ലാം എളുപ്പത്തിൽ ഡ്രാഗ് ചെയ്യാൻ കഴിയുന്നു. എന്നിരുന്നാലും, പേജിൽ ഏകദേശം 10 മൊഡ്യൂളുകൾ ആയപ്പോൾ, എഡിറ്റിംഗ് വേഗത കുറഞ്ഞതിനാൽ ഇത് ഉപയോഗിച്ച് തുടർന്ന് പ്രവർത്തിക്കാൻ ബുദ്ധിമുട്ടായി…
അതുകൊണ്ട് അവരുടെ അഭിപ്രായത്തിൽ, പേജ് ബിൽഡർ സാൻഡ്‌വിച്ചിന് പെർഫോമൻസ് പ്രശ്നങ്ങളുണ്ട്. ഞങ്ങൾ എപ്പോഴും ഫീഡ്‌ബാക്കുകൾ ശ്രദ്ധിക്കുന്നതിനാൽ, ഞങ്ങൾ ഇത് പരിശോധിച്ചു.
പ്രവർത്തനക്ഷമത (പെർഫോമൻസ്) പരിശോധിക്കുന്നു
PBS-ന്റെ പെർഫോമൻസ് പരിശോധിക്കാൻ ഞങ്ങൾക്ക് ഒരു മാർഗ്ഗം ആവശ്യമായിരുന്നു; PBS പ്രധാനമായും Javascript വഴി ബ്രൗസറിലാണ് പ്രവർത്തിക്കുന്നത് എന്നതിനാൽ, ഈ ജോലിക്ക് ഏറ്റവും അനുയോജ്യമായ ഉപകരണം Chrome-ന്റെ Timeline profiler ആയിരുന്നു. റൺടൈമിൽ ഒരു വെബ്‌പേജിൽ ഏതൊക്കെ പ്രക്രിയകളാണ് നടക്കുന്നതെന്ന് തിരിച്ചറിയാനും അളക്കാനും ടൈംലൈൻ പ്രൊഫൈലറിന് കഴിയും, ഇത് വേഗത കുറയ്ക്കുന്ന തടസ്സങ്ങൾ (bottlenecks) കണ്ടെത്താൻ തികച്ചും അനുയോജ്യമാണ്.
ഏറ്റവും ലളിതമായ ഘട്ടങ്ങൾ ആദ്യം പരീക്ഷിക്കണമെന്ന് ഞങ്ങൾ കരുതി – ഒന്നിലധികം എലമെന്റുകളിലൂടെയും വരികളിലൂടെയും ഞങ്ങളുടെ മൗസ് ചലിപ്പിക്കുക. ലളിതമല്ലേ? ഇത്രയും ലളിതമായ ഒന്നിൽ ഞങ്ങൾ പെർഫോമൻസ് പ്രശ്നങ്ങൾ നേരിടേണ്ടി വരില്ലെന്ന് ഞങ്ങൾക്ക് ഉറപ്പായിരുന്നു. നിർഭാഗ്യവശാൽ, ഞങ്ങൾക്ക് തെറ്റി.
റെക്കോർഡ് ബട്ടൺ അമർത്തിയ ശേഷം, ഞങ്ങൾ സ്ക്രീനിൽ ഏകദേശം 2 സെക്കൻഡ് മൗസ് ചലിപ്പിച്ചു, തുടർന്ന് സ്റ്റോപ്പ് ബട്ടൺ അമർത്തി. പ്രൊഫൈലറിൽ നിന്നുള്ള ടൈംലൈൻ ഫലം ഇതാ:
ഇതാ നോക്കൂ. ഇത് മുഴുവൻ പെർഫോമൻസ് ബോട്ടിൽനെക്കുകൾ കൊണ്ട് നിറഞ്ഞിരിക്കുന്നു!
ഗ്രാഫിൽ ഒരുപാട് കാര്യങ്ങൾ സംഭവിക്കുന്നുണ്ട്, എന്നാൽ ഏറ്റവും പ്രകടമായ പ്രശ്നം അതിൽ ധാരാളം പർപ്പിൾ നിറത്തിലുള്ള ഭാഗങ്ങൾ ഉണ്ട് എന്നതാണ് (അത് ഉണ്ടാവാൻ പാടില്ലാത്തതായിരുന്നു). കൂടാതെ, ഈ പർപ്പിൾ ഭാഗങ്ങൾ വളരെ വീതിയുള്ളതുമാണ്, മാത്രമല്ല അവയെല്ലാം ഗ്രാഫിന്റെ ഉയർന്ന പരിധിയിൽ എത്തുന്നതായും കാണാം. ഗ്രാഫ് എപ്പോഴും നിറഞ്ഞതാണെന്നും പർപ്പിൾ ഭാഗങ്ങൾ ഒരിക്കലും പൂജ്യത്തിലേക്ക് താഴുന്നില്ലെന്നും നിങ്ങൾക്ക് കാണാം. ബ്രൗസർ എപ്പോഴും എന്തെങ്കിലും ചെയ്യുന്ന തിരക്കിലാണെന്നും ഒരിക്കലും വിശ്രമിക്കുന്നില്ലെന്നും തോന്നുന്നു.
എന്നാൽ ഈ പർപ്പിൾ ഭാഗങ്ങളെല്ലാം യഥാർത്ഥത്തിൽ എന്താണ് അർത്ഥമാക്കുന്നത്?
അവയെ reflows എന്നാണ് വിളിക്കുന്നതെന്ന് പ്രൊഫൈലർ ഞങ്ങളോട് കാണിച്ചുതന്നു. Google ഡെവലപ്പർ സൈറ്റിൽ:
ഡോക്യുമെന്റിലെ ഘടകങ്ങളുടെ സ്ഥാനങ്ങളും ജ്യാമിതികളും (geometries) വീണ്ടും കണക്കാക്കുന്നതിനുള്ള വെബ് ബ്രൗസർ പ്രക്രിയയുടെ പേരാണ് Reflow.. റീഫ്ലോ എന്നത് ബ്രൗസറിലെ ഉപയോക്തൃ-തടസ്സപ്പെടുത്തൽ (user-blocking) പ്രവർത്തനമാണ്.
അതായത്, PBS-ൽ നിങ്ങളുടെ മൗസ് ചലിപ്പിക്കുന്നത് വൻതോതിലുള്ള റീഫ്ലോകൾക്ക് കാരണമാകുന്നു. ഇതിലും മോശമായ കാര്യം, ഓരോ റീഫ്ലോയും കണക്കുകൂട്ടലുകൾ പൂർത്തിയാക്കാൻ ബ്രൗസറിനെ താൽക്കാലികമായി നിർത്തുന്നു എന്നതാണ്. കൂടുതൽ റീഫ്ലോകൾ കൂടുതൽ തവണ ബ്രൗസർ താൽക്കാലികമായി നിലയ്ക്കാൻ ഇടയാക്കുന്നു, കൂടാതെ അനുഭവം കൂടുതൽ തടസ്സങ്ങളുള്ളതായി (janky) മാറുന്നു. ലളിതമായി പറഞ്ഞാൽ, ഒരുപാട് പർപ്പിൾ ഭാഗങ്ങൾ = മോശം അവസ്ഥ.
അപ്പോൾ ആൻ പറഞ്ഞത് ശരിയാണെന്ന് വ്യക്തമായി: ഞങ്ങൾക്ക് ഒരു വലിയ പെർഫോമൻസ് ബോട്ടിൽനെക്ക് ഉണ്ട്, അതിനാൽ ഞങ്ങളുടെ ടീം അത് ഉടനടി പരിഹരിക്കുന്നതിനായി രംഗത്തിറങ്ങി.
ഞങ്ങളുടെ Reflow / Jank പ്രശ്നം പരിഹരിക്കുന്നു
മറ്റെന്തിനും മുമ്പ്, എന്തുകൊണ്ടാണ് ഈ റീഫ്ലോ ഉണ്ടാകുന്നത് എന്ന് കണ്ടെത്താൻ ഞങ്ങൾക്ക് കുറച്ച് ഗവേഷണം നടത്തേണ്ടതുണ്ടായിരുന്നു. Javascript-ലെ സാധാരണമായ പല കാര്യങ്ങൾക്കും ബ്രൗസറിൽ റീഫ്ലോ ഉണ്ടാക്കാൻ കഴിയുമെന്ന് ഞങ്ങൾ കണ്ടെത്തി.
ഒരു DOM എലമെന്റിന്റെ വീതി (width), ഉയരം (height) അല്ലെങ്കിൽ സ്ഥാനം (position) എന്നിവ ലഭിക്കുന്നതിന് നിങ്ങൾക്ക് ഉപയോഗിക്കാൻ കഴിയുന്ന മിക്കവാറും ഏത് ഫംഗ്ഷനും ഒരു റീഫ്ലോ ട്രിഗർ ചെയ്യാൻ കഴിയും. ഇതിന് കാരണമാകുന്ന ജാവാസ്ക്രിപ്റ്റിലെ എല്ലാ പ്രോപ്പർട്ടികളുടെയും ഫംഗ്ഷനുകളുടെയും വിപുലമായ ഒരു ലിസ്റ്റ് പോൾ ഐറിഷ് എഴുതിയിട്ടുണ്ട്. ദുഃഖകരമായ വാർത്ത എന്തെന്നാൽ, പേജ് ബിൽഡർ സാൻഡ്‌വിച്ച് ഈ പ്രോപ്പർട്ടികളും ഫംഗ്ഷനുകളും ധാരാളമായി ഉപയോഗിക്കുന്നുണ്ടായിരുന്നു, ഇവയെല്ലാം റീഫ്ലോയ്ക്ക് കാരണമാകുന്നു:
- elem.getBoundingClientRect()
- window.getComputedStyle()
- window.scrollY
- കൂടാതെ മറ്റു പലതും…
പരിഹാരം #1: ചെലവേറിയ റീഫ്ലോ പ്രക്രിയകൾ കാഷെ ചെയ്യുക (Caching)
ഏറ്റവും ലളിതമായ പരിഹാരം ആ പ്രോപ്പർട്ടികളും ഫംഗ്ഷനുകളും ഉപയോഗിക്കാതിരിക്കുക എന്നതാണ്. എന്നിരുന്നാലും, PBS അവയെ വളരെയധികം ആശ്രയിക്കുന്നു, അവയില്ലാതെ പ്രവർത്തിക്കാൻ ഞങ്ങൾക്ക് കഴിയില്ല.
ഞങ്ങളുടെ മുന്നിലുള്ള പരിഹാരം ആ ഫംഗ്ഷനുകളിലേക്കുള്ള കോളുകൾ കഴിയുന്നത്ര കുറയ്ക്കുക എന്നതാണ്. PBS-ന്റെ വിവിധ ഭാഗങ്ങളിൽ ഞങ്ങൾ ആ പ്രോപ്പർട്ടികളും ഫംഗ്ഷനുകളും പലതവണ ഉപയോഗിച്ചിരുന്നു, ഒപ്പം മിക്കപ്പോഴും ഒരേ DOM എലമെന്റിൽ ഒന്നിലധികം തവണ അവ ഉപയോഗിച്ചിരുന്നു എന്നതാണ് ഇതിലെ കഠിനമായ ഭാഗം. ഇത് പരിഹരിക്കുന്നതിന്, പ്രശ്നമുണ്ടാക്കുന്ന ഓരോ പ്രോപ്പർട്ടിക്കും/ഫംഗ്ഷനും ഞങ്ങൾ ഞങ്ങളുടേതായ കാഷിംഗ് സംവിധാനം സൃഷ്ടിച്ചു.
ഉദാഹരണത്തിന്, getBoundingClientRect ഫംഗ്ഷൻ നമുക്ക് ഒരു DOM എലമെന്റിന്റെ നിലവിലെ top, left, width, height, right, bottom പിക്സൽ അളവുകൾ നൽകുന്നു. PBS-ൽ എലമെന്റ് ഔട്ട്‌ലൈനുകൾ എവിടെ വരയ്ക്കണമെന്ന് കണക്കാക്കാൻ ഞങ്ങൾ ഈ ഫംഗ്ഷൻ എപ്പോഴും ഉപയോഗിക്കുന്നു. ഇതിനായി ഞങ്ങൾ സൃഷ്ടിച്ച കാഷിംഗ് ഫംഗ്ഷൻ ഇതാ:
// 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 ഉപയോഗിച്ചു. ഇപ്പോൾ ഓരോ തവണയും ക്ലയന്റ് റെക്റ്റ് ആവശ്യപ്പെടുമ്പോൾ, ഭാവിയിലെ റഫറൻസിനായി ഞങ്ങൾ ആ മൂല്യം സംഭരിക്കുന്നു, അതുവഴി റീഫ്ലോ ട്രിഗറുകളുടെ എണ്ണം പരിമിതപ്പെടുത്തുന്നു.
സംഭരിച്ച ക്ലയന്റ് റെക്റ്റുകൾ അസാധുവാകുമ്പോൾ (invalidated) കാഷെ മായ്‌ക്കാനുള്ള ഒരു മാർഗ്ഗവും ഞങ്ങൾക്ക് ആവശ്യമായിരുന്നു. ഉപയോക്താവ് പേജ് സ്ക്രോൾ ചെയ്യുമ്പോഴോ സ്ക്രീനിലെ എലമെന്റുകൾ ചേർക്കുകയോ മാറ്റുകയോ നീക്കം ചെയ്യുകയോ ചെയ്യുമ്പോൾ സംഭരിച്ചിരിക്കുന്ന ക്ലയന്റ് റെക്റ്റിന്റെ മൂല്യങ്ങൾ മാറുന്നു. അതിനാൽ ഞങ്ങൾക്ക് പുതിയ ക്ലയന്റ് റെക്റ്റ് മൂല്യങ്ങൾ ആവശ്യമുള്ളപ്പോഴെല്ലാം വിളിക്കാൻ കഴിയുന്ന ഒരു കാഷെ ക്ലിയറിംഗ് ഫംഗ്ഷൻ ഞങ്ങൾ സൃഷ്ടിച്ചു:
var clearClientRects = function() {
var i;
for ( i = 0; i < elemsWithBoundingRects.length; i++ ) {
if ( elemsWithBoundingRects[ i ] ) {
elemsWithBoundingRects[ i ]._boundingClientRect = null;
}
}
elemsWithBoundingRects = [];
};
ഞങ്ങൾ സാധാരണയായി ഉപയോഗിക്കുന്ന ചെലവേറിയ മറ്റ് ഫംഗ്ഷൻ കോളുകൾക്കും ഞങ്ങൾ ഇതേ കാഷിംഗ് സംവിധാനം നടപ്പിലാക്കി.
പരിഹാരം #2: FastDom ഉപയോഗിച്ച് Reads & Writes ഒരുമിച്ച് ഗ്രൂപ്പ് ചെയ്യുക
പരിഹാരം #1 നടപ്പിലാക്കിയത് PBS-ന്റെ പെർഫോമൻസ് വർദ്ധിപ്പിച്ചു, പക്ഷേ അത് പര്യാപ്തമായിരുന്നില്ല.
കൂടുതൽ ഗൂഗിൾ ചെയ്തപ്പോൾ, വിൽസൺ പേജ് എഴുതിയ Preventing ‘layout thrashing’ എന്ന ലേഖനം ഞങ്ങൾ കണ്ടു. വിൽസൺ പറയുന്നു:
JavaScript DOM-ൽ നിന്ന് അനിയന്ത്രിതമായി എഴുതുകയും (writes) വായിക്കുകയും (reads) ചെയ്യുമ്പോൾ, അത് ഒന്നിലധികം ഡോക്യുമെന്റ് റീഫ്ലോകൾക്ക് കാരണമാകുന്നു, ഇതാണ് Layout Thrashing (reflow) എന്ന് അറിയപ്പെടുന്നത്.
നിർദ്ദിഷ്ട റീഫ്ലോ ട്രിഗർ ചെയ്യുന്ന പ്രോപ്പർട്ടികളിലേക്കും ഫംഗ്ഷനുകളിലേക്കുമുള്ള നിങ്ങളുടെ കോളുകൾ പരിമിതപ്പെടുത്തിയാൽ മാത്രം പോരാ എന്ന് വ്യക്തമാണ്. നിങ്ങൾ DOM-ൽ തുടർച്ചയായി ഒന്നിലധികം “വായനകളും” (reads) “എഴുത്തുകളും” (writes) നടത്തുമ്പോൾ, അതും ഒരു ബ്രൗസർ റീഫ്ലോയ്ക്ക് കാരണമാകുന്നു. വിൽസന്റെ സൈറ്റിൽ നിന്നുള്ള ഒരു സാധാരണ ഉദാഹരണം ഇതാ:
// 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
മുകളിലുള്ള ഉദാഹരണം 3 റീഫ്ലോകൾക്ക് കാരണമാകുന്നു, കാരണം ഓരോ റൈറ്റിനും (write) ശേഷം മുഴുവൻ പേജിന്റെയും അളവുകൾ അസാധുവാക്കപ്പെടുന്നു. ഇതിനായി നിർദ്ദേശിച്ച പരിഹാരം, കോഡ് പുനഃക്രമീകരിച്ച് എല്ലാ റീഡുകളും റൈറ്റുകളും ഒരുമിച്ച് ഗ്രൂപ്പ് ചെയ്യുക എന്നതാണ്, അങ്ങനെയാകുമ്പോൾ ആകെ ഒരു ബ്രൗസർ റീഫ്ലോ മാത്രമേ ഉണ്ടാവുകയുള്ളൂ:
// 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-ൽ, റീഫ്ലോ ട്രിഗർ ചെയ്യുന്ന കാര്യങ്ങൾ വായിക്കുന്നതും എഴുതുന്നതും PBS-ന്റെ ലൈഫ്-സൈക്കിളിൽ വ്യത്യസ്ത സമയങ്ങളിൽ പല സ്ഥലങ്ങളിലാണ് സംഭവിക്കുന്നത്. ആയിരക്കണക്കിന് വരികളുള്ള ജാവാസ്ക്രിപ്റ്റ് കോഡ് പുനഃക്രമീകരിക്കുക എന്നത് പ്രായോഗികമല്ലായിരുന്നു.
ഞങ്ങളുടെ ഭാഗ്യത്തിന്, വിൽസൺ തന്റെ ലേഖനത്തിൽ ഒരു പരിഹാരവും നൽകിയിരുന്നു. അത്തരം റീഡുകളും റൈറ്റുകളും ഒരുമിച്ച് കൊണ്ടുവരാൻ സഹായിക്കുന്നതിന് അദ്ദേഹം FastDom എന്ന പേരിൽ ഒരു ചെറിയ യൂട്ടിലിറ്റി സ്ക്രിപ്റ്റ് നിർമ്മിച്ചിരുന്നു.
FastDom ഉപയോഗിക്കുന്നതും ഞങ്ങളുടെ മുകളിലുള്ള പരിഹാരം #1 ഉൾക്കൊള്ളുന്നതുമായ പേജ് ബിൽഡർ സാൻഡ്‌വിച്ചിൽ നിന്നുള്ള ചില കോഡുകൾ ഇതാ:
// 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) എക്സിക്യൂട്ട് ചെയ്യുകയും ചെയ്യുന്നു, ഇത് ബ്രൗസറിലെ എല്ലാ റീഫ്ലോകളും കുറയ്ക്കുന്നതിനായി എല്ലാ റീഡുകളെയും റൈറ്റുകളെയും കാര്യക്ഷമമായി ഒരുമിച്ച് കൊണ്ടുവരുന്നു.
പരിഹാരം #3: Style ഒബ്‌ജക്റ്റുകൾ ആക്‌സസ് ചെയ്യുന്നത് ഭാരമേറിയതാണ്
ചില സ്റ്റൈൽ-ഗെറ്റിംഗ് ഫംഗ്ഷനുകൾ മറ്റുള്ളവയേക്കാൾ വേഗതയുള്ളതാണെന്ന് jsPerf-ന്റെ സഹായത്തോടെ ഞങ്ങൾ കണ്ടെത്തി.
PBS-ൽ, ഒരു എലമെന്റിന്റെ ഒരു നിർദ്ദിഷ്ട സ്റ്റൈലിന്റെ നിലവിലെ മൂല്യം ഞങ്ങൾക്ക് സാധാരണയായി നേടേണ്ടതുണ്ട്. ഉദാഹരണത്തിന്, ടോപ്പ് മാർജിൻ ലഭിക്കുന്നതിന് ഞങ്ങൾ സാധാരണയായി ഇത് ഉപയോഗിക്കുന്നു:
var styles = window.getComputedStyle( elem );
var marginTop = styles.marginTop;
എന്നാൽ, താഴെ പറയുന്ന രീതി ചെയ്യുന്നത് വളരെ വേഗതയുള്ളതാണെന്ന് ഞങ്ങൾ കണ്ടെത്തി:
var marginTop = elem.style.marginTop;
എന്നിരുന്നാലും, elem.style.marginTop ഉം getComputedStyle ഉം വളരെ വ്യത്യസ്തമാണ്. ആദ്യത്തേത് എലമെന്റിന്റെ ഇൻലൈൻ സ്റ്റൈലിംഗ് മാത്രമേ നമുക്ക് നൽകുന്നുള്ളൂ, മാത്രമല്ല സ്റ്റൈൽഷീറ്റുകളൊന്നും കണക്കിലെടുക്കുന്നില്ല; രണ്ടാമത്തേത് ഇൻലൈൻ സ്റ്റൈലുകളും സ്റ്റൈൽഷീറ്റുകളും ഒരുപോലെ കണക്കിലെടുക്കുന്നു.
കൂടാതെ, getComputedStyle റിസൾട്ട് കാഷെ ചെയ്തപ്പോൾ പോലും, അത് വളരെ വേഗത കുറഞ്ഞതായിരുന്നു. സ്റ്റൈൽ ഒബ്‌ജക്റ്റ് ആക്‌സസ് ചെയ്യുന്നതാണ് വേഗത കുറയ്ക്കുന്ന പ്രക്രിയ എന്ന് വ്യക്തമായി.
ഞങ്ങളുടെ ഭാഗ്യത്തിന്, PBS എലമെന്റുകളിലേക്ക് ഇൻലൈൻ സ്റ്റൈലുകൾ ചേർക്കുന്നു, ഇൻലൈൻ സ്റ്റൈലുകൾക്ക് സ്റ്റൈൽഷീറ്റുകളേക്കാൾ മുൻഗണന ലഭിക്കുന്നതിനാൽ (മിക്കപ്പോഴും), ഇൻലൈൻ സ്റ്റൈൽ മൂല്യം ലഭിക്കുന്നത് തന്നെ പര്യാപ്തമായ സന്ദർഭങ്ങൾ ഉണ്ടാകും. അതിനാൽ മുകളിലുള്ള രണ്ട് രീതികളും സംയോജിപ്പിച്ചാൽ, ഞങ്ങൾക്ക് വളരെ വേഗത്തിൽ പ്രവർത്തിക്കുന്ന കോഡ് കണ്ടെത്താനാകും:
var marginTop = elem.style.marginTop;
if ( ! marginTop ) {
var styles = window.getComputedStyle( elem );
marginTop = styles.marginTop;
}
കോഡ് മെച്ചപ്പെടുത്തലുകളുടെ ഫലങ്ങൾ
മുകളിലുള്ള ഞങ്ങളുടെ 3 പരിഹാരങ്ങൾക്ക് ധാരാളം ഗവേഷണങ്ങളും പരിശോധനകളും യഥാർത്ഥ നടപ്പിലാക്കലും ആവശ്യമായി വന്നു (ഞങ്ങളുടെ ഫോണ്ടുകൾ ഫീച്ചർ റിലീസ് ചെയ്യുന്നത് വൈകിപ്പിക്കുകയും ചെയ്തു), എന്നാൽ ഒടുവിൽ അതെല്ലാം ഫലവത്തായി.
സ്ക്രീനിലുടനീളം 2 സെക്കൻഡ് മൗസ് ചലിപ്പിച്ച ഞങ്ങളുടെ പ്രാരംഭ പരിശോധനയിലേക്ക് തിരികെ പോകാം. പഴയ തടസ്സങ്ങൾ നിറഞ്ഞ/വികലമായ ടൈംലൈൻ ഇതാ:
പ്രവർത്തനക്ഷമത മെച്ചപ്പെടുത്തിയതിന് ശേഷം ഞങ്ങളുടെ പുതിയ ടൈംലൈൻ എങ്ങനെയിരിക്കുന്നുവെന്ന് ഇതാ:
നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഗ്രാഫിൽ പർപ്പിൾ നിറത്തിലുള്ള കാര്യങ്ങൾ വളരെ കുറവാണ്. ബ്രൗസർ നടത്തുന്ന പ്രക്രിയകളുടെ അളവിൽ പ്രകടമായ വ്യത്യാസമുണ്ട്. താഴെയുള്ള ചതുരാകൃതിയിലുള്ള ഭാഗങ്ങൾ കനം കുറഞ്ഞതുമാണ്, അതായത് പ്രക്രിയകൾ മുമ്പത്തേക്കാൾ വേഗത്തിൽ നടക്കുന്നു.
പഴയതും പുതിയതുമായ ഗ്രാഫുകളിലെ ഉയരമുള്ളതും വീതിയുള്ളതുമായ പർപ്പിൾ ഭാഗങ്ങളുടെ അളവ് താരതമ്യം ചെയ്താൽ, ഞങ്ങൾ കാണുന്നത് അത്ഭുതകരമായ 200% പെർഫോമൻസ് വർദ്ധനവാണ്! എല്ലാ തലങ്ങളിലും പെർഫോമൻസ് വർദ്ധിക്കുന്നത് ഞങ്ങൾ കാണുന്നുണ്ട്. വളരെ മികച്ചത്!
പാഠങ്ങളും പ്രധാന കണ്ടെത്തലുകളും
സത്യസന്ധമായി പറഞ്ഞാൽ, ആൻ ഇത് ചൂണ്ടിക്കാണിക്കുന്നതിന് മുമ്പ് PBS-ന് പെർഫോമൻസ് പ്രശ്നങ്ങളുണ്ടെന്ന് ഞങ്ങൾ കരുതിയിരുന്നില്ല. പ്രധാനമായും ഞങ്ങൾ ഡെവലപ്‌മെന്റ്-കേന്ദ്രീകൃത മെഷീനുകൾ ഉപയോഗിച്ചിരുന്നതിനാലും പെർഫോമൻസ് ബോട്ടിൽനെക്കുകൾ അത്ര പ്രകടമല്ലാത്തതിനാലുമാണിത്. തിരിഞ്ഞുനോക്കുമ്പോൾ, പെർഫോമൻസ് പരിശോധിക്കുന്നത് മുൻഗണനകളിൽ ഒന്നാക്കേണ്ടതായിരുന്നു. എന്നാൽ ഇപ്പോൾ, പതിപ്പ് 4.3 മുതൽ അത് പരിഹരിക്കപ്പെട്ടിരിക്കുന്നു. 
സ്വന്തം വേർഡ്പ്രസ്സ് പ്ലഗിൻ പ്രകടനം മെച്ചപ്പെടുത്താൻ ആഗ്രഹിക്കുന്നവർക്കായി, പ്രത്യേകിച്ചും നിങ്ങൾ കനത്ത ജാവാസ്ക്രിപ്റ്റ് ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, ഈ അനുഭവത്തിൽ നിന്നുള്ള എന്റെ നിർദ്ദേശങ്ങൾ ഇതാ:
- റീഫ്ലോ ട്രിഗർ ചെയ്യുന്ന പ്രോപ്പർട്ടികളിലേക്കും/ഫംഗ്ഷനുകളിലേക്കുമുള്ള നിങ്ങളുടെ കോളുകൾ പരിമിതപ്പെടുത്തുക/കാഷെ ചെയ്യുക. ഇത് ഒരു വഴികാട്ടിയായി ഉപയോഗിക്കുക: What forces layout/reflow. The comprehensive list.
- DOM സ്റ്റൈലുകളിലേക്കുള്ള “reads”, “writes” എന്നിവ ഒരുമിച്ച് ഗ്രൂപ്പ് ചെയ്യുക. നിങ്ങൾക്കായി ഇത് ചെയ്യാൻ FastDom ഉപയോഗിക്കുക.
- Chrome-ന്റെ Timeline profiler ഉപയോഗിക്കുക, കൂടാതെ കഴിയുന്നത്ര കുറഞ്ഞ റീഫ്ലോകൾ (പർപ്പിൾ കാര്യങ്ങൾ) മാത്രമേ ഉള്ളൂ എന്ന് ഉറപ്പാക്കുക.
നിങ്ങൾ അപൂർവ്വമായി മാത്രം ചിത്രങ്ങൾ ഉൾക്കൊള്ളുന്ന മുഴുനീള ലേഖനങ്ങൾ എഴുതുന്നതിൽ മാത്രം ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്ന ഒരു കടുത്ത ബ്ലോഗറാണെങ്കിൽ, നിലവിലുള്ള TinyMCE കണ്ടന്റ് എഡിറ്റർ നിങ്ങളുടെ ആവശ്യങ്ങൾക്ക് ഒരുപക്ഷേ മതിയായേക്കാം. ലേഖനങ്ങൾ എഴുതുന്നതിന് ആവശ്യമായ ടൂളുകൾ നിലവിലെ ടൂൾസെറ്റിൽ ഇതിനകം തന്നെയുണ്ട്, ബോൾഡ്, ഇറ്റാലിക്, തലക്കെട്ടുകൾ തുടങ്ങിയ നിങ്ങളുടെ അടിസ്ഥാന ടെക്സ്റ്റ് ഫോർമാറ്റിംഗ് ടൂളുകൾ നിങ്ങൾക്ക് ലഭിക്കുന്നു. എന്നാൽ അത്രമാത്രമേ അതിലുള്ളൂ.
ഇതാ നോക്കൂ. ഇത് മുഴുവൻ പെർഫോമൻസ് ബോട്ടിൽനെക്കുകൾ കൊണ്ട് നിറഞ്ഞിരിക്കുന്നു!
നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഗ്രാഫിൽ പർപ്പിൾ നിറത്തിലുള്ള കാര്യങ്ങൾ വളരെ കുറവാണ്. ബ്രൗസർ നടത്തുന്ന പ്രക്രിയകളുടെ അളവിൽ പ്രകടമായ വ്യത്യാസമുണ്ട്. താഴെയുള്ള ചതുരാകൃതിയിലുള്ള ഭാഗങ്ങൾ കനം കുറഞ്ഞതുമാണ്, അതായത് പ്രക്രിയകൾ മുമ്പത്തേക്കാൾ വേഗത്തിൽ നടക്കുന്നു.
