JavaScript ફ્રેમવર્કની કિંમત

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

• નેટવર્ક પર ફાઇલ અપલોડ કરી રહ્યું છે.
• ડાઉનલોડ કર્યા પછી અનપેક્ડ સોર્સ કોડને પાર્સિંગ અને કમ્પાઇલ કરવું.
• JavaScript કોડનો અમલ.
• મેમરી વપરાશ.

આ સંયોજન બહાર વળે છે ઘણું મોંઘુ.

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

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

આ પ્રોજેક્ટે મને આ સમજવામાં મદદ કરી. HTTP આર્કાઇવ.

માહિતી

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

મેં માર્ચ 2020 થી ડેટા એકત્રિત કર્યો, જે મારી પાસેનો સૌથી તાજેતરનો ડેટા હતો.

મેં તમામ સાઇટ્સ માટેના એકત્રિત HTTP આર્કાઇવ ડેટાની React, Vue અને Angular નો ઉપયોગ કરતી જોવા મળેલી સાઇટ્સ માટેના ડેટા સાથે સરખામણી કરવાનું નક્કી કર્યું, જોકે મેં અન્ય સ્રોત સામગ્રીનો પણ ઉપયોગ કરવાનું વિચાર્યું.

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

HTTP આર્કાઇવની લિંક્સ જે સાઇટ્સનું પ્રતિનિધિત્વ કરે છે જે અમને રસ ધરાવતી તકનીકોનો ઉપયોગ કરતી હોવાનું જાણવા મળ્યું છે

ફ્રેમવર્ક અથવા લાઇબ્રેરી
મોબાઇલ સાઇટ્સની લિંક્સ
નિયમિત સાઇટ્સની લિંક્સ

jQuery
4615474
3714643

પ્રતિક્રિયા
489827
241023

વ્યુ
85649
43691

કોણીય
19423
18088

આશાઓ અને સપના

અમે ડેટાનું વિશ્લેષણ કરવા આગળ વધીએ તે પહેલાં, હું જેની આશા રાખવા માંગુ છું તે વિશે વાત કરવા માંગુ છું.

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

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

શ્રેષ્ઠ ફ્રેમવર્ક એ બંને કરવું જોઈએ: સારો આધાર પૂરો પાડો, અને કાર્ય પર નિયંત્રણો લાદી જે તમને યોગ્ય પરિણામ પ્રાપ્ત કરવા દે.

ડેટાના સરેરાશ મૂલ્યોનું વિશ્લેષણ કરવાથી અમને જરૂરી માહિતી મળશે નહીં. અને, હકીકતમાં, આ અભિગમ આપણા ધ્યાનની બહાર જાય છે ઘણી બધી મહત્વપૂર્ણ વસ્તુઓ. તેના બદલે, મેં મારી પાસેના ડેટામાંથી પર્સેન્ટાઇલ સ્કોર મેળવ્યા. આ 10, 25, 50 (મધ્યમ), 75, 90 પર્સન્ટાઇલ્સ છે.

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

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 

Vue વેબસાઇટ્સ
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 

Vue વેબસાઇટ્સ
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 કોડની રકમ

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

આ ડેટા વિશે રસપ્રદ બાબત એ છે કે કેટલાક ફ્રેમવર્ક અને લાઇબ્રેરીઓ અન્ય કરતાં પ્રોજેક્ટ માટે વધુ સારા પ્રારંભિક બિંદુઓ ગણાય છે. jQuery સાથેની વેબસાઇટ્સ શ્રેષ્ઠ લાગે છે. તેમની ડેસ્કટૉપ સાઇટ્સ બધી સાઇટ્સ કરતાં 15% વધુ JavaScript ધરાવે છે, અને તેમની મોબાઇલ સાઇટ્સમાં 18% વધુ JavaScript છે. (કબૂલ છે કે, અહીંના ડેટામાં થોડી ત્રાંસી છે. હકીકત એ છે કે jQuery ઘણી સાઇટ્સ પર હાજર છે, તેથી તે સ્વાભાવિક છે કે આવી સાઇટ્સ અન્ય સાઇટ્સની કુલ સંખ્યા સાથે વધુ નજીકથી સંબંધિત છે. જો કે, આ કેવી રીતે અસર કરતું નથી. સ્ત્રોત ડેટા દરેક ફ્રેમવર્ક માટે આઉટપુટ છે.)

