JavaScript ചട്ടക്കൂടുകളുടെ വില

ഒരു വെബ്‌സൈറ്റിൽ ഒരു കൂട്ടം JavaScript കോഡ് പ്രവർത്തിപ്പിക്കുന്നതിനേക്കാൾ വേഗത കുറയ്ക്കാൻ മറ്റൊരു മാർഗവുമില്ല (പാൻ ഉദ്ദേശിച്ചിട്ടില്ല). ജാവാസ്ക്രിപ്റ്റ് ഉപയോഗിക്കുമ്പോൾ, പ്രോജക്റ്റ് പ്രകടനത്തിൽ കുറഞ്ഞത് നാല് തവണയെങ്കിലും നിങ്ങൾ പണം നൽകണം. സൈറ്റിൻ്റെ JavaScript കോഡ് ഉപയോക്താക്കളുടെ സിസ്റ്റങ്ങളെ ലോഡുചെയ്യുന്നത് ഇതാ:

• നെറ്റ്‌വർക്കിലൂടെ ഒരു ഫയൽ അപ്‌ലോഡ് ചെയ്യുന്നു.
• ഡൗൺലോഡ് ചെയ്‌തതിന് ശേഷം പായ്ക്ക് ചെയ്യാത്ത സോഴ്‌സ് കോഡ് പാഴ്‌സ് ചെയ്യുകയും കംപൈൽ ചെയ്യുകയും ചെയ്യുന്നു.
• JavaScript കോഡ് നടപ്പിലാക്കുന്നു.
• മെമ്മറി ഉപഭോഗം.

ഈ കോമ്പിനേഷൻ മാറുന്നു വളരെ ചെലവേറിയത്.

ഞങ്ങളുടെ പ്രോജക്റ്റുകളിൽ ഞങ്ങൾ കൂടുതൽ കൂടുതൽ JS കോഡ് ഉൾപ്പെടുത്തുന്നു. റിയാക്‌റ്റ്, വ്യൂ തുടങ്ങിയവ പോലുള്ള ചട്ടക്കൂടുകളും ലൈബ്രറികളും നൽകുന്ന സൈറ്റുകളിലേക്ക് ഓർഗനൈസേഷനുകൾ നീങ്ങുമ്പോൾ, ഞങ്ങൾ സൈറ്റുകളുടെ പ്രധാന പ്രവർത്തനം JavaScript-നെ ആശ്രയിച്ചിരിക്കുന്നു.

JavaScript ഫ്രെയിംവർക്കുകൾ ഉപയോഗിക്കുന്ന വളരെ കനത്ത വെബ്സൈറ്റുകൾ ഞാൻ കണ്ടിട്ടുണ്ട്. എന്നാൽ ഈ വിഷയത്തെക്കുറിച്ചുള്ള എൻ്റെ കാഴ്ചപ്പാട് ശക്തമായി പക്ഷപാതപരമാണ്. ഞാൻ ജോലി ചെയ്യുന്ന കമ്പനികൾക്ക് സങ്കീർണ്ണമായ വെബ്‌സൈറ്റ് പ്രകടന പ്രശ്‌നങ്ങൾ ഉള്ളതിനാലാണ് കൃത്യമായി എൻ്റെ അടുക്കൽ വരുന്നത് എന്നതാണ് വസ്തുത. തൽഫലമായി, ഈ പ്രശ്നം എത്രത്തോളം വ്യാപകമാണെന്നും ഒരു പ്രത്യേക സൈറ്റിൻ്റെ അടിസ്ഥാനമായി ഒന്നോ അല്ലെങ്കിൽ മറ്റൊരു ചട്ടക്കൂട് തിരഞ്ഞെടുക്കുമ്പോൾ ഞങ്ങൾ എന്ത് "പിഴകൾ" നൽകുമെന്നും അറിയാൻ എനിക്ക് ജിജ്ഞാസ തോന്നി.

ഇത് മനസിലാക്കാൻ ഈ പ്രോജക്റ്റ് എന്നെ സഹായിച്ചു. HTTP ആർക്കൈവ്.

ഡാറ്റ

സാധാരണ ഡെസ്ക്ടോപ്പ് സൈറ്റുകളിലേക്കുള്ള മൊത്തം 4308655 ലിങ്കുകളും മൊബൈൽ സൈറ്റുകളിലേക്കുള്ള 5484239 ലിങ്കുകളും HTTP ആർക്കൈവ് പ്രോജക്റ്റ് ട്രാക്ക് ചെയ്യുന്നു. ഈ ലിങ്കുകളുമായി ബന്ധപ്പെട്ട നിരവധി സൂചകങ്ങളിൽ, അനുബന്ധ സൈറ്റുകളിൽ കണ്ടെത്തിയ സാങ്കേതികവിദ്യകളുടെ ഒരു ലിസ്റ്റ് ഉൾപ്പെടുന്നു. വ്യത്യസ്‌ത ചട്ടക്കൂടുകളും ലൈബ്രറികളും ഉപയോഗിക്കുന്ന ആയിരക്കണക്കിന് സൈറ്റുകൾ നമുക്ക് മാതൃകയാക്കാമെന്നും അവർ ക്ലയൻ്റുകൾക്ക് എത്ര കോഡ് അയയ്‌ക്കുന്നുവെന്നും ആ കോഡ് ഉപയോക്താക്കളുടെ സിസ്റ്റങ്ങളിൽ എത്രമാത്രം ലോഡ് നൽകുന്നുവെന്നും മനസ്സിലാക്കാമെന്നാണ് ഇതിനർത്ഥം.

2020 മാർച്ച് മുതൽ ഞാൻ ഡാറ്റ ശേഖരിച്ചു, എനിക്ക് ആക്‌സസ് ലഭിച്ച ഏറ്റവും പുതിയ ഡാറ്റയാണിത്.

റിയാക്റ്റ്, വ്യൂ, ആംഗുലാർ എന്നിവ ഉപയോഗിക്കുന്നതായി കണ്ടെത്തിയ സൈറ്റുകൾക്കായുള്ള ഡാറ്റയുമായി എല്ലാ സൈറ്റുകൾക്കുമായി സംഗ്രഹിച്ച എച്ച്ടിടിപി ആർക്കൈവ് ഡാറ്റ താരതമ്യം ചെയ്യാൻ ഞാൻ തീരുമാനിച്ചു, എന്നിരുന്നാലും മറ്റ് സോഴ്‌സ് മെറ്റീരിയലുകളും ഉപയോഗിക്കുന്നത് ഞാൻ പരിഗണിച്ചു.

ഇത് കൂടുതൽ രസകരമാക്കാൻ, ഉറവിട ഡാറ്റ സെറ്റിലേക്ക് jQuery ഉപയോഗിക്കുന്ന സൈറ്റുകളും ഞാൻ ചേർത്തു. ഈ ലൈബ്രറി ഇപ്പോഴും വളരെ ജനപ്രിയമാണ്. റിയാക്റ്റ്, വ്യൂ, ആംഗുലാർ എന്നിവ വാഗ്ദാനം ചെയ്യുന്ന സിംഗിൾ പേജ് ആപ്ലിക്കേഷൻ (എസ്‌പിഎ) മോഡലിൽ നിന്ന് വ്യത്യസ്തമായ വെബ്‌സൈറ്റ് വികസനത്തിനായുള്ള ഒരു സമീപനവും ഇത് അവതരിപ്പിക്കുന്നു.

ഞങ്ങൾക്ക് താൽപ്പര്യമുള്ള സാങ്കേതികവിദ്യകൾ ഉപയോഗിക്കുന്നതായി കണ്ടെത്തിയ സൈറ്റുകളെ പ്രതിനിധീകരിക്കുന്ന HTTP ആർക്കൈവിലെ ലിങ്കുകൾ

