अहम पाथ को समझना

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

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

प्रोग्रेसिव रेंडरिंग

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

जब ब्राउज़र के पास किसी पेज को रेंडर करने के लिए संसाधन मिल जाते हैं, तो आम तौर पर वह ऐसा करना शुरू कर देता है. इसलिए, इमेज को कब रेंडर करना है, यह विकल्प तय करने का समय यह है कि पेज को कब रेंडर करना है?

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

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

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

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

(ज़रूरी) रेंडरिंग पाथ

रेंडरिंग पाथ में ये चरण शामिल हैं:

  • एचटीएमएल से डॉक्यूमेंट ऑब्जेक्ट मॉडल (DOM) बनाना.
  • सीएसएस से सीएसएस ऑब्जेक्ट मॉडल (CSSOM) बनाना.
  • DOM या CSSOM में बदलाव करने वाला कोई भी JavaScript लागू करना.
  • DOM और CSSOM से रेंडर ट्री बनाना.
  • पेज पर स्टाइल और लेआउट से जुड़ी कार्रवाइयां करें, ताकि यह देखा जा सके कि कौनसे एलिमेंट कहां फ़िट होंगे.
  • मेमोरी में मौजूद एलिमेंट के पिक्सल पेंट करें.
  • अगर इनमें से कोई भी पिक्सल ओवरलैप करता है, तो पिक्सल को कंपोज़ करें.
  • सभी मिलने वाले पिक्सल को स्क्रीन पर फ़िज़िकल तौर पर बनाएं.
रेंडरिंग की प्रोसेस का डायग्राम, जैसा कि पिछली सूची में बताया गया है.

इन सभी चरणों को पूरा करने के बाद ही, उपयोगकर्ता को स्क्रीन पर कॉन्टेंट दिखेगा.

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

क्रिटिकल रेंडरिंग पाथ पर कौनसे संसाधन मौजूद हैं?

ब्राउज़र को कुछ ज़रूरी संसाधनों के डाउनलोड होने का इंतज़ार करना होगा, ताकि वह शुरुआती रेंडर पूरा कर सके. इन संसाधनों में इस तरह की जानकारी शामिल है:

  • यह एचटीएमएल का हिस्सा है.
  • <head> एलिमेंट में रेंडर होने वाले सीएसएस को ब्लॉक करें.
  • <head> एलिमेंट में JavaScript को रेंडर करने से रोकने वाला.

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

खास तौर पर, शुरुआती रेंडर के लिए, ब्राउज़र आम तौर पर इन बातों का इंतज़ार नहीं करेगा:

  • सभी एचटीएमएल.
  • फ़ॉन्ट.
  • छवियां.
  • <head> एलिमेंट के बाहर वह JavaScript जो रेंडर नहीं करता उसे ब्लॉक नहीं किया जा सकता. उदाहरण के लिए, एचटीएमएल के आखिर में रखे गए <script> एलिमेंट.
  • <head> एलिमेंट के बाहर रेंडर न करने वाला सीएसएस या media एट्रिब्यूट वाली ऐसी सीएसएस जो मौजूदा व्यूपोर्ट पर लागू नहीं होती.

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

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

हालांकि, यह ज़रूरी नहीं है कि <head> एलिमेंट में दिए गए सभी रिसॉर्स, पेज रेंडर होने के शुरुआती दौर में हों. इसलिए, ब्राउज़र सिर्फ़ उन रिसॉर्स का इंतज़ार करता है जो हैं. यह जानने के लिए कि ज़रूरी रेंडरिंग पाथ में कौनसे रिसॉर्स हैं, आपको रेंडर ब्लॉक करने वाले और पार्सर ब्लॉक करने वाले सीएसएस और JavaScript को समझना होगा.

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

कुछ रिसॉर्स को इतना ज़रूरी माना जाता है कि ब्राउज़र, पेज को तब तक रेंडर नहीं करता, जब तक वह ठीक नहीं हो जाता. सीएसएस डिफ़ॉल्ट रूप से इस कैटगरी में आता है.

जब किसी ब्राउज़र को सीएसएस दिखता है, तो चाहे वह <style> एलिमेंट में इनलाइन सीएसएस हो या <link rel=stylesheet href="..."> एलिमेंट से तय किया गया ऐसा रिसॉर्स जिसका बाहरी तौर पर संदर्भ दिया गया हो. ऐसे में ब्राउज़र, ज़्यादा कॉन्टेंट को तब तक रेंडर नहीं करता, जब तक कि वह उस सीएसएस को डाउनलोड और प्रोसेस नहीं कर लेता.

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

रेंडर होने से रोकने वाले रिसॉर्स, जैसे कि सीएसएस का इस्तेमाल, पेज का पता चलने पर, उसकी सभी रेंडरिंग को ब्लॉक करने के लिए किया जाता है. इसका मतलब है कि कुछ सीएसएस रेंडर होने की सुविधा को ब्लॉक कर रही हैं या नहीं, यह इस बात पर निर्भर करता है कि ब्राउज़र ने उन्हें ढूंढा है या नहीं. कुछ ब्राउज़र (शुरुआत में Firefox और अब Chrome भी) सिर्फ़ रेंडर को ब्लॉक करने वाले संसाधन के नीचे मौजूद कॉन्टेंट को रेंडर करने से रोकते हैं. इसका मतलब है कि रेंडर होने के ज़रूरी पाथ के लिए, आम तौर पर हमारी दिलचस्पी <head> में रेंडर रोकने वाले रिसॉर्स में होती है, क्योंकि वे पूरे पेज को रेंडर होने से असरदार तरीके से ब्लॉक करते हैं.

