ആരും ചർച്ച ചെയ്യാത്ത ആ DOM കുരുക്ക്
പതിനായിരം ലോഗ് എൻട്രികൾ ഉൾക്കൊള്ളുന്ന ഒരു സപ്പോർട്ട് ഡാഷ്ബോർഡ് സങ്കൽപ്പിക്കുക. അല്ലെങ്കിൽ എല്ലാ കോൺടാക്റ്റുകളും ഒരൊറ്റ സ്ക്രോളബിൾ ടേബിളിൽ കാണിക്കാൻ ശ്രമിക്കുന്ന ഒരു CRM. React-ൽ ഇത് നിർമ്മിക്കാനുള്ള കോഡ് കാണാൻ തികച്ചും നിസ്സാരമായി തോന്നും. നിങ്ങൾ ഒരു array-ലൂടെ map ചെയ്യുന്നു, കുറച്ച് JSX റിട്ടേൺ ചെയ്യുന്നു, എന്നിട്ട് ഫ്രെയിംവർക്കിനെ അതിന്റെ ജോലി ചെയ്യാൻ വിടുന്നു. നൂറ് വരികളുള്ള ഡെവലപ്മെന്റ് ഘട്ടത്തിൽ എല്ലാം നന്നായി പ്രവർത്തിക്കും. എന്നാൽ പ്രൊഡക്ഷൻ ഡാറ്റ വരുമ്പോൾ പേജ് വളരെ സാവധാനത്തിലാകുന്നു.
ബ്രൗസർ മടിയനായതുകൊണ്ടല്ല ഇത് സംഭവിക്കുന്നത്. നിങ്ങൾ ആവശ്യപ്പെട്ടത് കൃത്യമായി അത് ചെയ്യുന്നുണ്ട്, അതാണ് പ്രശ്നം. ഓരോ വരിയും ഒരു DOM നോഡായി മാറുന്നു. ഓരോ നോഡിനും സ്റ്റൈലിംഗ് നൽകുന്നു, ലേഔട്ട് ചെയ്യുന്നു, പെയിന്റ് ചെയ്യുന്നു, മെമ്മറിയിൽ ട്രാക്ക് ചെയ്യുന്നു. നിങ്ങൾ സ്ക്രോൾ ചെയ്യുമ്പോൾ, നിങ്ങൾ കാണുന്ന ഭാഗം മാത്രമല്ല, മുഴുവൻ ട്രീയുടെയും പൊസിഷനുകൾ ബ്രൗസർ വീണ്ടും കണക്കാക്കുന്നു. ഇവന്റ് ലിസണറുകൾ കുമിഞ്ഞുകൂടുന്നു. മെമ്മറി ഉപയോഗം വർദ്ധിക്കുന്നു. ഒടുവിൽ മെയിൻ ത്രെഡ് (main thread) തടസ്സപ്പെടുകയും ക്ലിക്കുകൾക്കോ കീസ്ട്രോക്കുകൾക്കോ സ്ക്രോളിനോ പോലും ഇന്റർഫേസ് പ്രതികരിക്കാതാവുകയും ചെയ്യുന്നു. സാങ്കേതികമായി ആപ്ലിക്കേഷൻ ക്രാഷ് ആയിട്ടില്ലെങ്കിലും, അത് ഉപയോഗിക്കുന്ന ഉപയോക്താവിനെ സംബന്ധിച്ചിടത്തോളം അനുഭവം പൂർണ്ണമായും തകരാറിലായതുപോലെയാണ്.
ബ്രൗസർ എല്ലാ എലമെന്റുകളെയും ഒരേസമയം ആക്റ്റീവ് മെമ്മറിയിൽ നിലനിർത്താൻ ശ്രമിക്കുന്നത് കൊണ്ടാണ് ഇത് സംഭവിക്കുന്നത്. നിങ്ങളുടെ UI-യുടെ വിർച്വൽ വിവരണങ്ങൾ (virtual descriptions) നിർമ്മിക്കുന്നതിൽ React കാര്യക്ഷമമായിരിക്കാം, എന്നാൽ ആ വിവരണങ്ങൾ ഡോക്യുമെന്റിലെ യഥാർത്ഥ നോഡുകളായി മാറുമ്പോൾ, അവയ്ക്ക് സാധാരണ HTML-ന് തുല്യമായ റിസോഴ്സ് ചിലവ് വരുന്നു. ഫ്രെയിംവർക്കിനുള്ളിൽ തന്നെ ഇതിനൊരു പരിഹാരമില്ല. ലിസ്റ്റ് എങ്ങനെ DOM-ലേക്ക് നൽകുന്നു എന്നതിൽ നിങ്ങൾക്ക് ഒരു ഘടനാപരമായ മാറ്റം ആവശ്യമാണ്.
വിർച്വലൈസേഷൻ (Virtualization) എന്നാൽ യഥാർത്ഥത്തിൽ എന്താണ്?
വിർച്വലൈസേഷൻ എന്നത് ആ ഘടനാപരമായ മാറ്റമാണ്. മുഴുവൻ array-യും റെൻഡർ ചെയ്യാൻ React-നോട് ആവശ്യപ്പെടുന്നതിന് പകരം, വ്യൂപോർട്ടിൽ (viewport) ഉൾക്കൊള്ളാൻ കഴിയുന്ന ഐറ്റങ്ങളും അതിന് മുകളിലും താഴെയുമുള്ള ചെറിയൊരു ബഫറും മാത്രം നിങ്ങൾ റെൻഡർ ചെയ്യുന്നു. ഉപയോക്താവ് സ്ക്രോൾ ചെയ്യുമ്പോൾ, കാഴ്ചയിൽ നിന്ന് മാറുന്ന നോഡുകളെ ആപ്ലിക്കേഷൻ ഒഴിവാക്കുകയും എതിർവശത്തുനിന്ന് വരുന്ന പുതിയവ നിർമ്മിക്കുകയും ചെയ്യുന്നു. മൊത്തം സ്ക്രോൾ ചെയ്യാവുന്ന ഉയരം നിലനിർത്തുന്നതിനാൽ (സാധാരണയായി ഒരു വലിയ കണ്ടെയ്നർ എലമെന്റ് വഴിയോ കൃത്യമായി കണക്കാക്കിയ ഒരു സ്പേസർ വഴിയോ), ഉപയോക്താവിന് ഇത് ഇപ്പോഴും ഒരു തുടർച്ചയായ ലിസ്റ്റ് പോലെ തോന്നും. കാണുന്ന ഐറ്റങ്ങൾ ഡാറ്റാസെറ്റിലൂടെ നീങ്ങുന്ന ഒരു വിൻഡോ മാത്രമാണ്.
ഒരു പ്രൊജക്ടർ ഗേറ്റിലൂടെ കടന്നുപോകുന്ന ഫിലിം സ്ട്രിപ്പ് പോലെ ഇതിനെ കരുതുക. കാണികൾക്ക് ചലനം സുഗമമായി കാണാം, എന്നാൽ മെഷീനറി നിലവിൽ പൊസിഷനിലുള്ള ഫ്രെയിമിനെ മാത്രം പ്രകാശിപ്പിക്കുന്നു. റീലിന്റെ ബാക്കി ഭാഗം ഫീഡിലും സ്പൂളുകളിലും ആണ് ഉള്ളത്, പ്രകാശ പാതയിലല്ല. വിർച്വലൈസ്ഡ് ലിസ്റ്റുകളും ഇതേപോലെയാണ് പ്രവർത്തിക്കുന്നത്. ഡാറ്റാസെറ്റ് എന്നത് റീൽ ആണ്, വ്യൂപോർട്ട് എന്നത് ഗേറ്റ് ആണ്.
ഇത് പരമ്പരാഗതമായ ലേസി ലോഡിംഗ് (lazy loading) അല്ല. ലേസി ലോഡിംഗിൽ ഉപയോക്താവ് ഡാറ്റയ്ക്ക് അടുത്തേക്ക് സ്ക്രോൾ ചെയ്യുന്നത് വരെ ഡാറ്റ എടുക്കുന്നത് വൈകിപ്പിക്കുന്നു. എന്നാൽ വിർച്വലൈസേഷനിൽ നിങ്ങളുടെ പക്കൽ ഡാറ്റ ഉണ്ടെന്ന് കരുതുന്നു, പക്ഷേ ഏത് ഭാഗങ്ങൾ യഥാർത്ഥ DOM എലമെന്റുകളായി മാറ്റണം എന്നതിൽ നിങ്ങൾ തിരഞ്ഞെടുപ്പുകൾ നടത്തുന്നു. ഈ രണ്ട് സാങ്കേതിക വിദ്യകളും ഒരുമിച്ച് പ്രവർത്തിക്കാം, പക്ഷേ അവ പരിഹരിക്കുന്നത് വ്യത്യസ്ത പ്രശ്നങ്ങളാണ്.
ഈ മാറ്റം എന്തുകൊണ്ട് പെട്ടെന്ന് അനുഭവപ്പെടുന്നു?
ഇതിന്റെ ഗുണങ്ങൾ നാല് കാര്യങ്ങളിൽ കാണാം, ഇവയെല്ലാം ഒരേ അടിസ്ഥാനപരമായ ആശ്വാസവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു: ഉപയോക്താവിന് കാണാൻ കഴിയാത്ത കാര്യങ്ങൾക്കായി നിങ്ങൾ കൂടുതൽ റിസോഴ്സുകൾ ചെലവാക്കുന്നത് നിങ്ങൾ ഒഴിവാക്കുന്നു.
വേഗത്തിലുള്ള ലോഡിംഗ് സമയം. ബ്രൗസർ പേജ് തുറക്കുമ്പോൾ, പതിനയ്യായിരം വരികൾക്ക് പകരം ഒരു പതിനഞ്ച് വരികൾ മാത്രമായിരിക്കും അത് പെയിന്റ് ചെയ്യുന്നത്. ആദ്യത്തെ പ്രധാനപ്പെട്ട പെയിന്റിംഗ് വേഗത്തിൽ ലഭിക്കുന്നു. നോഡുകൾ നിർമ്മിക്കാനും അവ ഡോക്യുമെന്റിൽ ഘടിപ്പിക്കാനും ജാവാസ്ക്രിപ്റ്റ് എഞ്ചിൻ കുറഞ്ഞ സമയം ചെലവഴിക്കുന്നതിനാൽ 'time-to-interactive' കുറയുന്നു.
കുറഞ്ഞ മെമ്മറി ഉപയോഗം. ഒരു DOM നോഡ് എന്നത് കൂടുതൽ റിസോഴ്സ് ആവശ്യമായ ഒന്നാണ്. ഓരോന്നിനും സ്റ്റൈൽ റൂളുകൾ, ലേഔട്ട് മെട്രിക്സ്, ഇവന്റ് ബൈൻഡിംഗുകൾ എന്നിവയുമായി ബന്ധമുണ്ട്. ആക്റ്റീവ് നോഡുകളുടെ എണ്ണം കുറച്ചു दर्जनമായി കുറച്ചാൽ മെമ്മറി ഉപയോഗം ഗണ്യമായി കുറയും. കുറഞ്ഞ ശേഷിയുള്ള ഉപകരണങ്ങളിലോ ദീർഘനേരം ഉപയോഗിക്കുമ്പോഴോ, ഇത് ടാബ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റം വഴി ക്ലോസ് ചെയ്യപ്പെടുന്നത് തടയാൻ സഹായിക്കും.
സുഗമമായ സ്ക്രോളിംഗ് പെർഫോമൻസ്. ട്രീയിൽ കുറഞ്ഞ നോഡുകൾ ഉള്ളതിനാൽ, സ്ക്രോൾ ഇവന്റുകൾക്കിടയിൽ ലേഔട്ട്, പെയിന്റ് ഘട്ടങ്ങളിൽ ബ്രൗസർ കുറഞ്ഞ സമയം ചെലവഴിക്കുന്നു. മറഞ്ഞിരിക്കുന്ന ഉള്ളടക്കത്തിന്റെ ജ്യാമിതി (geometry) നിരന്തരം കണക്കാക്കാതെ തന്നെ കോമ്പോസിറ്റർ ത്രെഡിന് (compositor thread) ചലനങ്ങൾ കൈകാര്യം ചെയ്യാൻ കഴിയും. ഇതിന്റെ ഫലമായി മോണിറ്ററിന്റെ റിഫ്രഷ് റേറ്റോട് അടുത്ത രീതിയിലുള്ള സ്ക്രോളിംഗ് ലഭിക്കുന്നു.
സ്ഥിരതയുള്ള ഫ്രെയിം റേറ്റുകൾ. മെയിൻ ത്രെഡ് ലേഔട്ട് ജോലികളിൽ കുടുങ്ങിക്കിടക്കാത്തതിനാൽ മറ്റ് പ്രവർത്തനങ്ങൾക്കായി കൂടുതൽ സമയം ലഭിക്കുന്നു. ആനിമേഷനുകൾ സുഗമമായി തുടരുന്നു. നെറ്റ്വർക്ക് റെസ്പോൺസുകൾ പ്രോസസ്സ് ചെയ്യാൻ സാധിക്കുന്നു. റെൻഡർ പാത്ത് ഒരു തടസ്സമാകാത്തതിനാൽ പുതിയ ഡാറ്റ വരുമ്പോൾ UI ഫ്രീസ് ആകുന്നില്ല.
ശരിയായ രീതിയിൽ ഇത് നടപ്പിലാക്കുക
React ഇക്കോസിസ്റ്റത്തിൽ, react-window, കൂടുതൽ ഫീച്ചറുകളുള്ള react-virtualized തുടങ്ങിയ ലൈബ്രറികൾ ഈ രീതി നടപ്പിലാക്കാൻ സഹായിക്കുന്നു. ഇതിന്റെ അടിസ്ഥാന ആശയം ഒന്നുതന്നെയാണ്: നിങ്ങൾ ഒരു ഐറ്റം റെൻഡറർ നിർവചിക്കുന്നു, ആകെ ഐറ്റങ്ങളുടെ എണ്ണം നൽകുന്നു, ബാക്കി വിൻഡോയിംഗ് കണക്കുകൂട്ടലുകൾ ലൈബ്രറി കൈകാര്യം ചെയ്യുന്നു. എന്നാൽ ഇതിലെ ചെറിയ കാര്യങ്ങൾ പലപ്പോഴും ആളുകളെ കുഴപ്പിക്കാറുണ്ട്.
ഒന്നാമതായി, കണ്ടെയ്നറിന് (container) കൃത്യമായ ഒരു ഉയരം (height) ആവശ്യമാണ്. ലിസ്റ്റ് ഉൾക്കൊള്ളുന്ന പാരന്റ് എലമെന്റ് അതിന്റെ ചൈൽഡ്രന്മാർക്ക് അനുസരിച്ച് വലുതാകുകയാണെങ്കിൽ, വ്യൂപോർട്ട് അതിര് (viewport boundary) ഇല്ലാത്തതിനാൽ ഏതെല്ലാം ഐറ്റങ്ങളാണ് കാണുന്നത് എന്ന് കണക്കാക്കാൻ വിർച്വലൈസേഷന് കഴിയില്ല. നിങ്ങൾ ലിസ്റ്റിനെ ഒരു നിശ്ചിത ഉയരത്തിലോ അല്ലെങ്കിൽ കൃത്യമായ നിയന്ത്രണങ്ങളുള്ള ഒരു ഫ്ലെക്സ് കണ്ടെയ്നറിലോ (flex container) ലോക്ക് ചെയ്യണം.
രണ്ടാമതായി, ഐറ്റത്തിന്റെ വലിപ്പം (sizing) വളരെ പ്രധാനമാണ്. നിശ്ചിത ഉയരമുള്ള റോകൾ (fixed-height rows) ആണ് ഏറ്റവും ലളിതമായ രീതി. ലൈബ്രറി ഓരോ റോയുടെയും ഉയരം അതിന്റെ ഇൻഡക്സ് (index) ഉപയോഗിച്ച് ഗുണിച്ചുകൊണ്ട് ഓരോ എലമെന്റും എവിടെ വരണമെന്ന് കൃത്യമായി മനസ്സിലാക്കുന്നു. ചിത്രങ്ങൾ അടങ്ങിയ ചാറ്റ് മെസ്സേജുകൾ അല്ലെങ്കിൽ കമന്റ് ത്രെഡുകൾ പോലുള്ള വേരിയബിൾ ഹൈറ്റ് ഉള്ള ഉള്ളടക്കങ്ങൾ വരുമ്പോൾ, മൗണ്ട് ചെയ്തതിന് ശേഷം അളന്ന് ആവശ്യാനുസരണം മാറ്റം വരുത്താൻ ലൈബ്രറി നിർബന്ധിതമാകും. ഈ അളക്കൽ പ്രക്രിയ വൈകിയാൽ സ്ക്രോൾ ചെയ്യുമ്പോൾ വിറയൽ (scroll jitter) അനുഭവപ്പെടാം. നിങ്ങളുടെ ഡാറ്റ അനുവദിക്കുന്നുണ്ടെങ്കിൽ, ഒരേ ഉയരമോ അല്ലെങ്കിൽ കുറഞ്ഞ ഉയരമോ (minimum height) നിർബന്ധമാക്കുക. ഇല്ലെങ്കിൽ, ഒരു വേരിയബിൾ ഹൈറ്റ് വിർച്വലൈസർ ഉപയോഗിക്കുക, അതിന്റെ സങ്കീർണ്ണതകൾ ഉൾക്കൊള്ളാൻ തയ്യാറാവുക.
മൂന്നാമതായി, ഓവർസ്കാനിംഗ് (overscanning) നിങ്ങളുടെ സഹായിയാണ്. സ്ക്രീനിൽ കാണുന്നവ മാത്രം റെൻഡർ ചെയ്യുന്നത് ഉപയോക്താവ് വേഗത്തിൽ സ്ക്രോൾ ചെയ്യുമ്പോൾ വെളുത്ത വരകൾ കാണാൻ കാരണമാകും. മിക്ക ലൈബ്രറികളും സ്ക്രീനിന് മുകളിലും താഴെയുമായി കുറച്ച് അധികം ഐറ്റങ്ങൾ കൂടി റെൻഡർ ചെയ്യാൻ അനുവദിക്കുന്നു. DOM അമിതമായി വർദ്ധിപ്പിക്കാതെ തന്നെ ഈ വിടവുകൾ മറയ്ക്കാൻ സാധാരണയായി രണ്ട് അല്ലെങ്കിൽ മൂന്ന് റോകളുടെ ഓവർസ്കാനിംഗ് മതിയാകും.
നാലാമതായി, key പ്രോപ്പ് അവഗണിക്കരുത്. ഒരു വിർച്വലൈസ്ഡ് ലിസ്റ്റിൽ, സ്ക്രോൾ ചെയ്യുമ്പോൾ ഐറ്റങ്ങൾ പഴയ DOM നോഡുകൾ തന്നെ വീണ്ടും ഉപയോഗിക്കുന്നു. സ്റ്റേബിൾ ആയ കീകൾ (stable keys) ഉപയോഗിക്കുന്നത് റിയാക്റ്റ് (React) തെറ്റായ രീതിയിൽ റീകൺസിലിയേഷൻ (reconciliation) നടത്തുന്നത് തടയുകയും റോ കമ്പോണന്റുകൾക്കുള്ളിലെ സ്റ്റേറ്റ് നശിപ്പിക്കുന്നത് ഒഴിവാക്കുകയും ചെയ്യുന്നു. നിങ്ങളുടെ ലിസ്റ്റ് റോകളിൽ ഇൻപുട്ടുകൾ, ടോഗിളുകൾ അല്ലെങ്കിൽ എക്സ്പാൻഡബിൾ സെക്ഷനുകൾ ഉണ്ടെങ്കിൽ, മോശം കീകൾ ഉപയോഗിക്കുന്നത് ഡാറ്റയിലെ പിശകുകളാണെന്ന് തോന്നിക്കുന്ന തരത്തിൽ UI സ്റ്റേറ്റിനെ ബാധിച്ചേക്കാം, എന്നാൽ യഥാർത്ഥത്തിൽ അവ റെൻഡറിംഗിലെ തെറ്റുകളാണ്.
ഒരു സൂക്ഷ്മമായ കെണി ബ്രൗസറിലെ 'find-in-page' ഫീച്ചറാണ്. ഹൈഡൻ ഐറ്റങ്ങൾ DOM-ൽ ഇല്ലാത്തതിനാൽ, ബ്രൗസറിലെ സെർച്ച് ബോക്സിന് അവ കാണാൻ കഴിയില്ല. വലിയൊരു ലിസ്റ്റിലെ ടെക്സ്റ്റ് കണ്ടെത്താൻ ഉപയോക്താക്കൾ Ctrl+F ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, ഡോക്യുമെന്റിന് പകരം ഡാറ്റാസെറ്റിന് (dataset) നേരെ പ്രവർത്തിക്കുന്ന ഒരു കസ്റ്റം സെർച്ച് നിങ്ങൾ നിർമ്മിക്കേണ്ടി വരും. ലിസ്റ്റിന്റെ സെമാന്റിക്സ് (semantics) ശ്രദ്ധിച്ചില്ലെങ്കിൽ സ്ക്രീൻ റീഡറുകൾക്കും സന്ദർഭം നഷ്ടപ്പെട്ടേക്കാം, അതിനാൽ അസിസ്റ്റീവ് ടെക്നോളജി ഉപയോഗിച്ച് പരിശോധിക്കുകയും ഡൈനാമിക് ലോഡിംഗിനായി ലൈവ് റീജിയൻ അനൗൺസ്മെന്റുകൾ (live region announcements) ചേർക്കുന്നത് പരിഗണിക്കുകയും ചെയ്യുക.
എപ്പോഴാണ് ഇത് ഒഴിവാക്കേണ്ടത്
വിർച്വലൈസേഷൻ സൗജന്യമല്ല. ഇത് ഡിപെൻഡൻസി ഭാരം (dependency weight), കോർഡിനേറ്റ് മാത്തമാറ്റിക്സ്, കൺസ്ട്രയിന്റ് ഓവർഹെഡ് എന്നിവ വർദ്ധിപ്പിക്കുന്നു. നിങ്ങളുടെ ലിസ്റ്റിൽ അമ്പതോ നൂറോ ഐറ്റങ്ങൾ മാത്രമേ ഉള്ളൂവെങ്കിൽ, ബ്രൗസറിന് അത് സഹായമില്ലാതെ തന്നെ കൈകാര്യം ചെയ്യാൻ കഴിയും. മുഴുവൻ ലിസ്റ്റും റെൻഡർ ചെയ്ത് മുന്നോട്ട് പോകുക. ലിസ്റ്റ് ഐറ്റങ്ങൾ ഓരോന്നും അങ്ങേയറ്റം സങ്കീർണ്ണമാണെങ്കിലും ഇതേ കാര്യം ബാധകമാണ്. വിർച്വലൈസേഷൻ ആയിരക്കണക്കിന് നോഡുകളിൽ നിന്ന് നിങ്ങളെ രക്ഷിച്ചേക്കാം, എന്നാൽ വലിയൊരു ചാർട്ടോ വീഡിയോ എലമെന്റോ അടങ്ങിയ ഒരു നോഡിൽ നിന്ന് അത് നിങ്ങളെ രക്ഷിക്കില്ല. ആദ്യം ഐറ്റത്തിന്റെ അമിത വലിപ്പം (item bloat) പരിഹരിക്കുക.
ലിസ്റ്റ് സ്ക്രോൾ ചെയ്യാത്ത സാഹചര്യത്തിലും വിർച്വലൈസേഷൻ ഒഴിവാക്കുക. നിങ്ങൾ 'next', 'previous' ബട്ടണുകൾ ഉപയോഗിച്ച് പേജിനേഷൻ (pagination) ചെയ്യുകയാണെങ്കിൽ, അതായത് ഓരോ പേജിലും ഇരുപത് ഐറ്റങ്ങൾ മാത്രം കാണിക്കുന്നുണ്ടെങ്കിൽ, അവിടെ വിൻഡോയിംഗ് (windowing) ചെയ്യേണ്ട ആവശ്യമില്ല. ഉപയോക്താവ് വലിയൊരു തുടർച്ചയായ ക്രമത്തിൽ (contiguous sequence) സ്ക്രോൾ ചെയ്യാൻ ആഗ്രഹിക്കുമ്പോൾ മാത്രമേ ഈ സാങ്കേതികവിദ്യ ഗുണകരമാകൂ.
യഥാർത്ഥ പാഠം
വിർച്വലൈസേഷൻ എന്നത് ഒരു ലൈബ്രറി തിരഞ്ഞെടുപ്പല്ല, മറിച്ച് ഒരു ചിന്താഗതിയാണ്. DOM എന്നത് ഒരു അനന്തമായ കാൻവാസ് അല്ല, മറിച്ച് പരിമിതമായ ഒരു വിഭവമാണെന്ന് ഇത് നിങ്ങളെ ബോധ്യപ്പെടുത്തുന്നു. ഇത് നടപ്പിലാക്കുന്നതിന് മുമ്പ്, Chrome DevTools തുറന്ന് ഒരു പെർഫോമൻസ് പ്രൊഫൈൽ റെക്കോർഡ് ചെയ്യുക, ലേഔട്ട് അല്ലെങ്കിൽ പെയിന്റ് സമയം (layout or paint time) ആണ് യഥാർത്ഥ പ്രശ്നമെന്ന് ഉറപ്പുവരുത്തുക. DOM ആണ് തടസ്സം (bottleneck) എന്ന് മനസ്സിലാക്കിയാൽ, കൺസ്ട്രയിന്റുകൾ പാലിക്കാൻ തയ്യാറാവുക. ഉയരം കൃത്യമാക്കുക, കീകൾ ശ്രദ്ധിക്കുക, മിതമായ രീതിയിൽ ഓവർസ്കാനിംഗ് ചെയ്യുക, അക്സസിബിലിറ്റി (accessibility) പരിശോധിക്കുക. ശരിയായി ചെയ്താൽ, ഒരു വിർച്വലൈസ്ഡ് ലിസ്റ്റ് ഉപയോഗശൂന്യമായ ഒരു ഡാറ്റാ ഭിത്തിയെ ഒരു നേറ്റീവ് സ്ക്രോൾ വ്യൂ പോലെ ലളിതമായി അനുഭവപ്പെടുന്ന ഒന്നാക്കി മാറ്റും. ബ്രൗസർ കഷ്ടപ്പെടുന്നത് നിൽക്കും, ഉപയോക്താക്കൾ കാത്തുനിൽക്കുന്നത് നിൽക്കും, ആപ്പ് നിങ്ങൾ ഉദ്ദേശിച്ചതുപോലെ വേഗത്തിലുള്ള ഒരു ഇന്റർഫേസ് ആയി മാറും.