બ્રાઉઝર રેન્ડરિંગ પાઇપલાઇનમાં નિપુણતા: જાવાસ્ક્રિપ્ટના પર્ફોર્મન્સ પરના પ્રભાવનું ઊંડાણપૂર્વક વિશ્લેષણ

ડિજિટલ દુનિયામાં, ઝડપ એ માત્ર એક સુવિધા નથી; તે એક ઉત્તમ વપરાશકર્તા અનુભવનો પાયો છે. ધીમી, પ્રતિભાવવિહીન વેબસાઇટ વપરાશકર્તાની નિરાશા, બાઉન્સ દરમાં વધારો અને આખરે, વ્યવસાયના લક્ષ્યો પર નકારાત્મક અસર તરફ દોરી શકે છે. વેબ ડેવલપર્સ તરીકે, અમે આ અનુભવના આર્કિટેક્ટ છીએ, અને બ્રાઉઝર આપણા કોડને દ્રશ્ય, ઇન્ટરેક્ટિવ પેજમાં કેવી રીતે ફેરવે છે તેની મૂળભૂત પ્રક્રિયાને સમજવી સર્વોપરી છે. આ પ્રક્રિયા, જે ઘણીવાર જટિલતામાં ઘેરાયેલી હોય છે, તેને બ્રાઉઝર રેન્ડરિંગ પાઇપલાઇન તરીકે ઓળખવામાં આવે છે.

આધુનિક વેબ ઇન્ટરેક્ટિવિટીના કેન્દ્રમાં જાવાસ્ક્રિપ્ટ છે. તે એવી ભાષા છે જે આપણા સ્ટેટિક પેજીસમાં જીવંતતા લાવે છે, ડાયનેમિક કન્ટેન્ટ અપડેટ્સથી લઈને જટિલ સિંગલ-પેજ એપ્લિકેશન્સ સુધી બધું જ સક્ષમ કરે છે. જોકે, મોટી શક્તિ સાથે મોટી જવાબદારી પણ આવે છે. ઓપ્ટિમાઇઝ ન થયેલ જાવાસ્ક્રિપ્ટ વેબના નબળા પર્ફોર્મન્સ પાછળના સૌથી સામાન્ય કારણોમાંનું એક છે. તે બ્રાઉઝરની રેન્ડરિંગ પાઇપલાઇનને વિક્ષેપિત કરી શકે છે, વિલંબિત કરી શકે છે અથવા ખર્ચાળ, બિનજરૂરી કાર્ય કરવા માટે દબાણ કરી શકે છે, જે 'જંક' (jank) તરીકે ઓળખાતી ભયાનક સ્થિતિ તરફ દોરી જાય છે—અટકતાં એનિમેશન્સ, વપરાશકર્તા ઇનપુટ પર ધીમો પ્રતિસાદ અને એકંદરે સુસ્ત અનુભવ.

આ વ્યાપક માર્ગદર્શિકા ફ્રન્ટ-એન્ડ ડેવલપર્સ, પર્ફોર્મન્સ એન્જિનિયર્સ અને ઝડપી વેબ બનાવવા માટે ઉત્સાહી કોઈપણ માટે બનાવવામાં આવી છે. અમે બ્રાઉઝર રેન્ડરિંગ પાઇપલાઇનને સરળ બનાવીશું, તેને સમજવામાં સરળ તબક્કાઓમાં વિભાજીત કરીશું. વધુ મહત્ત્વનું એ છે કે, અમે આ પ્રક્રિયામાં જાવાસ્ક્રિપ્ટની ભૂમિકા પર પ્રકાશ પાડીશું, તે કેવી રીતે પર્ફોર્મન્સ માટે અવરોધ બની શકે છે તેનું ચોક્કસપણે અન્વેષણ કરીશું અને, નિર્ણાયક રીતે, તેને ઘટાડવા માટે આપણે શું કરી શકીએ તે જાણીશું. અંત સુધીમાં, તમે વધુ કાર્યક્ષમ જાવાસ્ક્રિપ્ટ લખવા અને વિશ્વભરના તમારા વપરાશકર્તાઓને એક સરળ, આનંદદાયક અનુભવ પ્રદાન કરવા માટે જ્ઞાન અને વ્યવહારુ વ્યૂહરચનાઓથી સજ્જ થશો.

વેબનો બ્લુપ્રિન્ટ: બ્રાઉઝર રેન્ડરિંગ પાઇપલાઇનને સમજવી

આપણે ઓપ્ટિમાઇઝ કરીએ તે પહેલાં, આપણે સમજવું જ જોઈએ. બ્રાઉઝર રેન્ડરિંગ પાઇપલાઇન (જેને ક્રિટિકલ રેન્ડરિંગ પાથ તરીકે પણ ઓળખવામાં આવે છે) એ પગલાંઓની એક શૃંખલા છે જે બ્રાઉઝર તમે લખેલા HTML, CSS અને જાવાસ્ક્રિપ્ટને સ્ક્રીન પરના પિક્સેલ્સમાં રૂપાંતરિત કરવા માટે અનુસરે છે. તેને એક અત્યંત કાર્યક્ષમ ફેક્ટરી એસેમ્બલી લાઇન તરીકે વિચારો. દરેક સ્ટેશનનું એક વિશિષ્ટ કાર્ય હોય છે, અને સમગ્ર લાઇન કાર્યક્ષમતા ઉત્પાદન એક સ્ટેશનથી બીજા સ્ટેશન પર કેટલી સરળતાથી આગળ વધે છે તેના પર નિર્ભર કરે છે.

જ્યારે વિશિષ્ટતાઓ બ્રાઉઝર એન્જિનો (જેમ કે ક્રોમ/એજ માટે બ્લિંક, ફાયરફોક્સ માટે ગેકો, અને સફારી માટે વેબકિટ) વચ્ચે સહેજ અલગ હોઈ શકે છે, મૂળભૂત તબક્કાઓ વૈચારિક રીતે સમાન છે. ચાલો આ એસેમ્બલી લાઇનમાંથી પસાર થઈએ.

