🌭 🛣️ 🎼 जब CSS पेज पार्सिंग हो तो क्या करें? 🤲🏼 🎅🏾 🈷️

हाल ही में, मैंने एक साइट का ऑडिट किया और एक पैटर्न preload/polyfillदेखा, जो मैंने पहले ही कई ग्राहकों के साथ देखा है। आज, इस पहले से लोकप्रिय पैटर्न के उपयोग की अनुशंसा नहीं की जाती है। हालांकि, वेब ब्राउज़रों द्वारा पूर्व-लोडिंग सामग्री के तंत्र के सावधानीपूर्वक उपयोग के महत्व को समझाने के लिए इस पर विचार करना उपयोगी है। यह दिलचस्प भी है क्योंकि यह आपको एक वास्तविक उदाहरण प्रदर्शित करने की अनुमति देता है कि किसी दस्तावेज़ में तत्वों का क्रम प्रदर्शन को कैसे प्रभावित कर सकता है (यह इस अद्भुत हैरी रॉबर्ट्स लेख में चर्चा की गई है )। सामग्री, जिसका अनुवाद आज हम प्रकाशित करते हैं, उन स्थितियों के विश्लेषण के लिए समर्पित है जिसमें सीएसएस संसाधनों का अनुचित और असामयिक संभाल वेब पृष्ठों के प्रदर्शन को प्रभावित करता है।

लोडसीएसएस के बारे में

मैं फिलामेंट समूह का एक बड़ा प्रशंसक हूं - वे महान परियोजनाओं की एक अविश्वसनीय राशि जारी करते हैं। इसके अलावा, वे लगातार अमूल्य उपकरण बनाते हैं और उन्हें वेब को बेहतर बनाने के लिए साझा करते हैं। इन उपकरणों में से एक लोडसीएसएस है , जो लंबे समय तक बहुत ही उपकरण था जिसे मैंने सभी को गैर-महत्वपूर्ण सीएसएस संसाधनों को लोड करने के लिए उपयोग करने की सिफारिश की थी।

हालांकि अब यह बदल गया है (और फिलामेंट समूह ने एक उत्कृष्ट लेख प्रकाशित किया है कि उसके कर्मचारी इन दिनों का उपयोग करना पसंद करते हैं), फिर भी, जब मैं साइटों का ऑडिट करता हूं, तो अक्सर यह देखता हूं कि वे loadCSSउत्पादन में इसका उपयोग कैसे करते हैं।

पैटर्न है कि मैं भर में आया है पैटर्न हैpreload/polyfill। इस दृष्टिकोण का उपयोग करते हुए, शैलियों के साथ किसी भी फाइल को प्रीलोड मोड में लोड किया जाता है ( relसंबंधित लिंक की विशेषता सेट की जाती है preload)। उसके बाद, जब वे उपयोग करने के लिए तैयार हों, तो onloadउन्हें पेज से जोड़ने के लिए अपनी घटनाओं को लागू करें।

<link rel="preload" href="path/to/mystylesheet.css" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="path/to/mystylesheet.css"></noscript>

चूंकि सभी ब्राउज़र डिज़ाइन का समर्थन नहीं करते हैं <a href="https://caniuse.com/#feat=link-rel-preload"><link rel="preload"></a>, इसलिए प्रोजेक्ट loadCSSडेवलपर्स को एक सुविधाजनक पॉलीफ़िल प्रदान करता है, जिसे संबंधित विवरण के विवरण के बाद पेज में जोड़ा जाता है:

<link rel="preload" href="path/to/mystylesheet.css" as="style" onload="this.rel='stylesheet'">
<noscript>
    <link rel="stylesheet" href="path/to/mystylesheet.css">
</noscript>
<script>
/*! loadCSS rel=preload polyfill. [c]2017 Filament Group, Inc. MIT License */
(function(){ ... }());
</script>

नेटवर्क प्राथमिकताओं में विकार

मैं कभी भी इस पैटर्न का उत्साही प्रशंसक नहीं रहा हूं। प्रीलोडिंग एक अशिष्ट उपकरण है। सामग्री लिंक का उपयोग करके डाउनलोड की गई rel="preload"सामग्री नेटवर्क संसाधनों के लिए अन्य सामग्रियों के साथ सफलतापूर्वक लड़ती है। उपयोग preloadमान लेता है कि स्टाइलशीट जो इस तथ्य के कारण अतुल्यकालिक रूप से लोड करते हैं कि वे पृष्ठ के आउटपुट में महत्वपूर्ण भूमिका नहीं निभाते हैं, ब्राउज़र से बहुत उच्च प्राथमिकता प्राप्त करते हैं।