ചട്ടക്കൂട് അല്ലെങ്കിൽ ലൈബ്രറി
മൊബൈൽ സൈറ്റുകളിലേക്കുള്ള ലിങ്കുകൾ
സാധാരണ സൈറ്റുകളിലേക്കുള്ള ലിങ്കുകൾ

വിക്കി
4615474
3714643

തിരിച്ചടി നടത്തുക
489827
241023

വ്യൂ
85649
43691

കോണീയ
19423
18088

പ്രതീക്ഷകളും സ്വപ്നങ്ങളും

ഞങ്ങൾ ഡാറ്റ വിശകലനം ചെയ്യുന്നതിനു മുമ്പ്, ഞാൻ പ്രതീക്ഷിക്കാൻ ആഗ്രഹിക്കുന്നതിനെക്കുറിച്ച് സംസാരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

ഒരു അനുയോജ്യമായ ലോകത്ത്, ചട്ടക്കൂടുകൾ ഡവലപ്പർമാരുടെ ആവശ്യങ്ങൾ നിറവേറ്റുന്നതിനും ഞങ്ങളുടെ സൈറ്റുകളുടെ ദൈനംദിന ഉപയോക്താക്കൾക്ക് ചില പ്രത്യേക ആനുകൂല്യങ്ങൾ നൽകുന്നതിനും അപ്പുറം പോകുമെന്ന് ഞാൻ വിശ്വസിക്കുന്നു. ഉൽപ്പാദനക്ഷമത ആ നേട്ടങ്ങളിൽ ഒന്ന് മാത്രമാണ്. പ്രവേശനക്ഷമതയും സുരക്ഷയും ഇവിടെ ഓർമ്മ വരുന്നു. എന്നാൽ ഇത് ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം മാത്രമാണ്.

അതിനാൽ, അനുയോജ്യമായ ഒരു ലോകത്ത്, ചില തരത്തിലുള്ള ചട്ടക്കൂടുകൾ ഉയർന്ന പ്രകടനമുള്ള വെബ്സൈറ്റ് സൃഷ്ടിക്കുന്നത് എളുപ്പമാക്കണം. ഒന്നുകിൽ ചട്ടക്കൂട് ഡവലപ്പർക്ക് ഒരു പ്രോജക്റ്റ് നിർമ്മിക്കുന്നതിനുള്ള മാന്യമായ അടിത്തറ നൽകുന്നു എന്നതിനാലോ അല്ലെങ്കിൽ വികസനത്തിന് നിയന്ത്രണങ്ങൾ ഏർപ്പെടുത്തുന്നതിനാലോ എന്തെങ്കിലും വികസിപ്പിക്കുന്നത് ബുദ്ധിമുട്ടാക്കുന്ന ആവശ്യകതകൾ മുന്നോട്ട് വച്ചതിനാലോ ഇത് ചെയ്യണം. അത് മന്ദഗതിയിലായി മാറുന്നു.

മികച്ച ചട്ടക്കൂടുകൾ രണ്ടും ചെയ്യണം: ഒരു നല്ല അടിസ്ഥാനം നൽകുക, മാന്യമായ ഫലം നേടാൻ നിങ്ങളെ അനുവദിക്കുന്ന ജോലിയിൽ നിയന്ത്രണങ്ങൾ ഏർപ്പെടുത്തുക.

ഡാറ്റയുടെ ശരാശരി മൂല്യങ്ങൾ വിശകലനം ചെയ്യുന്നത് ഞങ്ങൾക്ക് ആവശ്യമായ വിവരങ്ങൾ നൽകില്ല. വാസ്തവത്തിൽ, ഈ സമീപനം നമ്മുടെ ശ്രദ്ധയ്ക്ക് അതീതമാണ് പ്രധാനപ്പെട്ട ഒരുപാട് കാര്യങ്ങൾ. പകരം, എൻ്റെ പക്കലുള്ള ഡാറ്റയിൽ നിന്ന് ഞാൻ പെർസെൻറൈൽ സ്‌കോറുകൾ കണ്ടെത്തി. ഇവയാണ് 10, 25, 50 (മധ്യസ്ഥ), 75, 90 ശതമാനം.

10, 90 ശതമാനങ്ങളിൽ എനിക്ക് പ്രത്യേക താൽപ്പര്യമുണ്ട്. ഒരു പ്രത്യേക ചട്ടക്കൂടിനുള്ള ഏറ്റവും മികച്ച പ്രകടനത്തെ (അല്ലെങ്കിൽ ഏറ്റവും കുറഞ്ഞതോതിൽ കൂടുതലോ കുറവോ) പത്താം ശതമാനം പ്രതിനിധീകരിക്കുന്നു. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഒരു പ്രത്യേക ചട്ടക്കൂട് ഉപയോഗിക്കുന്ന സൈറ്റുകളുടെ 10% മാത്രമേ ഈ നിലയിലോ ഉയർന്ന തലത്തിലോ എത്തുകയുള്ളൂ എന്നാണ് ഇതിനർത്ഥം. നേരെമറിച്ച്, നാണയത്തിൻ്റെ മറുവശമാണ് 10-ആം ശതമാനം - കാര്യങ്ങൾ എത്ര മോശമാണെന്ന് ഇത് കാണിക്കുന്നു. 90-ാമത്തെ പെർസെൻറ്റൈൽ ആണ് ട്രെയിലിംഗ് സൈറ്റുകൾ-ഏറ്റവും വലിയ തോതിൽ JS കോഡ് ഉള്ള അല്ലെങ്കിൽ പ്രധാന ത്രെഡിൽ കോഡ് പ്രോസസ്സ് ചെയ്യാൻ ഏറ്റവും കൂടുതൽ സമയം ആവശ്യമുള്ള അവസാനത്തെ 90% സൈറ്റുകൾ.

JavaScript കോഡിൻ്റെ വോള്യങ്ങൾ

ആരംഭിക്കുന്നതിന്, നെറ്റ്‌വർക്കിലൂടെ വിവിധ സൈറ്റുകൾ കൈമാറുന്ന JavaScript കോഡിൻ്റെ വലുപ്പം വിശകലനം ചെയ്യുന്നത് അർത്ഥമാക്കുന്നു.

മൊബൈൽ ഉപകരണങ്ങളിലേക്ക് കൈമാറിയ JavaScript കോഡിൻ്റെ (KB) തുക

ശതമാനം
10
25
50
75
90

എല്ലാ സൈറ്റുകളും
93.4 
196.6 
413.5 
746.8 
1201.6 

jQuery സൈറ്റുകൾ
110.3 
219.8 
430.4 
748.6 
1162.3 

വ്യൂ വെബ്‌സൈറ്റുകൾ
244.7 
409.3 
692.1 
1065.5 
1570.7 

കോണീയ വെബ്സൈറ്റുകൾ
445.1 
675.6 
1066.4 
1761.5 
2893.2 

പ്രതികരണ വെബ്‌സൈറ്റുകൾ
345.8 
441.6 
690.3 
1238.5 
1893.6 

മൊബൈൽ ഉപകരണങ്ങളിലേക്ക് അയച്ച JavaScript കോഡിൻ്റെ അളവ്

JavaScript കോഡിൻ്റെ (KB) തുക ഡെസ്‌ക്‌ടോപ്പ് ഉപകരണങ്ങളിലേക്ക് കൈമാറി

ശതമാനം
10
25
50
75
90

എല്ലാ സൈറ്റുകളും
105.5 
226.6 
450.4 
808.8 
1267.3 

jQuery സൈറ്റുകൾ
121.7 
242.2 
458.3 
803.4 
1235.3 

വ്യൂ വെബ്‌സൈറ്റുകൾ
248.0 
420.1 
718.0 
1122.5 
1643.1 

കോണീയ വെബ്സൈറ്റുകൾ
468.8 
716.9 
1144.2 
1930.0 
3283.1 

