👀 🍮 😈 जावास्क्रिप्ट चौखटे की कीमत 😯 ⭕️ 👹

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

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

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

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

परियोजना ने मुझे यह पता लगाने में मदद की ।

डेटा

HTTP संग्रह परियोजना, कुल मिलाकर, डेस्कटॉप डिवाइसों को समर्पित नियमित साइटों के लिए 4,308,655 लिंक और मोबाइल साइटों के लिए 5,484,239 लिंक को ट्रैक करती है। इन लिंक से जुड़े कई संकेतकों में, संबंधित साइटों पर पाई जाने वाली प्रौद्योगिकियों की एक सूची है। इसका मतलब है कि हम हजारों साइटों का एक नमूना बना सकते हैं जो विभिन्न चौखटे और पुस्तकालयों का उपयोग करते हैं, और यह पता लगाते हैं कि वे ग्राहकों को कितना कोड भेजते हैं, और उपयोगकर्ता सिस्टम इस कोड को कितना लोड करते हैं।

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

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

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

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

ढांचा या पुस्तकालय	मोबाइल साइटों के लिए लिंक	नियमित साइटों के लिए लिंक
jQuery	4615474	3714643
प्रतिक्रिया	489,827	241,023
Vue	85,649	43,691
कोणीय	19,423	18,088

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

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

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

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

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

मंझला डेटा मूल्यों का विश्लेषण हमें आवश्यक जानकारी नहीं देगा। और, वास्तव में, इस तरह का दृष्टिकोण हमारे ध्यान से परे बहुत महत्वपूर्ण है । इसके बजाय, मैंने प्रतिशत में व्यक्त अपने डेटा संकेतकों से कटौती की। यह 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
Vue-	244.7	409.3	692.1	1065.5	1570.7
Angular-	445.1	675.6	1066.4	1761.5	2893.2
React-	345.8	441.6	690.3	1238.5	1893.6

JavaScript-,

JavaScript- (),

	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
Angular-	468.8	716.9	1144.2	1930.0	3283.1
React-	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	पचास	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	पचास	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
Angular-	482.2	777.9	1365.5	2400.6	4171.8
React-	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% अधिक मुख्य थ्रेड टाइम प्रसंस्करण JS कोड खर्च करती हैं। मोबाइल साइटों के लिए, यह आंकड़ा 313% है। प्रतिक्रिया साइटों में सबसे खराब प्रदर्शन है। डेस्कटॉप उपकरणों पर, वे सभी साइटों की तुलना में कोड प्रसंस्करण पर 248% अधिक समय खर्च करते हैं, और मोबाइल उपकरणों पर - 658% अधिक। 658% एक टाइपो नहीं है। 10 वें प्रतिशतक पर, रिएक्ट साइटें मुख्य थ्रेड समय के 2.7 सेकंड खर्च करते हैं जो उनके पास कोड को संसाधित करने के लिए होता है।

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

90 वें प्रतिशत के लिए प्रतिशत विचलन 10 वीं प्रतिशत के लिए समान मूल्यों से बेहतर दिखते हैं। लेकिन यहां यह याद रखने योग्य है कि समय को इंगित करने वाले नंबर बहुत डरावने लगते हैं। कहें - रिएक्ट पर निर्मित साइट के लिए मोबाइल डिवाइस की मुख्य धारा में 20.8 सेकंड। (मेरा मानना है कि इस समय के दौरान वास्तव में क्या होता है इसकी कहानी एक अलग लेख के योग्य है)।

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

सीपीयू समय (मिलीसेकंड में) मोबाइल उपकरणों पर स्क्रिप्ट के प्रसंस्करण से संबंधित ऐसी स्थिति में जहां साइटें केवल एक ढांचे या केवल एक पुस्तकालय का उपयोग करती हैं

प्रतिशतक	10	25	पचास	75	90
, jQuery	542.9	1062.2	2297.4	4769.7	8718.2
, Vue	944.0	1716.3	3194.7	5959.6	9843.8
, Angular	1328.9	2151.9	3695.3	6629.3	11607.7
, React	2443.2	4620.5	10061.4	17074.3	24956.3

सीपीयू समय मोबाइल उपकरणों पर लिपियों के प्रसंस्करण से संबंधित ऐसी स्थिति में जहां साइटों पर केवल एक ही फ्रेमवर्क का उपयोग किया जाता है, या केवल एक पुस्तकालय

सबसे पहले, यह आश्चर्यजनक नहीं है: जब किसी साइट पर केवल एक ढांचे या एक पुस्तकालय का उपयोग किया जाता है, तो ऐसी साइट का प्रदर्शन अधिक बार होता है सुधरने से नहीं सुधरने से। प्रत्येक उपकरण के संकेतक 10 और 25 प्रतिशत पर बेहतर दिखते हैं। यह समझ में आता है। एक साइट जो एक ढांचे का उपयोग करके बनाई गई है, वह उस साइट की तुलना में अधिक उत्पादक होनी चाहिए जो दो या अधिक रूपरेखाओं या पुस्तकालयों का उपयोग करके बनाई गई है।

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

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

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

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

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

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

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

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

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

सारांश

अच्छे ढांचे को डेवलपर्स को वेब प्रोजेक्ट (सुरक्षा, पहुंच, प्रदर्शन) के मामले में उच्च-गुणवत्ता वाला आधार प्रदान करना चाहिए, या इसमें अंतर्निहित प्रतिबंध होना चाहिए, जिससे इन प्रतिबंधों का उल्लंघन करने वाले कुछ बनाने में मुश्किल हो।

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

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

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

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

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

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

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

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

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

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

प्रिय पाठकों! आप सही जावास्क्रिप्ट फ्रेमवर्क कैसे देखते हैं?