JavaScript फ्रेमवर्कची किंमत

वेबसाइट धीमा करण्याचा कोणताही वेगवान मार्ग नाही (कोणत्याही श्लेषाचा हेतू नाही) त्यावर JavaScript कोडचा समूह चालवण्यापेक्षा. JavaScript वापरताना, तुम्हाला किमान चार वेळा प्रोजेक्ट परफॉर्मन्समध्ये त्यासाठी पैसे द्यावे लागतील. साइटचा JavaScript कोड वापरकर्त्यांच्या सिस्टमला कशासह लोड करतो ते येथे आहे:

• नेटवर्कवर फाइल डाउनलोड करत आहे.
• डाउनलोड केल्यानंतर अनपॅक केलेला स्त्रोत कोड पार्स करणे आणि संकलित करणे.
• JavaScript कोडची अंमलबजावणी.
• मेमरी वापर.

हे संयोजन बाहेर वळते खूप महागडे.

आणि आम्ही आमच्या प्रकल्पांमध्ये अधिकाधिक JS कोड समाविष्ट करत आहोत. संस्था फ्रेमवर्क आणि लायब्ररी जसे की React, Vue आणि इतरांद्वारे समर्थित साइटकडे जात असताना, आम्ही साइट्सची मुख्य कार्यक्षमता JavaScript वर खूप अवलंबून करत आहोत.

मी JavaScript फ्रेमवर्क वापरून खूप भारी साइट्स पाहिल्या आहेत. परंतु या प्रकरणाकडे पाहण्याची माझी दृष्टी फारच पक्षपाती आहे. वस्तुस्थिती अशी आहे की मी ज्या कंपन्यांसोबत काम करतो त्या तंतोतंत माझ्याकडे वळतात कारण त्यांना साइटच्या कामगिरीच्या क्षेत्रात जटिल समस्यांचा सामना करावा लागतो. परिणामी, ही समस्या किती सामान्य आहे याबद्दल आणि एखाद्या विशिष्ट साइटसाठी आधार म्हणून आम्ही एक किंवा दुसरी फ्रेमवर्क निवडतो तेव्हा आम्ही कोणत्या प्रकारचे "दंड" भरतो याबद्दल मला उत्सुकता निर्माण झाली.

प्रकल्पाने मला हे समजण्यास मदत केली. HTTP संग्रह.

डेटा

HTTP संग्रहण प्रकल्प नियमित डेस्कटॉप साइट्सच्या एकूण 4308655 लिंक्स आणि मोबाइल साइट्सच्या 5484239 लिंक्सचा मागोवा घेते. या लिंक्सशी संबंधित अनेक मेट्रिक्समध्ये संबंधित साइट्सवर सापडलेल्या तंत्रज्ञानाची यादी आहे. याचा अर्थ आम्ही विविध फ्रेमवर्क आणि लायब्ररी वापरणार्‍या हजारो साइट्सचे नमुने घेऊ शकतो आणि ते क्लायंटला किती कोड पाठवतात आणि वापरकर्त्यांच्या सिस्टमवर हा कोड किती लोड करतो हे जाणून घेऊ शकतो.

मी मार्च 2020 चा डेटा गोळा केला, जो माझ्याकडे अ‍ॅक्सेस असलेला सर्वात अलीकडील डेटा होता.

मी सर्व साइटवरील एकत्रित HTTP संग्रहण डेटाची तुलना React, Vue आणि Angular वापरून आढळलेल्या साइट्सच्या डेटाशी करण्याचे ठरवले, जरी मी इतर स्त्रोत सामग्री वापरण्याचा विचार केला.

ते अधिक मनोरंजक बनवण्यासाठी, मी स्त्रोत डेटा सेटमध्ये jQuery वापरणाऱ्या साइट्स देखील जोडल्या आहेत. हे लायब्ररी अजूनही खूप लोकप्रिय आहे. हे React, Vue आणि Angular द्वारे ऑफर केलेल्या सिंगल पेज अॅप्लिकेशन (SPA) मॉडेलपेक्षा वेब डेव्हलपमेंटसाठी भिन्न दृष्टीकोन देखील सादर करते.

HTTP आर्काइव्हमधील दुवे ज्या साइट्सना स्वारस्य असलेल्या तंत्रज्ञानाचा वापर करत असल्याचे आढळले आहे

फ्रेमवर्क किंवा लायब्ररी
मोबाइल साइट्सच्या लिंक्स
नियमित साइट्सचे दुवे

jQuery
4615474
3714643

प्रतिक्रिया द्या
489827
241023

व्ह्यू
85649
43691

टोकदार
19423
18088