हाल ही का एक इनोवेशन है blocking=render एट्रिब्यूट, जिसे Chrome 105 में जोड़ा गया है. इससे डेवलपर, <link>, <script> या <style> एलिमेंट को साफ़ तौर पर तब तक रेंडर करने वाले ब्लॉक करने वाले विकल्प के तौर पर मार्क कर सकते हैं, जब तक कि एलिमेंट प्रोसेस नहीं हो जाता. हालांकि, इस दौरान पार्सर को दस्तावेज़ प्रोसेस करने की अनुमति मिल जाती है.

पार्सर रोकने वाले संसाधन

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

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

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

ब्लॉक करने वाले संसाधनों की पहचान करना

कई परफ़ॉर्मेंस ऑडिटिंग टूल, रेंडर और पार्सर ब्लॉक करने वाले संसाधनों की पहचान करते हैं. WebPageTest संसाधन के यूआरएल की बाईं ओर नारंगी रंग के गोले से रेंडर रोकने वाले संसाधनों को मार्क करता है:

WebPageTest से जनरेट किए गए नेटवर्क वॉटरफ़ॉल डायग्राम का स्क्रीनशॉट. पार्सर को रोकने वाले रिसॉर्स को रिसॉर्स के यूआरएल की बाईं ओर नारंगी रंग के सर्कल से नोट किया जाता है और रेंडर होने के शुरू होने के समय की पहचान एक गहरी हरी लाइन से की जाती है.

रेंडर होने से पहले, रेंडर करने वाले सभी संसाधनों को डाउनलोड और प्रोसेस करना ज़रूरी होगा. वॉटरफ़ॉल में गहरे हरे रंग की लाइन से इसका पता चलता है.

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

रेंडर ब्लॉक करने वाले संसाधनों को हटाने के लिए, Lighthouse के ऑडिट का स्क्रीनशॉट. ऑडिट में वे संसाधन दिखते हैं जो रेंडरिंग ब्लॉक करते हैं. साथ ही, इससे यह भी पता चलता है कि वे कितने समय के लिए ब्लॉक करते हैं.

ज़रूरी रेंडरिंग पाथ को ऑप्टिमाइज़ करना

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

ज़रूरी कॉन्टेंटफ़ुल रेंडरिंग पाथ

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

दूसरा तरीका यह है कि कॉन्टेंटफ़ुल रेंडरिंग पाथ या मुख्य पाथ के हिस्से के तौर पर, सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) या फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) तक के समय पर ध्यान दिया जाए, जैसा कि दूसरे लोग इसे कॉल कर सकते हैं. इस मामले में, आपको ऐसे रिसॉर्स शामिल करने पड़ सकते हैं जो ज़रूरी रूप से ब्लॉक न हों, क्योंकि क्रिटिकल रेंडरिंग पाथ की सामान्य परिभाषा रही है, लेकिन कॉन्टेंटफ़ुल पेंट बनाने के लिए ज़रूरी हैं.

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

कॉन्टेंटफ़ुल रेंडरिंग पाथ की पहचान करना

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

Lighthouse के एलसीपी ऑडिट का स्क्रीनशॉट, जिसमें पेज का एलसीपी एलिमेंट दिखाया जाता है. साथ ही, इसमें यह भी दिखाया जाता है कि इस चरण में कितना समय बीता, जैसे कि टीटीएफ़बी, लोड में लगा समय, लोड होने में लगने वाला समय, और रेंडर होने में लगने वाला समय.

ज़्यादा जटिल साइटों के लिए, Lighthouse अहम अनुरोधों की चेन को भी हाइलाइट करता है, जिसके लिए अलग से ऑडिट किया जाता है:

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

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

देखें कि आपको कितना ज्ञान है

क्रिटिकल रेंडरिंग पाथ का क्या मतलब है?

किसी पेज को पूरी तरह से रेंडर करने के लिए ज़रूरी संसाधनों की कम से कम संख्या.
फिर से कोशिश करें.
शुरुआती पेज रेंडर करने के लिए ज़रूरी संसाधनों की कम से कम संख्या.
सही जवाब!

क्रिटिकल रेंडरिंग पाथ में कौनसे संसाधन शामिल हैं?

यह एचटीएमएल का हिस्सा है.
सही जवाब!
<head> एलिमेंट में रेंडर होने वाले सीएसएस को ब्लॉक करें.
सही जवाब!
<head> एलिमेंट में JavaScript को रेंडर करने से रोकने वाला.
सही जवाब!

पेज रेंडरिंग का एक ज़रूरी हिस्सा रेंडर पर रोक लगाना क्यों ज़रूरी है?

किसी पेज को शुरुआत में, इस्तेमाल न की जा सकने वाली या साफ़ तौर पर काम न करने वाली स्थिति में रेंडर होने से रोकने के लिए.
सही जवाब!
पूरी तरह रेंडर होने तक उपयोगकर्ताओं को पेज देखने से रोकने के लिए.
फिर से कोशिश करें.

JavaScript, एचटीएमएल पार्सर को क्यों ब्लॉक करता है (यह मानते हुए कि defer, async या module एट्रिब्यूट को <script> एलिमेंट पर नहीं बताया गया है)?

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

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

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