പ്രതികരണ വെബ്‌സൈറ്റുകൾ
308.6 
469.0 
841.9 
1472.2 
2197.8 

ഡെസ്‌ക്‌ടോപ്പ് ഉപകരണങ്ങളിലേക്ക് കൈമാറിയ JavaScript കോഡിൻ്റെ അളവ്

സൈറ്റുകൾ ഉപകരണങ്ങളിലേക്ക് അയയ്‌ക്കുന്ന JS കോഡിൻ്റെ വലുപ്പത്തെക്കുറിച്ച് മാത്രമേ ഞങ്ങൾ സംസാരിക്കുകയുള്ളൂവെങ്കിൽ, നിങ്ങൾ പ്രതീക്ഷിക്കുന്നതുപോലെ എല്ലാം കാണപ്പെടും. അതായത്, ചട്ടക്കൂടുകളിലൊന്ന് ഉപയോഗിക്കുകയാണെങ്കിൽ, അനുയോജ്യമായ സാഹചര്യത്തിൽ പോലും, സൈറ്റിനായുള്ള ജാവാസ്ക്രിപ്റ്റ് കോഡിൻ്റെ അളവ് വർദ്ധിക്കും എന്നാണ് ഇതിനർത്ഥം. ഇത് ആശ്ചര്യകരമല്ല - നിങ്ങൾക്ക് ഒരു JavaScript ഫ്രെയിംവർക്ക് ഒരു സൈറ്റിൻ്റെ അടിസ്ഥാനമാക്കാൻ കഴിയില്ല, കൂടാതെ പ്രോജക്റ്റിനായുള്ള JS കോഡിൻ്റെ അളവ് വളരെ കുറവായിരിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു.

ഈ ഡാറ്റയുടെ രസകരമായ കാര്യം, ചില ചട്ടക്കൂടുകളും ലൈബ്രറികളും ഒരു പ്രോജക്റ്റിനായി മറ്റുള്ളവയേക്കാൾ മികച്ച ആരംഭ പോയിൻ്റുകളായി കണക്കാക്കാം എന്നതാണ്. jQuery ഉള്ള വെബ്‌സൈറ്റുകൾ മികച്ചതായി കാണപ്പെടുന്നു. അവരുടെ ഡെസ്ക്ടോപ്പ് സൈറ്റുകളിൽ എല്ലാ സൈറ്റുകളേക്കാളും 15% കൂടുതൽ JavaScript അടങ്ങിയിരിക്കുന്നു, അവരുടെ മൊബൈൽ സൈറ്റുകളിൽ 18% കൂടുതൽ JavaScript അടങ്ങിയിരിക്കുന്നു. (ഇവിടെയുള്ള ഡാറ്റയിൽ ചില വ്യതിയാനങ്ങൾ ഉണ്ടെന്ന് സമ്മതിക്കാം. jQuery പല സൈറ്റുകളിലും ഉണ്ട് എന്നതാണ് വസ്തുത, അതിനാൽ അത്തരം സൈറ്റുകൾ മറ്റുള്ളവയേക്കാൾ മൊത്തം സൈറ്റുകളുടെ എണ്ണവുമായി കൂടുതൽ അടുത്ത് ബന്ധപ്പെട്ടിരിക്കുന്നത് സ്വാഭാവികമാണ്. എന്നിരുന്നാലും, ഇത് എങ്ങനെ ബാധിക്കില്ല ഓരോ ചട്ടക്കൂടിനും ഉറവിട ഡാറ്റ ഔട്ട്പുട്ട് ആണ്.)

15-18% കോഡ് വളർച്ച ഒരു പ്രധാന സംഖ്യയാണെങ്കിലും, മറ്റ് ചട്ടക്കൂടുകളുമായും ലൈബ്രറികളുമായും താരതമ്യം ചെയ്യുമ്പോൾ, jQuery ചുമത്തുന്ന നികുതി വളരെ കുറവാണ്. എല്ലാ സൈറ്റുകളേക്കാളും 10% കൂടുതൽ ഡാറ്റ ഡെസ്‌ക്‌ടോപ്പ് ഉപകരണങ്ങളിലേക്കും മൊബൈൽ ഉപകരണങ്ങളിലേക്ക് 344% കൂടുതൽ ഡാറ്റയും പത്താം പെർസെൻറ്റൈലിലെ കോണീയ സൈറ്റുകൾ അയയ്ക്കുന്നു. എല്ലാ സൈറ്റുകളേക്കാളും ഡെസ്‌ക്‌ടോപ്പ് ഉപകരണങ്ങളിലേക്ക് 377% കൂടുതൽ കോഡ് അയയ്‌ക്കുന്ന, മൊബൈൽ ഉപകരണങ്ങളിലേക്ക് 193% കൂടുതൽ കോഡ് അയയ്‌ക്കുന്ന റിയാക്റ്റ് സൈറ്റുകളാണ് അടുത്ത ഭാരമേറിയത്.

ഒരു ചട്ടക്കൂട് ഉപയോഗിക്കുന്നത് അതിൻ്റെ പ്രവർത്തനത്തിൻ്റെ തുടക്കത്തിൽ തന്നെ ഒരു നിശ്ചിത അളവിലുള്ള കോഡ് പ്രോജക്റ്റിൽ ഉൾപ്പെടുത്തുമെന്ന് ഞാൻ നേരത്തെ സൂചിപ്പിച്ചിരുന്നുവെങ്കിലും, ഡവലപ്പറെ എങ്ങനെയെങ്കിലും പരിമിതപ്പെടുത്താൻ ചട്ടക്കൂടിന് കഴിയുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. പ്രത്യേകിച്ചും, ഞങ്ങൾ കോഡിൻ്റെ പരമാവധി തുക പരിമിതപ്പെടുത്തുന്നതിനെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്.

രസകരമായ കാര്യം, jQuery സൈറ്റുകൾ ഈ ആശയം പിന്തുടരുന്നു എന്നതാണ്. 10-ാം പെർസെൻറ്റൈൽ തലത്തിൽ, അവ എല്ലാ സൈറ്റുകളേക്കാളും (15-18% വരെ) അൽപ്പം ഭാരമുള്ളവയാണെങ്കിലും, 90-ആം ശതമാനം തലത്തിൽ, എല്ലാ സൈറ്റുകളേക്കാളും അൽപ്പം ഭാരം കുറഞ്ഞവയാണ് - ഡെസ്‌ക്‌ടോപ്പിലും മൊബൈൽ പതിപ്പുകളിലും ഏകദേശം 3%. ഇത് വളരെ പ്രധാനപ്പെട്ട ഒരു നേട്ടമാണെന്ന് ഇതിനർത്ഥമില്ല, എന്നാൽ jQuery സൈറ്റുകൾക്ക് അവയുടെ ഏറ്റവും വലിയ പതിപ്പുകളിൽ പോലും വലിയ ജാവാസ്ക്രിപ്റ്റ് കോഡ് വലുപ്പങ്ങൾ ഇല്ലെന്ന് പറയാം.

എന്നാൽ മറ്റ് ചട്ടക്കൂടുകളെക്കുറിച്ച് ഇത് പറയാൻ കഴിയില്ല.

10-ആം ശതമാനത്തിൻ്റെ കാര്യത്തിലെന്നപോലെ, കോണിലും റിയാക്ടിലുമുള്ള 90-ആം ശതമാനം സൈറ്റുകൾ മറ്റ് സൈറ്റുകളിൽ നിന്ന് വ്യത്യസ്തമാണ്, പക്ഷേ അവ നിർഭാഗ്യവശാൽ, മോശമായതിന് വ്യത്യാസപ്പെട്ടിരിക്കുന്നു.

