संसाधन लोड करना ऑप्टिमाइज़ करें

पिछले मॉड्यूल में, क्रिटिकल रेंडरिंग पाथ के पीछे कुछ सिद्धांत था एक्सप्लोर किया है और रेंडर-ब्लॉकिंग और पार्सर-ब्लॉक करने वाले संसाधनों से शुरुआती रेंडरिंग के दौरान, अब आपको पता चल गया है कि इसके पीछे की थ्योरी क्या है इसके बाद, आप कीवर्ड को ऑप्टिमाइज़ करने के लिए रेंडरिंग पाथ.

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

रेंडर होने से रोकना

जैसा कि पिछले मॉड्यूल में बताया गया था, सीएसएस, render-blocking संसाधन है. क्योंकि यह ब्राउज़र को सीएसएस ऑब्जेक्ट मॉडल तक, कोई भी कॉन्टेंट रेंडर करने से रोकता है (CSSOM) को बनाया गया है. ब्राउज़र इस तरह की फ़्लैश बिना स्टाइल वाला कॉन्टेंट (एफ़ओयूसी), जो उपयोगकर्ता अनुभव के लिहाज़ से अच्छा नहीं होता है.

पिछले वीडियो में, एक छोटा एफ़ओयूसी दिया गया है. इसमें पेज को बिना इस्तेमाल करते हैं. इसके बाद, पेज का सीएसएस होने के बाद, सभी स्टाइल लागू कर दिए जाते हैं पूरी तरह से लोड होता है और पेज का बिना स्टाइल वाला वर्शन होता है तुरंत स्टाइल वर्शन से बदल दिया गया.

आम तौर पर, FOUC कुछ ऐसा है जिसे आप आमतौर पर नहीं देखते, बल्कि को समझना ज़रूरी है, ताकि आपको पता चल सके कि ब्राउज़र रेंडरिंग को क्यों ब्लॉक करता है जब तक कि सीएसएस डाउनलोड करके पेज पर लागू नहीं हो जाता. रेंडर होने से रोकना अवांछनीय नहीं है, लेकिन आपको इसके कार्य करने की अवधि कम करनी है आपकी सीएसएस को ऑप्टिमाइज़ करती रहेगी.

पार्सर ब्लॉक करना

पार्सर ब्लॉक करने वाला संसाधन, एचटीएमएल पार्सर को बाधित कर देता है, जैसे कि <script> async या defer विशेषताओं के बिना एलिमेंट. जब पार्सर को <script> एलिमेंट है, तो ब्राउज़र को पहले स्क्रिप्ट का आकलन करना होगा और उसे एक्ज़ीक्यूट करना होगा और बाकी एचटीएमएल को पार्स करने की प्रोसेस शुरू करें. इसे डिज़ाइन के मुताबिक बनाया गया है, क्योंकि स्क्रिप्ट DOM को तब भी संशोधित या ऐक्सेस किया जा सकता है, जब उसे बनाया जा रहा हो.

<!-- This is a parser-blocking script: -->
<script src="/script.js"></script>

बाहरी JavaScript फ़ाइलों का इस्तेमाल करते समय (async या defer के बिना), यह पार्सर होता है फ़ाइल के डाउनलोड होने, पार्स होने, और लागू किया गया. इनलाइन JavaScript का इस्तेमाल करने पर, पार्सर इसी तरह से ब्लॉक रहता है इनलाइन स्क्रिप्ट को पार्स किया जाता है और एक्ज़ीक्यूट किया जाता है.

ध्यान दें: पार्सर को ब्लॉक करने वाले <script> को यह ज़रूरी है साथ ही, फ़्लाइट में रेंडर होने से रोकने वाले सीएसएस रिसॉर्स के आने और जाने का इंतज़ार करें इसे ब्राउज़र द्वारा निष्पादित किए जाने से पहले पार्स किया गया होता है. इसे स्क्रिप्ट के तौर पर डिज़ाइन में भी बनाया गया है रेंडर ब्लॉक करने की स्टाइल शीट में बताए गए स्टाइल ऐक्सेस कर सकता है (उदाहरण के लिए, element.getComputedStyle() का इस्तेमाल करके).

प्रीलोड स्कैनर

