जावास्क्रिप्ट बंडलिंग और प्रदर्शन: सर्वश्रेष्ठ अभ्यास

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



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

दृष्टिकोण नंबर 1: बिल्कुल सब कुछ बंडल में मिलता है (यह धागे की एक बड़ी गेंद जैसा दिखता है)

मुख्य विचार: इस दृष्टिकोण का उपयोग न करें।

इस दृष्टिकोण के साथ, मॉड्यूल बिल्डर का उपयोग बंडल में सब कुछ पैकेज करने के लिए किया जाता है - निर्भरता और एप्लिकेशन कोड दोनों। उत्पादन यार्न की एक बड़ी गेंद की तरह कुछ है। मेरे उदाहरण में, इसमें react , react-dom और एप्लिकेशन का कोड शामिल है। सभी प्रोजेक्ट कोड वाला एकल बंडल पृष्ठ से जुड़ा है:

 <!-- index.html --> <script src="bundle.[hash].min.js"></script> 

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

क्यों? तथ्य यह है कि HTTP / 2 का उपयोग करते समय, कई अनुरोधों का निष्पादन अब सिस्टम पर पहले जैसा लोड नहीं बनाता है। नतीजतन, कोड को एक बड़े बंडल में पैक करना अब परियोजना को महत्वपूर्ण लाभ नहीं देता है।

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

HTTP / 2 आज 95% से अधिक ग्राहकों द्वारा समर्थित है। 2019 में, यह प्रोटोकॉल अधिकांश सर्वरों द्वारा लागू किया गया था। 2019 में HTTP / 2 का उपयोग करने के बारे में और अधिक जानकारी प्राप्त करें।

दृष्टिकोण नंबर 2: परियोजना कोड की अलग पैकेजिंग और तीसरे पक्ष के पुस्तकालयों के कोड (कोड पृथक्करण)

मुख्य विचार: कृपया इस दृष्टिकोण का उपयोग करें।

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

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

यहाँ स्क्रिप्ट कनेक्शन कोड क्या है:

 <!-- index.html --> <script src="vendor.[hash].min.js"></script> <script src="index.[hash].min.js"></script> 

और यहाँ पृष्ठ लोड करने के लिए झरना समयरेखा है, जब HTTP / 2 का उपयोग किया जाता है।


झरना पृष्ठ लोड अनुसूची

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

 <!-- index.html --> <script src="vendor.react.[hash].min.js"></script> <script src="vendor.others.[hash].min.js"></script> <script src="index.[hash].min.js"></script> 

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

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

दृष्टिकोण # 3: कुछ निर्भरता के कोड के लिए सार्वजनिक CDN का उपयोग करना

मुख्य विचार: इस दृष्टिकोण का उपयोग न करें।

यदि आप उन लोगों में से एक हैं जो वेब डेवलपमेंट में थोड़े पुराने जमाने के हैं (जैसे कि), तो आपको एक आंतरिक एहसास हो सकता है कि हम vendor.react से vendor.react करने में सक्षम हो सकते हैं। vendor.react फ़ाइल, खंड "दृष्टिकोण सं।" 2 ", एक सार्वजनिक CDN संसाधन का उपयोग कर:

 <!-- index.html --> <script crossorigin src="https://unpkg.com/react@16.12.0/umd/react.production.min.js"></script> <script crossorigin src="https://unpkg.com/react-dom@16.12.0/umd/react-dom.production.min.js"></script> <script src="index.[hash].min.js"></script> 

मैं ध्यान देता हूं कि इस दृष्टिकोण का उपयोग करते समय, वेबपैक प्रोजेक्ट कलेक्टर को यह बताना आवश्यक है कि वह बंडल से react और react-dom कोड को बाहर कर दे।

पहली नज़र में, यह सब काफी अच्छा लग रहा है, लेकिन इस दृष्टिकोण में कुछ नुकसान हैं जिन्हें मैं विचार करने का प्रस्ताव देता हूं।

▍ माइनस # 1: एक ही डिपेंडेंसी फाइलों के विभिन्न साइट्स का उपयोग करना? अब नहीं ...

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

