जावास्क्रिप्ट मूल्य 2019

पिछले कुछ वर्षों में, जिसे " जावास्क्रिप्ट मूल्य " कहा जाता है, ने बढ़ती पार्सिंग गति और लिपियों के ब्राउज़र संकलन के कारण बड़े सकारात्मक बदलाव देखे हैं। अब, 2019 में, जावास्क्रिप्ट द्वारा बनाए गए सिस्टम पर लोड के मुख्य घटक स्क्रिप्ट का लोड समय और उनके निष्पादन का समय है।



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

वेबसाइट अनुकूलन के लिए सामान्य व्यावहारिक दिशानिर्देश

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

1. स्क्रिप्ट डाउनलोड करने के लिए आवश्यक समय कम करने का प्रयास करें।
   
   
   • अपने जेएस बंडलों को छोटा रखने की कोशिश करें। यह मोबाइल उपकरणों के लिए डिज़ाइन की गई साइटों के लिए विशेष रूप से महत्वपूर्ण है। छोटे बंडलों का उपयोग करने से कोड लोडिंग समय में सुधार होता है, मेमोरी उपयोग के स्तर को कम करता है, और प्रोसेसर पर लोड को कम करता है।
   • सभी प्रोजेक्ट कोड को एक बड़े बंडल के रूप में प्रस्तुत करने से रोकने की कोशिश करें। यदि बंडल का आकार लगभग 50-100 Kb से अधिक है - इसे छोटे आकार के अलग-अलग टुकड़ों में विभाजित करें। HTTP / 2 मल्टीप्लेक्सिंग के लिए धन्यवाद, कई सर्वर अनुरोधों और कई प्रतिक्रियाओं को एक साथ संसाधित किया जा सकता है। यह डेटा लोडिंग के लिए अतिरिक्त अनुरोधों को पूरा करने की आवश्यकता से जुड़ी प्रणाली पर लोड को कम करता है।
   • यदि आप मोबाइल प्रोजेक्ट पर काम कर रहे हैं, तो कोड को यथासंभव छोटा रखने की कोशिश करें। यह सिफारिश मोबाइल नेटवर्क पर कम डेटा दरों के साथ जुड़ी हुई है। इसके अलावा, स्मृति के किफायती उपयोग के लिए प्रयास करें।
2. स्क्रिप्ट निष्पादित करने के लिए आवश्यक समय कम करने का प्रयास करें।
   
   
   • उन लम्बे कार्यों का उपयोग करने से बचें, जो मुख्य धागे को लंबे समय तक लोड कर सकते हैं और पृष्ठों के लिए आवश्यक समय बढ़ा सकते हैं, जिसमें उपयोगकर्ता उनसे बातचीत कर सकते हैं। वर्तमान परिवेश में, लोड होने के बाद चलने वाली स्क्रिप्ट "जावास्क्रिप्ट की कीमत" में एक बड़ा योगदान देती है।
3. बड़े कोड स्निपेट को पृष्ठों में एम्बेड न करें।
   
   
   • निम्नलिखित नियम का यहां पालन किया जाना चाहिए: यदि स्क्रिप्ट का आकार 1 Kb से अधिक है, तो इसे पृष्ठ कोड में एम्बेड न करने का प्रयास करें। इस सिफारिश के कारणों में से एक तथ्य यह है कि 1 Kb वह सीमा है जिसके बाद क्रोम में बाहरी स्क्रिप्ट कोड का कैशिंग काम करना शुरू कर देता है। इसके अलावा, ध्यान रखें कि एम्बेडेड स्क्रिप्ट्स को पार्स करना और संकलित करना अभी भी मुख्य धागे में चल रहा है।

लिपियों को लोड करना और निष्पादित करना इतना महत्वपूर्ण क्यों है?

आधुनिक परिस्थितियों में स्क्रिप्ट के लोडिंग और निष्पादन समय का अनुकूलन करना क्यों महत्वपूर्ण है? स्क्रिप्ट लोडिंग समय उन स्थितियों में बहुत महत्वपूर्ण है जहां साइटें धीमे नेटवर्क के माध्यम से एक्सेस की जाती हैं। इस तथ्य के बावजूद कि 4 जी नेटवर्क (और यहां तक ​​कि 5 जी) अधिक से अधिक फैल रहे हैं, मोबाइल इंटरनेट कनेक्शन का उपयोग करने के कई मामलों में NetworkInformation.effectiveType गुण संकेतक दिखाते हैं जो 3 जी नेटवर्क के स्तर पर या यहां तक ​​कि निचले स्तर पर भी हैं।

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

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


पृष्ठ को लोड करने की प्रक्रिया में लगभग 10-30% समय V8 का उपयोग करके कोड निष्पादन पर खर्च किया जाता है