प्रीलोड स्कैनर, सेकंडरी एचटीएमएल के रूप में ब्राउज़र ऑप्टिमाइज़ेशन है यह पार्सर, रॉ एचटीएमएल के रिस्पॉन्स को स्कैन करता है, ताकि उसे ढूंढा जा सके और अनुमान के हिसाब से फ़ेच किया जा सके संसाधनों को फिर से खोज सकता है. इसके लिए उदाहरण के लिए, प्रीलोड स्कैनर से ब्राउज़र को किसी <img> एलिमेंट में दिया गया संसाधन, एचटीएमएल पार्सर के ब्लॉक होने पर भी सीएसएस और JavaScript जैसे संसाधनों को फ़ेच और प्रोसेस करते समय.

प्रीलोड स्कैनर का फ़ायदा लेने के लिए, ज़रूरी संसाधनों को शामिल किया जाना चाहिए सर्वर से भेजे गए एचटीएमएल मार्कअप में. संसाधन लोड होने के ये पैटर्न हैं इसे प्रीलोड स्कैनर नहीं खोज सकता:

• background-image प्रॉपर्टी का इस्तेमाल करके, सीएसएस ने इमेज लोड की हैं. ये इमेज रेफ़रंस, सीएसएस में होते हैं और उन्हें प्रीलोड स्कैनर से नहीं ढूंढा जा सकता.
• <script> एलिमेंट मार्कअप के तौर पर, डाइनैमिक तौर पर लोड की जाने वाली स्क्रिप्ट इंजेक्ट की गईं JavaScript या डाइनैमिक import() का इस्तेमाल करके लोड किए गए मॉड्यूल का इस्तेमाल करके, डीओएम में शामिल होना चाहिए.
• JavaScript का इस्तेमाल करके, क्लाइंट पर रेंडर किया गया एचटीएमएल. ऐसा मार्कअप इसमें शामिल होता है स्ट्रिंग को JavaScript संसाधनों में स्ट्रिंग के रूप में नहीं दिखाता है. साथ ही, उसे पहले से लोड किए जाने की वजह से, खोजा नहीं जा सकता है स्कैनर.
• सीएसएस @import के बारे में एलान.

संसाधन लोड होने के ये सभी पैटर्न, देर से खोजे गए संसाधन हैं. इसलिए, को प्रीलोड स्कैनर से फ़ायदा नहीं मिलता है. जब भी हो सके, इनसे बचें. अगर आपने इस तरह के पैटर्न से बचना नहीं संभव है. हालाँकि, आपके पास रिसॉर्स खोजने में होने वाली देरी से बचने के लिए preload संकेत.

ध्यान दें: preload संसाधन संकेत शामिल है संसाधन के अगले मॉड्यूल में संकेत.

सीएसएस

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

छोटा करना

सीएसएस फ़ाइलों को छोटा करने से, सीएसएस रिसॉर्स की फ़ाइल का साइज़ कम हो जाता है, जिससे वे तेज़ी से डाउनलोड करने के लिए किया जा सकता है. यह प्राथमिक रूप से किसी सोर्स सीएसएस फ़ाइल, जैसे कि स्पेस और न दिखने वाले दूसरे वर्ण और आउटपुट एक नई ऑप्टिमाइज़ की गई फ़ाइल का परिणाम:

/* Unminified CSS: */

/* Heading 1 */
h1 {
  font-size: 2em;
  color: #000000;
}

/* Heading 2 */
h2 {
  font-size: 1.5em;
  color: #000000;
}

