जावास्क्रिप्ट ढांचे की कीमत

किसी वेबसाइट को धीमा करने का उस पर ढेर सारे जावास्क्रिप्ट कोड चलाने से तेज़ कोई तरीका नहीं है (कोई मज़ाक नहीं)। जावास्क्रिप्ट का उपयोग करते समय, आपको प्रोजेक्ट प्रदर्शन में इसके लिए कम से कम चार बार भुगतान करना होगा। यहां बताया गया है कि साइट का जावास्क्रिप्ट कोड उपयोगकर्ताओं के सिस्टम को किससे लोड करता है:

• नेटवर्क पर फ़ाइल अपलोड करना.
• डाउनलोड करने के बाद अनपैक्ड सोर्स कोड को पार्स करना और संकलित करना।
• जावास्क्रिप्ट कोड निष्पादित करना।
• मेमोरी खपत.

यह संयोजन बनता है बहुत महँगा.

और हम अपनी परियोजनाओं में अधिक से अधिक जेएस कोड शामिल कर रहे हैं। जैसे-जैसे संगठन रिएक्ट, व्यू और अन्य जैसे फ्रेमवर्क और लाइब्रेरी द्वारा संचालित साइटों की ओर बढ़ रहे हैं, हम साइटों की मुख्य कार्यक्षमता को जावास्क्रिप्ट पर बहुत अधिक निर्भर बना रहे हैं।

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

इस प्रोजेक्ट ने मुझे यह पता लगाने में मदद की। HTTP संग्रह.

डेटा

HTTP आर्काइव प्रोजेक्ट नियमित डेस्कटॉप साइटों के लिए कुल 4308655 लिंक और मोबाइल साइटों के लिए 5484239 लिंक ट्रैक करता है। इन लिंकों से जुड़े कई संकेतकों में से संबंधित साइटों पर पाई जाने वाली प्रौद्योगिकियों की एक सूची है। इसका मतलब है कि हम उन हजारों साइटों का नमूना ले सकते हैं जो विभिन्न ढांचे और पुस्तकालयों का उपयोग करते हैं और सीखते हैं कि वे ग्राहकों को कितना कोड भेजते हैं और वह कोड उपयोगकर्ताओं के सिस्टम पर कितना लोड डालता है।

मैंने मार्च 2020 से डेटा एकत्र किया, जो कि मेरी पहुंच का सबसे हालिया डेटा था।

मैंने सभी साइटों के लिए एकत्रित HTTP संग्रह डेटा की तुलना रिएक्ट, व्यू और एंगुलर का उपयोग करने वाली साइटों के डेटा से करने का निर्णय लिया, हालांकि मैंने अन्य स्रोत सामग्री का उपयोग करने पर भी विचार किया।

इसे और अधिक रोचक बनाने के लिए, मैंने स्रोत डेटा सेट में jQuery का उपयोग करने वाली साइटें भी जोड़ीं। यह लाइब्रेरी आज भी बहुत लोकप्रिय है. यह वेबसाइट विकास के लिए एक दृष्टिकोण भी पेश करता है जो रिएक्ट, व्यू और एंगुलर द्वारा पेश किए गए सिंगल पेज एप्लिकेशन (एसपीए) मॉडल से अलग है।

HTTP संग्रह में लिंक उन साइटों का प्रतिनिधित्व करते हैं जो हमारी रुचि की प्रौद्योगिकियों का उपयोग करते हुए पाए गए हैं

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

jQuery
4615474
3714643

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

Vue
85649
43691

कोणीय
19423
18088

उम्मीदें और सपने

इससे पहले कि हम डेटा का विश्लेषण करने के लिए आगे बढ़ें, मैं इस बारे में बात करना चाहता हूं कि मैं क्या आशा करना चाहता हूं।

मेरा मानना ​​है कि एक आदर्श दुनिया में, फ्रेमवर्क डेवलपर्स की जरूरतों को पूरा करने से आगे बढ़ जाएगा और हमारी साइटों के रोजमर्रा के उपयोगकर्ताओं को कुछ ठोस लाभ प्रदान करेगा। उत्पादकता उन लाभों में से एक है। यहां पहुंच और सुरक्षा का भी ख्याल आता है। लेकिन यही सबसे महत्वपूर्ण बात है.