आशा आणि स्वप्नं

आम्ही डेटा विश्लेषणाकडे जाण्यापूर्वी, मला कशाची आशा आहे याबद्दल मला बोलायचे आहे.

मला विश्वास आहे की आदर्श जगात, फ्रेमवर्क विकासकांच्या गरजा पूर्ण करतील आणि आमच्या साइटच्या दैनंदिन वापरकर्त्यांना काही ठोस फायदे प्रदान करतील. उत्पादकता हा त्यापैकी फक्त एक फायदा आहे. येथे प्रवेशयोग्यता आणि सुरक्षितता देखील लक्षात येते. पण ही फक्त सर्वात महत्वाची गोष्ट आहे.

म्हणून, आदर्श जगात, काही प्रकारच्या फ्रेमवर्कने उच्च-कार्यक्षमता साइट तयार करणे सोपे केले पाहिजे. हे एकतर या वस्तुस्थितीमुळे केले पाहिजे की फ्रेमवर्क विकासकाला प्रकल्प तयार करण्यासाठी एक सभ्य आधार देते किंवा ते विकासावर निर्बंध लादते या वस्तुस्थितीमुळे, वळणावळणाच्या विकासास गुंतागुंतीचे बनवणाऱ्या आवश्यकता पुढे ठेवते. मंद होण्यासाठी बाहेर.

सर्वोत्कृष्ट फ्रेमवर्कने दोन्ही गोष्टी केल्या पाहिजेत: एक चांगला आधार द्या आणि कामावर निर्बंध लादणे, ज्यामुळे तुम्हाला एक सभ्य परिणाम मिळू शकेल.

डेटाच्या मध्यवर्ती मूल्यांचे विश्लेषण केल्याने आम्हाला आवश्यक असलेली माहिती मिळणार नाही. आणि, खरं तर, हा दृष्टीकोन आपल्या लक्षाबाहेर जातो खूप महत्वाचे. त्याऐवजी, मी माझ्याकडे असलेल्या डेटामधून टक्केवारी काढली. हे 10, 25, 50 (मध्यम), 75, 90 पर्सेंटाइल आहेत.

मला 10वी आणि 90वीच्या पर्सेंटाइलमध्ये विशेष रस आहे. 10 वी पर्सेंटाइल विशिष्ट फ्रेमवर्कसाठी सर्वोत्तम कामगिरीचे (किंवा कमीत कमी अधिक किंवा कमी जवळ) प्रतिनिधित्व करते. दुसऱ्या शब्दांत, याचा अर्थ असा आहे की विशिष्ट फ्रेमवर्क वापरणार्‍या केवळ 10% साइट्स या स्तरावर किंवा उच्च स्तरावर पोहोचतात. दुसरीकडे, 90 व्या टक्केवारी ही नाण्याची दुसरी बाजू आहे - ती आपल्याला दर्शवते की गोष्टी किती वाईट असू शकतात. 90 व्या पर्सेंटाइल ही अनुगामी साइट्स आहेत—त्या शेवटच्या 10% साइट्स ज्यांच्याकडे सर्वात जास्त JS कोड आहे किंवा त्यांच्या कोडवर मुख्य थ्रेडवर प्रक्रिया करण्यासाठी सर्वात जास्त वेळ लागतो.

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 

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% अधिक असते. (कबूल आहे की, येथे काही डेटा करप्ट आहे. वस्तुस्थिती अशी आहे की jQuery अनेक साइट्सवर उपस्थित आहे, त्यामुळे अशा साइट्स एकूण साइट्सच्या तुलनेत इतरांपेक्षा अधिक जवळून संबंधित आहेत हे स्वाभाविक आहे. तथापि, हे किती कच्चे आहे यावर परिणाम होत नाही. डेटा प्रत्येक फ्रेमवर्कसाठी आउटपुट आहे.)

कोड व्हॉल्यूममध्ये 15-18% वाढ ही एक उल्लेखनीय आकडेवारी आहे, इतर फ्रेमवर्क आणि लायब्ररींशी याची तुलना केल्यास, jQuery द्वारे आकारला जाणारा "कर" खूपच कमी आहे असा निष्कर्ष काढू शकतो. 10 व्या पर्सेंटाइलमधील कोनीय साइट सर्व साइट्सपेक्षा डेस्कटॉपवर 344% अधिक डेटा आणि मोबाइलवर 377% अधिक डेटा पाठवतात. प्रतिक्रिया साइट्स या पुढील सर्वात वजनदार आहेत, सर्व साइट्सपेक्षा 193% अधिक कोड डेस्कटॉपवर आणि 270% अधिक मोबाइलवर पाठवतात.