90-ാം ശതമാനത്തിൽ, കോണീയ സൈറ്റുകൾ എല്ലാ സൈറ്റുകളേക്കാളും 141% കൂടുതൽ ഡാറ്റ മൊബൈൽ ഉപകരണങ്ങളിലേക്കും ഡെസ്‌ക്‌ടോപ്പ് ഉപകരണങ്ങളിലേക്ക് 159% കൂടുതൽ ഡാറ്റയും അയയ്ക്കുന്നു. റിയാക്റ്റ് സൈറ്റുകൾ എല്ലാ സൈറ്റുകളേക്കാളും 73% കൂടുതൽ ഡെസ്‌ക്‌ടോപ്പ് ഉപകരണങ്ങളിലേക്ക് അയയ്‌ക്കുന്നു, കൂടാതെ മൊബൈൽ ഉപകരണങ്ങളിലേക്ക് 58% കൂടുതൽ. 90-ാം പെർസെൻറ്റൈലിലെ റിയാക്റ്റ് സൈറ്റുകളുടെ കോഡ് വലുപ്പം 2197.8 KB ആണ്. ഇതിനർത്ഥം ഈ സൈറ്റുകൾ അവരുടെ ഏറ്റവും അടുത്ത Vue അടിസ്ഥാനമാക്കിയുള്ള എതിരാളികളേക്കാൾ 322.9 KB കൂടുതൽ ഡാറ്റ മൊബൈൽ ഉപകരണങ്ങളിലേക്ക് അയയ്ക്കുന്നു എന്നാണ്. Angular, React എന്നിവയെ അടിസ്ഥാനമാക്കിയുള്ള ഡെസ്ക്ടോപ്പ് സൈറ്റുകളും മറ്റ് സൈറ്റുകളും തമ്മിലുള്ള വിടവ് ഇതിലും വലുതാണ്. ഉദാഹരണത്തിന്, സമാന Vue സൈറ്റുകളേക്കാൾ 554.7 KB കൂടുതൽ JS കോഡ് ഉപകരണങ്ങളിലേക്ക് React ഡെസ്ക്ടോപ്പ് സൈറ്റുകൾ അയയ്ക്കുന്നു.

പ്രധാന ത്രെഡിൽ JavaScript കോഡ് പ്രോസസ്സ് ചെയ്യാൻ എടുക്കുന്ന സമയം

മുകളിലെ ഡാറ്റ വ്യക്തമായി സൂചിപ്പിക്കുന്നത് ചട്ടക്കൂടുകളും ലൈബ്രറികളും ഉപയോഗിക്കുന്ന സൈറ്റുകളിൽ വലിയ അളവിലുള്ള JavaScript കോഡ് അടങ്ങിയിരിക്കുന്നു എന്നാണ്. പക്ഷേ, തീർച്ചയായും, ഇത് നമ്മുടെ സമവാക്യത്തിൻ്റെ ഒരു ഭാഗം മാത്രമാണ്.

JavaScript കോഡ് ബ്രൗസറിൽ വന്നതിനുശേഷം, അത് പ്രവർത്തന നിലയിലേക്ക് കൊണ്ടുവരേണ്ടതുണ്ട്. പ്രധാന ബ്രൗസർ ത്രെഡിലെ കോഡ് ഉപയോഗിച്ച് നടപ്പിലാക്കേണ്ട പ്രവർത്തനങ്ങളാണ് പ്രത്യേകിച്ചും പല പ്രശ്‌നങ്ങൾക്കും കാരണം. ഉപയോക്തൃ പ്രവർത്തനങ്ങൾ പ്രോസസ്സ് ചെയ്യുന്നതിനും ശൈലികൾ കണക്കാക്കുന്നതിനും പേജ് ലേഔട്ട് നിർമ്മിക്കുന്നതിനും പ്രദർശിപ്പിക്കുന്നതിനും പ്രധാന ത്രെഡ് ഉത്തരവാദിയാണ്. നിങ്ങൾ JavaScript ടാസ്‌ക്കുകൾ ഉപയോഗിച്ച് പ്രധാന ത്രെഡിനെ മറികടക്കുകയാണെങ്കിൽ, മറ്റ് ജോലികൾ സമയബന്ധിതമായി പൂർത്തിയാക്കാൻ അതിന് അവസരമുണ്ടാകില്ല. ഇത് പേജുകളുടെ പ്രവർത്തനത്തിൽ കാലതാമസത്തിനും "ബ്രേക്കുകൾക്കും" കാരണമാകുന്നു.

HTTP ആർക്കൈവ് ഡാറ്റാബേസിൽ V8 എഞ്ചിൻ്റെ പ്രധാന ത്രെഡിൽ JavaScript കോഡ് പ്രോസസ്സ് ചെയ്യാൻ എത്ര സമയമെടുക്കും എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു. ഇതിനർത്ഥം നമുക്ക് ഈ ഡാറ്റ ശേഖരിക്കാനും വിവിധ സൈറ്റുകളുടെ JavaScript പ്രോസസ്സ് ചെയ്യുന്നതിന് പ്രധാന ത്രെഡ് എത്ര സമയമെടുക്കുമെന്ന് മനസ്സിലാക്കാനും കഴിയും എന്നാണ്.

മൊബൈൽ ഉപകരണങ്ങളിലെ സ്ക്രിപ്റ്റ് പ്രോസസ്സിംഗുമായി ബന്ധപ്പെട്ട CPU സമയം (മില്ലിസെക്കൻഡിൽ).

ശതമാനം
10
25
50
75
90

എല്ലാ സൈറ്റുകളും
356.4
959.7
2372.1
5367.3
10485.8

jQuery സൈറ്റുകൾ
575.3
1147.4
2555.9
5511.0
10349.4

വ്യൂ വെബ്‌സൈറ്റുകൾ
1130.0
2087.9
4100.4
7676.1
12849.4

കോണീയ വെബ്സൈറ്റുകൾ
1471.3
2380.1
4118.6
7450.8
13296.4

പ്രതികരണ വെബ്‌സൈറ്റുകൾ
2700.1
5090.3
9287.6
14509.6
20813.3

മൊബൈൽ ഉപകരണങ്ങളിലെ സ്ക്രിപ്റ്റ് പ്രോസസ്സിംഗുമായി ബന്ധപ്പെട്ട CPU സമയം

ഡെസ്ക്ടോപ്പ് ഉപകരണങ്ങളിലെ സ്ക്രിപ്റ്റ് പ്രോസസ്സിംഗുമായി ബന്ധപ്പെട്ട CPU സമയം (മില്ലിസെക്കൻഡിൽ).

ശതമാനം
10
25
50
75
90

എല്ലാ സൈറ്റുകളും
146.0
351.8
831.0
1739.8
3236.8

jQuery സൈറ്റുകൾ
199.6
399.2
877.5
1779.9
3215.5

വ്യൂ വെബ്‌സൈറ്റുകൾ
350.4
650.8
1280.7
2388.5
4010.8

കോണീയ വെബ്സൈറ്റുകൾ
482.2
777.9
1365.5
2400.6
4171.8

പ്രതികരണ വെബ്‌സൈറ്റുകൾ
508.0
1045.6
2121.1
4235.1
7444.3

ഡെസ്ക്ടോപ്പ് ഉപകരണങ്ങളിലെ സ്ക്രിപ്റ്റ് പ്രോസസ്സിംഗുമായി ബന്ധപ്പെട്ട CPU സമയം

ഇവിടെ നിങ്ങൾക്ക് വളരെ പരിചിതമായ ഒന്ന് കാണാൻ കഴിയും.