જ્યારે 15-18% કોડ વૃદ્ધિ એ નોંધપાત્ર આંકડો છે, જ્યારે અન્ય ફ્રેમવર્ક અને લાઇબ્રેરીઓની તુલનામાં, jQuery દ્વારા લાદવામાં આવેલ કર ઘણો ઓછો છે. 10મી પર્સન્ટાઈલમાં કોણીય સાઇટ્સ ડેસ્કટોપ ઉપકરણોને બધી સાઇટ્સ કરતાં 344% વધુ ડેટા મોકલે છે, અને મોબાઇલ ઉપકરણો પર 377% વધુ. રિએક્ટ સાઇટ્સ એ પછીની સૌથી ભારે છે, જે બધી સાઇટ્સ કરતાં ડેસ્કટૉપ ડિવાઇસ પર 193% વધુ કોડ મોકલે છે અને મોબાઇલ ડિવાઇસ પર 270% વધુ કોડ મોકલે છે.

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

રસપ્રદ વાત એ છે કે jQuery સાઇટ્સ આ વિચારને અનુસરે છે. તેમ છતાં, તેઓ, 10મી પર્સન્ટાઈલ સ્તરે, બધી સાઇટ્સ કરતાં સહેજ ભારે હોય છે (15-18% દ્વારા), તેઓ, 90મા પર્સન્ટાઈલ સ્તરે, બધી સાઇટ્સ કરતાં સહેજ હળવા હોય છે - ડેસ્કટૉપ અને મોબાઇલ વર્ઝન બંનેમાં લગભગ 3%. આનો અર્થ એ નથી કે આ એક ખૂબ જ નોંધપાત્ર લાભ છે, પરંતુ એવું કહી શકાય કે jQuery સાઇટ્સ પાસે તેમના સૌથી મોટા સંસ્કરણોમાં પણ ઓછામાં ઓછા વિશાળ JavaScript કોડ કદ નથી.

પરંતુ તે જ અન્ય માળખા વિશે કહી શકાય નહીં.

જેમ 10મી પર્સેન્ટાઈલના કિસ્સામાં, એંગ્યુલર અને રિએક્ટ પરની 90મી પર્સેન્ટાઈલ સાઇટ્સ અન્ય સાઇટ્સથી અલગ છે, પરંતુ કમનસીબે, વધુ ખરાબ માટે તેઓ અલગ છે.

90મી પર્સેન્ટાઇલ પર, એંગ્યુલર સાઇટ્સ તમામ સાઇટ્સ કરતાં મોબાઇલ ડિવાઇસ પર 141% વધુ ડેટા અને ડેસ્કટૉપ ડિવાઇસ પર 159% વધુ ડેટા મોકલે છે. રિએક્ટ સાઇટ્સ બધી સાઇટ્સ કરતાં ડેસ્કટૉપ ડિવાઇસ પર 73% વધુ અને મોબાઇલ ડિવાઇસ પર 58% વધુ મોકલે છે. 90મી પર્સેન્ટાઇલ પર પ્રતિક્રિયા સાઇટ્સનું કોડ કદ 2197.8 KB છે. આનો અર્થ એ છે કે આ સાઇટ્સ તેમના નજીકના Vue-આધારિત સ્પર્ધકો કરતાં મોબાઇલ ઉપકરણો પર 322.9 KB વધુ ડેટા મોકલે છે. એંગ્યુલર અને રિએક્ટ અને અન્ય સાઇટ્સ પર આધારિત ડેસ્કટોપ સાઇટ્સ વચ્ચેનું અંતર હજી વધારે છે. ઉદાહરણ તરીકે, રિએક્ટ ડેસ્કટોપ સાઇટ્સ સમાન Vue સાઇટ્સ કરતાં ઉપકરણોને 554.7 KB વધુ JS કોડ મોકલે છે.

મુખ્ય થ્રેડ પર 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

Vue વેબસાઇટ્સ
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

Vue વેબસાઇટ્સ
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 પર પ્રક્રિયા કરવામાં નોંધપાત્ર રીતે ઓછો ખર્ચ કરે છે. 10મી પર્સેન્ટાઇલ પર, બધી સાઇટ્સની તુલનામાં, મોબાઇલ ઉપકરણો પરની jQuery સાઇટ્સ મુખ્ય થ્રેડ પર JS કોડની પ્રક્રિયા કરવામાં 61% વધુ સમય વિતાવે છે. ડેસ્કટોપ jQuery સાઇટ્સના કિસ્સામાં, પ્રક્રિયા સમય 37% વધે છે. 90મી પર્સેન્ટાઇલ પર, jQuery સાઇટ્સના સ્કોર્સ એકંદર સ્કોર્સની ખૂબ નજીક છે. ખાસ કરીને, મોબાઇલ ઉપકરણો પરની jQuery સાઇટ્સ મુખ્ય થ્રેડમાં તમામ સાઇટ્સ કરતાં 1.3% ઓછો સમય વિતાવે છે, અને ડેસ્કટોપ ઉપકરણો પર તેઓ મુખ્ય થ્રેડમાં 0.7% ઓછો સમય વિતાવે છે.

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