પગલું 1: પાર્સિંગ - કોડથી સમજણ સુધી

પ્રક્રિયા કાચા ટેક્સ્ટ-આધારિત સંસાધનોથી શરૂ થાય છે: તમારી HTML અને CSS ફાઇલો. બ્રાઉઝર સીધા આની સાથે કામ કરી શકતું નથી; તેને આને એવી રચનામાં પાર્સ કરવાની જરૂર છે જે તે સમજી શકે.

• HTML પાર્સિંગથી DOM: બ્રાઉઝરનું HTML પાર્સર HTML માર્કઅપ પર પ્રક્રિયા કરે છે, તેને ટોકનાઇઝ કરે છે અને તેને ડોક્યુમેન્ટ ઓબ્જેક્ટ મોડેલ (DOM) નામના ટ્રી-જેવા ડેટા સ્ટ્રક્ચરમાં બનાવે છે. DOM પેજના કન્ટેન્ટ અને સ્ટ્રક્ચરનું પ્રતિનિધિત્વ કરે છે. દરેક HTML ટેગ આ ટ્રીમાં એક 'નોડ' બને છે, જે તમારા ડોક્યુમેન્ટની હાયરાર્કીને પ્રતિબિંબિત કરતો પેરેન્ટ-ચાઇલ્ડ સંબંધ બનાવે છે.
• CSS પાર્સિંગથી CSSOM: તે જ સમયે, જ્યારે બ્રાઉઝર CSS (<style> ટેગમાં અથવા બાહ્ય <link> સ્ટાઇલશીટમાં) જુએ છે, ત્યારે તે તેને CSS ઓબ્જેક્ટ મોડેલ (CSSOM) બનાવવા માટે પાર્સ કરે છે. DOM ની જેમ, CSSOM એ એક ટ્રી સ્ટ્રક્ચર છે જેમાં DOM નોડ્સ સાથે સંકળાયેલી બધી સ્ટાઇલ્સ હોય છે, જેમાં ઇમ્પ્લિસિટ યુઝર-એજન્ટ સ્ટાઇલ્સ અને તમારા સ્પષ્ટ નિયમોનો સમાવેશ થાય છે.

એક મહત્ત્વનો મુદ્દો: CSS ને રેન્ડર-બ્લોકિંગ સંસાધન ગણવામાં આવે છે. બ્રાઉઝર જ્યાં સુધી બધી CSS સંપૂર્ણપણે ડાઉનલોડ અને પાર્સ ન કરી લે ત્યાં સુધી પેજનો કોઈપણ ભાગ રેન્ડર કરશે નહીં. શા માટે? કારણ કે પેજને કેવી રીતે લેઆઉટ કરવું તે નક્કી કરતાં પહેલાં તેને દરેક એલિમેન્ટ માટેની અંતિમ સ્ટાઇલ્સ જાણવાની જરૂર છે. એક સ્ટાઇલ વિનાનું પેજ જે અચાનક પોતાની જાતને રિસ્ટાઇલ કરે તે એક ખરાબ વપરાશકર્તા અનુભવ હશે.

પગલું 2: રેન્ડર ટ્રી - વિઝ્યુઅલ બ્લુપ્રિન્ટ

એકવાર બ્રાઉઝર પાસે DOM (કન્ટેન્ટ) અને CSSOM (સ્ટાઇલ્સ) બંને હોય, ત્યારે તે તેમને રેન્ડર ટ્રી બનાવવા માટે જોડે છે. આ ટ્રી એ વાતનું પ્રતિનિધિત્વ કરે છે કે પેજ પર વાસ્તવમાં શું પ્રદર્શિત થશે.

રેન્ડર ટ્રી એ DOM ની એક-થી-એક કોપી નથી. તેમાં ફક્ત તે જ નોડ્સ શામેલ છે જે દૃષ્ટિની રીતે સંબંધિત છે. ઉદાહરણ તરીકે:

• <head>, <script>, અથવા <meta> જેવા નોડ્સ, જેનું કોઈ વિઝ્યુઅલ આઉટપુટ નથી, તેને અવગણવામાં આવે છે.
• CSS દ્વારા સ્પષ્ટપણે છુપાવેલા નોડ્સ (ઉદાહરણ તરીકે, display: none; સાથે) પણ રેન્ડર ટ્રીમાંથી બહાર રાખવામાં આવે છે. (નોંધ: visibility: hidden; વાળા એલિમેન્ટ્સ શામેલ છે, કારણ કે તેઓ હજી પણ લેઆઉટમાં જગ્યા રોકે છે).

રેન્ડર ટ્રીમાં દરેક નોડમાં DOM માંથી તેનું કન્ટેન્ટ અને CSSOM માંથી તેની ગણતરી કરેલ સ્ટાઇલ્સ બંને હોય છે.

પગલું 3: લેઆઉટ (અથવા રિફ્લો) - ભૌમિતિક ગણતરી

રેન્ડર ટ્રીનું નિર્માણ થયા પછી, બ્રાઉઝર હવે જાણે છે કે શું રેન્ડર કરવું, પરંતુ ક્યાં અથવા કેટલું મોટું તે નહીં. આ લેઆઉટ તબક્કાનું કામ છે. બ્રાઉઝર રૂટથી શરૂ કરીને રેન્ડર ટ્રીને પાર કરે છે અને દરેક નોડ માટે ચોક્કસ ભૌમિતિક માહિતીની ગણતરી કરે છે: તેનું કદ (પહોળાઈ, ઊંચાઈ) અને વ્યુપોર્ટની સાપેક્ષમાં પેજ પર તેની સ્થિતિ.