हालांकि पहले यह अच्छी तरह से काम कर सकता था, हाल ही में ब्राउज़रों में, बढ़ती सुरक्षा के लिए, उन्होंने कैश साझा करने के लिए एक तंत्र को लागू करना शुरू किया। हम इस तथ्य के बारे में बात कर रहे हैं कि आदर्श परिस्थितियों में भी, जब दो साइटें एक ही लाइब्रेरी का उपयोग करती हैं, एक ही CDN लिंक के माध्यम से लोड की जाती हैं, तो कोड को प्रत्येक डोमेन के लिए स्वतंत्र रूप से डाउनलोड किया जाता है, और कैश, गोपनीयता के कारणों के लिए सैंडबॉक्स में समाप्त होता है। एक विशिष्ट डोमेन के लिए आवंटित। जैसा कि यह निकला , यह तंत्र पहले से ही सफारी में लागू किया गया है (जाहिर है, यह 2013 से अस्तित्व में है!)। और अगर हम Chrome 77 के बारे में बात करते हैं, तो अभी के लिए कैश पृथक्करण को सक्षम करने के लिए आपको एक विशेष ध्वज का उपयोग करने की आवश्यकता है।

यह एक उचित धारणा बनाता है कि सार्वजनिक रूप से उपलब्ध सीडीएन का उपयोग कम हो जाएगा क्योंकि कैश साझाकरण अधिक ब्राउज़रों में लागू किया जाता है।

Auxiliary माइनस नंबर 2: सहायक संचालन पर सिस्टम संसाधनों की बर्बादी (प्रत्येक डोमेन के लिए)

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

यहाँ एक वाटरफॉल ग्राफ है जो एक पृष्ठ को लोड करने की प्रक्रिया को दिखाता है जो सार्वजनिक रूप से उपलब्ध सीडीएन संसाधन से स्क्रिप्ट का उपयोग करता है।


सार्वजनिक रूप से उपलब्ध CDN संसाधनों का उपयोग करके एक पृष्ठ को लोड करने के लिए जलप्रपात समयरेखा

लाल अंडाकार उन क्षेत्रों को उजागर करते हैं जिनमें ऑपरेशन होते हैं जो प्रश्नों के निष्पादन से पहले होते हैं। यह एक साधारण हैलो वर्ल्ड एप्लिकेशन के लिए बहुत अधिक सा लगता है।

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

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


सार्वजनिक रूप से उपलब्ध CDN संसाधनों का उपयोग नहीं करने वाले पृष्ठ के लिए जलप्रपात लोडिंग शेड्यूल

DependMinus नंबर 3: विभिन्न साइटों द्वारा निर्भरता के विभिन्न संस्करणों का उपयोग करना

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


विभिन्न साइटों द्वारा प्रयुक्त रिएक्ट संस्करण

यदि आप पहली बार React का उपयोग करके एक लोकप्रिय साइट खोलते हैं, और फिर दूसरी, तो यह पता चलता है कि इन दोनों साइटों के एक ही संस्करण का उपयोग करने की संभावना बहुत छोटी है।

अनुसंधान के दौरान, मुझे इन रिएक्ट साइटों के बारे में कुछ और रोचक जानकारी मिली। शायद वे आपको भी दिलचस्प लगेंगे:

• 2/3 साइटों पर, वेबपैक का उपयोग कोड बनाने के लिए किया जाता है।
• 87% साइटें HTTP / 2 का उपयोग करती हैं, जो कि 58% के औसत मूल्य से अधिक है।
• अधिकांश परियोजनाएं (लगभग 56%) स्वयं फोंट की मेजबानी करती हैं।

यहाँ मेरे प्रयोग के लिए स्रोत डेटा हैं।

.Minus नंबर 4: गैर-प्रदर्शन के मुद्दे

दुर्भाग्य से, आज जो लोग सार्वजनिक रूप से उपलब्ध सीडीएन संसाधनों का उपयोग करते हैं, उन्हें न केवल पृष्ठ लोडिंग गति के बारे में समस्याओं का सामना करना पड़ता है, बल्कि कुछ अन्य परेशानियों के साथ भी:

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

परिणाम

यह बहुत स्पष्ट है कि भविष्य दृष्टिकोण 2 के साथ है।

HTTP / 2 (जैसे Cloudflare या Cloudfront) का उपयोग करके अपने स्वयं के CDN संसाधनों को अपने सर्वर के सामने होस्ट करें। ब्राउज़र कैश को प्रभावी ढंग से उपयोग करने के लिए कोड को छोटे टुकड़ों में तोड़ दें। भविष्य में, उन टुकड़ों को, जिनमें साइट कोड को विभाजित किया गया है, और भी छोटे हो सकते हैं, जो व्यक्तिगत जावास्क्रिप्ट मॉड्यूल के आकार तक पहुंचते हैं, इस तथ्य के कारण कि ब्राउज़र ने इस तकनीक के लिए समर्थन को लागू करना शुरू कर दिया है।

प्रिय पाठकों! क्या आप अपनी वेब परियोजनाओं में कोड पृथक्करण तकनीकों का उपयोग करते हैं?