10મી પર્સેન્ટાઇલ પર, કોણીય ડેસ્કટોપ સાઇટ્સ તમામ સાઇટ્સ કરતાં JS કોડની પ્રક્રિયા કરવામાં 230% વધુ સમય પસાર કરે છે. મોબાઇલ સાઇટ્સ માટે આ આંકડો 313% છે. પ્રતિક્રિયા સાઇટ્સનું પ્રદર્શન સૌથી ખરાબ છે. ડેસ્કટૉપ ઉપકરણો પર તેઓ બધી સાઇટ્સ કરતાં 248% વધુ સમય કોડ પ્રોસેસિંગમાં વિતાવે છે, અને મોબાઇલ ઉપકરણો પર તેઓ કોડ પ્રોસેસિંગમાં 658% વધુ સમય વિતાવે છે. 658% એ ટાઈપો નથી. 10મી પર્સેન્ટાઈલ પર, રીએક્ટ સાઇટ્સ તેમના હાલના કોડ પર પ્રક્રિયા કરવામાં મુખ્ય થ્રેડ સમયની 2.7 સેકન્ડનો ખર્ચ કરે છે.

આ વિશાળ સંખ્યાઓની સરખામણીમાં 90મી પર્સેન્ટાઇલ સંખ્યાઓ ઓછામાં ઓછી થોડી સારી દેખાય છે. તમામ સાઇટ્સની તુલનામાં કોણીય પ્રોજેક્ટ્સ, ડેસ્કટોપ ઉપકરણો પર મુખ્ય થ્રેડમાં 29% વધુ સમય અને મોબાઇલ ઉપકરણો પર 27% વધુ સમય વિતાવે છે. પ્રતિક્રિયા સાઇટ્સના કિસ્સામાં, સમાન સૂચકાંકો અનુક્રમે 130% અને 98% જેવા દેખાય છે.

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

અહીં એક સંભવિત ગૂંચવણ છે (આભાર યર્મિયા આ સુવિધા તરફ મારું ધ્યાન દોરવા માટે અને આ દૃષ્ટિકોણથી ડેટાની કાળજીપૂર્વક તપાસ કરવા બદલ). હકીકત એ છે કે ઘણી સાઇટ્સ ઘણા ફ્રન્ટ-એન્ડ ટૂલ્સનો ઉપયોગ કરે છે. ખાસ કરીને, મેં ઘણી બધી સાઇટ્સ React અથવા Vue ની સાથે jQuery નો ઉપયોગ કરતી જોઈ છે કારણ કે આ સાઇટ્સ 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

વેબસાઇટ્સ કે જે ફક્ત પ્રતિક્રિયાનો ઉપયોગ કરે છે
2443.2
4620.5
10061.4
17074.3
24956.3

મોબાઇલ ઉપકરણો પર પ્રોસેસિંગ સ્ક્રિપ્ટ સાથે સંબંધિત પ્રોસેસર સમય એવી પરિસ્થિતિમાં કે જ્યાં સાઇટ્સ માત્ર એક ફ્રેમવર્ક અથવા માત્ર એક લાઇબ્રેરીનો ઉપયોગ કરે છે

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

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

આ થોડું વિચિત્ર છે, પરંતુ હું હજી પણ આ વિચિત્રતા માટે સમજૂતી શોધવાનો પ્રયત્ન કરીશ.

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

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

મોબાઇલ અને ડેસ્કટોપ ઉપકરણો વચ્ચેનું અંતર

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

પરંતુ જો તમે કોડ પર પ્રક્રિયા કરવા માટે જરૂરી સમયનું વિશ્લેષણ કરો છો, તો મોબાઇલ અને ડેસ્કટોપ ઉપકરણો વચ્ચેનું ખૂબ મોટું અંતર નોંધનીય બને છે.

ડેસ્કટોપની તુલનામાં મોબાઇલ ઉપકરણો પર સ્ક્રિપ્ટ પ્રોસેસિંગ સંબંધિત સમય (ટકાવારીમાં) વધારો

ટકાવારી
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