തുടക്കക്കാർക്കായി, jQuery ഉള്ള സൈറ്റുകൾ മറ്റുള്ളവയേക്കാൾ പ്രധാന ത്രെഡിൽ JavaScript പ്രോസസ്സ് ചെയ്യുന്നത് വളരെ കുറവാണ്. പത്താം ശതമാനത്തിൽ, എല്ലാ സൈറ്റുകളുമായും താരതമ്യം ചെയ്യുമ്പോൾ, മൊബൈൽ ഉപകരണങ്ങളിലെ jQuery സൈറ്റുകൾ പ്രധാന ത്രെഡിൽ JS കോഡ് പ്രോസസ്സ് ചെയ്യുന്നതിന് 10% കൂടുതൽ സമയം ചെലവഴിക്കുന്നു. ഡെസ്ക്ടോപ്പ് jQuery സൈറ്റുകളുടെ കാര്യത്തിൽ, പ്രോസസ്സിംഗ് സമയം 61% വർദ്ധിക്കുന്നു. 37-ാം ശതമാനത്തിൽ, jQuery സൈറ്റുകളുടെ സ്‌കോറുകൾ മൊത്തം സ്‌കോറുകളോട് വളരെ അടുത്താണ്. പ്രത്യേകിച്ചും, മൊബൈൽ ഉപകരണങ്ങളിലെ jQuery സൈറ്റുകൾ പ്രധാന ത്രെഡിൽ എല്ലാ സൈറ്റുകളേക്കാളും 90% കുറവ് സമയം ചെലവഴിക്കുന്നു, കൂടാതെ ഡെസ്‌ക്‌ടോപ്പ് ഉപകരണങ്ങളിൽ പ്രധാന ത്രെഡിൽ 1.3% കുറവ് സമയം ചെലവഴിക്കുന്നു.

ഞങ്ങളുടെ റേറ്റിംഗിൻ്റെ മറുവശത്ത് പ്രധാന ത്രെഡിലെ ഏറ്റവും വലിയ ലോഡിൻ്റെ സവിശേഷതയുള്ള ചട്ടക്കൂടുകളാണ്. ഇത് വീണ്ടും കോണീയവും പ്രതികരണവുമാണ്. അവ തമ്മിലുള്ള ഒരേയൊരു വ്യത്യാസം, റിയാക്റ്റ് സൈറ്റുകളേക്കാൾ വലിയ അളവിലുള്ള കോഡ് ബ്രൗസറുകളിലേക്ക് കോണീയ സൈറ്റുകൾ അയയ്‌ക്കുന്നുണ്ടെങ്കിലും, കോണീയ സൈറ്റുകളുടെ കോഡ് പ്രോസസ്സ് ചെയ്യുന്നതിന് കുറച്ച് സിപിയു സമയമെടുക്കും. വളരെ കുറവ്.

പത്താം ശതമാനത്തിൽ, എല്ലാ സൈറ്റുകളേക്കാളും കോണീയ ഡെസ്ക്ടോപ്പ് സൈറ്റുകൾ JS കോഡ് പ്രോസസ്സ് ചെയ്യുന്നതിന് 10% കൂടുതൽ പ്രധാന ത്രെഡ് സമയം ചെലവഴിക്കുന്നു. മൊബൈൽ സൈറ്റുകൾക്ക് ഇത് 230% ആണ്. റിയാക്ട് സൈറ്റുകൾക്ക് ഏറ്റവും മോശം പ്രകടനമുണ്ട്. ഡെസ്‌ക്‌ടോപ്പ് ഉപകരണങ്ങളിൽ അവർ എല്ലാ സൈറ്റുകളേക്കാളും 313% കൂടുതൽ സമയം കോഡ് പ്രോസസ്സ് ചെയ്യുന്നു, കൂടാതെ മൊബൈൽ ഉപകരണങ്ങളിൽ അവർ 248% കൂടുതൽ സമയം കോഡ് പ്രോസസ്സ് ചെയ്യുന്നു. 658% അക്ഷരത്തെറ്റല്ല. പത്താം ശതമാനത്തിൽ, റിയാക്റ്റ് സൈറ്റുകൾ അവരുടെ നിലവിലുള്ള കോഡ് പ്രോസസ്സ് ചെയ്യുന്നതിന് പ്രധാന ത്രെഡിൻ്റെ 658 സെക്കൻഡ് സമയം ചെലവഴിക്കുന്നു.

ഈ വലിയ സംഖ്യകളുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ 90-ാമത്തെ പെർസെൻറൈൽ സംഖ്യകൾ അൽപ്പമെങ്കിലും മെച്ചപ്പെട്ടതായി കാണപ്പെടുന്നു. കോണീയ പ്രോജക്റ്റുകൾ, എല്ലാ സൈറ്റുകളെയും അപേക്ഷിച്ച്, ഡെസ്‌ക്‌ടോപ്പ് ഉപകരണങ്ങളിലെ പ്രധാന ത്രെഡിൽ 29% കൂടുതൽ സമയവും മൊബൈൽ ഉപകരണങ്ങളിൽ 27% കൂടുതൽ സമയവും ചെലവഴിക്കുന്നു. റിയാക്റ്റ് സൈറ്റുകളുടെ കാര്യത്തിൽ, സമാന സൂചകങ്ങൾ യഥാക്രമം 130%, 98% എന്നിങ്ങനെയാണ് കാണപ്പെടുന്നത്.

90-ആം പെർസെൻറ്റൈലിൻ്റെ ഡീവിയേഷൻ ശതമാനം 10-ാം പെർസെൻറ്റൈലിൻ്റെ സമാന മൂല്യങ്ങളേക്കാൾ മികച്ചതായി കാണപ്പെടുന്നു. എന്നാൽ ഇവിടെ സമയം സൂചിപ്പിക്കുന്ന അക്കങ്ങൾ വളരെ ഭയാനകമായി തോന്നുന്നു എന്നത് ഓർമിക്കേണ്ടതാണ്. നമുക്ക് പറയാം - റിയാക്ടിൽ നിർമ്മിച്ച ഒരു സൈറ്റിനായുള്ള മൊബൈൽ ഉപകരണത്തിൻ്റെ പ്രധാന ത്രെഡിൽ 20.8 സെക്കൻഡ്. (ഈ സമയത്ത് യഥാർത്ഥത്തിൽ എന്താണ് സംഭവിക്കുന്നത് എന്നതിൻ്റെ കഥ ഒരു പ്രത്യേക ലേഖനത്തിന് അർഹമാണെന്ന് ഞാൻ വിശ്വസിക്കുന്നു).

ഇവിടെ ഒരു സങ്കീർണതയുണ്ട് (നന്ദി ജെറമിയ ഈ സവിശേഷതയിലേക്ക് എൻ്റെ ശ്രദ്ധ ആകർഷിക്കുന്നതിനും ഈ വീക്ഷണകോണിൽ നിന്നുള്ള ഡാറ്റ ശ്രദ്ധാപൂർവ്വം പരിശോധിക്കുന്നതിനും). പല സൈറ്റുകളും നിരവധി ഫ്രണ്ട് എൻഡ് ടൂളുകൾ ഉപയോഗിക്കുന്നു എന്നതാണ് വസ്തുത. പ്രത്യേകിച്ചും, ഈ സൈറ്റുകൾ jQuery-ൽ നിന്ന് മറ്റ് ഫ്രെയിംവർക്കുകളിലേക്കോ ലൈബ്രറികളിലേക്കോ മൈഗ്രേറ്റ് ചെയ്യുന്നതിനാൽ, ഒരുപാട് സൈറ്റുകൾ React അല്ലെങ്കിൽ Vue എന്നിവയ്‌ക്കൊപ്പം jQuery ഉപയോഗിക്കുന്നത് ഞാൻ കണ്ടു. തൽഫലമായി, ഞാൻ ഡാറ്റാബേസിലേക്ക് മടങ്ങി, ഇത്തവണ React, jQuery, Angular അല്ലെങ്കിൽ Vue എന്നിവ മാത്രം ഉപയോഗിക്കുന്ന സൈറ്റുകളുമായി പൊരുത്തപ്പെടുന്ന ലിങ്കുകൾ മാത്രം തിരഞ്ഞെടുത്തു, എന്നാൽ അവയുടെ സംയോജനമല്ല. എനിക്ക് കിട്ടിയത് ഇതാ.