આ પ્રક્રિયાને રિફ્લો તરીકે પણ ઓળખવામાં આવે છે. 'રિફ્લો' શબ્દ ખાસ કરીને યોગ્ય છે કારણ કે એક એલિમેન્ટમાં ફેરફાર તેની સાંકળ પ્રતિક્રિયા કરી શકે છે, જેનાથી તેના ચિલ્ડ્રન, એન્સેસ્ટર્સ અને સિબલિંગ્સની ભૌમિતિની પુનઃગણતરી કરવાની જરૂર પડે છે. ઉદાહરણ તરીકે, પેરેન્ટ એલિમેન્ટની પહોળાઈ બદલવાથી સંભવતઃ તેના બધા વંશજો માટે રિફ્લો થશે. આ લેઆઉટને સંભવિત રીતે ખૂબ જ ગણતરીની દ્રષ્ટિએ ખર્ચાળ કામગીરી બનાવે છે.

પગલું 4: પેઇન્ટ - પિક્સેલ્સ ભરવા

હવે જ્યારે બ્રાઉઝર દરેક એલિમેન્ટની રચના, સ્ટાઇલ્સ, કદ અને સ્થિતિ જાણે છે, ત્યારે તે માહિતીને સ્ક્રીન પર વાસ્તવિક પિક્સેલ્સમાં રૂપાંતરિત કરવાનો સમય છે. પેઇન્ટ તબક્કા (અથવા રિપેઇન્ટ)માં દરેક નોડના તમામ દ્રશ્ય ભાગો માટે પિક્સેલ્સ ભરવાનો સમાવેશ થાય છે: રંગો, ટેક્સ્ટ, છબીઓ, બોર્ડર્સ, શેડોઝ, વગેરે.

આ પ્રક્રિયાને વધુ કાર્યક્ષમ બનાવવા માટે, આધુનિક બ્રાઉઝર્સ ફક્ત એક જ કેનવાસ પર પેઇન્ટ કરતા નથી. તેઓ ઘણીવાર પેજને બહુવિધ લેયર્સમાં વિભાજીત કરે છે. ઉદાહરણ તરીકે, CSS transform અથવા <video> એલિમેન્ટવાળા જટિલ એલિમેન્ટને તેના પોતાના લેયરમાં પ્રમોટ કરી શકાય છે. પછી પેઇન્ટિંગ પ્રતિ-લેયર ધોરણે થઈ શકે છે, જે અંતિમ પગલા માટે એક મહત્ત્વપૂર્ણ ઓપ્ટિમાઇઝેશન છે.

પગલું 5: કમ્પોઝિટિંગ - અંતિમ ચિત્રને એસેમ્બલ કરવું

અંતિમ તબક્કો કમ્પોઝિટિંગ છે. બ્રાઉઝર બધા વ્યક્તિગત રીતે પેઇન્ટ કરેલા લેયર્સ લે છે અને સ્ક્રીન પર પ્રદર્શિત અંતિમ છબી બનાવવા માટે તેમને સાચા ક્રમમાં એસેમ્બલ કરે છે. અહીં લેયર્સની શક્તિ સ્પષ્ટ થાય છે.

જો તમે એવા એલિમેન્ટને એનિમેટ કરો છો જે તેના પોતાના લેયર પર છે (ઉદાહરણ તરીકે, transform: translateX(10px); નો ઉપયોગ કરીને), તો બ્રાઉઝરને સમગ્ર પેજ માટે લેઆઉટ અથવા પેઇન્ટ તબક્કાઓ ફરીથી ચલાવવાની જરૂર નથી. તે ફક્ત હાલના પેઇન્ટ કરેલા લેયરને ખસેડી શકે છે. આ કાર્ય ઘણીવાર ગ્રાફિક્સ પ્રોસેસિંગ યુનિટ (GPU) ને સોંપવામાં આવે છે, જે તેને અત્યંત ઝડપી અને કાર્યક્ષમ બનાવે છે. આ જ સિલ્કી-સ્મૂધ, 60 ફ્રેમ્સ-પ્રતિ-સેકન્ડ (fps) એનિમેશન પાછળનું રહસ્ય છે.

જાવાસ્ક્રિપ્ટનો ભવ્ય પ્રવેશ: ઇન્ટરેક્ટિવિટીનું એન્જિન

તો જાવાસ્ક્રિપ્ટ આ સુવ્યવસ્થિત પાઇપલાઇનમાં ક્યાં બંધબેસે છે? દરેક જગ્યાએ. જાવાસ્ક્રિપ્ટ એ ગતિશીલ શક્તિ છે જે DOM અને CSSOM ને બનાવ્યા પછી કોઈપણ સમયે સંશોધિત કરી શકે છે. આ તેનું પ્રાથમિક કાર્ય અને તેનું સૌથી મોટું પર્ફોર્મન્સ જોખમ છે.

ડિફૉલ્ટ રૂપે, જાવાસ્ક્રિપ્ટ પાર્સર-બ્લોકિંગ છે. જ્યારે HTML પાર્સર <script> ટેગ (જે async અથવા defer સાથે ચિહ્નિત નથી) જુએ છે, ત્યારે તેણે DOM બનાવવાની તેની પ્રક્રિયાને રોકવી જ જોઇએ. તે પછી સ્ક્રિપ્ટને ફેચ કરશે (જો તે બાહ્ય હોય), તેને એક્ઝિક્યુટ કરશે, અને તે પછી જ HTML નું પાર્સિંગ ફરી શરૂ કરશે. જો આ સ્ક્રિપ્ટ તમારા ડોક્યુમેન્ટના <head> માં સ્થિત હોય, તો તે તમારા પેજના પ્રારંભિક રેન્ડરમાં નોંધપાત્ર વિલંબ કરી શકે છે કારણ કે DOM નું નિર્માણ અટકી ગયું છે.

બ્લોક કરવું કે નહીં: `async` અને `defer`

આ બ્લોકિંગ વર્તનને ઘટાડવા માટે, અમારી પાસે <script> ટેગ માટે બે શક્તિશાળી એટ્રિબ્યુટ્સ છે:

• defer: આ એટ્રિબ્યુટ બ્રાઉઝરને કહે છે કે HTML પાર્સિંગ ચાલુ હોય ત્યારે સ્ક્રિપ્ટને બેકગ્રાઉન્ડમાં ડાઉનલોડ કરો. સ્ક્રિપ્ટ પછી ફક્ત HTML પાર્સર સમાપ્ત થયા પછી, પરંતુ DOMContentLoaded ઇવેન્ટ ફાયર થાય તે પહેલાં એક્ઝિક્યુટ થવાની ખાતરી આપવામાં આવે છે. જો તમારી પાસે બહુવિધ ડિફર્ડ સ્ક્રિપ્ટ્સ હોય, તો તે ડોક્યુમેન્ટમાં દેખાય તે ક્રમમાં એક્ઝિક્યુટ થશે. આ તે સ્ક્રિપ્ટ્સ માટે એક ઉત્તમ પસંદગી છે જેને સંપૂર્ણ DOM ઉપલબ્ધ હોવાની જરૂર હોય અને જેનો એક્ઝિક્યુશન ક્રમ મહત્ત્વનો હોય.
• async: આ એટ્રિબ્યુટ પણ બ્રાઉઝરને HTML પાર્સિંગને બ્લોક કર્યા વિના બેકગ્રાઉન્ડમાં સ્ક્રિપ્ટ ડાઉનલોડ કરવા માટે કહે છે. જોકે, જલદી સ્ક્રિપ્ટ ડાઉનલોડ થાય છે, HTML પાર્સર અટકશે, અને સ્ક્રિપ્ટ એક્ઝિક્યુટ થશે. Async સ્ક્રિપ્ટ્સનો કોઈ ગેરંટીકૃત એક્ઝિક્યુશન ક્રમ નથી. આ એનાલિટિક્સ અથવા જાહેરાતો જેવી સ્વતંત્ર, થર્ડ-પાર્ટી સ્ક્રિપ્ટ્સ માટે યોગ્ય છે, જ્યાં એક્ઝિક્યુશન ક્રમ મહત્ત્વનો નથી અને તમે ઇચ્છો છો કે તે શક્ય તેટલી જલદી ચાલે.

બધું બદલવાની શક્તિ: DOM અને CSSOM માં ફેરફાર

એકવાર એક્ઝિક્યુટ થયા પછી, જાવાસ્ક્રિપ્ટને DOM અને CSSOM બંનેની સંપૂર્ણ API એક્સેસ હોય છે. તે એલિમેન્ટ્સ ઉમેરી શકે છે, તેમને દૂર કરી શકે છે, તેમની સામગ્રી બદલી શકે છે, અને તેમની સ્ટાઇલ્સમાં ફેરફાર કરી શકે છે. ઉદાહરણ તરીકે: document.getElementById('welcome-banner').style.display = 'none'; જાવાસ્ક્રિપ્ટની આ એક જ લાઇન 'welcome-banner' એલિમેન્ટ માટે CSSOM માં ફેરફાર કરે છે. આ ફેરફાર હાલના રેન્ડર ટ્રીને અમાન્ય કરશે, જે બ્રાઉઝરને સ્ક્રીન પર અપડેટ પ્રતિબિંબિત કરવા માટે રેન્ડરિંગ પાઇપલાઇનના ભાગોને ફરીથી ચલાવવા માટે દબાણ કરશે.

પર્ફોર્મન્સના વિલન: જાવાસ્ક્રિપ્ટ પાઇપલાઇનને કેવી રીતે અવરોધે છે

જ્યારે પણ જાવાસ્ક્રિપ્ટ DOM અથવા CSSOM માં ફેરફાર કરે છે, ત્યારે તે રિફ્લો અને રિપેઇન્ટને ટ્રિગર કરવાનું જોખમ ચલાવે છે. જ્યારે ડાયનેમિક વેબ માટે આ જરૂરી છે, ત્યારે આ કામગીરીને બિનકાર્યક્ષમ રીતે કરવાથી તમારી એપ્લિકેશન અટકી શકે છે. ચાલો સૌથી સામાન્ય પર્ફોર્મન્સની મુશ્કેલીઓનું અન્વેષણ કરીએ.

દુષ્ટ ચક્ર: ફોર્સ્ડ સિંક્રોનસ લેઆઉટ્સ અને લેઆઉટ થ્રેશિંગ

આ દલીલપૂર્વક ફ્રન્ટ-એન્ડ ડેવલપમેન્ટમાં સૌથી ગંભીર અને સૂક્ષ્મ પર્ફોર્મન્સ સમસ્યાઓમાંની એક છે. જેમ આપણે ચર્ચા કરી, લેઆઉટ એક ખર્ચાળ કામગીરી છે. કાર્યક્ષમ બનવા માટે, બ્રાઉઝર્સ સ્માર્ટ હોય છે અને DOM ફેરફારોને બેચ કરવાનો પ્રયાસ કરે છે. તેઓ તમારા જાવાસ્ક્રિપ્ટ સ્ટાઇલ ફેરફારોને કતારમાં મૂકે છે અને પછી, પછીના સમયે (સામાન્ય રીતે વર્તમાન ફ્રેમના અંતે), તેઓ બધા ફેરફારોને એક જ વારમાં લાગુ કરવા માટે એક જ લેઆઉટ ગણતરી કરશે.

જોકે, તમે આ ઓપ્ટિમાઇઝેશનને તોડી શકો છો. જો તમારું જાવાસ્ક્રિપ્ટ કોઈ સ્ટાઇલમાં ફેરફાર કરે છે અને પછી તરત જ ભૌમિતિક મૂલ્યની વિનંતી કરે છે (જેમ કે એલિમેન્ટનું offsetHeight, offsetWidth, અથવા getBoundingClientRect()), તો તમે બ્રાઉઝરને લેઆઉટ સ્ટેપને સિંક્રોનસલી કરવા માટે દબાણ કરો છો. બ્રાઉઝરે અટકવું પડે છે, બધા પેન્ડિંગ સ્ટાઇલ ફેરફારો લાગુ કરવા પડે છે, સંપૂર્ણ લેઆઉટ ગણતરી ચલાવવી પડે છે, અને પછી વિનંતી કરેલ મૂલ્ય તમારી સ્ક્રિપ્ટને પરત કરવું પડે છે. આને ફોર્સ્ડ સિંક્રોનસ લેઆઉટ કહેવાય છે.

