ब्राउज़र पेज को रेंडर कर सके, उससे पहले उसे DOM और CSSOM ट्री बनाना होगा. इस वजह से, हमें यह पक्का करना होगा कि हम ब्राउज़र को एचटीएमएल और सीएसएस, दोनों को जल्द से जल्द उपलब्ध कराएं.
खास जानकारी
- बाइट → वर्ण → टोकन → नोड → ऑब्जेक्ट मॉडल.
- एचटीएमएल मार्कअप को दस्तावेज़ ऑब्जेक्ट मॉडल (डीओएम) में बदल दिया जाता है. सीएसएस मार्कअप को सीएसएस ऑब्जेक्ट मॉडल (सीएसएसओएम) में बदला जाता है.
- DOM और CSSOM स्वतंत्र डेटा स्ट्रक्चर हैं.
- Chrome DevTools के परफ़ॉर्मेंस पैनल की मदद से, हम DOM और CSSOM को बनाने और प्रोसेस करने की लागत को कैप्चर करके उसकी जांच करते हैं.
डॉक्यूमेंट ऑब्जेक्ट मॉडल (DOM)
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width,initial-scale=1" />
<link href="style.css" rel="stylesheet" />
<title>Critical Path</title>
</head>
<body>
<p>Hello <span>web performance</span> students!</p>
<div><img src="awesome-photo.jpg" /></div>
</body>
</html>
चलिए, सबसे आसान केस से शुरुआत करते हैं: कुछ टेक्स्ट और एक इमेज वाला सादा एचटीएमएल पेज. ब्राउज़र इस पेज को कैसे प्रोसेस करता है?
- कन्वर्ज़न: ब्राउज़र, डिस्क या नेटवर्क से एचटीएमएल के रॉ बाइट पढ़ता है और फ़ाइल की तय की गई एन्कोडिंग के आधार पर उन्हें अलग-अलग वर्णों (जैसे कि UTF-8) में बदल देता है.
- टोकनाइज़ करना: ब्राउज़र वर्णों की स्ट्रिंग को अलग-अलग टोकन में बदलता है—जैसा कि W3C HTML5 स्टैंडर्ड में बताया गया है, जैसे कि "<html>", "<body>"—और ऐंगल ब्रैकेट में मौजूद अन्य स्ट्रिंग. हर टोकन का एक खास मतलब होता है और उसके अपने नियम होते हैं.
- Lexing: उत्सर्जित होने वाले टोकन "ऑब्जेक्ट" में बदल जाते हैं, जो उनकी प्रॉपर्टी और नियम तय करते हैं.
- डीओएम बनाना: एचटीएमएल मार्कअप अलग-अलग टैग (कुछ टैग दूसरे टैग में शामिल होते हैं) के बीच के संबंध तय करता है. इसलिए, बनाए गए ऑब्जेक्ट, ट्री डेटा स्ट्रक्चर में लिंक किए जाते हैं और ऑरिजनल मार्कअप में तय किए गए पैरंट-चाइल्ड संबंधों को भी कैप्चर करते हैं: एचटीएमएल ऑब्जेक्ट, बॉडी ऑब्जेक्ट का पैरंट है और body, पैराग्राफ़ ऑब्जेक्ट का पैरंट है. इस तरह, यह इसी तरह की अन्य चीज़ों में भी शामिल होता है.
इस पूरी प्रोसेस का आखिरी आउटपुट, हमारे आसान पेज का दस्तावेज़ ऑब्जेक्ट मॉडल (DOM) है. ब्राउज़र इसका इस्तेमाल, पेज को आगे की प्रोसेसिंग के लिए करता है.
जब भी ब्राउज़र एचटीएमएल मार्कअप को प्रोसेस करता है, तो ऊपर बताए गए सभी चरण पूरे किए जाते हैं: बाइट को वर्णों में बदलना, टोकन की पहचान करना, टोकन को नोड में बदलना, और डीओएम ट्री बनाना. इस पूरी प्रोसेस में कुछ समय लग सकता है, खास तौर पर तब, जब हमारे पास प्रोसेस करने के लिए बहुत ज़्यादा एचटीएमएल हो.
अगर आपने Chrome DevTools खोला है और पेज लोड होने के दौरान टाइमलाइन को रिकॉर्ड किया है, तो ऊपर दिए गए उदाहरण में यह देखा जा सकता है कि इस चरण को पूरा करने में कितना समय लगा. ऊपर दिए गए उदाहरण में, एचटीएमएल के एक हिस्से को डीओएम ट्री में बदलने में हमें करीब 5 मि॰से॰ का समय लगा. बड़े पेज के लिए, इस प्रोसेस में काफ़ी ज़्यादा समय लग सकता है. आसान ऐनिमेशन बनाते समय, अगर ब्राउज़र को बड़ी मात्रा में एचटीएमएल प्रोसेस करना पड़ता है, तो यह एक बड़ी समस्या बन सकता है.
डीओएम ट्री, दस्तावेज़ के मार्कअप के प्रॉपर्टी और संबंधों को कैप्चर करता है, लेकिन यह हमें यह नहीं बताता कि रेंडर किए जाने पर एलिमेंट कैसा दिखेगा. यह CSSOM की ज़िम्मेदारी है.
सीएसएस ऑब्जेक्ट मॉडल (CSSOM)
जब ब्राउज़र हमारे आसान पेज का DOM बना रहा था, तब उसे दस्तावेज़ के हेड सेक्शन में एक लिंक टैग मिला. यह लिंक, एक बाहरी सीएसएस स्टाइलशीट का रेफ़रंस देता है: style.css. हमें पता चलता है कि पेज को रेंडर करने के लिए इस रिसॉर्स की ज़रूरत है, तो वह इस संसाधन के लिए तुरंत अनुरोध भेजता है. अनुरोध के साथ यहां दिया गया कॉन्टेंट मिलता है:
body {
font-size: 16px;
}
p {
font-weight: bold;
}
span {
color: red;
}
p span {
display: none;
}
img {
float: right;
}
हम अपनी स्टाइल के बारे में सीधे एचटीएमएल मार्कअप (इनलाइन) में एलान कर सकते थे, लेकिन अपनी सीएसएस को एचटीएमएल से अलग रखने से, हम कॉन्टेंट और डिज़ाइन को अलग-अलग समस्याओं की तरह समझ सकते हैं: डिज़ाइनर, सीएसएस पर काम कर सकते हैं, डेवलपर एचटीएमएल पर फ़ोकस कर सकते हैं और इसी तरह आगे बढ़ सकते हैं.
एचटीएमएल की तरह, हमें मिले हुए सीएसएस नियमों को किसी ऐसी चीज़ में बदलना होता है जिसे ब्राउज़र समझ सके और उसके साथ काम कर सके. इसलिए, हम एचटीएमएल प्रोसेस को दोहराते हैं, लेकिन एचटीएमएल के बजाय सीएसएस के लिए:
सीएसएस बाइट को वर्णों में, फिर टोकन, फिर नोड में बदला जाता है. इसके बाद, उन्हें "सीएसएस ऑब्जेक्ट मॉडल" (CSSOM) नाम की ट्री स्ट्रक्चर में लिंक किया जाता है:
CSSOM की ट्री संरचना क्यों होती है? पेज पर किसी भी ऑब्जेक्ट के लिए शैलियों के आखिरी सेट का हिसाब लगाते समय, ब्राउज़र उस नोड पर लागू होने वाले सबसे सामान्य नियम से शुरू होता है (उदाहरण के लिए, अगर यह किसी बॉडी एलिमेंट का चाइल्ड है, तो सभी बॉडी स्टाइल लागू होती हैं). इसके बाद ज़्यादा खास नियमों को लागू करके तय की गई शैली को बार-बार बेहतर करता है; यानी "कैस्केड डाउन" नियम.
इसे और भी ठोस बनाने के लिए, ऊपर दिए गए CSSOM ट्री पर विचार करें. <span> टैग में मौजूद जो भी टेक्स्ट,
बॉडी एलिमेंट के अंदर होता है उसका फ़ॉन्ट साइज़ 16 पिक्सल होता है
और उसमें लाल रंग का टेक्स्ट होता है.
font-size डायरेक्टिव, body से span तक नीचे की ओर कैस्केड होता है. हालांकि, अगर span टैग किसी पैराग्राफ़ (p) टैग का चाइल्ड है, तो उसका कॉन्टेंट नहीं दिखाया जाता है.
साथ ही, ध्यान रखें कि ऊपर दिया गया ट्री, पूरा CSSOM ट्री नहीं है और सिर्फ़ वही स्टाइल दिखाता है जिसे हमने अपनी स्टाइलशीट में बदला है. हर ब्राउज़र, स्टाइल का एक डिफ़ॉल्ट सेट उपलब्ध कराता है, जिसे "उपयोगकर्ता एजेंट स्टाइल" भी कहते हैं. ऐसा तब होता है, जब हम अपना कोई भी सेट उपलब्ध नहीं कराते हैं—और हमारी स्टाइल, इन डिफ़ॉल्ट को बदल देती हैं.
सीएसएस प्रोसेसिंग में कितना समय लगता है, यह पता लगाने के लिए DevTool में टाइमलाइन को फिर से कैलकुलेट करें" इवेंट खोजें: डीओएम पार्सिंग के उलट, टाइमलाइन में अलग से "पार्स सीएसएस" एंट्री नहीं दिखती. इसके बजाय, यह पार्सिंग और CSSOM ट्री कंस्ट्रक्शन को कैप्चर करती है. साथ ही, इस एक इवेंट के तहत कंप्यूट किए गए स्टाइल का बार-बार कैलकुलेशन करती है.
हमारी छोटी सी स्टाइलशीट को प्रोसेस करने में ~0.6 मि॰से॰ का समय लगता है और पेज के आठ एलिमेंट पर इसका असर पड़ता है—ज़्यादा नहीं, लेकिन एक बार फिर, बिना किसी शुल्क के. हालांकि, आठ एलिमेंट कहां से आए हैं? CSSOM और DOM स्वतंत्र डेटा स्ट्रक्चर हैं! ऐसा लगता है कि ब्राउज़र किसी महत्वपूर्ण चरण को छिपा रहा है. इसके बाद, उस रेंडर ट्री के बारे में बात करते हैं जो DOM और CSSOM को एक साथ लिंक करता है.