WebPageTest से ली गई निम्न छवि, इस समस्या को बहुत अच्छी तरह से प्रदर्शित करती है। 3-6 लाइनों में, आप एक पैटर्न का उपयोग करके सीएसएस फ़ाइलों के अतुल्यकालिक लोडिंग देख सकते हैं preload। लेकिन, जबकि डेवलपर्स इन फाइलों को इतना महत्वपूर्ण नहीं मानते हैं कि उन्हें डाउनलोड करना रेंडरिंग, उपयोग को अवरुद्ध कर देगाpreload इसका मतलब है कि शेष संसाधनों को प्राप्त करने से पहले उन्हें लोड किया जाएगा।

सीएसएस फाइलें जो लोड किए जाने पर प्रीलोड पैटर्न का उपयोग करती हैं, जो अन्य संसाधनों की तुलना में पहले ब्राउज़र में आती हैं, भले ही वे संसाधन नहीं हैं जो पृष्ठ के प्रारंभिक प्रतिपादन के लिए अत्यंत आवश्यक हैं

HTML पार्सर लॉक

संसाधन लोडिंग की प्राथमिकता से जुड़ी समस्याएं ज्यादातर स्थितियों में पैटर्न का उपयोग करने से बचने के लिए पहले से ही पर्याप्त हैं preload। लेकिन इस मामले में, स्थिति एक और स्टाइलशीट की उपस्थिति से बढ़ जाती है, जिसे सामान्य तरीके से लोड किया जाता है।

<link rel="stylesheet" href="path/to/main.css" />
<link rel="preload" href="path/to/mystylesheet.css" as="style" onload="this.rel='stylesheet'">
<noscript>
    <link rel="stylesheet" href="path/to/mystylesheet.css">
</noscript>
<script>
/*! loadCSS rel=preload polyfill. [c]2017 Filament Group, Inc. MIT License */
(function(){ ... }());
</script>

उपयोग करते समय समान समस्याएं होती हैं, preloadइस तथ्य की ओर जाता है कि सबसे महत्वपूर्ण फाइलों को उच्च प्राथमिकता नहीं मिलती है। लेकिन यह उतना ही महत्वपूर्ण है, और शायद कम स्पष्ट है, इससे ब्राउज़र की पृष्ठ को पार्स करने की क्षमता पर क्या प्रभाव पड़ता है।

फिर, यह पहले से ही विस्तार से लिखा गया है , इसलिए मैं उस सामग्री को पढ़ने के लिए सलाह देता हूं ताकि यह समझने में बेहतर हो कि क्या हो रहा है। यहाँ मैं इसके बारे में संक्षेप में बात करूँगा।

आमतौर पर, लोडिंग स्टाइल पेज रेंडरिंग को ब्लॉक करता है। पृष्ठ प्रदर्शित करने में सक्षम होने के लिए ब्राउज़र को क्वेरी और पार्स शैलियों की आवश्यकता होती है। हालाँकि, यह ब्राउज़र को शेष HTML कोड को पार्स करने से नहीं रोकता है।

दूसरी ओर, लिपियां पार्सर को अवरुद्ध कर देती हैं यदि वे चिह्नित नहीं हैं deferया async।

चूंकि ब्राउज़र को यह मान लेना है कि स्क्रिप्ट या तो पृष्ठ की सामग्री को या तो स्वयं को या उस पर लागू शैलियों को हेरफेर कर सकती है, इसलिए इस स्क्रिप्ट को चलाने के बारे में सावधानी बरतने की आवश्यकता है। यदि ब्राउज़र जानता है कि कुछ CSS कोड लोड हो रहा है, तो वह इस CSS कोड के आने का इंतजार करेगा और उसके बाद यह स्क्रिप्ट चलाएगा। और चूंकि स्क्रिप्ट निष्पादित होने तक ब्राउज़र दस्तावेज़ को पार्स करना जारी नहीं रख सकता है, इसका मतलब है कि शैलियाँ अब केवल रेंडरिंग ब्लॉक नहीं करती हैं। वे ब्राउज़र को HTML पार्स करने से रोकते हैं।

यह व्यवहार बाहरी स्क्रिप्ट और पृष्ठ में एम्बेड की गई स्क्रिप्ट दोनों के लिए सही है। यदि CSS लोड हो जाता है, तो इनलाइन तब तक नहीं चलती है जब तक यह CSS ब्राउज़र में नहीं आती है।