अगर हम मोबाइल उपकरणों के बारे में बात करते हैं, तो एक औसत फोन (Moto G4) पर एक उच्च-स्तरीय डिवाइस (पिक्सेल 3) की तुलना में JS कोड पर reddit.com को निष्पादित करने में 3-4 गुना अधिक समय लगता है। एक कमजोर डिवाइस (अल्काटेल 1X की कीमत $ 100 से कम है) पर, इसी समस्या को हल करने के लिए Pixel 3 जैसी किसी चीज़ से कम से कम 6 गुना अधिक समय की आवश्यकता होती है।


विभिन्न वर्गों के मोबाइल उपकरणों पर जेएस कोड को संसाधित करने के लिए आवश्यक समय

कृपया ध्यान दें कि reddit.com के मोबाइल और डेस्कटॉप संस्करण भिन्न हैं। इसलिए, आप मोबाइल उपकरणों के परिणामों की तुलना नहीं कर सकते हैं और कहते हैं, मैकबुक प्रो।

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


लंबे समय से चल रहे कार्य मुख्य धागे को पकड़ते हैं। उन्हें टुकड़ों में तोड़ दिया जाना चाहिए

V8 सुधार स्क्रिप्ट को पार्स और संकलित करने की गति कैसे बढ़ाते हैं?

Chrome 60 के समय से V8 में स्रोत JS कोड को पार्स करने की गति 2 गुना बढ़ गई है। उसी समय, पार्सिंग और संकलन अब "जावास्क्रिप्ट मूल्य" में कम योगदान करते हैं। यह अन्य क्रोम अनुकूलन प्रयासों के लिए धन्यवाद है जो इन कार्यों को समानांतर करने के लिए अग्रणी है।

V8 में, मुख्य थ्रेड में उत्पादित पार्सिंग और संकलन कोड पर काम की मात्रा औसतन 40% कम हो जाती है। उदाहरण के लिए, फेसबुक के लिए इस सूचक का सुधार 46% था, Pinterest के लिए - 62%। उच्चतम परिणाम, 81%, YouTube के लिए प्राप्त किया गया था। इस तरह के परिणाम इस तथ्य के कारण संभव हैं कि पार्सिंग और संकलन को एक अलग स्ट्रीम में स्थानांतरित किया जाता है। और यह मुख्य धारा के बाहर समान कार्यों के स्ट्रीमिंग समाधान के बारे में मौजूदा सुधारों के अलावा है।


जेएस क्रोम के विभिन्न संस्करणों में पार्सिंग समय

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


उस समय में जब क्रोम 61 को फेसबुक जेएस कोड को संसाधित करने की आवश्यकता थी, क्रोम 75 फेसबुक कोड और ट्विटर कोड की राशि के छह गुना दोनों को संसाधित कर सकता है।

आइए बात करते हैं कि ऐसे सुधार कैसे प्राप्त किए गए थे। संक्षेप में, स्क्रिप्ट संसाधन को वर्कफ़्लो में स्ट्रीमिंग मोड में पार्स और संकलित किया जा सकता है। इसका मतलब निम्न है:

• V8 मुख्य थ्रेड को अवरुद्ध किए बिना JS कोड को पार्स और संकलित कर सकता है।
• स्क्रिप्ट की स्ट्रीम प्रोसेसिंग तब शुरू होती है जब यूनिवर्सल HTML पार्सर का सामना <script> । एक HTML पार्सर स्क्रिप्ट को संभालता है जो पृष्ठ पार्सिंग को ब्लॉक करता है। अतुल्यकालिक स्क्रिप्ट के साथ मिलना, वह काम करना जारी रखता है।
• अधिकांश वास्तविक दुनिया के परिदृश्यों में, कुछ नेटवर्क कनेक्शन की गति की विशेषता है, V8 लोड होने की तुलना में तेजी से कोड को पार्स करता है। परिणामस्वरूप, V8 स्क्रिप्ट के अंतिम बाइट्स लोड होने के बाद कुछ मिलीसेकंड कोड को पार्स करने और संकलित करने के कार्यों को पूरा करता है।

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


स्क्रिप्ट को टुकड़ों में ब्राउज़र को भेजा जाता है। कोड के कम से कम 30 Kb होने के बाद V8 ने डेटा प्रोसेसिंग शुरू कर दी।

Chrome 71 में, हम एक कार्य-आधारित प्रणाली पर चले गए। यहां, अनुसूचक एक साथ कई अतुल्यकालिक / विलंबित स्क्रिप्ट प्रोसेसिंग सत्र शुरू कर सकता है। इस परिवर्तन के कारण, मुख्य धागे को पार्स करके बनाया गया भार लगभग 20% कम हो गया है। इससे वास्तविक साइटों पर प्राप्त TTI / FID स्कोर में लगभग 2% सुधार हुआ।


Chrome 71 एक कार्य-आधारित कोड प्रसंस्करण प्रणाली का उपयोग करता है। इस दृष्टिकोण के साथ, अनुसूचक एक ही समय में कई अतुल्यकालिक / लंबित लिपियों को संसाधित कर सकता है।