സൈറ്റുകൾ ഒരു ചട്ടക്കൂട് അല്ലെങ്കിൽ ഒരു ലൈബ്രറി മാത്രം ഉപയോഗിക്കുന്ന സാഹചര്യങ്ങളിൽ മൊബൈൽ ഉപകരണങ്ങളിലെ സ്ക്രിപ്റ്റ് പ്രോസസ്സിംഗുമായി ബന്ധപ്പെട്ട പ്രോസസ്സർ സമയം (മില്ലിസെക്കൻഡിൽ)

ശതമാനം
10
25
50
75
90

jQuery മാത്രം ഉപയോഗിക്കുന്ന സൈറ്റുകൾ
542.9
1062.2
2297.4
4769.7
8718.2

Vue മാത്രം ഉപയോഗിക്കുന്ന സൈറ്റുകൾ
944.0
1716.3
3194.7
5959.6
9843.8

കോണീയം മാത്രം ഉപയോഗിക്കുന്ന സൈറ്റുകൾ
1328.9
2151.9
3695.3
6629.3
11607.7

React മാത്രം ഉപയോഗിക്കുന്ന വെബ്‌സൈറ്റുകൾ
2443.2
4620.5
10061.4
17074.3
24956.3

സൈറ്റുകൾ ഒരു ചട്ടക്കൂട് അല്ലെങ്കിൽ ഒരു ലൈബ്രറി മാത്രം ഉപയോഗിക്കുന്ന സാഹചര്യത്തിൽ മൊബൈൽ ഉപകരണങ്ങളിൽ സ്ക്രിപ്റ്റുകൾ പ്രോസസ്സ് ചെയ്യുന്നതുമായി ബന്ധപ്പെട്ട പ്രോസസ്സർ സമയം

ആദ്യം, ആശ്ചര്യകരമല്ലാത്ത ഒന്ന്: ഒരു സൈറ്റ് ഒരു ചട്ടക്കൂട് അല്ലെങ്കിൽ ഒരു ലൈബ്രറി മാത്രം ഉപയോഗിക്കുമ്പോൾ, അത്തരം ഒരു സൈറ്റിൻ്റെ പ്രകടനം പലപ്പോഴും മെച്ചപ്പെടുന്നു. ഓരോ ഉപകരണത്തിൻ്റെയും പ്രകടനം 10-ഉം 25-ഉം ശതമാനത്തിൽ മികച്ചതായി കാണപ്പെടുന്നു. അർത്ഥവത്താണ്. രണ്ടോ അതിലധികമോ ചട്ടക്കൂടുകളോ ലൈബ്രറികളോ ഉപയോഗിച്ച് നിർമ്മിച്ച സൈറ്റിനേക്കാൾ വേഗമേറിയതായിരിക്കണം ഒരു ചട്ടക്കൂട് ഉപയോഗിച്ച് നിർമ്മിച്ച സൈറ്റ്.

വാസ്തവത്തിൽ, ഞങ്ങൾ പരിശോധിച്ച എല്ലാ ഫ്രണ്ട്-എൻഡ് ടൂളുകളുടെയും സ്‌കോറുകൾ എല്ലാ സാഹചര്യങ്ങളിലും മികച്ചതായി കാണപ്പെട്ടു, ഒരു കൗതുകകരമായ ഒഴികെ. എന്നെ ആശ്ചര്യപ്പെടുത്തിയത്, 50-ആം ശതമാനത്തിലും അതിനുമുകളിലും, റിയാക്റ്റ് ഉപയോഗിക്കുന്ന സൈറ്റുകൾ അവർ ഉപയോഗിക്കുന്ന ഒരേയൊരു ലൈബ്രറി ആയിരിക്കുമ്പോൾ മോശം പ്രകടനം കാഴ്ചവെക്കുന്നു എന്നതാണ്. ഇതാണ്, ഞാൻ ഈ ഡാറ്റ ഇവിടെ അവതരിപ്പിക്കാൻ കാരണം.

ഇത് അൽപ്പം വിചിത്രമാണ്, പക്ഷേ ഈ അപരിചിതത്വത്തിന് ഒരു വിശദീകരണത്തിനായി ഞാൻ ഇപ്പോഴും ശ്രമിക്കും.

ഒരു പ്രോജക്‌റ്റ് റിയാക്‌റ്റും jQuery ഉം ഉപയോഗിക്കുന്നുവെങ്കിൽ, ആ പ്രോജക്‌റ്റ് മിക്കവാറും jQuery-ൽ നിന്ന് റിയാക്‌റ്റിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുന്ന പ്രക്രിയയിൽ എവിടെയോ ആയിരിക്കും. ഒരുപക്ഷേ അദ്ദേഹത്തിന് ഈ ലൈബ്രറികൾ ഇടകലർന്ന ഒരു കോഡ്ബേസ് ഉണ്ടായിരിക്കാം. റിയാക്റ്റ് സൈറ്റുകളേക്കാൾ പ്രധാന ത്രെഡിൽ jQuery സൈറ്റുകൾ കുറച്ച് സമയം ചെലവഴിക്കുന്നത് ഞങ്ങൾ ഇതിനകം കണ്ടിട്ടുള്ളതിനാൽ, jQuery-യിൽ ചില പ്രവർത്തനങ്ങൾ നടപ്പിലാക്കുന്നത് സൈറ്റിൻ്റെ പ്രകടനം അൽപ്പം മെച്ചപ്പെടുത്താൻ സഹായിക്കുമെന്ന് ഇത് ഞങ്ങളോട് പറഞ്ഞേക്കാം.

എന്നാൽ പ്രോജക്റ്റ് jQuery-ൽ നിന്ന് React-ലേക്ക് മാറുകയും കൂടുതൽ കൂടുതൽ React-നെ ആശ്രയിക്കുകയും ചെയ്യുമ്പോൾ സ്ഥിതി മാറുന്നു. സൈറ്റ് യഥാർത്ഥത്തിൽ ഉയർന്ന നിലവാരത്തിൽ നിർമ്മിച്ചതാണെങ്കിൽ, സൈറ്റ് ഡെവലപ്പർമാർ React ശ്രദ്ധാപൂർവ്വം ഉപയോഗിക്കുകയാണെങ്കിൽ, അത്തരമൊരു സൈറ്റിൽ എല്ലാം ശരിയാകും. എന്നാൽ ശരാശരി റിയാക്റ്റ് സൈറ്റിനെ സംബന്ധിച്ചിടത്തോളം, റിയാക്റ്റിൻ്റെ വിപുലമായ ഉപയോഗം അർത്ഥമാക്കുന്നത് പ്രധാന ത്രെഡ് വർദ്ധിച്ച ലോഡിന് വിധേയമാണ് എന്നാണ്.

മൊബൈൽ, ഡെസ്ക്ടോപ്പ് ഉപകരണങ്ങൾ തമ്മിലുള്ള വിടവ്

മൊബൈൽ, ഡെസ്‌ക്‌ടോപ്പ് അനുഭവങ്ങൾ തമ്മിലുള്ള വിടവ് എത്ര വലുതാണെന്ന് പര്യവേക്ഷണം ചെയ്യുക എന്നതാണ് ഞാൻ ഡാറ്റയിലേക്ക് നോക്കിയ മറ്റൊരു മാർഗം. ജാവാസ്ക്രിപ്റ്റ് കോഡിൻ്റെ വോള്യങ്ങൾ താരതമ്യം ചെയ്യുന്നതിനെക്കുറിച്ച് നമ്മൾ സംസാരിക്കുകയാണെങ്കിൽ, അത്തരമൊരു താരതമ്യം ഭയാനകമായ ഒന്നും വെളിപ്പെടുത്തുന്നില്ല. തീർച്ചയായും, ഡൗൺലോഡ് ചെയ്യാവുന്ന ചെറിയ അളവിലുള്ള കോഡ് കാണുന്നത് നന്നായിരിക്കും, എന്നാൽ മൊബൈലിൻ്റെയും ഡെസ്ക്ടോപ്പ് കോഡിൻ്റെയും അളവിൽ വലിയ വ്യത്യാസമില്ല.