समस्या का अध्ययन

इस समस्या की कल्पना करने का सबसे समझदार तरीका है क्रोम डेवलपर टूल्स का उपयोग करना (मैं वास्तव में उस स्तर को पसंद करता हूं जिसमें ये उपकरण बढ़े हैं)।

क्रोम टूल में एक टैब Performanceहै जिसके साथ आप पेज लोड प्रोफाइल रिकॉर्ड कर सकते हैं। मैं कृत्रिम रूप से नेटवर्क कनेक्शन को धीमा करने की सलाह देता हूं ताकि समस्या खुद ही तेज हो जाए।

इस मामले में, मैंने फास्ट 3 जी नेटवर्क सेटअप का उपयोग करके परीक्षण किया। यदि आप मुख्य थ्रेड के साथ निकटता से देखते हैं, तो आप समझ सकते हैं कि CSS फ़ाइल लोड करने का अनुरोध HTML पार्सिंग की बहुत शुरुआत में होता है (पेज लोड होने के बाद लगभग 1.7 सेकंड)।

HTML पार्सिंग ब्लॉक के नीचे एक छोटी आयत एक CSS फ़ाइल प्राप्त करने के अनुरोध का प्रतिनिधित्व करती है।

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

यदि आप बड़ी तस्वीर को देखते हैं, तो यह पता चलता है कि सीएसएस लोड करने की शुरुआत के बाद, मुख्य धागा 1.1 सेकंड से अधिक के लिए निष्क्रिय है।

इसलिए, 2.8 सेकंड बीत चुके हैं, शैली भरी हुई है, ब्राउज़र इसे संसाधित करता है। तभी हम अंतर्निहित स्क्रिप्ट की प्रोसेसिंग देखते हैं, और उसके बाद ब्राउज़र अंततः HTML पार्सिंग पर लौटता है।

सीएसएस लगभग 2.8 सेकंड में आता है, जिसके बाद हम देखते हैं कि ब्राउज़र HTML को पार्स करना जारी रखता है

फ़ायरफ़ॉक्स एक अच्छा अपवाद है

उपरोक्त व्यवहार Chrome, Edge और Safari के लिए सामान्य है। फ़ायरफ़ॉक्स लोकप्रिय ब्राउज़रों की सूची का एक अच्छा अपवाद है।

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

जब तक स्क्रिप्ट डोम में हेरफेर नहीं करती है, जिससे सट्टा पार्सिंग के परिणामों को छोड़ने की आवश्यकता होती है, यह दृष्टिकोण फ़ायरफ़ॉक्स को लाभ लेने की अनुमति देता है। बेशक, अगर ब्राउज़र को सट्टा निर्मित डोम ट्री को गिराना है, तो इसका मतलब है कि उसने इस पेड़ को बनाने से कुछ भी उपयोगी नहीं किया।

यह एक दिलचस्प दृष्टिकोण है। मैं यह जानने के लिए बहुत उत्सुक था कि यह कितना प्रभावी है। हालाँकि, हालाँकि, फ़ायरफ़ॉक्स परफ़ॉर्मर प्रोइलर में इसके बारे में कोई जानकारी नहीं है। वहां आपको पता नहीं चल सकता है कि सट्टा पार्सर ने काम किया है या नहीं, क्या इसके द्वारा किए गए कार्य को फिर से करना आवश्यक है, और यदि इसे अभी भी फिर से तैयार करना है, तो यह प्रदर्शन को कैसे प्रभावित करेगा।

मैंने उन लोगों के साथ बात की जो फ़ायरफ़ॉक्स डेवलपर टूल के लिए ज़िम्मेदार हैं, और मैं कह सकता हूं कि उनके पास भविष्य में ऐसी जानकारी पेश करने के लिए दिलचस्प विचार हैं। मुझे उम्मीद है कि वे सफल होंगे।

समस्या का समाधान

क्लाइंट के मामले में, जिसका मैंने शुरुआत में उल्लेख किया था, इस समस्या को हल करने में पहला कदम बेहद सरल था: पैटर्न से छुटकारा पाएं preload/polyfill। गैर-महत्वपूर्ण CSS को लोड करना व्यर्थ है। यहां आपको rel="preload"एक विशेषता के बजाय, उपयोग करने के लिए स्विच करने की आवश्यकता है media="print"। यह वही है जो फिलामेंट समूह के विशेषज्ञ सलाह देते हैं। इसके अलावा, यह दृष्टिकोण आपको पॉलीफ़िल से पूरी तरह से छुटकारा पाने की अनुमति देता है।