यापूर्वी, मी नमूद केले आहे की फ्रेमवर्क वापरण्याचा अर्थ असा आहे की प्रकल्पामध्ये विशिष्ट प्रमाणात कोड समाविष्ट केला जाईल, त्यावरील कामाच्या अगदी सुरुवातीस, मला आशा आहे की फ्रेमवर्क विकासकाला कसा तरी मर्यादित करण्यास सक्षम आहे. विशेषतः, आम्ही कोडची कमाल रक्कम मर्यादित करण्याबद्दल बोलत आहोत.

विशेष म्हणजे jQuery साइट या कल्पनेचे अनुसरण करतात. ते 10व्या पर्सेंटाइलवर (15-18%) सर्व साइट्सपेक्षा किंचित जड असले तरी, ते डेस्कटॉप आणि मोबाइल दोन्हीवर 90व्या पर्सेंटाइलवर 3% वर थोडे हलके आहेत. याचा अर्थ असा नाही की हा एक अतिशय महत्त्वाचा फायदा आहे, परंतु असे म्हटले जाऊ शकते की jQuery साइट्समध्ये, त्यांच्या सर्वात मोठ्या आवृत्त्यांमध्येही, जावास्क्रिप्ट कोडचे मोठे आकार नसतात.

परंतु इतर फ्रेमवर्कबद्दल असेच म्हणता येणार नाही.

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 वर प्रक्रिया करण्यासाठी किती वेळ लागतो हे शोधू शकतो.

मोबाइल डिव्हाइसवरील स्क्रिप्ट प्रक्रियेशी संबंधित प्रोसेसर वेळ (मिलिसेकंदांमध्ये).

टक्केवारी
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

मोबाइल उपकरणांवर स्क्रिप्ट प्रक्रियेशी संबंधित प्रोसेसर वेळ

डेस्कटॉप उपकरणांवर स्क्रिप्ट प्रक्रियेशी संबंधित प्रोसेसर वेळ (मिलिसेकंदांमध्ये).

टक्केवारी
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

डेस्कटॉप उपकरणांवर स्क्रिप्ट प्रक्रियेशी संबंधित प्रोसेसर वेळ

येथे आपण खूप परिचित काहीतरी पाहू शकता.

सुरुवातीच्यासाठी, 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% सारखे दिसतात.

90 व्या पर्सेंटाइलसाठी टक्केवारीचे विचलन 10 व्या पर्सेंटाइलसाठी समान मूल्यांपेक्षा चांगले दिसतात. परंतु येथे हे लक्षात ठेवण्यासारखे आहे की वेळ दर्शविणारी संख्या त्याऐवजी भयानक वाटते. React सह तयार केलेल्या वेबसाइटसाठी मुख्य मोबाइल थ्रेडवर 20.8 सेकंद म्हणू. (माझ्या मते या काळात प्रत्यक्षात काय घडते याची कथा एका स्वतंत्र लेखास पात्र आहे).

येथे एक संभाव्य गुंतागुंत आहे (धन्यवाद यिर्मया या वैशिष्ट्याकडे माझे लक्ष वेधण्यासाठी आणि या दृष्टिकोनातून डेटाचा काळजीपूर्वक विचार केल्याबद्दल). वस्तुस्थिती अशी आहे की अनेक साइट अनेक फ्रंट-एंड टूल्स वापरतात. विशेषतः, मी React किंवा Vue सोबत jQuery वापरत असलेल्या बर्‍याच साइट्स पाहिल्या आहेत, कारण त्या साइट्स jQuery वरून इतर फ्रेमवर्क किंवा लायब्ररीमध्ये स्थलांतरित होत आहेत. परिणामी, मी पुन्हा डेटाबेस दाबला, यावेळी फक्त प्रतिक्रिया, 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 आणि jQuery दोन्ही वापरत असेल, तर तो प्रोजेक्ट बहुधा jQuery वरून React मध्ये स्थलांतरित होण्याच्या प्रक्रियेत अर्धवट असेल. कदाचित त्याच्याकडे कोडबेस आहे ज्यामध्ये ही लायब्ररी मिसळलेली आहेत. आम्ही आधीच पाहिले आहे की jQuery साइट्स प्रतिक्रिया साइट्सपेक्षा मुख्य थ्रेडवर कमी वेळ घालवतात, हे आम्हाला सांगू शकते की jQuery मध्ये काही कार्यक्षमता लागू केल्याने साइट कार्यप्रदर्शन थोडे सुधारण्यास मदत होते.

पण प्रकल्प jQuery वरून React मध्ये बदलत असताना आणि 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

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