पब्लिश किया गया: 31 मार्च, 2014
ब्राउज़र पेज को रेंडर कर सके, उससे पहले उसे DOM और CSSOM ट्री का निर्माण करना होगा. इसलिए, हमें यह पक्का करना होगा कि हम ब्राउज़र को एचटीएमएल और सीएसएस, दोनों को जल्द से जल्द डिलीवर करें.
खास जानकारी
- बाइट → वर्ण → टोकन → नोड → ऑब्जेक्ट मॉडल.
- एचटीएमएल मार्कअप को दस्तावेज़ ऑब्जेक्ट मॉडल (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>
सबसे आसान मामले से शुरू करें: कुछ टेक्स्ट और एक इमेज वाला सादा HTML पेज. ब्राउज़र इस पेज को कैसे प्रोसेस करता है?
- बदलाव: ब्राउज़र, डिस्क या नेटवर्क से एचटीएमएल के रॉ बाइट पढ़ता है और उन्हें फ़ाइल के तय किए गए कोड में बदलने के तरीके (उदाहरण के लिए, UTF-8) के आधार पर, अलग-अलग वर्णों में बदल देता है.
- टोकन बनाना: ब्राउज़र, वर्णों की स्ट्रिंग को अलग-अलग टोकन में बदल देता है. जैसे,
<html>,<body>. यह बदलाव, W3C के HTML5 स्टैंडर्ड के मुताबिक किया जाता है. साथ ही, ऐंगल ब्रैकेट में मौजूद अन्य स्ट्रिंग को भी बदला जाता है. हर टोकन का एक खास मतलब होता है और इसके लिए नियमों का एक सेट होता है. - लेक्सिंग: निकलने वाले टोकन को "ऑब्जेक्ट" में बदल दिया जाता है, जिससे उनकी प्रॉपर्टी और नियमों के बारे में पता चलता है.
- DOM बनाना: आखिर में, एचटीएमएल मार्कअप अलग-अलग टैग के बीच के संबंधों को तय करता है (कुछ टैग दूसरे टैग में होते हैं). इसलिए, बनाए गए ऑब्जेक्ट को ट्री डेटा स्ट्रक्चर में लिंक किया जाता है. यह स्ट्रक्चर, मूल मार्कअप में तय किए गए पैरंट-चाइल्ड रिलेशनशिप को भी कैप्चर करता है: एचटीएमएल ऑब्जेक्ट, बॉडी ऑब्जेक्ट का पैरंट होता है, बॉडी ऑब्जेक्ट, पैराग्राफ़ ऑब्जेक्ट का पैरंट होता है. ऐसा तब तक होता है, जब तक दस्तावेज़ का पूरा रेप्रज़ेंटेशन नहीं बन जाता.
इस पूरी प्रोसेस का आखिरी आउटपुट हमारे आसान पेज का डॉक्यूमेंट ऑब्जेक्ट मॉडल (डीओएम) है. ब्राउज़र, पेज की आगे की सभी प्रोसेसिंग के लिए इसका इस्तेमाल करता है.
जब भी ब्राउज़र एचटीएमएल मार्कअप को प्रोसेस करता है, तो वह पहले से तय किए गए सभी चरणों से गुज़रता है: बाइट को वर्ण में बदलना, टोकन की पहचान करना, टोकन को नोड में बदलना, और डीओएम ट्री बनाना. इस पूरी प्रोसेस में कुछ समय लग सकता है. खास तौर पर, अगर हमें ज़्यादा एचटीएमएल प्रोसेस करना है.
Chrome DevTools खोलकर पेज लोड होने के दौरान टाइमलाइन रिकॉर्ड करने पर, यह देखा जा सकता है कि इस चरण को पूरा करने में कितना समय लगा. पिछले उदाहरण में, एचटीएमएल के एक हिस्से को डीओएम ट्री में बदलने में पांच मि॰से॰ लगे थे. बड़े पेज के लिए, इस प्रोसेस में काफ़ी ज़्यादा समय लग सकता है. अगर ब्राउज़र को बहुत ज़्यादा एचटीएमएल प्रोसेस करना पड़ता है, तो स्मूद ऐनिमेशन बनाने में समस्या आ सकती है.
DOM ट्री, दस्तावेज़ मार्कअप की प्रॉपर्टी और रिलेशनशिप कैप्चर करता है. हालांकि, इससे हमें यह पता नहीं चलता कि रेंडर होने पर एलिमेंट कैसा दिखेगा. यह सीएसएसओएम की ज़िम्मेदारी है.
सीएसएस ऑब्जेक्ट मॉडल (CSSOM)
जब ब्राउज़र हमारे बुनियादी पेज का डीओएम बना रहा था, तब उसे दस्तावेज़ के <head> में एक <link> एलिमेंट मिला, जो बाहरी सीएसएस स्टाइल शीट: style.css का रेफ़रंस दे रहा था. यह अनुमान लगाकर कि पेज को रेंडर करने के लिए, उसे इस संसाधन की ज़रूरत होगी, वह तुरंत इस संसाधन के लिए अनुरोध भेजता है. इसके बाद, उसे यह कॉन्टेंट मिलता है:
body {
font-size: 16px;
}
p {
font-weight: bold;
}
span {
color: red;
}
p span {
display: none;
}
img {
float: right;
}
हम अपनी स्टाइल का एलान सीधे एचटीएमएल मार्कअप (इनलाइन) में कर सकते थे. हालांकि, सीएसएस को एचटीएमएल से अलग रखने से, हम कॉन्टेंट और डिज़ाइन को अलग-अलग चिंताओं के तौर पर मान सकते हैं. डिज़ाइनर, सीएसएस पर काम कर सकते हैं और डेवलपर, एचटीएमएल के साथ-साथ दूसरी समस्याओं पर ध्यान दे सकते हैं.
एचटीएमएल की तरह ही, हमें मिलने वाले सीएसएस नियमों को किसी ऐसी चीज़ में बदलना होगा जिसे ब्राउज़र समझ सके और उसके साथ काम कर सके. इसलिए, हम एचटीएमएल की प्रोसेस को दोहराते हैं, लेकिन एचटीएमएल के बजाय सीएसएस के लिए:
सीएसएस बाइट को वर्णों में, फिर टोकन में, और फिर नोड में बदला जाता है. आखिर में, उन्हें एक ट्री स्ट्रक्चर में लिंक कर दिया जाता है, जिसे "CSS ऑब्जेक्ट मॉडल" (CSSOM) कहा जाता है:
CSSOM की ट्री संरचना क्यों होती है? पेज पर किसी भी ऑब्जेक्ट के लिए स्टाइल के आखिरी सेट का हिसाब लगाते समय, ब्राउज़र उस नोड पर लागू होने वाले सबसे सामान्य नियम से शुरू होता है. उदाहरण के लिए, अगर यह बॉडी एलिमेंट का चाइल्ड है, तो बॉडी की सभी स्टाइल लागू होती हैं. इसके बाद, ब्राउज़र ज़्यादा खास नियमों को लागू करके, कैलकुलेट की गई स्टाइल को बार-बार बेहतर बनाता है. इसका मतलब है कि नियम "कैस्केड डाउन" होते हैं.
इसे ज़्यादा बेहतर तरीके से समझने के लिए, पहले बताए गए CSSOM ट्री को देखें. बॉडी एलिमेंट में मौजूद <span> टैग में मौजूद किसी भी टेक्स्ट का फ़ॉन्ट साइज़ 16 पिक्सल होता है और वह लाल रंग का होता है. font-size डायरेक्टिव, body से span तक कैस्केड करता है. हालांकि, अगर कोई span पैराग्राफ़ (p) टैग का चाइल्ड है, तो उसका कॉन्टेंट नहीं दिखाया जाता.
यह भी ध्यान दें कि पहले बताया गया ट्री, पूरा CSSOM ट्री नहीं है. इसमें सिर्फ़ वे स्टाइल दिखती हैं जिन्हें हमने अपनी स्टाइल शीट में बदलने का फ़ैसला लिया है. हर ब्राउज़र, स्टाइल का एक डिफ़ॉल्ट सेट उपलब्ध कराता है. इसे "उपयोगकर्ता एजेंट स्टाइल" भी कहा जाता है. जब हम अपने स्टाइल उपलब्ध नहीं कराते, तो हमें यही स्टाइल दिखते हैं. हमारे स्टाइल, इन डिफ़ॉल्ट स्टाइल को बदल देते हैं.
सीएसएस प्रोसेसिंग में कितना समय लगता है, यह जानने के लिए DevTools में टाइमलाइन रिकॉर्ड करें और "स्टाइल फिर से कैलकुलेट करें" इवेंट देखें: डीओएम पार्स करने के उलट, टाइमलाइन में "सीएसएस पार्स करें" एंट्री अलग से नहीं दिखती. इसके बजाय, यह पार्स करने और CSSOM ट्री बनाने के साथ-साथ, इस एक इवेंट के तहत कैलकुलेट की गई स्टाइल की बार-बार गिनती को कैप्चर करती है.
हमारी सामान्य स्टाइल हेट को प्रोसेस करने में ~0.6 मिलीसेकंड लगते हैं. साथ ही, यह पेज के आठ एलिमेंट पर असर डालती है. हालांकि, यह समय काफ़ी नहीं है, लेकिन फिर भी यह समय लगता है. हालांकि, आठ एलिमेंट कहां से आए हैं? CSSOM और DOM स्वतंत्र डेटा स्ट्रक्चर हैं! ऐसा लगता है कि ब्राउज़र कोई अहम चरण छिपा रहा है. इसके बाद, रेंडर ट्री को शामिल किया जाएगा और यह DOM और CSSOM को एक साथ लिंक करेगा.