<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

यह पहले से ही हमें एक बेहतर स्थिति में रखता है: अब नेटवर्क प्राथमिकताएं डाउनलोड के वास्तविक महत्व के साथ बहुत बेहतर गठबंधन की जाती हैं। और हमें अंतर्निहित स्क्रिप्ट से भी छुटकारा मिलता है।

इस स्थिति में, सीएसएस को लोड करने के लिए अनुरोध शुरू करने वाली रेखा के नीचे दस्तावेज़ हेडर में स्थित एक और अंतर्निहित स्क्रिप्ट अभी भी है। यदि आप इस स्क्रिप्ट को स्थानांतरित करते हैं ताकि यह सीएसएस लोड करने वाली लाइन के सामने हो, तो यह पार्सर लॉक को समाप्त कर देगा। यदि आप Chrome डेवलपर टूल का उपयोग करके फिर से पृष्ठ का विश्लेषण करते हैं, तो अंतर पूरी तरह से स्पष्ट हो जाएगा।

पेज कोड में बदलाव करने से पहले, एचटीएमएल पार्सर 1939 की लाइन में रुक गया, जिसमें एक अंतर्निहित स्क्रिप्ट का सामना करना पड़ा, और लगभग एक सेकंड के लिए यहां रहा। अनुकूलन के बाद, वह 5281 लाइन में सक्षम हो गया।

इससे पहले, पार्सर 1939 में लाइन में रुक गया और सीएसएस को लोड करने के लिए इंतजार कर रहा था, लेकिन अब यह लाइन 5281 तक पहुंच गया है। पेज के अंत में, एक और अंतर्निहित स्क्रिप्ट है जो पार्सर को फिर से रोकती है।

यह समस्या का त्वरित समाधान है। यह विकल्प नहीं है जो समस्या के अंतिम समाधान का प्रतिनिधित्व करता है। तत्वों के क्रम को बदलना और पैटर्नpreload/polyfillसेछुटकारा पानासिर्फ पहला कदम है। आप किसी पृष्ठ पर महत्वपूर्ण सीएसएस कोड को किसी बाहरी फ़ाइल से लोड करने के बजाय एम्बेड करके इस समस्या को हल कर सकते हैं। पैटर्नpreload/polyfillइनलाइन CSS के अलावा उपयोग करने के लिए डिज़ाइन किया गया। यह हमें स्क्रिप्ट से जुड़ी समस्याओं को पूरी तरह से नजरअंदाज करने और यह सुनिश्चित करने की अनुमति देता है कि ब्राउज़र, पहले अनुरोध को निष्पादित करने के बाद, पेज को रेंडर करने के लिए सभी शैलियों को आवश्यक करता है।

लेकिन अभी के लिए, यह ध्यान दिया जाना चाहिए कि जिस तरह से शैलियों को लोड किया जाता है और डोम में तत्वों के क्रम के बारे में प्रोजेक्ट में बहुत छोटे बदलाव करके हम एक अच्छा प्रदर्शन को बढ़ावा दे सकते हैं।

सारांश

यदि आप एक loadCSSपैटर्न का उपयोग करते preload/polyfillहैं, तो स्टाइल लोडिंग पैटर्न पर जाएं print।
यदि आपके पास बाहरी शैलियाँ हैं जो सामान्य तरीके से लोड की जाती हैं (यानी, इन शैलियों की फ़ाइलों के नियमित लिंक का उपयोग करके), सभी अंतर्निहित स्क्रिप्ट्स को स्थानांतरित करें, जो शैलियों को लोड करने के लिए लिंक के ऊपर ले जाया जा सकता है।
रेंडरिंग की सबसे तेज़ शुरुआत सुनिश्चित करने के लिए पृष्ठ में महत्वपूर्ण शैलियों को एम्बेड करें।

प्रिय पाठकों! क्या आपको सीएसएस के कारण पेज रेंडरिंग को धीमा करने में समस्या का सामना करना पड़ा है?

PS
RUVDS 8 मार्च को सभी आईटी पेशेवरों को बधाई देता है!
इस साल, हमने ट्यूलिप नहीं देने और गीक उपहारों का चयन नहीं करने का फैसला किया। हमने एक अलग रास्ता अपनाया और आईटी में महिला विशेषज्ञों की उपस्थिति दिखाने के लिए आईटी को महिला पृष्ठ बनाया ।

जब CSS पेज पार्सिंग हो तो क्या करें?