ക്രിട്ടിക്കൽ റെൻഡറിംഗ് പാത്ത് വിശകലനം ചെയ്ത് ഒപ്റ്റിമൈസ് ചെയ്തുകൊണ്ട് വെബ് പെർഫോമൻസ് മെച്ചപ്പെടുത്തുക. JavaScript റെൻഡറിംഗിനെ എങ്ങനെ ബാധിക്കുന്നു, അത് എങ്ങനെ പരിഹരിക്കാം എന്നതിനെക്കുറിച്ചുള്ള ഒരു സമഗ്ര ഗൈഡ്.
JavaScript പെർഫോമൻസ് ഒപ്റ്റിമൈസേഷൻ: ക്രിട്ടിക്കൽ റെൻഡറിംഗ് പാത്തിലേക്കുള്ള ആഴത്തിലുള്ള ഒരന്വേഷണം
വെബ് ഡെവലപ്‌മെൻ്റ് ലോകത്ത്, വേഗത എന്നത് ഒരു ഫീച്ചർ മാത്രമല്ല; നല്ല ഉപയോക്തൃ അനുഭവത്തിൻ്റെ അടിത്തറയാണ്. സാവധാനം ലോഡ് ചെയ്യുന്ന ഒരു വെബ്‌സൈറ്റ് ഉയർന്ന ബൗൺസ് നിരക്കുകൾക്കും കുറഞ്ഞ പരിവർത്തനങ്ങൾക്കും നിരാശരായ பார்வையாளர்களுக்கும் കാരണമാകും. വെബ് പെർഫോമൻസിന് നിരവധി ഘടകങ്ങൾ സംഭാവന നൽകുമ്പോൾ, ഏറ്റവും അടിസ്ഥാനപരവും പലപ്പോഴും തെറ്റിദ്ധരിക്കപ്പെടുന്നതുമായ ആശയങ്ങളിലൊന്നാണ് ക്രിട്ടിക്കൽ റെൻഡറിംഗ് പാത്ത് (CRP). ബ്രൗസറുകൾ ഉള്ളടക്കം എങ്ങനെ റെൻഡർ ചെയ്യുന്നു എന്നതും, അതിലും പ്രധാനമായി, JavaScript ഈ പ്രക്രിയയുമായി എങ്ങനെ ഇടപെടുന്നു എന്നതും പെർഫോമൻസിനെക്കുറിച്ച് ഗൗരവമായി ചിന്തിക്കുന്ന ഏതൊരു ഡെവലപ്പർക്കും പരമപ്രധാനമാണ്.
ഈ സമഗ്രമായ ഗൈഡ് നിങ്ങളെ ക്രിട്ടിക്കൽ റെൻഡറിംഗ് പാത്തിലേക്ക് ആഴത്തിലുള്ള ഒരു യാത്രക്ക് കൊണ്ടുപോകുന്നു, പ്രത്യേകിച്ചും JavaScript-ൻ്റെ പങ്കിനെക്കുറിച്ച് ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു. ആഗോള ഉപയോക്തൃ അടിത്തറയ്‌ക്കായി നിങ്ങളുടെ വെബ് ആപ്ലിക്കേഷനുകൾ വേഗത്തിലും പ്രതികരണശേഷിയുള്ളതുമാക്കാൻ സഹായിക്കുന്ന ശക്തമായ ഒപ്റ്റിമൈസേഷൻ ടെക്നിക്കുകൾ എങ്ങനെ വിശകലനം ചെയ്യാമെന്നും ബോട്ടിൽനെക്കുകൾ തിരിച്ചറിയാമെന്നും ഞങ്ങൾ ഇവിടെ പരിശോധിക്കും.
എന്താണ് ക്രിട്ടിക്കൽ റെൻഡറിംഗ് പാത്ത്?
HTML, CSS, JavaScript എന്നിവയെ സ്ക്രീനിൽ കാണുന്ന പിക്സലുകളാക്കി മാറ്റാൻ ഒരു ബ്രൗസർ സ്വീകരിക്കേണ്ട ഘട്ടങ്ങളുടെ ഒരു ശ്രേണിയാണ് ക്രിട്ടിക്കൽ റെൻഡറിംഗ് പാത്ത്. CRP ഒപ്റ്റിമൈസേഷന്റെ പ്രാഥമിക ലക്ഷ്യം, പ്രാരംഭത്തിലുള്ള "above-the-fold" ഉള്ളടക്കം എത്രയും വേഗം ഉപയോക്താവിന് നൽകുക എന്നതാണ്. ഇത് എത്ര വേഗത്തിൽ സംഭവിക്കുന്നുവോ അത്രത്തോളം വേഗത്തിൽ ഉപയോക്താവിന് പേജ് ലോഡ് ചെയ്യുന്നതായി അനുഭവപ്പെടും.
പാതയിൽ നിരവധി പ്രധാന ഘട്ടങ്ങൾ അടങ്ങിയിരിക്കുന്നു:
- DOM നിർമ്മാണം: സെർവറിൽ നിന്ന് HTML ഡോക്യുമെൻ്റിൻ്റെ ആദ്യ ബൈറ്റുകൾ ബ്രൗസർക്ക് ലഭിക്കുമ്പോൾ ഈ പ്രക്രിയ ആരംഭിക്കുന്നു. ഇത് HTML മാർക്ക്അപ്പ് ക്യാരക്ടർ ബൈ ക്യാരക്ടർ പാഴ്‌സ് ചെയ്യാൻ തുടങ്ങുകയും Document Object Model (DOM) നിർമ്മിക്കുകയും ചെയ്യുന്നു. HTML ഡോക്യുമെൻ്റിലെ എല്ലാ നോഡുകളെയും (എലമെൻ്റുകൾ, ആട്രിബ്യൂട്ടുകൾ, ടെക്സ്റ്റ്) പ്രതിനിധീകരിക്കുന്ന ട്രീ പോലുള്ള ഘടനയാണ് DOM.
- CSSOM നിർമ്മാണം: ബ്രൗസർ DOM നിർമ്മിക്കുമ്പോൾ, ഒരു CSS സ്റ്റൈൽഷീറ്റ് കണ്ടുമുട്ടിയാൽ (
<link>ടാഗിലോ ഇൻലൈൻ<style>ബ്ലോക്കിലോ), അത് CSS Object Model (CSSOM) നിർമ്മിക്കാൻ തുടങ്ങുന്നു. DOM-ന് സമാനമായി, CSSOM എന്നത് പേജിലെ എല്ലാ ശൈലികളും അവയുടെ ബന്ധങ്ങളും അടങ്ങിയ ഒരു ട്രീ ഘടനയാണ്. HTML-ൽ നിന്ന് വ്യത്യസ്തമായി, CSS സ്ഥിരമായി render-blocking ആണ്. എല്ലാ CSS-ഉം ഡൗൺലോഡ് ചെയ്ത് പാഴ്‌സ് ചെയ്യുന്നതുവരെ ബ്രൗസറിന് പേജിന്റെ ഒരു ഭാഗവും റെൻഡർ ചെയ്യാൻ കഴിയില്ല, കാരണം പിന്നീടുള്ള ശൈലികൾ ആദ്യത്തേതിനെ മറികടക്കാൻ സാധ്യതയുണ്ട്. - Render Tree നിർമ്മാണം: DOM ഉം CSSOM ഉം തയ്യാറായിക്കഴിഞ്ഞാൽ, ബ്രൗസർ അവയെ സംയോജിപ്പിച്ച് Render Tree ഉണ്ടാക്കുന്നു. ഈ ട്രീയിൽ പേജ് റെൻഡർ ചെയ്യാൻ ആവശ്യമായ നോഡുകൾ മാത്രമേ അടങ്ങിയിരിക്കുകയുള്ളൂ. ഉദാഹരണത്തിന്,
display: none;എന്നുള്ള എലമെൻ്റുകളും<head>ടാഗും Render Tree-യിൽ ഉൾപ്പെടുന്നില്ല, കാരണം അവ ദൃശ്യപരമായി റെൻഡർ ചെയ്യുന്നില്ല. Render Tree-ക്ക് എന്ത് ഡിസ്‌പ്ലേ ചെയ്യണമെന്ന് അറിയാം, പക്ഷേ എവിടെ, എത്ര വലുപ്പത്തിൽ എന്ന് അറിയില്ല. - Layout (അഥവാ Reflow): Render Tree നിർമ്മിച്ച ശേഷം, ബ്രൗസർ ലേഔട്ട് ഘട്ടത്തിലേക്ക് കടക്കുന്നു. ഈ ഘട്ടത്തിൽ, വ്യൂപോർട്ടിന് ആപേക്ഷികമായി Render Tree-യിലെ ഓരോ നോഡിൻ്റെയും കൃത്യമായ വലുപ്പവും സ്ഥാനവും ഇത് കണക്കാക്കുന്നു. ഈ ഘട്ടത്തിൻ്റെ ഫലമായി ലഭിക്കുന്നത് പേജിലെ ഓരോ എലമെൻ്റിൻ്റെയും കൃത്യമായ ജ്യാമിതി രേഖപ്പെടുത്തുന്ന ഒരു "ബോക്സ് മോഡൽ" ആണ്.
- Paint: അവസാനമായി, ബ്രൗസർ ലേഔട്ട് വിവരങ്ങൾ എടുത്ത് സ്ക്രീനിലെ ഓരോ നോഡിനുമുള്ള പിക്സലുകൾ "paint" ചെയ്യുന്നു. ഇതിൽ ടെക്സ്റ്റ്, നിറങ്ങൾ, ചിത്രങ്ങൾ, ബോർഡറുകൾ, ഷാഡോകൾ എന്നിവ വരയ്ക്കുന്നത് ഉൾപ്പെടുന്നു - അടിസ്ഥാനപരമായി പേജിന്റെ എല്ലാ ദൃശ്യഭാഗങ്ങളും റാസ്റ്ററൈസ് ചെയ്യുന്നു. കാര്യക്ഷമത മെച്ചപ്പെടുത്താൻ ഈ പ്രക്രിയ ഒന്നിലധികം ലെയറുകളിൽ സംഭവിക്കാം.
- Composite: പേജ് കണ്ടൻ്റ് ഒന്നിലധികം ലെയറുകളിലേക്ക് പെയിൻ്റ് ചെയ്തിട്ടുണ്ടെങ്കിൽ, സ്ക്രീനിൽ അവസാന ചിത്രം പ്രദർശിപ്പിക്കുന്നതിന് ബ്രൗസർ ഈ ലെയറുകൾ ശരിയായ ക്രമത്തിൽ കോമ്പോസിറ്റ് ചെയ്യണം. ആനിമേഷനുകൾക്കും സ്ക്രോളിംഗിനും ഈ ഘട്ടം വളരെ പ്രധാനമാണ്, കാരണം ലേഔട്ട്, പെയിൻ്റ് ഘട്ടങ്ങൾ വീണ്ടും പ്രവർത്തിപ്പിക്കുന്നതിനേക്കാൾ പൊതുവെ കോമ്പോസിറ്റിംഗ് കമ്പ്യൂട്ടേഷണൽപരമായി കുറഞ്ഞ ചിലവേറിയതാണ്.
ക്രിട്ടിക്കൽ റെൻഡറിംഗ് പാതയിൽ JavaScript-ൻ്റെ തടസ്സമുണ്ടാക്കുന്ന പങ്ക്
അപ്പോൾ JavaScript ഈ ചിത്രത്തിൽ എവിടെയാണ് വരുന്നത്? DOM, CSSOM എന്നിവ രണ്ടും മാറ്റാൻ കഴിയുന്ന ശക്തമായ ഭാഷയാണ് JavaScript. എന്നിരുന്നാലും, ഈ ശക്തിക്ക് ഒരു വിലയുണ്ട്. JavaScript-ന് ക്രിട്ടിക്കൽ റെൻഡറിംഗ് പാതയെ തടസ്സപ്പെടുത്താൻ കഴിയും, ഇത് റെൻഡറിംഗിൽ കാര്യമായ കാലതാമസത്തിന് കാരണമാവുകയും ചെയ്യും.
പാർസർ-Blocking JavaScript
സ്ഥിരമായി, JavaScript parser-blocking ആണ്. ബ്രൗസറിൻ്റെ HTML പാർസർ ഒരു <script> ടാഗ് കണ്ടെത്തുമ്പോൾ, DOM നിർമ്മിക്കുന്ന പ്രക്രിയ താൽക്കാലികമായി നിർത്തണം. തുടർന്ന് അത് JavaScript ഫയൽ ഡൗൺലോഡ് ചെയ്യാനും (ബാഹ്യമെങ്കിൽ), പാഴ്‌സ് ചെയ്യാനും, എക്സിക്യൂട്ട് ചെയ്യാനും തുടങ്ങുന്നു. ഈ പ്രക്രിയ ബ്ലോക്ക് ചെയ്യുന്നതിന് കാരണം, സ്ക്രിപ്റ്റ് document.write() പോലെ എന്തെങ്കിലും ചെയ്യാൻ സാധ്യതയുണ്ട്, ഇത് മുഴുവൻ DOM ഘടനയെയും മാറ്റാൻ സാധ്യതയുണ്ട്. HTML സുരക്ഷിതമായി പാഴ്‌സ് ചെയ്യുന്നത് പുനരാരംഭിക്കുന്നതിന് മുമ്പ് സ്ക്രിപ്റ്റ് പൂർത്തിയാകുന്നതുവരെ കാത്തിരിക്കാൻ ബ്രൗസറിന് മറ്റ് മാർഗ്ഗമില്ല.
ഈ സ്ക്രിപ്റ്റ് നിങ്ങളുടെ ഡോക്യുമെൻ്റിൻ്റെ <head>-ൽ ആണെങ്കിൽ, ഇത് തുടക്കത്തിൽ തന്നെ DOM നിർമ്മാണത്തെ തടസ്സപ്പെടുത്തുന്നു. ഇതിനർത്ഥം ബ്രൗസറിന് റെൻഡർ ചെയ്യാൻ ഉള്ളടക്കമൊന്നുമില്ല, കൂടാതെ സ്ക്രിപ്റ്റ് പൂർണ്ണമായി പ്രോസസ്സ് ചെയ്യുന്നതുവരെ ഉപയോക്താവ് വെളുത്ത സ്ക്രീനിൽ നോക്കിയിരിക്കേണ്ടിവരും. മോശം പ്രകടനം ഉണ്ടാകുന്നതിനുള്ള പ്രധാന കാരണം ഇതാണ്.
DOM, CSSOM മാനിപ്പുലേഷൻ
JavaScript-ന് CSSOM-നെ ചോദ്യം ചെയ്യാനും മാറ്റം വരുത്താനും കഴിയും. ഉദാഹരണത്തിന്, നിങ്ങളുടെ സ്ക്രിപ്റ്റ് element.style.width പോലുള്ള കമ്പ്യൂട്ട് ചെയ്ത ശൈലി ആവശ്യപ്പെടുകയാണെങ്കിൽ, ശരിയായ ഉത്തരം നൽകുന്നതിന് CSS എല്ലാം ഡൗൺലോഡ് ചെയ്ത് പാഴ്‌സ് ചെയ്തു എന്ന് ബ്രൗസർ ആദ്യം ഉറപ്പാക്കണം. ഇത് നിങ്ങളുടെ JavaScript-നും CSS-നും ഇടയിൽ ഒരു ഡിപൻഡൻസി ഉണ്ടാക്കുന്നു, CSSOM തയ്യാറാകുന്നതുവരെ സ്ക്രിപ്റ്റ് എക്സിക്യൂഷൻ തടസ്സപ്പെടാൻ സാധ്യതയുണ്ട്.
കൂടാതെ, JavaScript DOM-ൽ മാറ്റങ്ങൾ വരുത്തുകയാണെങ്കിൽ (ഉദാഹരണത്തിന്, ഒരു എലമെൻ്റ് ചേർക്കുകയോ നീക്കം ചെയ്യുകയോ ചെയ്യുക) അല്ലെങ്കിൽ CSSOM-ൽ (ഉദാഹരണത്തിന്, ഒരു ക്ലാസ് മാറ്റുക), അത് ബ്രൗസറിൻ്റെ പ്രവർത്തനങ്ങളുടെ ഒരു പരമ്പരയ്ക്ക് കാരണമാകും. ഒരു മാറ്റം ബ്രൗസറിനെ ലേഔട്ട് വീണ്ടും കണക്കാക്കാൻ (ഒരു റീഫ്ലോ) തുടർന്ന് സ്ക്രീനിന്റെ ബാധിച്ച ഭാഗങ്ങൾ വീണ്ടും പെയിൻ്റ് ചെയ്യാൻ നിർബന്ധിതമാക്കിയേക്കാം. പതിവായതോ മോശമായി സമയബന്ധിതമായി ചെയ്യുന്നതോ ആയ മാനിപ്പുലേഷനുകൾ മന്ദഗതിയിലുള്ളതും പ്രതികരണശേഷിയില്ലാത്തതുമായ ഉപയോക്തൃ ഇൻ്റർഫേസിലേക്ക് നയിച്ചേക്കാം.
ക്രിട്ടിക്കൽ റെൻഡറിംഗ് പാത്ത് എങ്ങനെ വിശകലനം ചെയ്യാം
ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിന് മുമ്പ്, നിങ്ങൾ ആദ്യം അളക്കണം. CRP വിശകലനം ചെയ്യുന്നതിന് ബ്രൗസർ ഡെവലപ്പർ ടൂളുകളാണ് ഏറ്റവും നല്ലത്. ഈ ആവശ്യത്തിനായി ശക്തമായ ടൂളുകൾ നൽകുന്ന Chrome DevTools-ൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാം.
പെർഫോമൻസ് ടാബ് ഉപയോഗിക്കുന്നു
നിങ്ങളുടെ പേജ് റെൻഡർ ചെയ്യാൻ ബ്രൗസർ ചെയ്യുന്ന എല്ലാ കാര്യങ്ങളുടെയും വിശദമായ ടൈംലൈൻ പെർഫോമൻസ് ടാബ് നൽകുന്നു.
- Chrome DevTools തുറക്കുക (Ctrl+Shift+I അല്ലെങ്കിൽ Cmd+Option+I).
- പെർഫോമൻസ് ടാബിലേക്ക് പോകുക.
- ടൈംലൈനിൽ പ്രധാന അളവുകൾ കാണുന്നതിന് "വെബ് വൈറ്റൽസ്" ചെക്ക്ബോക്സ് ടിക്ക് ചെയ്തിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക.
- പേജ് ലോഡിംഗ് പ്രൊഫൈലിംഗ് ആരംഭിക്കാൻ റീലോഡ് ബട്ടൺ ക്ലിക്കുചെയ്യുക (അല്ലെങ്കിൽ Ctrl+Shift+E / Cmd+Shift+E അമർത്തുക).
പേജ് ലോഡ് ചെയ്ത ശേഷം, നിങ്ങൾക്ക് ഒരു ഫ്ലെയിം ചാർട്ട് കാണാൻ കഴിയും. Main ത്രെഡ് വിഭാഗത്തിൽ നിങ്ങൾ എന്താണ് ശ്രദ്ധിക്കേണ്ടതെന്ന് താഴെക്കൊടുക്കുന്നു:
- Long Tasks: 50 മില്ലിസെക്കൻഡിൽ കൂടുതൽ എടുക്കുന്ന ഏതൊരു ടാസ്‌ക്കും ചുവന്ന ത്രികോണം കൊണ്ട് അടയാളപ്പെടുത്തിയിരിക്കുന്നു. ഇവ ഒപ്റ്റിമൈസേഷനുള്ള പ്രധാന സ്ഥാനാർത്ഥികളാണ്, കാരണം അവ പ്രധാന ത്രെഡിനെ തടസ്സപ്പെടുത്തുകയും UI പ്രതികരണശേഷിയില്ലാത്തതാക്കുകയും ചെയ്യും.
- Parse HTML (നീല): ബ്രൗസർ നിങ്ങളുടെ HTML എവിടെയാണ് പാഴ്‌സ് ചെയ്യുന്നതെന്ന് ഇത് കാണിക്കുന്നു. വലിയ വിടവുകളോ തടസ്സങ്ങളോ നിങ്ങൾ കാണുകയാണെങ്കിൽ, അതിന് കാരണം ഒരു ബ്ലോക്ക് ചെയ്യുന്ന സ്ക്രിപ്റ്റ് ആയിരിക്കാം.
- Evaluate Script (മഞ്ഞ): ഇവിടെയാണ് JavaScript എക്സിക്യൂട്ട് ചെയ്യുന്നത്. പേജ് ലോഡിംഗിൻ്റെ തുടക്കത്തിൽ വലിയ മഞ്ഞ ബ്ലോക്കുകൾക്കായി നോക്കുക. ഇവയാണ് നിങ്ങളുടെ ബ്ലോക്ക് ചെയ്യുന്ന സ്ക്രിപ്റ്റുകൾ.
- Recalculate Style (ஊதா): ഇത് CSSOM നിർമ്മാണത്തെയും ശൈലി കണക്കുകൂട്ടലുകളെയും സൂചിപ്പിക്കുന്നു.
- Layout (ஊதா): ഈ ബ്ലോക്കുകൾ ലേഔട്ട് അല്ലെങ്കിൽ റീഫ്ലോ ഘട്ടത്തെ പ്രതിനിധീകരിക്കുന്നു. ഇവയിൽ പലതും നിങ്ങൾ കാണുകയാണെങ്കിൽ, നിങ്ങളുടെ JavaScript ജ്യാമിതീയ ഗുണവിശേഷതകൾ ആവർത്തിച്ച് വായിക്കുകയും എഴുതുകയും ചെയ്യുന്നതിലൂടെ "ലേഔട്ട് ത്രാഷിംഗിന്" കാരണമാകുന്നുണ്ടാകാം.
- Paint (பச்சை): ഇത് പെയിൻ്റിംഗ് പ്രക്രിയയാണ്.
നെറ്റ്‌വർക്ക് ടാബ് ഉപയോഗിക്കുന്നു
വിഭവങ്ങളുടെ ഡൗൺലോഡുകളുടെ ക്രമവും കാലയളവും മനസ്സിലാക്കുന്നതിന് നെറ്റ്‌വർക്ക് ടാബിൻ്റെ വാട്ടർഫാൾ ചാർട്ട് വിലമതിക്കാനാവാത്തതാണ്.
- DevTools തുറന്ന് Network ടാബിലേക്ക് പോകുക.
- പേജ് വീണ്ടും ലോഡ് ചെയ്യുക.
- ഓരോ റിസോഴ്സും (HTML, CSS, JS, ചിത്രങ്ങൾ) എപ്പോൾ അഭ്യർത്ഥിച്ചു, ഡൗൺലോഡ് ചെയ്തു എന്ന് വാട്ടർഫാൾ വ്യൂ നിങ്ങളെ കാണിക്കുന്നു.
വാട്ടർഫാളിന്റെ മുകളിലുള്ള അഭ്യർത്ഥനകളിൽ ശ്രദ്ധിക്കുക. പേജ് റെൻഡർ ചെയ്യാൻ തുടങ്ങുന്നതിന് മുമ്പ് ഡൗൺലോഡ് ചെയ്യുന്ന CSS, JavaScript ഫയലുകൾ നിങ്ങൾക്ക് എളുപ്പത്തിൽ കണ്ടെത്താനാകും. ഇവയാണ് നിങ്ങളുടെ റെൻഡർ-Blocking റിസോഴ്സുകൾ.
ലൈറ്റ്ഹൗസ് ഉപയോഗിക്കുന്നു
Chrome DevTools-ൽ നിർമ്മിച്ചിട്ടുള്ള ഒരു ഓട്ടോമേറ്റഡ് ഓഡിറ്റിംഗ് ടൂളാണ് ലൈറ്റ്ഹൗസ് (ലൈറ്റ്ഹൗസ് ടാബിന് കീഴിൽ). ഇത് ഉയർന്ന തലത്തിലുള്ള പ്രകടന സ്കോറും പ്രവർത്തനക്ഷമമായ ശുപാർശകളും നൽകുന്നു.
CRP-ക്കുള്ള പ്രധാന ഓഡിറ്റാണ് "റെൻഡർ-Blocking ഉറവിടങ്ങൾ ഇല്ലാതാക്കുക." ഈ റിപ്പോർട്ട് ഫസ്റ്റ് കണ്ടന്റ്ഫുൾ പെയിൻ്റിനെ (FCP) വൈകിപ്പിക്കുന്ന CSS, JavaScript ഫയലുകൾ വ്യക്തമായി ലിസ്റ്റ് ചെയ്യും, ഇത് ഒപ്റ്റിമൈസേഷനുള്ള ലക്ഷ്യങ്ങളുടെ വ്യക്തമായ ലിസ്റ്റ് നൽകുന്നു.
JavaScript-നുള്ള പ്രധാന ഒപ്റ്റിമൈസേഷൻ തന്ത്രങ്ങൾ
പ്രശ്നങ്ങൾ എങ്ങനെ തിരിച്ചറിയാമെന്ന് ഇപ്പോൾ നമുക്കറിയാം, ഇനി പരിഹാരങ്ങൾ എന്തൊക്കെയാണെന്ന് നോക്കാം. പ്രാരംഭ റെൻഡറിംഗിനെ തടസ്സപ്പെടുത്തുന്ന JavaScript-ൻ്റെ അളവ് കുറയ്ക്കുക എന്നതാണ് ലക്ഷ്യം.
1. `async`, `defer` എന്നിവയുടെ ശക്തി
HTML പാർസറെ തടസ്സപ്പെടുത്തുന്നതിൽ നിന്ന് JavaScript-നെ തടയുന്നതിനുള്ള ഏറ്റവും ലളിതവും ഫലപ്രദവുമായ മാർഗ്ഗം നിങ്ങളുടെ <script> ടാഗുകളിൽ `async`, `defer` ആട്രിബ്യൂട്ടുകൾ ഉപയോഗിക്കുക എന്നതാണ്.
- Standard
<script>:<script src="script.js"></script>
നമ്മൾ ചർച്ച ചെയ്തതുപോലെ, ഇത് parser-blocking ആണ്. HTML പാഴ്‌സിംഗ് നിർത്തുന്നു, സ്ക്രിപ്റ്റ് ഡൗൺലോഡ് ചെയ്യുകയും എക്സിക്യൂട്ട് ചെയ്യുകയും ചെയ്യുന്നു, തുടർന്ന് പാഴ്‌സിംഗ് പുനരാരംഭിക്കുന്നു. <script async>:<script src="script.js" async></script>
HTML പാഴ്‌സിംഗിനൊപ്പം സമാന്തരമായി സ്ക്രിപ്റ്റ് അസിൻക്രണസ്സായി ഡൗൺലോഡ് ചെയ്യുന്നു. സ്ക്രിപ്റ്റ് ഡൗൺലോഡ് ചെയ്യുന്നത് പൂർത്തിയാകുമ്പോൾ, HTML പാഴ്‌സിംഗ് താൽക്കാലികമായി നിർത്തി സ്ക്രിപ്റ്റ് എക്സിക്യൂട്ട് ചെയ്യുന്നു. എക്സിക്യൂഷൻ ഓർഡർ ഉറപ്പില്ല; സ്ക്രിപ്റ്റുകൾ ലഭ്യമാകുമ്പോൾ എക്സിക്യൂട്ട് ചെയ്യുന്നു. DOM-നെയോ മറ്റ് സ്ക്രിപ്റ്റുകളെയോ ആശ്രയിക്കാത്ത സ്വതന്ത്രമായ, മൂന്നാം കക്ഷി സ്ക്രിപ്റ്റുകൾക്ക് ഇത് ഏറ്റവും മികച്ചതാണ്, ഉദാഹരണത്തിന് അനലിറ്റിക്സ് അല്ലെങ്കിൽ പരസ്യ സ്ക്രിപ്റ്റുകൾ.<script defer>:<script src="script.js" defer></script>
HTML പാഴ്‌സിംഗിനൊപ്പം സമാന്തരമായി സ്ക്രിപ്റ്റ് അസിൻക്രണസ്സായി ഡൗൺലോഡ് ചെയ്യുന്നു. എന്നിരുന്നാലും, HTML ഡോക്യുമെൻ്റ് പൂർണ്ണമായി പാഴ്‌സ് ചെയ്ത ശേഷം മാത്രമേ സ്ക്രിപ്റ്റ് എക്സിക്യൂട്ട് ചെയ്യൂ (`DOMContentLoaded` ഇവൻ്റിന് തൊട്ടുമുമ്പ്). `defer` ഉള്ള സ്ക്രിപ്റ്റുകൾ ഡോക്യുമെൻ്റിൽ ദൃശ്യമാകുന്ന ക്രമത്തിൽ എക്സിക്യൂട്ട് ചെയ്യുമെന്ന് ഉറപ്പുണ്ട്. DOM-മായി ബന്ധപ്പെടേണ്ടതും പ്രാരംഭ പെയിൻ്റിംഗിന് നിർണായകമല്ലാത്തതുമായ മിക്ക സ്ക്രിപ്റ്റുകൾക്കും ഇത് ഏറ്റവും നല്ല രീതിയാണ്.
പൊതുവായ നിയമം: നിങ്ങളുടെ പ്രധാന ആപ്ലിക്കേഷൻ സ്ക്രിപ്റ്റുകൾക്കായി `defer` ഉപയോഗിക്കുക. സ്വതന്ത്രമായ മൂന്നാം കക്ഷി സ്ക്രിപ്റ്റുകൾക്കായി `async` ഉപയോഗിക്കുക. പ്രാരംഭ റെൻഡറിംഗിന് അത്യാവശ്യമല്ലാത്ത ബ്ലോക്ക് ചെയ്യുന്ന സ്ക്രിപ്റ്റുകൾ <head>-ൽ ഉപയോഗിക്കുന്നത് ഒഴിവാക്കുക.
2. കോഡ് സ്പ്ലിറ്റിംഗ്
ആധുനിക വെബ് ആപ്ലിക്കേഷനുകൾ പലപ്പോഴും ഒരൊറ്റ, വലിയ JavaScript ഫയലായി ബണ്ടിൽ ചെയ്യപ്പെടുന്നു. ഇത് HTTP അഭ്യർത്ഥനകളുടെ എണ്ണം കുറയ്ക്കുമ്പോൾ, പ്രാരംഭ പേജ് കാഴ്ചയ്ക്ക് ആവശ്യമില്ലാത്ത ധാരാളം കോഡ് ഡൗൺലോഡ് ചെയ്യാൻ ഇത് ഉപയോക്താവിനെ നിർബന്ധിതരാക്കുന്നു.
ആവശ്യമനുസരിച്ച് ലോഡ് ചെയ്യാൻ കഴിയുന്ന ചെറിയ ഭാഗങ്ങളായി വലിയ ബണ്ടിലിനെ വിഭജിക്കുന്ന പ്രക്രിയയാണ് കോഡ് സ്പ്ലിറ്റിംഗ്. ഉദാഹരണത്തിന്:
- Initial Chunk: നിലവിലെ പേജിന്റെ ദൃശ്യമായ ഭാഗം റെൻഡർ ചെയ്യാൻ ആവശ്യമായ JavaScript മാത്രമേ ഇതിൽ അടങ്ങിയിരിക്കുകയുള്ളൂ.
- On-Demand Chunks: മറ്റ് റൂട്ടുകൾ, മോഡലുകൾ അല്ലെങ്കിൽ താഴെയുള്ള ഫീച്ചറുകൾക്കുള്ള കോഡ് ഇതിൽ അടങ്ങിയിരിക്കുന്നു. ഉപയോക്താവ് ആ റൂട്ടിലേക്ക് നാവിഗേറ്റ് ചെയ്യുമ്പോളോ ഫീച്ചറുമായി സംവദിക്കുമ്പോളോ മാത്രമേ ഇവ ലോഡ് ചെയ്യൂ.
Webpack, Rollup, Parcel പോലുള്ള ആധുനിക ബണ്ടിലറുകൾക്ക് ഡൈനാമിക് `import()` സിൻ്റാക്സ് ഉപയോഗിച്ച് കോഡ് സ്പ്ലിറ്റിംഗിനുള്ള പിന്തുണയുണ്ട്. React (`React.lazy` ഉപയോഗിച്ച്), Vue പോലുള്ള ഫ്രെയിംവർക്കുകൾ കോമ്പോണൻ്റ് തലത്തിൽ കോഡ് വിഭജിക്കാൻ എളുപ്പവഴികൾ നൽകുന്നു.
3. ട്രീ ഷേക്കിംഗും ഡെഡ് കോഡ് എലിമിനേഷനും
കോഡ് സ്പ്ലിറ്റിംഗ് ഉപയോഗിച്ച് പോലും, നിങ്ങളുടെ പ്രാരംഭ ബണ്ടിലിൽ ഉപയോഗിക്കാത്ത കോഡ് അടങ്ങിയിരിക്കാം. നിങ്ങൾ ലൈബ്രറികൾ ഇമ്പോർട്ട് ചെയ്യുമ്പോൾ അവയുടെ ഒരു ചെറിയ ഭാഗം മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂവെങ്കിൽ ഇത് സാധാരണമാണ്.
നിങ്ങളുടെ ഫൈനൽ ബണ്ടിലിൽ നിന്ന് ഉപയോഗിക്കാത്ത കോഡ് ഇല്ലാതാക്കാൻ ആധുനിക ബണ്ടിലറുകൾ ഉപയോഗിക്കുന്ന ഒരു പ്രക്രിയയാണ് ട്രീ ഷേക്കിംഗ്. ഇത് നിങ്ങളുടെ `import`, `export` സ്റ്റേറ്റ്‌മെൻ്റുകൾ സ്റ്റാറ്റിക്കായി വിശകലനം ചെയ്യുകയും ഏത് കോഡാണ് എത്തിച്ചേരാനാവാത്തതെന്ന് കണ്ടെത്തുകയും ചെയ്യുന്നു. നിങ്ങളുടെ ഉപയോക്താക്കൾക്ക് ആവശ്യമുള്ള കോഡ് മാത്രം നൽകുന്നതിലൂടെ, നിങ്ങൾക്ക് ബണ്ടിൽ വലുപ്പങ്ങൾ ഗണ്യമായി കുറയ്ക്കാൻ കഴിയും, ഇത് വേഗത്തിലുള്ള ഡൗൺലോഡുകളിലേക്കും പാഴ്‌സിംഗ് സമയങ്ങളിലേക്കും നയിക്കുന്നു.
4. മിനിഫിക്കേഷനും കംപ്രഷനും
ഏതൊരു പ്രൊഡക്ഷൻ വെബ്‌സൈറ്റിനും ഇത് അടിസ്ഥാനപരമായ കാര്യങ്ങളാണ്.
- മിനിഫിക്കേഷൻ: ഇത് നിങ്ങളുടെ കോഡിന്റെ പ്രവർത്തനത്തെ മാറ്റാതെ തന്നെ വൈറ്റ്‌സ്‌പേസ്, കമൻ്റുകൾ, ന്യൂലൈനുകൾ പോലുള്ള ആവശ്യമില്ലാത്ത ക്യാരക്ടറുകൾ നീക്കം ചെയ്യുകയും വേരിയബിൾ പേരുകൾ ചെറുതാക്കുകയും ചെയ്യുന്ന ഒരു ഓട്ടോമേറ്റഡ് പ്രക്രിയയാണ്. ഇത് ഫയലിന്റെ വലുപ്പം കുറയ്ക്കുന്നു. Terser (JavaScript-ന്) cssnano (CSS-ന്) പോലുള്ള ടൂളുകൾ സാധാരണയായി ഉപയോഗിക്കുന്നു.
- കംപ്രഷൻ: മിനിഫിക്കേഷന് ശേഷം, നിങ്ങളുടെ സെർവർ ഫയലുകൾ ബ്രൗസറിലേക്ക് അയയ്ക്കുന്നതിന് മുമ്പ് കംപ്രസ് ചെയ്യണം. Gzip പോലുള്ള അൽഗോരിതങ്ങൾക്ക് ഫയൽ വലുപ്പങ്ങൾ 70-80% വരെ കുറയ്ക്കാൻ കഴിയും. തുടർന്ന് ബ്രൗസർക്ക് ലഭിച്ച ശേഷം അവയെ ഡീകംപ്രസ്സ് ചെയ്യുന്നു. ഇതൊരു സെർവർ കോൺഫിഗറേഷനാണ്, പക്ഷേ നെറ്റ്‌വർക്ക് ട്രാൻസ്ഫർ സമയം കുറയ്ക്കുന്നതിന് ഇത് നിർണായകമാണ്.
5. ഇൻലൈൻ ക്രിട്ടിക്കൽ JavaScript (ശ്രദ്ധയോടെ ഉപയോഗിക്കുക)
ആദ്യത്തെ പെയിൻ്റിംഗിന് അത്യാവശ്യമായ JavaScript-ൻ്റെ വളരെ ചെറിയ ഭാഗങ്ങൾക്ക് (ഉദാഹരണത്തിന്, ഒരു തീം അല്ലെങ്കിൽ ഒരു നിർണായക പോളിഫിൽ സജ്ജീകരിക്കുന്നത്), അവയെ നിങ്ങളുടെ HTML-ൽ <head>-ലെ <script> ടാഗിനുള്ളിൽ നേരിട്ട് ഇൻലൈൻ ചെയ്യാവുന്നതാണ്. ഇത് ഒരു നെറ്റ്‌വർക്ക് അഭ്യർത്ഥന സംരക്ഷിക്കുന്നു, ഇത് ഉയർന്ന ലേറ്റൻസി മൊബൈൽ കണക്ഷനുകളിൽ ഗുണം ചെയ്യും. എന്നിരുന്നാലും, ഇത് വളരെ കുറഞ്ഞ അളവിൽ മാത്രം ഉപയോഗിക്കണം. ഇൻലൈൻ ചെയ്ത കോഡ് നിങ്ങളുടെ HTML ഡോക്യുമെൻ്റിൻ്റെ വലുപ്പം വർദ്ധിപ്പിക്കുകയും ബ്രൗസർക്ക് പ്രത്യേകം കാഷെ ചെയ്യാൻ കഴിയില്ല. ഇത് ശ്രദ്ധാപൂർവ്വം പരിഗണിക്കേണ്ട ഒരു ട്രേഡ്-ഓഫ് ആണ്.
പുതിയ സാങ്കേതിക വിദ്യകളും ആധുനിക സമീപനങ്ങളും
സെർവർ-സൈഡ് റെൻഡറിംഗ് (SSR), സ്റ്റാറ്റിക് സൈറ്റ് ജനറേഷൻ (SSG)
Next.js (React-ന്), Nuxt.js (Vue-ന്), SvelteKit പോലുള്ള ഫ്രെയിംവർക്കുകൾ SSR, SSG എന്നിവ ജനപ്രിയമാക്കി. ഈ ടെക്നിക്കുകൾ ക്ലയിൻ്റിൻ്റെ ബ്രൗസറിൽ നിന്നുള്ള പ്രാരംഭ റെൻഡറിംഗ് വർക്ക് സെർവറിലേക്ക് മാറ്റുന്നു.
- SSR: സെർവർ അഭ്യർത്ഥിച്ച പേജിനായുള്ള പൂർണ്ണ HTML റെൻഡർ ചെയ്ത് ബ്രൗസറിലേക്ക് അയയ്ക്കുന്നു. ബ്രൗസറിന് ഈ HTML ഉടനടി ഡിസ്‌പ്ലേ ചെയ്യാൻ കഴിയും, ഇത് വളരെ വേഗത്തിലുള്ള ഫസ്റ്റ് കണ്ടന്റ്ഫുൾ പെയിൻ്റിംഗിലേക്ക് നയിക്കുന്നു. തുടർന്ന് JavaScript ലോഡ് ചെയ്യുകയും പേജിനെ "ഹൈഡ്രേറ്റ്" ചെയ്യുകയും അത് ഇൻ്ററാക്ടീവ് ആക്കുകയും ചെയ്യുന്നു.
- SSG: ഓരോ പേജിനുമുള്ള HTML ബിൽഡ് സമയത്ത് ജനറേറ്റ് ചെയ്യുന്നു. ഒരു ഉപയോക്താവ് ഒരു പേജ് അഭ്യർത്ഥിക്കുമ്പോൾ, ഒരു CDN-ൽ നിന്ന് ഒരു സ്റ്റാറ്റിക് HTML ഫയൽ തൽക്ഷണം നൽകുന്നു. ഉള്ളടക്കം കൂടുതലുള്ള സൈറ്റുകൾക്ക് ഇത് ഏറ്റവും വേഗതയേറിയ സമീപനമാണ്.
SSR, SSG എന്നിവ രണ്ടും ക്ലയിൻ്റ്-സൈഡ് JavaScript എക്സിക്യൂട്ട് ചെയ്യാൻ തുടങ്ങുന്നതിന് മുമ്പ് തന്നെ അർത്ഥവത്തായ ഒരു ഫസ്റ്റ് പെയിൻ്റ് നൽകി CRP പ്രകടനം ഗണ്യമായി മെച്ചപ്പെടുത്തുന്നു.
വെബ് വർക്കേഴ്സ്
നിങ്ങളുടെ ആപ്ലിക്കേഷന് വലിയ, ദീർഘകാല കമ്പ്യൂട്ടേഷനുകൾ (സങ്കീർണ്ണമായ ഡാറ്റാ വിശകലനം, ഇമേജ് പ്രോസസ്സിംഗ് അല്ലെങ്കിൽ ക്രിപ്റ്റോഗ്രഫി പോലെ) നടത്തണമെങ്കിൽ, പ്രധാന ത്രെഡിൽ ഇത് ചെയ്യുന്നത് റെൻഡറിംഗിനെ തടസ്സപ്പെടുത്തുകയും നിങ്ങളുടെ പേജിനെ മരവിപ്പിച്ചതായി തോന്നിപ്പിക്കുകയും ചെയ്യും. പ്രധാന UI ത്രെഡിൽ നിന്ന് പൂർണ്ണമായി വേർതിരിച്ച്, ഒരു പശ്ചാത്തല ത്രെഡിൽ ഈ സ്ക്രിപ്റ്റുകൾ പ്രവർത്തിപ്പിക്കാൻ അനുവദിക്കുന്നതിലൂടെ വെബ് വർക്കേഴ്സ് ഒരു പരിഹാരം നൽകുന്നു. ഇത് നിങ്ങളുടെ ആപ്ലിക്കേഷനെ പ്രതികരിക്കുന്ന രീതിയിൽ നിലനിർത്തുന്നു.
CRP ഒപ്റ്റിമൈസേഷനായുള്ള ഒരു പ്രായോഗിക വർക്ക്ഫ്ലോ
നിങ്ങളുടെ പ്രോജക്റ്റുകളിൽ പ്രയോഗിക്കാൻ കഴിയുന്ന ഒരു പ്രവർത്തനക്ഷമമായ വർക്ക്ഫ്ലോയിലേക്ക് നമുക്ക് ഇതെല്ലാം ഒരുമിപ്പിക്കാം.
- ഓഡിറ്റ്: ഒരു അടിസ്ഥാനരേഖയിൽ നിന്ന് ആരംഭിക്കുക. നിങ്ങളുടെ നിലവിലെ അവസ്ഥ മനസ്സിലാക്കാൻ നിങ്ങളുടെ പ്രൊഡക്ഷൻ ബിൽഡിൽ ഒരു ലൈറ്റ്ഹൗസ് റിപ്പോർട്ടും പെർഫോമൻസ് പ്രൊഫൈലും പ്രവർത്തിപ്പിക്കുക. നിങ്ങളുടെ FCP, LCP, TTI എന്നിവ ശ്രദ്ധിക്കുക, കൂടാതെ ഏതെങ്കിലും വലിയ ടാസ്‌ക്കുകളോ റെൻഡർ-Blocking ഉറവിടങ്ങളോ തിരിച്ചറിയുക.
- തിരിച്ചറിയുക: DevTools നെറ്റ്‌വർക്ക്, പെർഫോമൻസ് ടാബുകളിലേക്ക് ആഴത്തിൽ ഇറങ്ങുക. പ്രാരംഭ റെൻഡറിംഗിനെ തടസ്സപ്പെടുത്തുന്നത് ഏത് സ്ക്രിപ്റ്റുകളും സ്റ്റൈൽഷീറ്റുകളുമാണെന്ന് കൃത്യമായി കണ്ടെത്തുക. ഓരോ ഉറവിടത്തിനും സ്വയം ചോദിക്കുക: "ആദ്യത്തെ ഉള്ളടക്കം കാണുന്നതിന് ഇത് ഉപയോക്താവിന് അത്യാവശ്യമാണോ?"
- മുൻഗണന നൽകുക: above-the-fold ഉള്ളടക്കത്തെ ബാധിക്കുന്ന കോഡിൽ നിങ്ങളുടെ ശ്രമങ്ങൾ കേന്ദ്രീകരിക്കുക. ഈ ഉള്ളടക്കം എത്രയും വേഗം ഉപയോക്താവിന് ലഭ്യമാക്കുക എന്നതാണ് ലക്ഷ്യം. മറ്റെന്തെങ്കിലും പിന്നീട് ലോഡ് ചെയ്യാവുന്നതാണ്.
- ഒപ്റ്റിമൈസ് ചെയ്യുക:
- എല്ലാ അത്യാവശ്യമല്ലാത്ത സ്ക്രിപ്റ്റുകളിലേക്കും
deferപ്രയോഗിക്കുക. - സ്വതന്ത്രമായ മൂന്നാം കക്ഷി സ്ക്രിപ്റ്റുകൾക്കായി
asyncഉപയോഗിക്കുക. - നിങ്ങളുടെ റൂട്ടുകൾക്കും വലിയ കോമ്പോണൻ്റുകൾക്കും കോഡ് സ്പ്ലിറ്റിംഗ് നടപ്പിലാക്കുക.
- നിങ്ങളുടെ ബിൽഡ് പ്രോസസ്സിൽ മിനിഫിക്കേഷനും ട്രീ ഷേക്കിംഗും ഉൾപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക.
- നിങ്ങളുടെ സെർവറിൽ Brotli അല്ലെങ്കിൽ Gzip കംപ്രഷൻ പ്രവർത്തനക്ഷമമാക്കാൻ നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ ടീമുമായി ചേർന്ന് പ്രവർത്തിക്കുക.
- CSS-ന്, പ്രാരംഭ കാഴ്ചയ്ക്ക് ആവശ്യമായ നിർണായക CSS ഇൻലൈൻ ചെയ്യുന്നതും ബാക്കിയുള്ളവ ലേസി-ലോഡ് ചെയ്യുന്നതും പരിഗണിക്കുക.
- എല്ലാ അത്യാവശ്യമല്ലാത്ത സ്ക്രിപ്റ്റുകളിലേക്കും
- അളക്കുക: മാറ്റങ്ങൾ നടപ്പിലാക്കിയ ശേഷം, ഓഡിറ്റ് വീണ്ടും പ്രവർത്തിപ്പിക്കുക. നിങ്ങളുടെ പുതിയ സ്കോറുകളും സമയക്രമവും അടിസ്ഥാനരേഖയുമായി താരതമ്യം ചെയ്യുക. നിങ്ങളുടെ FCP മെച്ചപ്പെട്ടോ? റെൻഡർ-Blocking ഉറവിടങ്ങൾ കുറവാണോ?
- ആവർത്തിക്കുക: വെബ് പെർഫോമൻസ് എന്നത് ഒറ്റത്തവണയുള്ള പരിഹാരമല്ല; ഇതൊരു തുടർച്ചയായ പ്രക്രിയയാണ്. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ വളരുന്നതിനനുസരിച്ച്, പുതിയ പ്രകടന തടസ്സങ്ങൾ ഉയർന്നുവരാം. പ്രകടന ഓഡിറ്റിംഗ് നിങ്ങളുടെ ഡെവലപ്‌മെൻ്റ്, ഡെപ്ലോയ്‌മെൻ്റ് സൈക്കിളിന്റെ പതിവ് ഭാഗമാക്കുക.
ഉപസംഹാരം: പ്രകടനത്തിലേക്കുള്ള പാതയിൽ വൈദഗ്ദ്ധ്യം നേടുന്നു
നിങ്ങളുടെ ആപ്ലിക്കേഷനെ ജീവസുറ്റതാക്കാൻ ബ്രൗസർ പിന്തുടരുന്ന ബ്ലൂപ്രിൻ്റാണ് ക്രിട്ടിക്കൽ റെൻഡറിംഗ് പാത്ത്. ഡെവലപ്പർമാർ എന്ന നിലയിൽ, ഈ പാതയെക്കുറിച്ചുള്ള നമ്മുടെ ധാരണയും നിയന്ത്രണവും, പ്രത്യേകിച്ചും JavaScript-നെ സംബന്ധിച്ചിടത്തോളം, ഉപയോക്തൃ അനുഭവം മെച്ചപ്പെടുത്താൻ നമുക്കുള്ള ഏറ്റവും ശക്തമായ ഉത്തോലകങ്ങളിൽ ഒന്നാണ്. പ്രവർത്തിക്കുന്ന കോഡ് എഴുതുന്നതിനെക്കുറിച്ച് മാത്രം ചിന്തിക്കുന്നതിന് പകരം മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്ന കോഡ് എഴുതുന്നതിലൂടെ, നമുക്ക് പ്രവർത്തനക്ഷമമായ ആപ്ലിക്കേഷനുകൾ മാത്രമല്ല, ആഗോളതലത്തിലുള്ള ഉപയോക്താക്കൾക്ക് വേഗതയേറിയതും എളുപ്പത്തിൽ ആക്സസ് ചെയ്യാവുന്നതും ആസ്വാദ്യകരവുമാക്കാൻ കഴിയും.
യാത്ര വിശകലനത്തിൽ നിന്ന് ആരംഭിക്കുന്നു. നിങ്ങളുടെ ഡെവലപ്പർ ടൂളുകൾ തുറക്കുക, നിങ്ങളുടെ ആപ്ലിക്കേഷൻ പ്രൊഫൈൽ ചെയ്യുക, നിങ്ങളുടെ ഉപയോക്താവിനും പൂർണ്ണമായി റെൻഡർ ചെയ്ത പേജിനുമിടയിൽ നിൽക്കുന്ന ഓരോ ഉറവിടത്തെയും ചോദ്യം ചെയ്യാൻ ആരംഭിക്കുക. സ്ക്രിപ്റ്റുകൾ മാറ്റിവെക്കുക, കോഡ് വിഭജിക്കുക, നിങ്ങളുടെ പേലോഡ് കുറയ്ക്കുക തുടങ്ങിയ തന്ത്രങ്ങൾ ഉപയോഗിച്ച്, ബ്രൗസർക്ക് അതിൻ്റേതായ രീതിയിൽ കണ്ടൻ്റുകൾ വേഗത്തിൽ റെൻഡർ ചെയ്യാൻ കഴിയും.