इस पेज का अनुवाद Cloud Translation API से किया गया है.

अहम रेंडरिंग पाथ की परफ़ॉर्मेंस का विश्लेषण करना

Ilya Grigorik

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

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

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

अब तक, हमने खास तौर पर इस बात पर ध्यान दिया है कि संसाधन (CSS, JS या HTML फ़ाइल) के प्रोसेस होने के लिए उपलब्ध होने के बाद, ब्राउज़र में क्या होता है. हमने कैश मेमोरी से या नेटवर्क से रिसॉर्स को फ़ेच करने में लगने वाले समय को अनदेखा कर दिया है. हम यह मान लेंगे:

सर्वर तक एक नेटवर्क राउंडट्रिप (प्रसारण में लगने वाला समय) का शुल्क 100 मि॰से॰ है.
एचटीएमएल दस्तावेज़ के लिए सर्वर प्रतिक्रिया समय 100 मि.से. और दूसरी सभी फ़ाइलों के लिए 10 मि.से. है.

हैलो वर्ल्ड एक्सपीरियंस

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <title>Critical Path: No Style</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

इसे आज़माएँ

हम बेसिक एचटीएमएल मार्कअप और एक इमेज से शुरुआत करेंगे; कोई सीएसएस या JavaScript नहीं. चलिए, Chrome DevTools में अपनी नेटवर्क टाइमलाइन खोलें और इससे मिले रिसॉर्स वॉटरफ़ॉल की जांच करें:

CRP

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

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

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

हालांकि, load इवेंट (इसे onload के नाम से भी जाना जाता है) को इमेज पर ब्लॉक किया गया है: DevTools 335 मि॰से॰ में onload इवेंट की रिपोर्ट करता है. याद रखें कि onload इवेंट, उस पॉइंट को दिखाता है जहां पेज को डाउनलोड और प्रोसेस करने के लिए ज़रूरी सभी संसाधन हैं. इसके बाद, लोडिंग स्पिनर, ब्राउज़र (वॉटरफ़ॉल में लाल रंग की वर्टिकल लाइन) में घूमना बंद कर सकता है.

मिक्स में JavaScript और सीएसएस जोड़ना

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

<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure Script</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body onload="measureCRP()">
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="timing.js"></script>
  </body>
</html>

इसे आज़माएँ

JavaScript और सीएसएस जोड़ने से पहले:

डीओएम सीआरपी

JavaScript और सीएसएस की मदद से:

डीओएम, सीएसएसओएम, जीएस

बाहरी सीएसएस और JavaScript फ़ाइलें जोड़ने से, हमारे वॉटरफ़ॉल में दो और अनुरोध जुड़ जाते हैं. इनमें से सभी अनुरोध, ब्राउज़र एक ही समय पर भेज देते हैं. हालांकि, ध्यान दें कि अब domContentLoaded और onload इवेंट के समय का अंतर काफ़ी कम है.

इसकी क्या वजह है?

हमारे सामान्य एचटीएमएल वाले उदाहरण के उलट, हमें CSSOM बनाने के लिए, सीएसएस फ़ाइल को फ़ेच और पार्स करने की भी ज़रूरत होती है. साथ ही, रेंडर ट्री बनाने के लिए हमें DOM और CSSOM, दोनों की ज़रूरत होती है.
पेज में एक पार्सर को ब्लॉक करने वाली JavaScript फ़ाइल भी है, इसलिए domContentLoaded इवेंट को तब तक ब्लॉक रखा जाता है, जब तक सीएसएस फ़ाइल को डाउनलोड और पार्स नहीं किया जाता. ऐसा इसलिए है, क्योंकि JavaScript, CSSOM से क्वेरी कर सकता है, इसलिए JavaScript को चलाने से पहले, हमें CSS फ़ाइल के डाउनलोड होने तक ब्लॉक करना होगा.