જ્યારે આ લૂપની અંદર થાય છે, ત્યારે તે લેઆઉટ થ્રેશિંગ તરીકે ઓળખાતી વિનાશક પર્ફોર્મન્સ સમસ્યા તરફ દોરી જાય છે. તમે વારંવાર રીડ અને રાઇટ કરી રહ્યા છો, બ્રાઉઝરને એક જ ફ્રેમની અંદર વારંવાર આખા પેજને રિફ્લો કરવા માટે દબાણ કરી રહ્યા છો.

લેઆઉટ થ્રેશિંગનું ઉદાહરણ (શું ન કરવું):

            
function resizeAllParagraphs() {
  const paragraphs = document.querySelectorAll('p');
  for (let i = 0; i < paragraphs.length; i++) {
    // READ: gets the width of the container (forces layout)
    const containerWidth = document.body.offsetWidth;
    
    // WRITE: sets the paragraph's width (invalidates layout)
    paragraphs[i].style.width = (containerWidth / 2) + 'px';
  }
}

            

              
                Copy
              
            
          

આ કોડમાં, લૂપના દરેક ઇટરેશનની અંદર, આપણે offsetWidth (લેઆઉટ-ટ્રિગરિંગ રીડ) વાંચીએ છીએ અને પછી તરત જ style.width (લેઆઉટ-અમાન્ય કરતું રાઇટ) પર લખીએ છીએ. આ દરેક પેરેગ્રાફ પર રિફ્લો કરવા દબાણ કરે છે.

ઓપ્ટિમાઇઝ્ડ વર્ઝન (રીડ્સ અને રાઇટ્સનું બેચિંગ):

            
function resizeAllParagraphsOptimized() {
  const paragraphs = document.querySelectorAll('p');
  
  // First, READ all the values you need
  const containerWidth = document.body.offsetWidth;
  
  // Then, WRITE all the changes
  for (let i = 0; i < paragraphs.length; i++) {
    paragraphs[i].style.width = (containerWidth / 2) + 'px';
  }
}

            

              
                Copy
              
            
          

ફક્ત બધા રીડ્સ પહેલાં કરવા અને પછી બધા રાઇટ્સ કરવા માટે કોડને પુનર્ગઠિત કરીને, અમે બ્રાઉઝરને ઓપરેશન્સનું બેચિંગ કરવાની મંજૂરી આપીએ છીએ. તે પ્રારંભિક પહોળાઈ મેળવવા માટે એક લેઆઉટ ગણતરી કરે છે અને પછી બધા સ્ટાઇલ અપડેટ્સ પર પ્રક્રિયા કરે છે, જે ફ્રેમના અંતે એક જ રિફ્લો તરફ દોરી જાય છે. પર્ફોર્મન્સમાં તફાવત નાટકીય હોઈ શકે છે.

મુખ્ય થ્રેડ અવરોધ: લાંબા સમય સુધી ચાલતા જાવાસ્ક્રિપ્ટ કાર્યો

બ્રાઉઝરનો મુખ્ય થ્રેડ એક વ્યસ્ત સ્થળ છે. તે જાવાસ્ક્રિપ્ટ એક્ઝિક્યુશનને હેન્ડલ કરવા, વપરાશકર્તા ઇનપુટ (ક્લિક્સ, સ્ક્રોલ્સ) નો પ્રતિસાદ આપવા અને રેન્ડરિંગ પાઇપલાઇન ચલાવવા માટે જવાબદાર છે. કારણ કે જાવાસ્ક્રિપ્ટ સિંગલ-થ્રેડેડ છે, જો તમે એક જટિલ, લાંબા સમય સુધી ચાલતી સ્ક્રિપ્ટ ચલાવો છો, તો તમે અસરકારક રીતે મુખ્ય થ્રેડને બ્લોક કરી રહ્યા છો. જ્યારે તમારી સ્ક્રિપ્ટ ચાલી રહી હોય, ત્યારે બ્રાઉઝર બીજું કંઈ કરી શકતું નથી. તે ક્લિક્સનો પ્રતિસાદ આપી શકતું નથી, તે સ્ક્રોલ્સ પર પ્રક્રિયા કરી શકતું નથી, અને તે કોઈપણ એનિમેશન ચલાવી શકતું નથી. પેજ સંપૂર્ણપણે ફ્રોઝન અને પ્રતિભાવવિહીન બની જાય છે.

50ms કરતાં વધુ સમય લેતું કોઈપણ કાર્ય 'લોંગ ટાસ્ક' ગણવામાં આવે છે અને તે વપરાશકર્તા અનુભવ પર નકારાત્મક અસર કરી શકે છે, ખાસ કરીને ઇન્ટરેક્શન ટુ નેક્સ્ટ પેઇન્ટ (INP) કોર વેબ વાઇટલ પર. સામાન્ય કારણોમાં જટિલ ડેટા પ્રોસેસિંગ, મોટા API પ્રતિસાદનું સંચાલન અથવા સઘન ગણતરીઓ શામેલ છે.

આનો ઉકેલ એ છે કે લાંબા કાર્યોને નાના ટુકડાઓમાં વિભાજીત કરો અને વચ્ચે મુખ્ય થ્રેડને 'યીલ્ડ' કરો. આ બ્રાઉઝરને અન્ય બાકી કામગીરીને હેન્ડલ કરવાની તક આપે છે. આ કરવાનો એક સરળ રસ્તો setTimeout(callback, 0) છે, જે બ્રાઉઝરને શ્વાસ લેવાની તક મળ્યા પછી, ભવિષ્યના ટાસ્કમાં ચલાવવા માટે કૉલબેકને શેડ્યૂલ કરે છે.