इसलिए, एक आदर्श दुनिया में, किसी प्रकार की रूपरेखा से उच्च-प्रदर्शन वाली वेबसाइट बनाना आसान हो जाना चाहिए। यह या तो इस तथ्य के कारण किया जाना चाहिए कि ढांचा डेवलपर को एक परियोजना बनाने के लिए एक सभ्य आधार देता है, या इस तथ्य के कारण कि यह विकास पर प्रतिबंध लगाता है, इसके लिए आवश्यकताओं को सामने रखता है जिससे कुछ विकसित करना मुश्किल हो जाता है। वह धीमा हो जाता है।

सर्वोत्तम ढांचे को दोनों काम करने चाहिए: एक अच्छा आधार प्रदान करना, और उस काम पर प्रतिबंध लगाना जो आपको एक अच्छा परिणाम प्राप्त करने की अनुमति देता है।

डेटा के औसत मूल्यों का विश्लेषण करने से हमें वह जानकारी नहीं मिलेगी जिसकी हमें आवश्यकता है। और, वास्तव में, यह दृष्टिकोण हमारे ध्यान से परे चला जाता है बहुत सी महत्वपूर्ण बातें. इसके बजाय, मेरे पास मौजूद डेटा से मैंने प्रतिशत अंक प्राप्त किए। ये 10, 25, 50 (माध्यिका), 75, 90 प्रतिशतक हैं।

मुझे विशेष रूप से 10वें और 90वें प्रतिशतक में रुचि है। 10वां प्रतिशत किसी विशेष ढांचे के लिए सर्वोत्तम प्रदर्शन (या कम से कम सर्वोत्तम के करीब) का प्रतिनिधित्व करता है। दूसरे शब्दों में, इसका मतलब यह है कि किसी विशेष ढांचे का उपयोग करने वाली केवल 10% साइटें ही इस स्तर या उच्च स्तर तक पहुंचती हैं। दूसरी ओर, 90वां प्रतिशतक सिक्के का दूसरा पहलू है - यह हमें दिखाता है कि चीजें कितनी बुरी हो सकती हैं। 90वां प्रतिशत अनुगामी साइटें हैं - वे अंतिम 10% साइटें जिनमें जेएस कोड की सबसे बड़ी मात्रा है या मुख्य थ्रेड पर उनके कोड को संसाधित करने के लिए सबसे लंबा समय आवश्यक है।

जावास्क्रिप्ट कोड की मात्रा

आरंभ करने के लिए, नेटवर्क पर विभिन्न साइटों द्वारा प्रसारित जावास्क्रिप्ट कोड के आकार का विश्लेषण करना समझ में आता है।