Vue વેબસાઇટ્સ
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મી પર્સેન્ટાઇલ પર પણ, રિએક્ટ સાઇટ્સ ડેસ્કટૉપ મુખ્ય થ્રેડ કરતાં મોબાઇલ મુખ્ય થ્રેડ પર 431.5% વધુ સમય વિતાવે છે. jQuery માં સૌથી નાનું અંતર છે, પરંતુ અહીં પણ અનુરૂપ આંકડો 188.2% છે. જ્યારે વેબસાઈટ ડેવલપર્સ તેમના પ્રોજેક્ટ્સ એવી રીતે બનાવે છે કે તેમને પ્રક્રિયા કરવા માટે વધુ CPU સમયની જરૂર પડે છે (અને આવું જ થાય છે, અને તે સમય જતાં વધુ ખરાબ થાય છે), ઓછા-પાવર ઉપકરણોના માલિકોએ તેના માટે ચૂકવણી કરવી પડે છે.

પરિણામો

સારા માળખાએ વિકાસકર્તાઓને વેબ પ્રોજેક્ટ બનાવવા માટે સારો પાયો આપવો જોઈએ (સુરક્ષા, ઍક્સેસિબિલિટી, પ્રદર્શનની દ્રષ્ટિએ), અથવા બિલ્ટ-ઇન પ્રતિબંધો હોવા જોઈએ જે તે પ્રતિબંધોનું ઉલ્લંઘન કરતી કંઈક બનાવવાનું મુશ્કેલ બનાવે છે.

આ વેબ પ્રોજેક્ટ્સના પ્રદર્શનને લાગુ પડતું નથી લાગતું (અને દેખીતી રીતે તેમના પર ઉપલ્બધતા).

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

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

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

યોગ્ય પરિસ્થિતિઓમાં કેટલાક સમાધાન કરવું શક્ય છે, પરંતુ વિકાસકર્તાઓ સભાનપણે આવા સમાધાન કરે તે મહત્વપૂર્ણ છે.

પરંતુ અમારી પાસે આશાવાદનું કારણ પણ છે. તે ટૂલ્સના પ્રદર્શનને બહેતર બનાવવામાં મદદ કરવા માટે અમે આવરી લીધેલા કેટલાક ફ્રન્ટ-એન્ડ ટૂલ્સ પાછળના લોકો સાથે Chrome ડેવલપર્સ કેટલી નજીકથી કામ કરી રહ્યા છે તેનાથી હું પ્રોત્સાહિત છું.

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

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

• તમારી જાતને સામાન્ય સમજ સાથે તપાસો. શું તમારે ખરેખર તમારા પસંદ કરેલા ફ્રેમવર્કનો ઉપયોગ કરવાની જરૂર છે? શુદ્ધ JavaScript આજે ઘણું કરી શકે છે.
• શું તમારી પસંદગીના ફ્રેમવર્કનો હળવો વિકલ્પ છે (જેમ કે પ્રેક્ટ, સ્વેલ્ટ અથવા બીજું કંઈક) જે તમને તે ફ્રેમવર્કની 90% ક્ષમતાઓ આપી શકે?
• જો તમે પહેલાથી જ ફ્રેમવર્કનો ઉપયોગ કરી રહ્યાં હોવ, તો વિચારો કે શું એવું કંઈક છે જે વધુ સારા, વધુ રૂઢિચુસ્ત, માનક વિકલ્પો પ્રદાન કરે છે (ઉદાહરણ તરીકે, Vue ને બદલે Nuxt.js, React ને બદલે Next.js, વગેરે).
• શું કરશે તમારું બજેટ જાવાસ્ક્રિપ્ટ પ્રદર્શન?
• તમે કેવી રીતે કરી શકો મર્યાદા પ્રોજેક્ટમાં એકદમ જરૂરી કરતાં વધુ JavaScript કોડ દાખલ કરવાનું વધુ મુશ્કેલ બનાવવા માટે વિકાસ પ્રક્રિયા?
• જો તમે વિકાસની સરળતા માટે ફ્રેમવર્કનો ઉપયોગ કરી રહ્યાં છો, તો ધ્યાનમાં લો તમને જરૂર છે ગ્રાહકોને ફ્રેમવર્ક કોડ મોકલો. કદાચ તમે સર્વર પરની બધી સમસ્યાઓ હલ કરી શકો છો?

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

પ્રિય વાચકો! તમે આદર્શ JavaScript ફ્રેમવર્ક તરીકે શું જુઓ છો?

સોર્સ: www.habr.com