નાના-નાના ફેરફારોથી થતું મોટું નુકસાન: અતિશય DOM મેનિપ્યુલેશન્સ

જ્યારે એક DOM મેનિપ્યુલેશન ઝડપી હોય છે, ત્યારે હજારો મેનિપ્યુલેશન કરવા ખૂબ ધીમા હોઈ શકે છે. જ્યારે પણ તમે લાઇવ DOM માં કોઈ એલિમેન્ટ ઉમેરો, દૂર કરો અથવા સંશોધિત કરો છો, ત્યારે તમે રિફ્લો અને રિપેઇન્ટને ટ્રિગર કરવાનું જોખમ ચલાવો છો. જો તમારે વસ્તુઓની મોટી સૂચિ બનાવવાની અને તેમને એક પછી એક પેજ પર ઉમેરવાની જરૂર હોય, તો તમે બ્રાઉઝર માટે ઘણું બિનજરૂરી કામ કરી રહ્યા છો.

એક વધુ કાર્યક્ષમ અભિગમ એ છે કે તમારી DOM રચના 'ઓફલાઇન' બનાવો અને પછી તેને એક જ ઓપરેશનમાં લાઇવ DOM માં ઉમેરો. DocumentFragment એ હલકો, લઘુત્તમ DOM ઓબ્જેક્ટ છે જેનું કોઈ પેરેન્ટ નથી. તમે તેને એક અસ્થાયી કન્ટેનર તરીકે વિચારી શકો છો. તમે તમારા બધા નવા એલિમેન્ટ્સને ફ્રેગમેન્ટમાં ઉમેરી શકો છો, અને પછી સમગ્ર ફ્રેગમેન્ટને એક જ વારમાં DOM માં ઉમેરી શકો છો. આના પરિણામે ફક્ત એક જ રિફ્લો/રિપેઇન્ટ થાય છે, ભલે તમે કેટલા એલિમેન્ટ્સ ઉમેર્યા હોય.

DocumentFragment નો ઉપયોગ કરવાનું ઉદાહરણ:

            
const list = document.getElementById('my-list');
const data = ['Apple', 'Banana', 'Cherry', 'Date', 'Elderberry'];

// Create a DocumentFragment
const fragment = document.createDocumentFragment();

data.forEach(itemText => {
  const li = document.createElement('li');
  li.textContent = itemText;
  // Append to the fragment, not the live DOM
  fragment.appendChild(li);
});

// Append the entire fragment in one operation
list.appendChild(fragment);

            

              
                Copy
              
            
          

અટકી-અટકીને થતી હલનચલન: બિનકાર્યક્ષમ જાવાસ્ક્રિપ્ટ એનિમેશન્સ

જાવાસ્ક્રિપ્ટ સાથે એનિમેશન બનાવવું સામાન્ય છે, પરંતુ તેને બિનકાર્યક્ષમ રીતે કરવાથી અટકાવ અને 'જંક' થાય છે. એક સામાન્ય એન્ટિ-પેટર્ન એ છે કે લૂપમાં એલિમેન્ટ સ્ટાઇલ્સને અપડેટ કરવા માટે setTimeout અથવા setInterval નો ઉપયોગ કરવો.

સમસ્યા એ છે કે આ ટાઇમર્સ બ્રાઉઝરના રેન્ડરિંગ ચક્ર સાથે સિંક્રનાઇઝ નથી. તમારી સ્ક્રિપ્ટ ચાલી શકે છે અને બ્રાઉઝરે એક ફ્રેમ પેઇન્ટ કરવાનું સમાપ્ત કર્યા પછી તરત જ સ્ટાઇલ અપડેટ કરી શકે છે, જે તેને વધારાનું કામ કરવા માટે દબાણ કરે છે અને સંભવિત રીતે આગામી ફ્રેમની ડેડલાઇન ચૂકી જાય છે, જેના પરિણામે એક ફ્રેમ ડ્રોપ થાય છે.

જાવાસ્ક્રિપ્ટ એનિમેશન કરવાની આધુનિક, સાચી રીત requestAnimationFrame(callback) છે. આ API બ્રાઉઝરને કહે છે કે તમે એક એનિમેશન કરવા માંગો છો અને વિનંતી કરે છે કે બ્રાઉઝર આગામી એનિમેશન ફ્રેમ માટે વિંડોનું રિપેઇન્ટ શેડ્યૂલ કરે. તમારું કૉલબેક ફંક્શન બ્રાઉઝર તેનું આગલું પેઇન્ટ કરે તે પહેલાં તરત જ એક્ઝિક્યુટ થશે, જે ખાતરી કરે છે કે તમારા અપડેટ્સ સંપૂર્ણ રીતે સમયસર અને કાર્યક્ષમ છે. જો પેજ બેકગ્રાઉન્ડ ટેબમાં હોય તો બ્રાઉઝર કૉલબેક ન ચલાવીને પણ ઓપ્ટિમાઇઝ કરી શકે છે.

વધુમાં, તમે શું એનિમેટ કરો છો તે એટલું જ મહત્ત્વનું છે જેટલું તમે કેવી રીતે એનિમેટ કરો છો. width, height, top, અથવા left જેવી પ્રોપર્ટીઝ બદલવાથી લેઆઉટ તબક્કો ટ્રિગર થશે, જે ધીમો છે. સૌથી સરળ એનિમેશન માટે, તમારે ફક્ત કમ્પોઝિટર દ્વારા હેન્ડલ કરી શકાય તેવી પ્રોપર્ટીઝ પર જ વળગી રહેવું જોઈએ, જે સામાન્ય રીતે GPU પર ચાલે છે. આ મુખ્યત્વે છે:

• transform (ખસેડવા, સ્કેલ કરવા, ફેરવવા માટે)
• opacity (ફેડ ઇન/આઉટ માટે)