/* Minified CSS: */
h1,h2{color:#000}h1{font-size:2em}h2{font-size:1.5em}

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

अपने मूल रूप में, सीएसएस छोटा करना एक असरदार ऑप्टिमाइज़ेशन है. यह अपनी वेबसाइट के एफ़सीपी और कुछ मामलों में एलसीपी भी सुधारना होगा. ऐसे टूल बंडलर आपके लिए प्रोडक्शन में अपने-आप यह ऑप्टिमाइज़ेशन कर सकते हैं बिल्ड.

इस्तेमाल नहीं की गई सीएसएस को हटाएं

कोई भी कॉन्टेंट रेंडर करने से पहले, ब्राउज़र को पूरा कॉन्टेंट डाउनलोड और पार्स करना होगा स्टाइल शीट. पार्स करने में लगने वाले समय में वे स्टाइल भी शामिल हैं जो जो मौजूदा पेज पर इस्तेमाल नहीं किए गए हों. अगर किसी ऐसे बंडलर का इस्तेमाल किया जा रहा है जिसमें सभी सीएसएस शामिल हैं संसाधनों को एक फ़ाइल में एक्सपोर्ट करते हैं, तो हो सकता है कि आपके उपयोगकर्ता जो मौजूदा पेज को रेंडर करने के लिए ज़रूरी होते हैं.

मौजूदा पेज के लिए इस्तेमाल नहीं की गई सीएसएस का पता लगाने के लिए, Chrome में कवरेज टूल का इस्तेमाल करें DevTools.

Chrome DevTools में कवरेज टूल की मदद से, सीएसएस का पता लगाया जा सकता है (और JavaScript) का मौजूदा पेज पर इस्तेमाल नहीं किया गया. इसका इस्तेमाल सीएसएस फ़ाइलों को बांटने के लिए किया जा सकता है एक से ज़्यादा रिसॉर्स में बदल दिया जाए, ताकि उन्हें अलग-अलग पेजों पर लोड किया जा सके. बहुत बड़ा सीएसएस बंडल शिप करना. इससे पेज को रेंडर होने में देरी हो सकती है.

इस्तेमाल नहीं की गई सीएसएस को हटाने से दो तरह के नतीजे दिखते हैं: डाउनलोड की संख्या कम करने के साथ-साथ समय की मदद से, रेंडर ट्री कंस्ट्रक्शन को ऑप्टिमाइज़ किया जा रहा हो, क्योंकि ब्राउज़र को सीएसएस के कुछ नियमों को प्रोसेस न करें.

अहम जानकारी: आपके संगठन की बनावट के हिसाब से इस्तेमाल नहीं किए गए सीएसएस को पूरी तरह से खत्म नहीं किया जा सकता है, तो हो सकता है कि जिसकी आपको उम्मीद हो. बड़ी जीत पर ध्यान दें: अगर आपको किसी सीएसएस फ़ाइल का बड़ा हिस्सा दिखता है, मौजूदा पेज पर इसका इस्तेमाल नहीं किया गया है, तो हो सकता है कि इसका इस्तेमाल किसी और पेज पर किया गया हो (जिसे आप पूरी तरह से किसी दूसरी फ़ाइल पर ले जा सकते हैं) या इन्हें पूरी तरह से मिटाया जा सकता है, अगर अब आपके प्रोजेक्ट में सीएसएस का इस्तेमाल नहीं किया जा रहा है.

सीएसएस के @import एलानों से बचें

यह सुविधाजनक लग सकता है, लेकिन आपको सीएसएस में @import एलान से बचना चाहिए:

/* Don't do this: */
@import url('style.css');

जिस तरह एचटीएमएल में <link> एलिमेंट काम करता है, उसी तरह @import का एलान आप किसी स्टाइल शीट में से बाहरी सीएसएस रिसॉर्स इंपोर्ट कर सकते हैं. कॉन्टेंट बनाने इन दोनों तरीकों में बड़ा अंतर यह है कि एचटीएमएल <link> एलिमेंट एचटीएमएल रिस्पॉन्स का हिस्सा होता है, और इसलिए इसका पता सीएसएस से बहुत पहले चला जाता है इस फ़ाइल को @import के एलान के ज़रिए डाउनलोड किया गया है.

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

<!-- Do this instead: -->
<link rel="stylesheet" href="style.css">

ज़्यादातर मामलों में, आप किसी@import <link rel="stylesheet"> एलिमेंट. <link> एलिमेंट, स्टाइल शीट को अनुमति देते हैं एक साथ डाउनलोड किया जाता है. इससे लोड होने में लगने वाला कुल समय कम होता है, जबकि @import के मुकाबले यह समय कम होता है एलानों, जो स्टाइल शीट को लगातार डाउनलोड करते हैं.

ध्यान दें: अगर आपको @import का इस्तेमाल करना हो, जैसे कि कैस्केड लेयर या तीसरे पक्ष की स्टाइल शीट—का इस्तेमाल करके, देरी को कम किया जा सकता है इंपोर्ट की गई स्टाइल शीट के लिए preload डायरेक्टिव. इसके अलावा, सीएसएस प्रीप्रोसेसर—जैसे कि SASS या LESS—आम तौर पर @import का इस्तेमाल करते हैं सिंटैक्स की मदद से, और मॉड्यूलर वाली सोर्स फ़ाइलें शामिल की जाएंगी. हालांकि, जब किसी सीएसएस प्रीप्रोसेसर को @import एलानों के तहत, रेफ़र की गई फ़ाइलों को बंडल किया जाता है और एक स्टाइल शीट में लिखा जाना चाहिए. इसमें बार-बार अनुरोध करने पर जुर्माना नहीं लगता जो @import सामान्य सीएसएस में होती है.

ज़रूरी सीएसएस इनलाइन करें

सीएसएस फ़ाइलों को डाउनलोड होने में लगने वाले समय से पेज का एफ़सीपी बढ़ सकता है. इनलाइन करना <head> दस्तावेज़ की महत्वपूर्ण स्टाइल, सीएसएस रिसॉर्स, और—सही तरीके से इस्तेमाल किए जाने पर—शुरुआत में लोड होने में लगने वाले समय को कम कर सकता है, जब उपयोगकर्ता के ब्राउज़र की कैश मेमोरी प्राइम नहीं की गई है. बाकी सीएसएस को लोड किया जा सकता है एसिंक्रोनस तरीके से या <body> एलिमेंट के आखिर में जोड़ा जाता है.

मुख्य शब्द: क्रिटिकल सीएसएस, उन स्टाइल के बारे में बताते हैं जो इन कामों के लिए ज़रूरी होते हैं ऐसे कॉन्टेंट को रेंडर करना जो शुरुआती व्यूपोर्ट में दिखता है. नाम का पहला अक्षर व्यूपोर्ट सिद्धांत को कभी-कभी "पेज के ऊपरी हिस्से" भी कहा जाता है. शेष बाकी सीएसएस के लोड होने पर, पेज के कॉन्टेंट बिना स्टाइल के रह जाते हैं एसिंक्रोनस रूप से.

<head>
  <title>Page Title</title>
  <!-- ... -->
  <style>h1,h2{color:#000}h1{font-size:2em}h2{font-size:1.5em}</style>
</head>
<body>
  <!-- Other page markup... -->
  <link rel="stylesheet" href="non-critical.css">
</body>

अहम जानकारी: ज़रूरी स्टाइल एक्सट्रैक्ट करना और उन्हें बनाए रखना मुश्किल हो सकता है. कौनसी शैलियां शामिल की जानी चाहिए? कौनसा व्यूपोर्ट होना चाहिए लक्षित करता है? क्या इस प्रोसेस को ऑटोमेट किया जा सकता है? जब कोई व्यक्ति नीचे की ओर स्क्रोल करता है, तो क्या होता है गैर-ज़रूरी सीएसएस के लोड होने से पहले? उपयोगकर्ताओं पर इसका क्या असर पड़ता है, अगर वे क्या आपने FOUC के साथ काम किया है? ये सभी अच्छे सवाल हैं, जिन्हें ध्यान में रखना चाहिए, क्योंकि आपकी वेबसाइट के डिज़ाइन में, ज़रूरी सीएसएस का इस्तेमाल मुश्किल. हालांकि, कुछ मामलों में परफ़ॉर्मेंस को बेहतर बनाने के लिए, मेहनत करने की ज़रूरत पड़ सकती है मामलों को चुनें, इसलिए इस बात की जांच करें कि क्या बेहद ज़रूरी सीएसएस आपके लिए एक बेहतर विकल्प है वेबसाइट!

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

सीएसएस डेमो

JavaScript

JavaScript से वेब पर की जाने वाली ज़्यादातर इंटरैक्टिविटी बढ़ती है. हालांकि, इसके लिए काफ़ी पैसे खर्च करने पड़ते हैं. JavaScript की बहुत ज़्यादा शिपिंग करना, आपके वेब पेज को पेज के दौरान धीरे जवाब दे सकता है लोड होता है और इससे रिस्पॉन्स करने में आने वाली समस्याएं भी हो सकती हैं. इससे इंटरैक्शन धीमा हो जाता है—दोनों जिससे उपयोगकर्ता परेशान हो सकते हैं.

रेंडर होने से रोकने वाली JavaScript

defer या async एट्रिब्यूट के बिना <script> एलिमेंट लोड करने पर, ब्राउज़र तब तक पार्स और रेंडर होने से रोकता है, जब तक स्क्रिप्ट डाउनलोड, पार्स, और लागू किया गया. इसी तरह, इनलाइन स्क्रिप्ट तब तक पार्सर को ब्लॉक करती हैं, जब तक स्क्रिप्ट को पार्स नहीं किया जाता और लागू किया गया.

async बनाम defer

async और defer, एचटीएमएल को ब्लॉक किए बिना बाहरी स्क्रिप्ट को लोड होने की अनुमति देते हैं पार्सर और type="module" के साथ स्क्रिप्ट (इनलाइन स्क्रिप्ट सहित) अपने-आप टाल दिया जाएगा. हालांकि, async और defer में कुछ अंतर है उन्हें समझना ज़रूरी है.

https://html.spec.whatwg.org/multipage/scripting.html से लिया गया है

async के साथ लोड की गई स्क्रिप्ट डाउनलोड होते ही पार्स की जाती हैं और तुरंत एक्ज़ीक्यूट की जाती हैं, जबकि defer से लोड की गई स्क्रिप्ट तब चलाई जाती हैं, जब एचटीएमएल दस्तावेज़ पार्स करना हो खत्म हो गया—यह ब्राउज़र के DOMContentLoaded इवेंट के साथ ही होता है. इसके अलावा, async स्क्रिप्ट गलत क्रम में काम कर सकती हैं, जबकि defer स्क्रिप्ट बिना किसी क्रम के लागू कर सकती हैं उसी क्रम में लागू किए जाते हैं जिस क्रम में वे मार्कअप में दिखते हैं.

नोट: type="module" एट्रिब्यूट डिफ़ॉल्ट रूप से टाल दिए जाते हैं, जबकि DOM में <script> मार्कअप इंजेक्ट करके लोड की गई स्क्रिप्ट JavaScript के साथ async स्क्रिप्ट की तरह व्यवहार करते हैं.

क्लाइंट-साइड रेंडरिंग

आम तौर पर, आपको किसी भी ज़रूरी कॉन्टेंट को रेंडर करने के लिए JavaScript का इस्तेमाल करने से बचना चाहिए या पेज के एलसीपी एलिमेंट में. इसे क्लाइंट-साइड रेंडरिंग कहा जाता है और यह एक ऐसी तकनीक है इसका इस्तेमाल सिंगल पेज ऐप्लिकेशन (एसपीए) में बड़े पैमाने पर किया जाता है.

JavaScript के रेंडर किए गए मार्कअप को रिसॉर्स के तौर पर, प्रीलोड स्कैनर को साइडस्टेप में ले जाया जाता है वह क्लाइंट के रेंडर किए गए मार्कअप में मौजूद कॉन्टेंट को खोज नहीं सकता. यह एलसीपी इमेज जैसे ज़रूरी संसाधनों के डाउनलोड में देरी हो सकती है. ब्राउज़र स्क्रिप्ट के एक्ज़ीक्यूट होने के बाद ही एलसीपी इमेज डाउनलोड होनी शुरू होती है एलिमेंट को DOM पर ले जाते हैं. इसके बाद, स्क्रिप्ट तब ही एक्ज़ीक्यूट की जा सकती है, जब खोजा, डाउनलोड, और पार्स किया गया है. इसे अहम अनुरोध के तौर पर जाना जाता है चेन होनी चाहिए और इससे बचना चाहिए.

इसके अलावा, JavaScript का इस्तेमाल करके मार्कअप को रेंडर करने से नेविगेशन के जवाब में, सर्वर से डाउनलोड किए गए मार्कअप की तुलना में लंबे टास्क अनुरोध. एचटीएमएल की क्लाइंट-साइड रेंडरिंग का बहुत ज़्यादा इस्तेमाल करने से, इंटरैक्शन के इंतज़ार का समय. यह खास तौर पर उन मामलों में सही होता है जहां किसी पेज का डीओएम बहुत बड़ा होता है, जो JavaScript में बदलाव करने पर काफ़ी रेंडरिंग काम ट्रिगर करता है DOM.

छोटा करना

सीएसएस की तरह ही, JavaScript को कम करने से स्क्रिप्ट रिसॉर्स की फ़ाइल का साइज़ कम हो जाता है. इससे ब्राउज़र तेज़ी से डाउनलोड हो सकता है और ब्राउज़र JavaScript को तेज़ी से पार्स और कंपाइल करने की प्रोसेस को पूरा किया.

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

// Unuglified JavaScript source code:
export function injectScript () {
  const scriptElement = document.createElement('script');
  scriptElement.src = '/js/scripts.js';
  scriptElement.type = 'module';

  document.body.appendChild(scriptElement);
}

पिछले JavaScript सोर्स कोड को बढ़ाने पर, नतीजा ऐसा दिख सकता है कोड स्निपेट जैसा कुछ:

// Uglified JavaScript production code:
export function injectScript(){const t=document.createElement("script");t.src="/js/scripts.js",t.type="module",document.body.appendChild(t)}

पिछले स्निपेट में, आप देख सकते हैं कि कोई ऐसा वैरिएबल जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है सोर्स में मौजूद scriptElement को बदलकर, t कर दिया गया है. जब बड़े पैमाने पर लागू किया जाता है बहुत ज़्यादा बचत की है, वह भी बिना किसी रुकावट के. किसी वेबसाइट के प्रोडक्शन JavaScript से मिलने वाली सुविधाएं.

अगर आपने अपनी वेबसाइट के सोर्स कोड को प्रोसेस करने के लिए बंडलर का इस्तेमाल किया है, तो प्रोडक्शन बिल्ड के लिए अक्सर अपने-आप काम कर दिया जाता है. यूगलीफ़ायर—जैसे कि Terser, उदाहरण के लिए—भी कॉन्फ़िगर किया जा सकता है, जिससे आपको ज़्यादा बचत के लिए, इस्तेमाल किए जाने वाले एल्गोरिदम की अहमियत. हालांकि, आम तौर पर किसी भी शिकायत करने वाले टूल की डिफ़ॉल्ट सेटिंग ही कॉपीराइट के उल्लंघन की शिकायत करने के लिए काफ़ी होती हैं आउटपुट साइज़ और क्षमताओं के संरक्षण के बीच सही संतुलन है.

JavaScript डेमो

अपने ज्ञान को परखें

ब्राउज़र में एक से ज़्यादा सीएसएस फ़ाइलों को लोड करने का सबसे सही तरीका क्या है?

सीएसएस @import का एलान.

फिर से कोशिश करें.

एक से ज़्यादा <link> एलिमेंट.

सही!

ब्राउज़र प्रीलोड स्कैनर क्या करता है?

यह एक सेकंडरी एचटीएमएल पार्सर है, जो रॉ मार्कअप की जांच करता है, ताकि संसाधनों को डीओएम पार्सर से पहले ढूंढ सकें, ताकि उन्हें जल्दी खोजा जा सके.

सही!

इसमें <link rel="preload"> एलिमेंट का पता लगाता है एक HTML संसाधन है.

फिर से कोशिश करें.

जब ब्राउज़र डिफ़ॉल्ट रूप से एचटीएमएल को पार्स करने की सुविधा को कुछ समय के लिए ब्लॉक करता है, तो ऐसा क्यों होता है JavaScript संसाधन डाउनलोड कर रहे हैं?

बिना स्टाइल वाले कॉन्टेंट का फ़्लैश (FOUC) रोकने के लिए.

फिर से कोशिश करें.

क्योंकि JavaScript का मूल्यांकन करना CPU का उपयोग करने वाला काफ़ी गंभीर काम है, इसलिए एचटीएमएल पार्स करने की सुविधा से, सीपीयू को स्क्रिप्ट लोड करने के लिए ज़्यादा बैंडविथ मिलता है.

फिर से कोशिश करें.

क्योंकि स्क्रिप्ट DOM में बदलाव कर सकती हैं या उसे किसी और तरीके से ऐक्सेस कर सकती हैं.

सही!

अगला: संसाधन संकेतों से ब्राउज़र की सहायता करना

अब जब आपके पास यह मैनेज करने की सुविधा है कि <head> एलिमेंट में लोड किए गए संसाधन कैसे काम कर सकते हैं शुरुआती पेज लोड और अलग-अलग मेट्रिक पर असर डालते हैं. यह आगे बढ़ने का समय है. अगले सेशन में मॉड्यूल, संसाधनों के संकेतों के बारे में पता किया गया है, और यह भी बताया गया है कि वे किस तरह अहम संकेत दे सकते हैं ब्राउज़र, संसाधनों को लोड करना और क्रॉस-ऑरिजिन से कनेक्शन खोलना शुरू करना ब्राउज़र से पहले के सर्वर पर हो सकता है, नहीं तो उनके बिना.