आधुनिक स्क्रिप्ट लोड हो रहा है

प्रत्येक ब्राउज़र के लिए सही कोड पास करना कोई आसान काम नहीं है।

इस लेख में, हम इस समस्या को हल करने के लिए कई विकल्पों पर विचार करेंगे।



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

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

<script type="module" src="/modern.js"></script> <script nomodule src="/legacy.js"></script> 

दुर्भाग्य से, सब कुछ इतना सरल नहीं है। ऊपर दिखाया गया HTML दृष्टिकोण एज और सफारी में एक स्क्रिप्ट पुनः लोड को ट्रिगर करता है ।

क्या किया जा सकता है?

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

सबसे पहले, सफारी फिक्स है । सफारी 10.1, जेएस मॉड्यूल का समर्थन करता है, न कि स्क्रिप्ट में nomodule विशेषता, जो इसे आधुनिक और विरासत कोड दोनों को निष्पादित करने की अनुमति देता है। हालांकि, सफ़ारी 10 & 11 द्वारा समर्थित गैर-मानक beforeload घटना का उपयोग nomodule लिए किया जा सकता है।

विधि एक: डायनामिक डाउनलोड

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

 <!-- use a module script to detect modern browsers: --> <script type="module"> self.modern = true </script> <!-- now use that flag to load modern VS legacy code: --> <script> addEventListener('load', function() { var s = document.createElement('script') if ('noModule' in s) { // notice the casing s.type = 'module' s.src = '/modern.js' } else { s.src = '/legacy.js' } document.head.appendChild(s) }) </script> 

लेकिन इस दृष्टिकोण के साथ, आपको सही स्क्रिप्ट लागू करने से पहले "लिटमस" मॉड्यूल स्क्रिप्ट को पूरा करने के लिए इंतजार करना होगा। ऐसा इसलिए होता है क्योंकि <sript type="module"> हमेशा एसिंक्रोनस रूप से काम करता है। लेकिन एक बेहतर तरीका है!

nomodule में nomodule आप चेक करके इंडिपेंडेंट ऑप्शन को लागू कर सकते हैं। इसका मतलब है कि हम सफारी 10.1 जैसे ब्राउज़रों पर विचार करेंगे, भले ही वे मॉड्यूल का समर्थन करते हों। लेकिन यह सर्वश्रेष्ठ के लिए हो सकता है । यहाँ प्रासंगिक कोड है:

 var s = document.createElement('script') if ('noModule' in s) { // notice the casing s.type = 'module' s.src = '/modern.js' } else s.src = '/legacy.js' } document.head.appendChild(s) 

यह जल्दी से एक फ़ंक्शन में बदल सकता है जो आधुनिक या विरासत कोड को लोड करता है, और उनमें से अतुल्यकालिक लोडिंग भी प्रदान करता है:

 <script> $loadjs("/modern.js","/legacy.js") function $loadjs(src,fallback,s) { s = document.createElement('script') if ('noModule' in s) s.type = 'module', s.src = src else s.async = true, s.src = fallback document.head.appendChild(s) } </script> 

यहां समझौता क्या है?

प्रीलोड

चूंकि समाधान पूरी तरह से गतिशील है, ब्राउज़र हमारे जावास्क्रिप्ट संसाधनों का पता लगाने में सक्षम नहीं होगा जब तक कि वह बूटस्ट्रैपिंग कोड शुरू नहीं करता है जिसे हमने आधुनिक या विरासत स्क्रिप्ट सम्मिलित करने के लिए लिखा था। आमतौर पर, एक ब्राउज़र संसाधनों के लिए HTML स्कैन करता है जिसे वह पहले से डाउनलोड कर सकता है। यह समस्या हल हो गई है, लेकिन आदर्श रूप से नहीं: आप आधुनिक ब्राउज़र में पैकेज के आधुनिक संस्करण को लोड कर सकते हैं <link rl=modulpreload> का उपयोग करके।

दुर्भाग्य से, अभी तक केवल क्रोम modulepreload का समर्थन करता है ।

 <link rel="modulepreload" href="/modern.js"> <script type="module">self.modern=1</script> <!-- etc --> 

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

यहाँ यह समाधान उपयोग में कैसा दिख सकता है:

 <link rel="modulepreload" href="/modern.js"> <script type="module">self.modern=1</script> <script> $loadjs("/modern.js","/legacy.js") function $loadjs(e,d,c){c=document.createElement("script"),self.modern?(c.src=e,c.type="module"):c.src=d,document.head.appendChild(c)} </script> 

यह भी ध्यान दिया जाना चाहिए कि जेएस मॉड्यूल का समर्थन करने वाले ब्राउज़रों की सूची लगभग वही है जो समर्थन करते हैं <link rl=preload> । कुछ साइटों के लिए, <link rl=preload as=script crossorigin> बजाय <link rl=preload as=script crossorigin> उपयोग करना उचित हो सकता है। प्रदर्शन खराब हो सकता है क्योंकि क्लासिक स्क्रिप्ट modulepreload समय के साथ समान रूप से पार्स नहीं करता है, जैसा कि modulepreload साथ modulepreload ।

विधि दो: ट्रैक उपयोगकर्ता एजेंट

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

वास्तव में, यह सभी ब्राउज़रों के लिए HTML में एक ही <scrit src=bundle.js> से शुरू होता है। जब bundle.js का अनुरोध किया जाता है, तो सर्वर अनुरोधित ब्राउज़र के उपयोगकर्ता एजेंट स्ट्रिंग को पार्स करता है और चयन करता है कि कौन से जावास्क्रिप्ट को लौटना है - आधुनिक या विरासत, कैसे ब्राउज़र को मान्यता दी गई थी, इस पर निर्भर करता है।

दृष्टिकोण सार्वभौमिक है, लेकिन गंभीर परिणामों की ओर इशारा करता है:

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

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

 function renderPage(request, response) { let html = `<html><head>...`; const agent = request.headers.userAgent; const isModern = userAgent.isModern(agent); if (isModern) { html += ` <link rel="modulepreload" href="modern.mjs"> <script type="module" src="modern.mjs"></script> `; } else { html += ` <link rel="preload" as="script" href="legacy.js"> <script src="legacy.js"></script> `; } response.end(html); } 

प्रत्येक अनुरोध के जवाब में सर्वर पर पहले से ही HTML उत्पन्न करने वाली साइटों के लिए, यह आधुनिक स्क्रिप्ट डाउनलोड करने के लिए एक प्रभावी संक्रमण हो सकता है।

विधि तीन: ठीक पुराने ब्राउज़र

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

कुछ अनुप्रयोगों के लिए, यह एक आदर्श समझौता होगा: 90% ब्राउज़रों में कोड का आधुनिक संस्करण डाउनलोड करें, और पुराने लोगों को विरासत कोड दें। पुराने ब्राउज़रों में लोड बढ़ेगा।

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

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

    iOS-. <!-- polyfill `nomodule` in Safari 10.1: --> <script type="module"> !function(e,t,n){!("noModule"in(t=e.createElement("script")))&&"onbeforeload"in t&&(n=!1,e.addEventListener("beforeload",function(e){if(e.target===t)n=!0;else if(!e.target.hasAttribute("nomodule")||!n)return;e.preventDefault()},!0),t.type="module",t.src=".",e.head.appendChild(t),t.remove())}(document) </script> <!-- 90+% of browsers: --> <script src="modern.js" type="module'></script> <!-- IE, Edge <16, Safari <10.1, old desktop: --> <script src="legacy.js" nomodule async defer></script> 

विधि चार: पैकेज शर्तें लागू करें

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

 <!-- newer browsers will not load this bundle: --> <script nomodule src="polyfills.js"></script> <!-- all browsers load this one: --> <script src="/bundle.js"></script> 

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

और यदि आप WebPack का उपयोग करते हैं, तो html-webpack-plugin लिए एक सुविधाजनक html-webpack-plugin , जो पॉलीफ़िल के साथ पैकेज में नाममात्र जोड़ना आसान बनाता है।

तो क्या चुनना है?

उत्तर आपकी स्थिति पर निर्भर करता है। यदि आप क्लाइंट एप्लिकेशन बना रहे हैं, और आपके HTML में <sript> तुलना में थोड़ा अधिक है, तो आपको पहली विधि की आवश्यकता हो सकती है।

यदि आप एक साइट बना रहे हैं जो सर्वर पर प्रदान की गई है, और आप कैशिंग का खर्च उठा सकते हैं, तो दूसरी विधि आपके लिए उपयुक्त हो सकती है।

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

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

क्या पढ़ना है?

इस विषय के बारे में अधिक जानना चाहते हैं? आप यहां से शुरू कर सकते हैं:

• Webpack-esnext-boilerplate पर महान अतिरिक्त जानकारी।
• नेक्स्ट.जेएस में राल्फ़ ने मॉड्यूल / नॉमिनेट किया और आम समस्याओं के समाधान पर काम कर रहा है।