मोबाइल उपकरणों पर स्थानांतरित जावास्क्रिप्ट कोड (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 

मोबाइल उपकरणों पर भेजे गए जावास्क्रिप्ट कोड की मात्रा

डेस्कटॉप डिवाइस पर स्थानांतरित जावास्क्रिप्ट कोड (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 

डेस्कटॉप डिवाइसों पर स्थानांतरित जावास्क्रिप्ट कोड की मात्रा

यदि हम केवल जेएस कोड के आकार के बारे में बात करते हैं जो साइटें उपकरणों को भेजती हैं, तो सब कुछ वैसा ही दिखता है जैसा आप उम्मीद कर सकते हैं। अर्थात्, यदि किसी एक फ्रेमवर्क का उपयोग किया जाता है, तो इसका मतलब है कि आदर्श स्थिति में भी, साइट के लिए जावास्क्रिप्ट कोड की मात्रा बढ़ जाएगी। यह आश्चर्य की बात नहीं है - आप एक जावास्क्रिप्ट ढांचे को किसी साइट का आधार नहीं बना सकते हैं और उम्मीद कर सकते हैं कि परियोजना के लिए जेएस कोड की मात्रा बहुत कम होगी।

इस डेटा के बारे में दिलचस्प बात यह है कि कुछ फ्रेमवर्क और लाइब्रेरी को दूसरों की तुलना में किसी प्रोजेक्ट के लिए बेहतर शुरुआती बिंदु माना जा सकता है। jQuery वाली वेबसाइटें सबसे अच्छी लगती हैं। उनकी डेस्कटॉप साइटों में सभी साइटों की तुलना में 15% अधिक जावास्क्रिप्ट है, और उनकी मोबाइल साइटों में 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 कोड भेजती हैं।

मुख्य थ्रेड पर जावास्क्रिप्ट कोड को संसाधित करने में लगने वाला समय

उपरोक्त डेटा स्पष्ट रूप से इंगित करता है कि अध्ययन किए गए फ्रेमवर्क और लाइब्रेरी का उपयोग करने वाली साइटों में बड़ी मात्रा में जावास्क्रिप्ट कोड हैं। लेकिन, निःसंदेह, यह हमारे समीकरण का केवल एक हिस्सा है।

ब्राउज़र में जावास्क्रिप्ट कोड आने के बाद इसे कार्यशील स्थिति में लाना होगा। विशेष रूप से कई समस्याएं उन कार्यों के कारण होती हैं जिन्हें मुख्य ब्राउज़र थ्रेड में कोड के साथ किया जाना होता है। मुख्य थ्रेड उपयोगकर्ता क्रियाओं को संसाधित करने, शैलियों की गणना करने और पेज लेआउट बनाने और प्रदर्शित करने के लिए जिम्मेदार है। यदि आप मुख्य थ्रेड को जावास्क्रिप्ट कार्यों से भर देते हैं, तो उसे अन्य कार्यों को समय पर पूरा करने का अवसर नहीं मिलेगा। इससे पृष्ठों के संचालन में देरी और "ब्रेक" लग जाता है।

HTTP पुरालेख डेटाबेस में यह जानकारी होती है कि V8 इंजन के मुख्य थ्रेड पर जावास्क्रिप्ट कोड को संसाधित करने में कितना समय लगता है। इसका मतलब है कि हम यह डेटा एकत्र कर सकते हैं और जान सकते हैं कि मुख्य थ्रेड को विभिन्न साइटों की जावास्क्रिप्ट को संसाधित करने में कितना समय लगता है।

मोबाइल उपकरणों पर स्क्रिप्ट प्रोसेसिंग से संबंधित सीपीयू समय (मिलीसेकंड में)।

प्रतिशतक
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

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

डेस्कटॉप डिवाइस पर स्क्रिप्ट प्रोसेसिंग से संबंधित सीपीयू समय (मिलीसेकंड में)।

प्रतिशतक
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

डेस्कटॉप डिवाइस पर स्क्रिप्ट प्रोसेसिंग से संबंधित सीपीयू समय

यहां आप कुछ बहुत ही परिचित चीज़ देख सकते हैं।

शुरुआत के लिए, jQuery वाली साइटें अन्य की तुलना में मुख्य थ्रेड पर जावास्क्रिप्ट को संसाधित करने में काफी कम खर्च करती हैं। 10वें प्रतिशत पर, सभी साइटों की तुलना में, मोबाइल उपकरणों पर jQuery साइटें मुख्य थ्रेड पर JS कोड को संसाधित करने में 61% अधिक समय खर्च करती हैं। डेस्कटॉप jQuery साइटों के मामले में, प्रसंस्करण समय 37% बढ़ जाता है। 90वें प्रतिशतक पर, jQuery साइटों के स्कोर कुल स्कोर के बहुत करीब हैं। विशेष रूप से, मोबाइल डिवाइस पर jQuery साइटें सभी साइटों की तुलना में मुख्य थ्रेड में 1.3% कम समय बिताती हैं, और डेस्कटॉप डिवाइस पर वे मुख्य थ्रेड में 0.7% कम समय बिताती हैं।

हमारी रेटिंग के दूसरी तरफ ऐसे फ्रेमवर्क हैं जिनकी विशेषता मुख्य थ्रेड पर सबसे बड़ा भार है। यह, फिर से, एंगुलर और रिएक्ट है। उनके बीच एकमात्र अंतर यह है कि हालांकि एंगुलर साइटें रिएक्ट साइटों की तुलना में ब्राउज़रों को बड़ी मात्रा में कोड भेजती हैं, एंगुलर साइटों के कोड को संसाधित करने में कम सीपीयू समय लगता है। अब तक कम।

10वें प्रतिशत पर, एंगुलर डेस्कटॉप साइटें सभी साइटों की तुलना में जेएस कोड को संसाधित करने में 230% अधिक मुख्य थ्रेड समय खर्च करती हैं। मोबाइल साइटों के लिए यह आंकड़ा 313% है। रिएक्ट साइटों का प्रदर्शन सबसे खराब है। डेस्कटॉप डिवाइस पर वे सभी साइटों की तुलना में कोड प्रोसेसिंग में 248% अधिक समय खर्च करते हैं, और मोबाइल डिवाइस पर वे कोड प्रोसेसिंग में 658% अधिक समय खर्च करते हैं। 658% कोई टाइपो नहीं है। 10वें प्रतिशत पर, रिएक्ट साइटें अपने मौजूदा कोड को संसाधित करने में मुख्य थ्रेड समय के 2.7 सेकंड खर्च करती हैं।

इन विशाल संख्याओं की तुलना में 90वीं प्रतिशतक संख्याएँ कम से कम थोड़ी बेहतर दिखती हैं। सभी साइटों की तुलना में, कोणीय परियोजनाएं डेस्कटॉप उपकरणों पर मुख्य थ्रेड में 29% अधिक समय और मोबाइल उपकरणों पर 27% अधिक समय व्यतीत करती हैं। रिएक्ट साइटों के मामले में, समान संकेतक क्रमशः 130% और 98% दिखते हैं।

90वें प्रतिशतक के लिए विचलन प्रतिशत 10वें प्रतिशतक के समान मूल्यों से बेहतर दिखता है। लेकिन यहां यह याद रखने वाली बात है कि समय बताने वाले आंकड़े काफी डरावने लगते हैं। मान लीजिए - रिएक्ट पर बनी साइट के लिए मोबाइल डिवाइस के मुख्य थ्रेड में 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वें प्रतिशतक और उससे ऊपर पर, रिएक्ट का उपयोग करने वाली साइटें तब खराब प्रदर्शन करती हैं जब रिएक्ट ही एकमात्र लाइब्रेरी होती है जिसका वे उपयोग करते हैं। वैसे, यही कारण था कि मैं यह डेटा यहां प्रस्तुत कर रहा हूं।

यह थोड़ा अजीब है, लेकिन मैं फिर भी इस विचित्रता के लिए स्पष्टीकरण खोजने की कोशिश करूंगा।

यदि कोई प्रोजेक्ट रिएक्ट और jQuery दोनों का उपयोग करता है, तो संभवतः वह प्रोजेक्ट jQuery से रिएक्ट में माइग्रेट करने की प्रक्रिया में कहीं बीच में है। शायद उसके पास एक कोडबेस है जिसमें ये लाइब्रेरीज़ मिश्रित हैं। चूँकि हमने पहले ही देखा है कि jQuery साइटें रिएक्ट साइटों की तुलना में मुख्य थ्रेड पर कम समय बिताती हैं, यह हमें बता सकता है कि jQuery में कुछ कार्यक्षमता लागू करने से साइट के प्रदर्शन को थोड़ा बेहतर बनाने में मदद मिलती है।

लेकिन जैसे-जैसे प्रोजेक्ट jQuery से रिएक्ट की ओर बढ़ता है और रिएक्ट पर अधिक से अधिक निर्भर होता है, स्थिति बदल जाती है। यदि साइट वास्तव में उच्च गुणवत्ता के साथ बनाई गई है, और साइट डेवलपर्स रिएक्ट का सावधानीपूर्वक उपयोग करते हैं, तो ऐसी साइट के साथ सब कुछ ठीक हो जाएगा। लेकिन औसत रिएक्ट साइट के लिए, रिएक्ट के व्यापक उपयोग का मतलब है कि मुख्य थ्रेड बढ़े हुए लोड के अधीन है।

मोबाइल और डेस्कटॉप डिवाइस के बीच अंतर

डेटा को देखने का मेरा दूसरा तरीका यह पता लगाना था कि मोबाइल और डेस्कटॉप अनुभवों के बीच कितना बड़ा अंतर है। यदि हम जावास्क्रिप्ट कोड की मात्रा की तुलना करने की बात करते हैं, तो ऐसी तुलना से कुछ भी भयानक पता नहीं चलता है। बेशक, डाउनलोड करने योग्य कोड की छोटी मात्रा देखना अच्छा होगा, लेकिन मोबाइल और डेस्कटॉप कोड की मात्रा में बहुत अंतर नहीं है।

लेकिन यदि आप कोड को संसाधित करने में लगने वाले समय का विश्लेषण करते हैं, तो मोबाइल और डेस्कटॉप उपकरणों के बीच एक बहुत बड़ा अंतर ध्यान देने योग्य हो जाता है।

डेस्कटॉप उपकरणों की तुलना में मोबाइल उपकरणों पर स्क्रिप्ट प्रोसेसिंग से संबंधित समय में (प्रतिशत में) वृद्धि

प्रतिशतक
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वें प्रतिशत पर भी, रिएक्ट साइटें डेस्कटॉप मुख्य थ्रेड की तुलना में मोबाइल मुख्य थ्रेड पर 431.5% अधिक समय बिताती हैं। jQuery में सबसे छोटा अंतर है, लेकिन यहां भी संबंधित आंकड़ा 188.2% है। जब वेबसाइट डेवलपर अपने प्रोजेक्ट इस तरह से बनाते हैं कि उन्हें संसाधित करने के लिए अधिक सीपीयू समय की आवश्यकता होती है (और यही होता है, और समय के साथ यह और भी खराब हो जाता है), कम-शक्ति वाले उपकरणों के मालिकों को इसके लिए भुगतान करना पड़ता है।

परिणाम

अच्छे फ्रेमवर्क से डेवलपर्स को वेब प्रोजेक्ट (सुरक्षा, पहुंच, प्रदर्शन के संदर्भ में) बनाने के लिए एक अच्छी नींव मिलनी चाहिए, या इसमें अंतर्निहित प्रतिबंध होने चाहिए जो उन प्रतिबंधों का उल्लंघन करने वाली किसी चीज़ को बनाना मुश्किल बनाते हैं।

ऐसा प्रतीत होता है कि यह वेब परियोजनाओं के प्रदर्शन (और जाहिर तौर पर उनके प्रदर्शन) पर लागू नहीं होता है उपलब्धता).

यह ध्यान देने योग्य है कि सिर्फ इसलिए कि रिएक्ट या एंगुलर साइटें दूसरों की तुलना में कोड तैयार करने में अधिक CPU समय खर्च करती हैं, इसका मतलब यह नहीं है कि रिएक्ट साइटें चलते समय Vue साइटों की तुलना में अधिक CPU-सघन होती हैं। वास्तव में, हमने जो डेटा देखा वह फ्रेमवर्क और पुस्तकालयों के परिचालन प्रदर्शन के बारे में बहुत कम कहता है। वे विकास के दृष्टिकोण के बारे में अधिक बात करते हैं, जानबूझकर या नहीं, ये ढांचे प्रोग्रामर को उस ओर धकेल सकते हैं। हम फ्रेमवर्क, उनके पारिस्थितिकी तंत्र और सामान्य विकास तकनीकों के लिए दस्तावेज़ीकरण के बारे में बात कर रहे हैं।

यह कुछ ऐसी बात बताने लायक भी है जिसका हमने यहां विश्लेषण नहीं किया है, अर्थात्, साइट के पृष्ठों के बीच संक्रमण करते समय डिवाइस जावास्क्रिप्ट कोड निष्पादित करने में कितना समय व्यतीत करता है। एसपीए के पक्ष में तर्क यह है कि एक बार एकल पृष्ठ एप्लिकेशन ब्राउज़र में लोड हो जाने पर, उपयोगकर्ता, सिद्धांत रूप में, साइट के पृष्ठों तक तेज़ी से पहुंचने में सक्षम होगा। मेरा अपना अनुभव मुझे बताता है कि यह तथ्य से कोसों दूर है। लेकिन हमारे पास इस मुद्दे को स्पष्ट करने के लिए डेटा नहीं है।

यह स्पष्ट है कि यदि आप एक वेबसाइट बनाने के लिए किसी फ्रेमवर्क या लाइब्रेरी का उपयोग करते हैं, तो आप प्रोजेक्ट को शुरू में लोड करने और इसे जाने के लिए तैयार करने के मामले में एक समझौता कर रहे हैं। यह सबसे सकारात्मक परिदृश्यों पर भी लागू होता है।

उपयुक्त परिस्थितियों में कुछ समझौते करना संभव है, लेकिन यह महत्वपूर्ण है कि डेवलपर्स सचेत रूप से ऐसे समझौते करें।

लेकिन हमारे पास आशावाद का कारण भी है। मैं इस बात से प्रोत्साहित हूं कि क्रोम डेवलपर उन टूल के प्रदर्शन को बेहतर बनाने में मदद करने के लिए हमारे द्वारा कवर किए गए कुछ फ्रंट-एंड टूल के पीछे काम कर रहे हैं।

हालाँकि, मैं एक व्यावहारिक व्यक्ति हूँ। नए आर्किटेक्चर जितनी बार उन्हें हल करते हैं उतनी ही बार प्रदर्शन संबंधी समस्याएं भी पैदा करते हैं। और कमियों को दूर करने में समय लगता है. ठीक वैसे ही जैसे हमें इसकी उम्मीद नहीं करनी चाहिए नई नेटवर्क प्रौद्योगिकियाँ सभी प्रदर्शन समस्याओं का समाधान करेगा, आपको हमारे पसंदीदा फ्रेमवर्क के नए संस्करणों से इसकी उम्मीद नहीं करनी चाहिए।

यदि आप इस सामग्री में चर्चा किए गए फ्रंट-एंड टूल में से किसी एक का उपयोग करना चाहते हैं, तो इसका मतलब है कि आपको यह सुनिश्चित करने के लिए अतिरिक्त प्रयास करना होगा कि, संयोग से, आप अपने प्रोजेक्ट के प्रदर्शन को नुकसान न पहुंचाएं। किसी नए ढांचे का उपयोग शुरू करने से पहले विचार करने योग्य कुछ बातें यहां दी गई हैं:

• अपने आप को सामान्य ज्ञान से जाँचें। क्या आपको वास्तव में अपने चुने हुए ढांचे का उपयोग करने की आवश्यकता है? शुद्ध जावास्क्रिप्ट आज बहुत कुछ कर सकती है।
• क्या आपकी पसंद के ढांचे का कोई हल्का विकल्प है (जैसे प्रीएक्ट, स्वेल्ट या कुछ और) जो आपको उस ढांचे की 90% क्षमताएं दे सकता है?
• यदि आप पहले से ही एक फ्रेमवर्क का उपयोग कर रहे हैं, तो इस बारे में सोचें कि क्या ऐसा कुछ है जो बेहतर, अधिक रूढ़िवादी, मानक विकल्प प्रदान करता है (उदाहरण के लिए, Vue के बजाय Nuxt.js, रिएक्ट के बजाय Next.js, आदि)।
• आपका क्या होगा बजट जावास्क्रिप्ट प्रदर्शन?
• तुम कैसे सीमित करने के लिए क्या विकास प्रक्रिया किसी प्रोजेक्ट में बिल्कुल आवश्यक से अधिक जावास्क्रिप्ट कोड पेश करना अधिक कठिन बना देगी?
• यदि आप विकास में आसानी के लिए किसी ढांचे का उपयोग कर रहे हैं, तो विचार करें क्या आपको ज़रूरत है ग्राहकों को फ्रेमवर्क कोड भेजें। शायद आप सर्वर पर सभी समस्याओं का समाधान कर सकते हैं?

आम तौर पर, इन विचारों पर करीब से नज़र डालने लायक है, भले ही आप फ्रंट एंड को विकसित करने के लिए वास्तव में क्या चुनते हैं। लेकिन वे विशेष रूप से तब महत्वपूर्ण होते हैं जब आप किसी ऐसे प्रोजेक्ट पर काम कर रहे हों जिसमें शुरुआत में प्रदर्शन का अभाव हो।

प्रिय पाठकों! आप आदर्श जावास्क्रिप्ट ढाँचे के रूप में क्या देखते हैं?

स्रोत: www.habr.com