എന്നാൽ കോഡ് പ്രോസസ്സ് ചെയ്യുന്നതിന് ആവശ്യമായ സമയം നിങ്ങൾ വിശകലനം ചെയ്യുകയാണെങ്കിൽ, മൊബൈൽ, ഡെസ്ക്ടോപ്പ് ഉപകരണങ്ങൾ തമ്മിലുള്ള വളരെ വലിയ വിടവ് ശ്രദ്ധേയമാകും.

ഡെസ്‌ക്‌ടോപ്പുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ മൊബൈൽ ഉപകരണങ്ങളിലെ സ്‌ക്രിപ്റ്റ് പ്രോസസ്സിംഗുമായി ബന്ധപ്പെട്ട സമയത്തിൻ്റെ വർദ്ധനവ് (ശതമാനത്തിൽ).

ശതമാനം
10
25
50
75
90

എല്ലാ സൈറ്റുകളും
144.1
172.8
185.5
208.5
224.0

jQuery സൈറ്റുകൾ
188.2
187.4
191.3
209.6
221.9

വ്യൂ വെബ്‌സൈറ്റുകൾ
222.5
220.8
220.2
221.4
220.4

കോണീയ വെബ്സൈറ്റുകൾ
205.1
206.0
201.6
210.4
218.7

പ്രതികരണ വെബ്‌സൈറ്റുകൾ
431.5
386.8
337.9
242.6
179.6

ഒരു ഫോണും ലാപ്‌ടോപ്പും തമ്മിലുള്ള കോഡ് പ്രോസസ്സിംഗ് വേഗതയിൽ ചില വ്യത്യാസങ്ങൾ പ്രതീക്ഷിക്കപ്പെടുമ്പോൾ, അത്തരം വലിയ സംഖ്യകൾ എന്നോട് പറയുന്നത്, ആധുനിക ചട്ടക്കൂടുകൾ കുറഞ്ഞ പവർ ഉപകരണങ്ങളിൽ വേണ്ടത്ര ലക്ഷ്യമിടുന്നില്ലെന്നും തിരിച്ചറിഞ്ഞ വിടവ് അടയ്ക്കാനുള്ള ആഗ്രഹമാണെന്നും. പത്താം ശതമാനത്തിൽ പോലും, ഡെസ്‌ക്‌ടോപ്പ് മെയിൻ ത്രെഡിനേക്കാൾ 10% കൂടുതൽ സമയം മൊബൈൽ മെയിൻ ത്രെഡിൽ React സൈറ്റുകൾ ചെലവഴിക്കുന്നു. jQuery ആണ് ഏറ്റവും ചെറിയ വിടവ്, എന്നാൽ ഇവിടെയും 431.5% ആണ്. വെബ്‌സൈറ്റ് ഡെവലപ്പർമാർ അവരുടെ പ്രോജക്‌റ്റുകൾ പ്രോസസ്സ് ചെയ്യുന്നതിന് കൂടുതൽ സിപിയു സമയം ആവശ്യമായി വരുമ്പോൾ (ഇതാണ് സംഭവിക്കുന്നത്, കാലക്രമേണ ഇത് കൂടുതൽ വഷളാകുന്നു), കുറഞ്ഞ പവർ ഉപകരണങ്ങളുടെ ഉടമകൾ അതിന് പണം നൽകണം.

ഫലങ്ങൾ

നല്ല ചട്ടക്കൂടുകൾ വെബ് പ്രോജക്റ്റുകൾ നിർമ്മിക്കുന്നതിന് ഡവലപ്പർമാർക്ക് നല്ല അടിത്തറ നൽകണം (സുരക്ഷ, പ്രവേശനക്ഷമത, പ്രകടനം എന്നിവയിൽ), അല്ലെങ്കിൽ ആ നിയന്ത്രണങ്ങൾ ലംഘിക്കുന്ന എന്തെങ്കിലും സൃഷ്ടിക്കുന്നത് ബുദ്ധിമുട്ടാക്കുന്ന ബിൽറ്റ്-ഇൻ നിയന്ത്രണങ്ങൾ ഉണ്ടായിരിക്കണം.

വെബ് പ്രോജക്റ്റുകളുടെ പ്രകടനത്തിന് ഇത് ബാധകമല്ലെന്ന് തോന്നുന്നു (പ്രത്യക്ഷമായും അവയ്ക്ക് പ്രവേശനക്ഷമത).

റിയാക്റ്റ് അല്ലെങ്കിൽ ആംഗുലാർ സൈറ്റുകൾ കോഡ് തയ്യാറാക്കാൻ മറ്റുള്ളവരെ അപേക്ഷിച്ച് കൂടുതൽ സിപിയു സമയം ചിലവഴിക്കുന്നു എന്നതിനാൽ, പ്രവർത്തിക്കുമ്പോൾ റിയാക്റ്റ് സൈറ്റുകൾ വ്യൂ സൈറ്റുകളേക്കാൾ കൂടുതൽ സിപിയു-ഇൻ്റൻസീവ് ആണെന്ന് അർത്ഥമാക്കുന്നില്ല എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. വാസ്തവത്തിൽ, ഞങ്ങൾ നോക്കിയ ഡാറ്റ ചട്ടക്കൂടുകളുടെയും ലൈബ്രറികളുടെയും പ്രവർത്തന പ്രകടനത്തെക്കുറിച്ച് വളരെ കുറച്ച് മാത്രമേ പറയുന്നുള്ളൂ. ബോധപൂർവമായോ അല്ലാതെയോ ഈ ചട്ടക്കൂടുകൾക്ക് പ്രോഗ്രാമർമാരെ പ്രേരിപ്പിക്കുന്ന വികസന സമീപനങ്ങളെക്കുറിച്ച് അവർ കൂടുതൽ സംസാരിക്കുന്നു. ചട്ടക്കൂടുകൾക്കുള്ള ഡോക്യുമെൻ്റേഷൻ, അവയുടെ ആവാസവ്യവസ്ഥ, പൊതുവായ വികസന സാങ്കേതികതകൾ എന്നിവയെക്കുറിച്ചാണ് നമ്മൾ സംസാരിക്കുന്നത്.

ഞങ്ങൾ ഇവിടെ വിശകലനം ചെയ്യാത്ത ചിലതും പരാമർശിക്കേണ്ടതാണ്, അതായത്, സൈറ്റിൻ്റെ പേജുകൾക്കിടയിൽ പരിവർത്തനം ചെയ്യുമ്പോൾ ഉപകരണം ജാവാസ്ക്രിപ്റ്റ് കോഡ് നടപ്പിലാക്കാൻ എത്ര സമയം ചെലവഴിക്കുന്നു. സിംഗിൾ പേജ് ആപ്ലിക്കേഷൻ ബ്രൗസറിൽ ലോഡ് ചെയ്‌തുകഴിഞ്ഞാൽ, ഉപയോക്താവിന് സൈദ്ധാന്തികമായി സൈറ്റിൻ്റെ പേജുകൾ വേഗത്തിൽ ആക്‌സസ് ചെയ്യാൻ കഴിയും എന്നതാണ് SPA-യ്‌ക്ക് അനുകൂലമായ വാദം. ഇത് ഒരു വസ്തുതയിൽ നിന്ന് വളരെ അകലെയാണെന്ന് എൻ്റെ സ്വന്തം അനുഭവം എന്നോട് പറയുന്നു. എന്നാൽ ഈ പ്രശ്നം വ്യക്തമാക്കാൻ ഞങ്ങളുടെ പക്കൽ ഡാറ്റയില്ല.