આ પ્રોપર્ટીઝને એનિમેટ કરવાથી બ્રાઉઝરને લેઆઉટ અથવા પેઇન્ટ ફરીથી ચલાવ્યા વિના ફક્ત એલિમેન્ટના હાલના પેઇન્ટ કરેલા લેયરને ખસેડવા અથવા ફેડ કરવાની મંજૂરી મળે છે. આ સતત 60fps એનિમેશન પ્રાપ્ત કરવાની ચાવી છે.

થિયરીથી પ્રેક્ટિસ સુધી: પર્ફોર્મન્સ ઓપ્ટિમાઇઝેશન માટેનું ટૂલકિટ

થિયરી સમજવી એ પ્રથમ પગલું છે. હવે, ચાલો કેટલીક કાર્યક્ષમ વ્યૂહરચનાઓ અને સાધનો જોઈએ જેનો ઉપયોગ તમે આ જ્ઞાનને વ્યવહારમાં મૂકવા માટે કરી શકો છો.

સ્ક્રિપ્ટ્સને સમજદારીપૂર્વક લોડ કરવી

તમે તમારી જાવાસ્ક્રિપ્ટ કેવી રીતે લોડ કરો છો તે સંરક્ષણની પ્રથમ લાઇન છે. હંમેશા પૂછો કે શું કોઈ સ્ક્રિપ્ટ પ્રારંભિક રેન્ડર માટે ખરેખર મહત્ત્વપૂર્ણ છે. જો નહીં, તો DOM ની જરૂર હોય તેવી સ્ક્રિપ્ટ્સ માટે defer નો ઉપયોગ કરો અથવા સ્વતંત્ર સ્ક્રિપ્ટ્સ માટે async નો ઉપયોગ કરો. આધુનિક એપ્લિકેશન્સ માટે, ડાયનેમિક import() નો ઉપયોગ કરીને કોડ-સ્પ્લિટિંગ જેવી તકનીકોનો ઉપયોગ કરો જેથી ફક્ત વર્તમાન વ્યુ અથવા વપરાશકર્તાની ક્રિયાપ્રતિક્રિયા માટે જરૂરી જાવાસ્ક્રિપ્ટ જ લોડ થાય. વેબપેક અથવા રોલઅપ જેવા સાધનો તમારા અંતિમ બંડલ્સમાંથી બિનઉપયોગી કોડને દૂર કરવા માટે ટ્રી-શેકિંગ પણ ઓફર કરે છે, જે ફાઇલના કદમાં ઘટાડો કરે છે.

ઉચ્ચ-આવર્તન ઘટનાઓને કાબૂમાં રાખવી: ડિબાઉન્સિંગ અને થ્રોટલિંગ

કેટલીક બ્રાઉઝર ઘટનાઓ જેવી કે scroll, resize, અને mousemove પ્રતિ સેકન્ડમાં સેંકડો વખત ફાયર થઈ શકે છે. જો તમારી પાસે તેમની સાથે જોડાયેલ ખર્ચાળ ઇવેન્ટ હેન્ડલર હોય (દા.ત., જે DOM મેનિપ્યુલેશન કરે છે), તો તમે મુખ્ય થ્રેડને સરળતાથી ભરી શકો છો. અહીં બે પેટર્ન આવશ્યક છે:

• થ્રોટલિંગ (Throttling): ખાતરી કરે છે કે તમારું ફંક્શન નિર્દિષ્ટ સમયગાળા દીઠ વધુમાં વધુ એકવાર એક્ઝિક્યુટ થાય છે. ઉદાહરણ તરીકે, 'આ ફંક્શનને દર 200ms માં એક કરતા વધુ વખત ન ચલાવો'. આ અનંત સ્ક્રોલ હેન્ડલર્સ જેવી વસ્તુઓ માટે ઉપયોગી છે.
• ડિબાઉન્સિંગ (Debouncing): ખાતરી કરે છે કે તમારું ફંક્શન નિષ્ક્રિયતાના સમયગાળા પછી જ એક્ઝિક્યુટ થાય છે. ઉદાહરણ તરીકે, 'આ સર્ચ ફંક્શનને ફક્ત ત્યારે જ ચલાવો જ્યારે વપરાશકર્તા 300ms માટે ટાઇપ કરવાનું બંધ કરી દે'. આ ઓટોકમ્પલીટ સર્ચ બાર માટે યોગ્ય છે.

બોજને ઓછો કરવો: વેબ વર્કર્સનો પરિચય

ખરેખર ભારે, લાંબા સમય સુધી ચાલતી જાવાસ્ક્રિપ્ટ ગણતરીઓ માટે જેને સીધી DOM એક્સેસની જરૂર નથી, વેબ વર્કર્સ એક ગેમ-ચેન્જર છે. વેબ વર્કર તમને એક અલગ બેકગ્રાઉન્ડ થ્રેડ પર સ્ક્રિપ્ટ ચલાવવાની મંજૂરી આપે છે. આ મુખ્ય થ્રેડને વપરાશકર્તા માટે પ્રતિભાવશીલ રહેવા માટે સંપૂર્ણપણે મુક્ત કરે છે. તમે ડેટા મોકલવા અને પરિણામો પ્રાપ્ત કરવા માટે મુખ્ય થ્રેડ અને વર્કર થ્રેડ વચ્ચે સંદેશા પસાર કરી શકો છો. ઉપયોગના કિસ્સાઓમાં ઇમેજ પ્રોસેસિંગ, જટિલ ડેટા વિશ્લેષણ, અથવા બેકગ્રાઉન્ડ ફેચિંગ અને કેશિંગનો સમાવેશ થાય છે.

પર્ફોર્મન્સ ડિટેક્ટીવ બનવું: બ્રાઉઝર DevTools નો ઉપયોગ

તમે જે માપી શકતા નથી તેને ઓપ્ટિમાઇઝ કરી શકતા નથી. ક્રોમ, એજ અને ફાયરફોક્સ જેવા આધુનિક બ્રાઉઝર્સમાં પર્ફોર્મન્સ પેનલ તમારું સૌથી શક્તિશાળી સાધન છે. અહીં એક ઝડપી માર્ગદર્શિકા છે:

1. DevTools ખોલો અને 'Performance' ટેબ પર જાઓ.
2. રેકોર્ડ બટન પર ક્લિક કરો અને તમારી સાઇટ પર તે ક્રિયા કરો જે તમને શંકા છે કે ધીમી છે (દા.ત., સ્ક્રોલિંગ, બટન પર ક્લિક કરવું).
3. રેકોર્ડિંગ બંધ કરો.

તમને એક વિગતવાર ફ્લેમ ચાર્ટ રજૂ કરવામાં આવશે. આ શોધો:

• લોંગ ટાસ્કસ (Long Tasks): આ લાલ ત્રિકોણથી ચિહ્નિત થયેલ છે. આ તમારા મુખ્ય થ્રેડ બ્લોકર્સ છે. વિલંબનું કારણ કયું ફંક્શન હતું તે જોવા માટે તેમના પર ક્લિક કરો.
• જાંબલી 'Layout' બ્લોક્સ: એક મોટો જાંબલી બ્લોક લેઆઉટ તબક્કામાં વિતાવેલા નોંધપાત્ર સમયનો સંકેત આપે છે.
• ફોર્સ્ડ સિંક્રોનસ લેઆઉટ ચેતવણીઓ: સાધન ઘણીવાર તમને ફોર્સ્ડ રિફ્લો વિશે સ્પષ્ટપણે ચેતવણી આપશે, તમને જવાબદાર કોડની ચોક્કસ લાઇનો બતાવશે.
• મોટા લીલા 'Paint' બ્લોક્સ: આ જટિલ પેઇન્ટ ઓપરેશન્સનો સંકેત આપી શકે છે જે ઓપ્ટિમાઇઝ કરી શકાય છે.

વધુમાં, 'Rendering' ટેબ (ઘણીવાર DevTools ડ્રોઅરમાં છુપાયેલ હોય છે) માં 'Paint Flashing' જેવા વિકલ્પો છે, જે જ્યારે પણ સ્ક્રીનના વિસ્તારોને ફરીથી પેઇન્ટ કરવામાં આવે ત્યારે તેમને લીલા રંગમાં હાઇલાઇટ કરશે. આ બિનજરૂરી રિપેઇન્ટ્સને દૃષ્ટિની રીતે ડિબગ કરવાની એક ઉત્તમ રીત છે.

નિષ્કર્ષ: એક સમયે એક ફ્રેમ, એક ઝડપી વેબનું નિર્માણ

બ્રાઉઝર રેન્ડરિંગ પાઇપલાઇન એક જટિલ પરંતુ તાર્કિક પ્રક્રિયા છે. ડેવલપર્સ તરીકે, અમારો જાવાસ્ક્રિપ્ટ કોડ આ પાઇપલાઇનમાં સતત મહેમાન છે, અને તેનું વર્તન નક્કી કરે છે કે તે એક સરળ અનુભવ બનાવવામાં મદદ કરે છે કે વિક્ષેપકારક અવરોધોનું કારણ બને છે. દરેક તબક્કાને સમજીને—પાર્સિંગથી કમ્પોઝિટિંગ સુધી—આપણે એવો કોડ લખવા માટે જરૂરી સમજ મેળવીએ છીએ જે બ્રાઉઝરની સાથે કામ કરે છે, તેની વિરુદ્ધ નહીં.

મુખ્ય શીખ એ જાગૃતિ અને ક્રિયાનું મિશ્રણ છે:

• મુખ્ય થ્રેડનો આદર કરો: બિન-જટિલ સ્ક્રિપ્ટ્સને ડિફર કરીને, લાંબા કાર્યોને તોડીને, અને ભારે કામને વેબ વર્કર્સને સોંપીને તેને મુક્ત રાખો.
• લેઆઉટ થ્રેશિંગ ટાળો: DOM રીડ્સ અને રાઇટ્સને બેચ કરવા માટે તમારા કોડની રચના કરો. આ સરળ ફેરફાર મોટા પર્ફોર્મન્સ લાભો આપી શકે છે.
• DOM સાથે સ્માર્ટ બનો: લાઇવ DOM ને તમે કેટલી વાર સ્પર્શ કરો છો તે ઘટાડવા માટે DocumentFragments જેવી તકનીકોનો ઉપયોગ કરો.
• કાર્યક્ષમ રીતે એનિમેટ કરો: જૂની ટાઇમર પદ્ધતિઓ પર requestAnimationFrame ને પ્રાધાન્ય આપો અને transform અને opacity જેવી કમ્પોઝિટર-ફ્રેન્ડલી પ્રોપર્ટીઝ પર વળગી રહો.
• હંમેશા માપો: તમારી એપ્લિકેશનને પ્રોફાઇલ કરવા, વાસ્તવિક-દુનિયાના અવરોધોને ઓળખવા અને તમારા ઓપ્ટિમાઇઝેશનને માન્ય કરવા માટે બ્રાઉઝર ડેવલપર ટૂલ્સનો ઉપયોગ કરો.

ઉચ્ચ-પ્રદર્શન વેબ એપ્લિકેશન્સ બનાવવી એ અકાળ ઓપ્ટિમાઇઝેશન અથવા અસ્પષ્ટ યુક્તિઓ યાદ રાખવા વિશે નથી. તે મૂળભૂત રીતે તમે જે પ્લેટફોર્મ માટે બનાવી રહ્યા છો તેને સમજવા વિશે છે. જાવાસ્ક્રિપ્ટ અને રેન્ડરિંગ પાઇપલાઇન વચ્ચેના આંતરપ્રક્રિયામાં નિપુણતા મેળવીને, તમે તમારી જાતને દરેક જગ્યાએ, દરેક માટે ઝડપી, વધુ સ્થિતિસ્થાપક અને આખરે વધુ આનંદપ્રદ વેબ અનુભવો બનાવવાની શક્તિ આપો છો.