अगर हम अपनी बाहरी स्क्रिप्ट को इनलाइन स्क्रिप्ट से बदल दें, तो क्या होगा? स्क्रिप्ट सीधे पेज में इनलाइन की गई होने पर भी, ब्राउज़र इसे तब तक नहीं चला सकता, जब तक कि CSSOM नहीं बन जाता. कम शब्दों में कहें, तो इनलाइन JavaScript भी पार्सर ब्लॉकिंग है.

इसका मतलब है कि CSS पर ब्लॉक होने के बावजूद, क्या स्क्रिप्ट इनलाइन करने से पेज तेज़ी से रेंडर होता है? चलिए इसे आज़माकर देखते हैं, क्या होता है.

बाहरी JavaScript:

डीओएम, सीएसएसओएम, जीएस

इनलाइन किया गया JavaScript:

DOM, CSSOM, और इनलाइन JS

हम एक बार कम अनुरोध कर रहे हैं, लेकिन onload और domContentLoaded, दोनों का समय काफ़ी हद तक एक जैसा है. ऐसा क्यों हो रहा है? हम जानते हैं कि JavaScript को इनलाइन या बाहरी तौर पर सेट करने से कोई फ़र्क़ नहीं पड़ता, क्योंकि जैसे ही ब्राउज़र, स्क्रिप्ट टैग को हिट करता है वह ब्लॉक हो जाता है और CSSOM के बनने तक इंतज़ार करता है. इसके अलावा, हमारे पहले उदाहरण में बताया गया है कि ब्राउज़र, सीएसएस और JavaScript, दोनों को साथ-साथ डाउनलोड करता है और वे करीब-करीब एक ही समय पर डाउनलोड पूरा करते हैं. इस मामले में, JavaScript कोड को इनलाइन करने से ज़्यादा मदद नहीं मिलती. हालांकि, ऐसी कई रणनीतियां हैं जिनकी मदद से हमारे पेज को तेज़ी से रेंडर किया जा सकता है.

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

<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure Async</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body onload="measureCRP()">
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script async src="timing.js"></script>
  </body>
</html>

इसे आज़माएँ

पार्सर ब्लॉक करने वाला (बाहरी) JavaScript:

डीओएम, सीएसएसओएम, जीएस

एक साथ काम नहीं करने वाली (बाहरी) JavaScript:

DOM, CSSOM, एक साथ काम नहीं करने वाला JS

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

इसके अलावा, हम सीएसएस और JavaScript, दोनों को इनलाइन कर सकते थे:

<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure Inlined</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <style>
      p {
        font-weight: bold;
      }
      span {
        color: red;
      }
      p span {
        display: none;
      }
      img {
        float: right;
      }
    </style>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script>
      var span = document.getElementsByTagName('span')[0];
      span.textContent = 'interactive'; // change DOM text content
      span.style.display = 'inline'; // change CSSOM property
      // create a new element, style it, and append it to the DOM
      var loadTime = document.createElement('div');
      loadTime.textContent = 'You loaded this page on: ' + new Date();
      loadTime.style.color = 'blue';
      document.body.appendChild(loadTime);
    </script>
  </body>
</html>

इसे आज़माएँ

डीओएम, इनलाइन सीएसएस, इनलाइन JS

ध्यान दें कि domContentLoaded समय, पिछले उदाहरण की तरह ही है. हमने अपने JavaScript को एक साथ काम नहीं करने वाली प्रोसेस के तौर पर मार्क करने के बजाय, CSS और JS दोनों को पेज में ही इनलाइन कर दिया है. इससे हमारा एचटीएमएल पेज काफ़ी बड़ा हो जाता है, लेकिन इसका उलटा यह होता है कि ब्राउज़र को किसी बाहरी रिसॉर्स को फ़ेच करने के लिए इंतज़ार नहीं करना पड़ता; पेज में सब कुछ वहीं पर होता है.

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

आइए, देखते हैं कि क्या हम वापस जाकर परफ़ॉर्मेंस के कुछ सामान्य पैटर्न की पहचान कर सकते हैं.

परफ़ॉर्मेंस के पैटर्न

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

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <title>Critical Path: No Style</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