ഒരു വെബ്‌സൈറ്റ് സൃഷ്‌ടിക്കുന്നതിന് നിങ്ങൾ ഒരു ചട്ടക്കൂടോ ലൈബ്രറിയോ ഉപയോഗിക്കുകയാണെങ്കിൽ, ആദ്യം പ്രോജക്റ്റ് ലോഡുചെയ്യുന്നതിനും അത് പോകാൻ തയ്യാറാകുന്നതിനുമുള്ള കാര്യത്തിൽ നിങ്ങൾ ഒരു വിട്ടുവീഴ്ച ചെയ്യുന്നു എന്നതാണ് വ്യക്തം. ഏറ്റവും പോസിറ്റീവ് സാഹചര്യങ്ങൾക്ക് പോലും ഇത് ബാധകമാണ്.

ശരിയായ സാഹചര്യങ്ങളിൽ, ചില വിട്ടുവീഴ്ചകൾ വരുത്തുന്നത് പൂർണ്ണമായും സാധ്യമാണ്, എന്നാൽ ഡെവലപ്പർമാർ അത്തരം വിട്ടുവീഴ്ചകൾ ബോധപൂർവ്വം ചെയ്യുന്നത് പ്രധാനമാണ്.

എന്നാൽ നമുക്ക് ശുഭാപ്തിവിശ്വാസത്തിനും കാരണമുണ്ട്. ആ ടൂളുകളുടെ പ്രകടനം മെച്ചപ്പെടുത്താൻ സഹായിക്കുന്നതിന് ഞങ്ങൾ കവർ ചെയ്തിട്ടുള്ള ഫ്രണ്ട്-എൻഡ് ടൂളുകളിൽ ചിലതിന് പിന്നിലുള്ളവരുമായി Chrome ഡെവലപ്പർമാർ എത്രത്തോളം അടുത്ത് പ്രവർത്തിക്കുന്നു എന്നത് എന്നെ പ്രോത്സാഹിപ്പിക്കുന്നു.

എന്നിരുന്നാലും, ഞാൻ ഒരു പ്രായോഗിക വ്യക്തിയാണ്. പുതിയ ആർക്കിടെക്ചറുകൾ അവ പരിഹരിക്കുമ്പോൾ പലപ്പോഴും പ്രകടന പ്രശ്നങ്ങൾ സൃഷ്ടിക്കുന്നു. കൂടാതെ പോരായ്മകൾ ഇല്ലാതാക്കാൻ സമയമെടുക്കും. നമ്മൾ അത് പ്രതീക്ഷിക്കാൻ പാടില്ലാത്തത് പോലെ പുതിയ നെറ്റ്‌വർക്ക് സാങ്കേതികവിദ്യകൾ എല്ലാ പ്രകടന പ്രശ്നങ്ങളും പരിഹരിക്കും, ഞങ്ങളുടെ പ്രിയപ്പെട്ട ചട്ടക്കൂടുകളുടെ പുതിയ പതിപ്പുകളിൽ നിന്ന് നിങ്ങൾ ഇത് പ്രതീക്ഷിക്കേണ്ടതില്ല.

ഈ മെറ്റീരിയലിൽ ചർച്ച ചെയ്ത ഫ്രണ്ട്-എൻഡ് ടൂളുകളിൽ ഒന്ന് ഉപയോഗിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ആകസ്മികമായി, നിങ്ങളുടെ പ്രോജക്റ്റിൻ്റെ പ്രകടനത്തിന് ദോഷം വരുത്തുന്നില്ലെന്ന് ഉറപ്പാക്കാൻ നിങ്ങൾ കൂടുതൽ ശ്രമങ്ങൾ നടത്തേണ്ടിവരുമെന്നാണ് ഇതിനർത്ഥം. നിങ്ങൾ ഒരു പുതിയ ചട്ടക്കൂട് ഉപയോഗിക്കാൻ തുടങ്ങുന്നതിനുമുമ്പ് പരിഗണിക്കേണ്ട ചില പരിഗണനകൾ ഇതാ:

• സാമാന്യബുദ്ധി ഉപയോഗിച്ച് സ്വയം പരിശോധിക്കുക. നിങ്ങൾ തിരഞ്ഞെടുത്ത ചട്ടക്കൂട് ശരിക്കും ഉപയോഗിക്കേണ്ടതുണ്ടോ? ശുദ്ധമായ ജാവാസ്ക്രിപ്റ്റിന് ഇന്ന് വളരെയധികം ചെയ്യാൻ കഴിയും.
• നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന ചട്ടക്കൂടിന് (പ്രീക്റ്റ്, സ്വെൽറ്റ് അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും പോലെ) ആ ചട്ടക്കൂടിൻ്റെ 90% കഴിവുകളും നിങ്ങൾക്ക് നൽകാൻ കഴിയുന്ന ഒരു ഭാരം കുറഞ്ഞ ബദലുണ്ടോ?
• നിങ്ങൾ ഇതിനകം ഒരു ചട്ടക്കൂടാണ് ഉപയോഗിക്കുന്നതെങ്കിൽ, മികച്ചതും കൂടുതൽ യാഥാസ്ഥിതികവും സ്റ്റാൻഡേർഡ് ഓപ്‌ഷനുകളും നൽകുന്ന എന്തെങ്കിലും ഉണ്ടോ എന്ന് ചിന്തിക്കുക (ഉദാഹരണത്തിന്, Vue-ന് പകരം Nuxt.js, React-ന് പകരം Next.js മുതലായവ).
• നിങ്ങളുടെ എന്തു ചെയ്യും ബജറ്റ് JavaScript പ്രകടനം?
• നിനക്കെങ്ങനെ കഴിയും പരിധി ഒരു പ്രോജക്റ്റിലേക്ക് കൂടുതൽ ജാവാസ്ക്രിപ്റ്റ് കോഡ് അവതരിപ്പിക്കുന്നത് തികച്ചും ആവശ്യമുള്ളതിനേക്കാൾ കൂടുതൽ ബുദ്ധിമുട്ടാക്കുന്നതിനുള്ള വികസന പ്രക്രിയ?
• വികസനത്തിൻ്റെ എളുപ്പത്തിനായി നിങ്ങൾ ഒരു ചട്ടക്കൂട് ഉപയോഗിക്കുകയാണെങ്കിൽ, പരിഗണിക്കുക നിനക്ക് വേണോ ക്ലയൻ്റുകൾക്ക് ഫ്രെയിംവർക്ക് കോഡ് അയയ്ക്കുക. ഒരുപക്ഷേ നിങ്ങൾക്ക് സെർവറിലെ എല്ലാ പ്രശ്നങ്ങളും പരിഹരിക്കാനാകുമോ?

സാധാരണയായി, ഫ്രണ്ട് എൻഡ് വികസിപ്പിക്കാൻ നിങ്ങൾ കൃത്യമായി തിരഞ്ഞെടുക്കുന്നത് പരിഗണിക്കാതെ തന്നെ, ഈ ആശയങ്ങൾ സൂക്ഷ്മമായി പരിശോധിക്കേണ്ടതാണ്. എന്നാൽ ആരംഭിക്കുന്നതിന് പ്രകടനമില്ലാത്ത ഒരു പ്രോജക്റ്റിൽ നിങ്ങൾ പ്രവർത്തിക്കുമ്പോൾ അവ വളരെ പ്രധാനമാണ്.

പ്രിയ വായനക്കാർ! അനുയോജ്യമായ JavaScript ചട്ടക്കൂടായി നിങ്ങൾ എന്താണ് കാണുന്നത്?

അവലംബം: www.habr.com