Chrome 72 में, हमने स्क्रिप्ट्स को पार्स करने के लिए प्राथमिक प्रसंस्करण को स्ट्रीमिंग बनाया। अब नियमित रूप से सिंक्रोनस स्क्रिप्ट को भी इस तरह से हैंडल किया जाता है (हालाँकि यह बिल्ट-इन स्क्रिप्ट्स पर लागू नहीं होता है)। इसके अलावा, यदि मुख्य धागे को पार्स कोड की आवश्यकता होती है, तो हमने कार्य-आधारित पार्सिंग कार्यों को रद्द कर दिया। यह इस तथ्य के कारण किया जाता है कि इससे पहले से किए गए कुछ कार्यों को फिर से करने की आवश्यकता होती है।

Chrome के पिछले संस्करण में स्ट्रीमिंग पार्सिंग और कोड के स्ट्रीम संकलन का समर्थन था। फिर नेटवर्क से डाउनलोड की गई स्क्रिप्ट को पहले मुख्य स्ट्रीम में जाना चाहिए, और फिर इसे स्ट्रीमिंग स्क्रिप्ट प्रोसेसिंग सिस्टम पर रीडायरेक्ट किया जाएगा।

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

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

डेवलपर के टूल में जो सुधार देखे जा सकते हैं, वे कैसे प्रभावित हुए हैं?

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


समस्या डेवलपर टूल में है, जिसके कारण पार्सिंग स्क्रिप्ट के बारे में जानकारी प्रदर्शित की गई जैसे कि वे मुख्य धागे को पूरी तरह से ब्लॉक करते हैं

यहां आप देख सकते हैं कि Parse Script कार्य में 1.08 सेकंड लगते हैं। लेकिन जावास्क्रिप्ट को पार्स करना, वास्तव में, इतना धीमा नहीं है! इस बार, मुख्य धागे से डेटा की प्रतीक्षा करने के अलावा कुछ भी उपयोगी नहीं है।
Chrome 76 में, आप पहले से ही एक पूरी तरह से अलग तस्वीर देख सकते हैं।


Chrome 76 में, पार्सिंग कई छोटे कार्यों में टूट गया है

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


Google अनुरेखण का उपयोग करके RCS डेटा का विश्लेषण

परिवर्तनों ने वास्तविक साइटों के साथ काम को कैसे प्रभावित किया?

आइए कुछ उदाहरण देखें कि कैसे स्ट्रीमिंग स्क्रिप्ट प्रसंस्करण ने ब्राउज़िंग वास्तविक साइटों को प्रभावित किया।

▍Reddit

एक मैकबुक प्रो पर reddit.com देखें। मुख्य और कार्यकर्ता थ्रेड्स में खर्च किए गए जेएस कोड को पार्स और संकलित करने का समय

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

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

▍Facebook

अपने मैकबुक प्रो पर facebook.com देखें। मुख्य और कार्यकर्ता थ्रेड्स में खर्च किए गए जेएस कोड को पार्स और संकलित करने का समय

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

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

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

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

JSON पार्सिंग मूल्य

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

जेएस वस्तुओं का उपयोग करते हुए पहला दृष्टिकोण, इस तरह दिखता है:

 const data = { foo: 42, bar: 1337 }; //  

JSON स्ट्रिंग्स का उपयोग करते हुए दूसरा दृष्टिकोण, ऐसे निर्माणों का उपयोग शामिल है:

 const data = JSON.parse('{"foo":42,"bar":1337}'); //  

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

बड़ी मात्रा में डेटा के भंडारण के रूप में ऑब्जेक्ट शाब्दिक का उपयोग करना एक और खतरा बन गया है। मुद्दा यह है कि जोखिम है कि ऐसे शाब्दिक दो बार संसाधित किए जा सकते हैं:

1. पहला प्रसंस्करण पास शाब्दिक के प्रारंभिक पार्सिंग के साथ किया जाता है।
2. दूसरा दृष्टिकोण शाब्दिक के "आलसी" पार्सिंग के दौरान किया जाता है।

आप प्रोसेसिंग ऑब्जेक्ट के पहले पास से छुटकारा नहीं पा सकते। लेकिन, सौभाग्य से, शीर्ष स्तर पर या PIFE के अंदर ऑब्जेक्ट शाब्दिक रूप से रखकर दूसरे पास से बचा जा सकता है।

साइटों पर बार-बार आने पर कोड को पार्स करने और संकलन करने के बारे में क्या?

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


V8 में कोड कैशिंग प्रणाली

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

परिणाम

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

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

प्रिय पाठकों! क्या आप आधुनिक ब्राउज़रों द्वारा जेएस-कोड प्रसंस्करण की ख़ासियत को ध्यान में रखते हुए अपनी वेब परियोजनाओं का अनुकूलन करते हैं?