इसे आज़माएँ

नमस्ते वर्ल्ड सीआरपी

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

चलिए, अब बाहरी सीएसएस फ़ाइल की मदद से भी उसी पेज को देखते हैं:

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

इसे आज़माएँ

DOM + CSSOM सीआरपी

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

आइए, वह शब्दावली तय करें जिसका इस्तेमाल हम क्रिटिकल रेंडरिंग पाथ के बारे में बताने के लिए करते हैं:

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

आइए, अब इसकी तुलना, ऊपर दिए गए एचटीएमएल + सीएसएस के उदाहरण के क्रिटिकल पाथ एट्रिब्यूट से करें:

DOM + CSSOM सीआरपी

2 अहम संसाधन
पाथ की कम से कम ज़रूरी लंबाई के लिए 2 या इससे ज़्यादा राउंडट्रिप
क्रिटिकल बाइट का 9 केबी

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

अब आइए मिक्स में एक और JavaScript फ़ाइल जोड़ते हैं.

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="app.js"></script>
  </body>
</html>

इसे आज़माएँ

हमने app.js जोड़ा है, जो पेज पर मौजूद बाहरी JavaScript ऐसेट है. साथ ही, यह पार्सर ब्लॉकिंग (जो कि ज़रूरी है) रिसॉर्स भी है. इससे भी बुरा यह है कि JavaScript फ़ाइल को चलाने के लिए हमें ब्लॉक करना पड़ता है और CSSOM के लिए इंतज़ार करना पड़ता है; याद रखें कि JavaScript, CSSOM पर क्वेरी कर सकता है और इसलिए ब्राउज़र style.css के डाउनलोड होने और CSSOM बनने तक रुक जाता है.

DOM, CSSOM, JavaScript सीआरपी

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

3 अहम संसाधन
पाथ की कम से कम ज़रूरी लंबाई के लिए 2 या इससे ज़्यादा राउंडट्रिप
क्रिटिकल बाइट का 11 केबी

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

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

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="app.js" async></script>
  </body>
</html>

इसे आज़माएँ

DOM, CSSOM, एसिंक्रोनस JavaScript सीआरपी

एसिंक्रोनस स्क्रिप्ट के कई फ़ायदे हैं:

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

इस वजह से, ऑप्टिमाइज़ किया गया हमारा पेज अब दो अहम रिसॉर्स (एचटीएमएल और सीएसएस) पर वापस आ गया है. इनकी पाथ लंबाई कम से कम दो राउंडट्रिप और कुल 9 केबी है.

आख़िर में, अगर सीएसएस स्टाइलशीट की ज़रूरत सिर्फ़ प्रिंट के लिए होती, तो वह कैसा दिखता?

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" media="print" />
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="app.js" async></script>
  </body>
</html>

इसे आज़माएँ

डीओएम, ब्लॉक न करने वाला सीएसएस, और एक साथ काम नहीं करने वाली JavaScript सीआरपी

क्योंकि style.css रिसॉर्स का इस्तेमाल सिर्फ़ प्रिंट करने के लिए किया जाता है. इसलिए, पेज को रेंडर करने के लिए ब्राउज़र को उस पर ब्लॉक करने की ज़रूरत नहीं होती. इसलिए, DOM के निर्माण पूरा होते ही, ब्राउज़र में पेज को रेंडर करने के लिए ज़रूरी जानकारी इकट्ठा हो जाती है. इस वजह से, इस पेज पर सिर्फ़ एक ज़रूरी रिसॉर्स (एचटीएमएल दस्तावेज़) है. साथ ही, रेंडरिंग पाथ की कम से कम ज़रूरी लंबाई एक राउंडट्रिप है.

अहम रेंडरिंग पाथ की परफ़ॉर्मेंस का विश्लेषण करना

हैलो वर्ल्ड एक्सपीरियंस

मिक्स में JavaScript और सीएसएस जोड़ना

परफ़ॉर्मेंस के पैटर्न

सुझाव/राय दें या शिकायत करें