प्रॉम्प्ट और संदर्भ
एक कंटेंट पेज एक साथ DOM में सैकड़ों कार्ड डालता है, जिससे प्रारंभिक लेआउट और स्क्रॉलिंग के दौरान लंबे टास्क (long tasks) उत्पन्न होते हैं। इंटरव्यूअर आपसे content-visibility: auto का मूल्यांकन करने, यह कौन से कार्यों को छोड़ता है यह समझाने, ऑफ़-स्क्रीन आकार का अनुमान लगाने, और यह तय करने के लिए कहता है कि पेजिनेशन या वर्चुअलाइज़ेशन की आवश्यकता कब बनी रहती है। इसमें माप, एक्सेसिबिलिटी और रोलबैक मानदंड शामिल करें।
इंटरव्यूअर क्या जांच रहा है
वे यह देखना चाहते हैं कि क्या आप रेंडरिंग पाइपलाइन और CSS कंटेनमेंट के बीच के संबंध को समझते हैं, ऑफ़-स्क्रीन रेंडरिंग को छोड़ने और DOM आकार को कम करने के बीच अंतर कर सकते हैं, और अनुमानित ऊंचाइयों, फ़ोकस नेविगेशन और कम्पैटिबिलिटी को संभाल सकते हैं। केवल एक CSS लाइन या बिना सत्यापित किया गया गुणक किसी ऑप्टिमाइज़ेशन को सिद्ध नहीं करता है।
पहले पूछने योग्य स्पष्टीकरण प्रश्न
- कितने कार्ड हैं, प्रत्येक कार्ड कितना जटिल है, और पहली स्क्रीन का लक्ष्य क्या है?
- बाधा (bottleneck) स्क्रिप्ट, स्टाइल गणना, लेआउट, पेंट, मेमोरी या नेटवर्क में कहाँ है?
- क्या कार्ड की ऊँचाइयाँ स्थिर हैं, या इमेज और फ़ॉन्ट लोड होने के बाद उन्हें बदलते हैं?
- क्या पेज फाइंड-इन-पेज, कीबोर्ड फ़ोकस, स्क्रीन रीडर या प्रिंट पर निर्भर करता है?
- ब्राउज़र समर्थन दायरा और एक्सेसिबिलिटी स्वीकृति मानदंड क्या लागू होते हैं?
30-सेकंड का उत्तर फ़्रेमवर्क
मैं पहले परफ़ॉर्मेंस पैनल में लंबे टास्क और लेआउट लागत की पुष्टि करूँगा, फिर चंक किए गए ऑफ़-स्क्रीन कार्ड पर content-visibility: auto आज़माऊँगा। यह ब्राउज़र को एक सबट्री के लिए लेआउट और पेंट छोड़ने की अनुमति देता है जो अस्थायी रूप से अप्रासंगिक है, जबकि कंटेंट DOM और एक्सेसिबिलिटी ट्री में बना रहता है। साइज़ कंटेनमेंट अनरेंडर की गई सामग्री को एक खाली बॉक्स की तरह व्यवहार करा सकता है, इसलिए मैं इसे एक मापे गए contain-intrinsic-size के साथ जोड़ूँगा और लेआउट शिफ्ट को ट्रैक करूँगा। यदि DOM का आकार या डेटा वॉल्यूम अभी भी बाधा बना रहता है, तो मैं पेजिनेशन या वर्चुअलाइज़ेशन का उपयोग करूँगा।
चरण-दर-चरण गहन विश्लेषण
चरण 1: ऑप्टिमाइज़ेशन लक्ष्य की पुष्टि करें
फ़र्स्ट पेंट, इंटरैक्शन लेटेंसी, लंबे टास्क, लेआउट संख्या, पेंट समय और मेमोरी रिकॉर्ड करें। समान डेटा, डिवाइस, व्यूपोर्ट और कैश स्थितियों के साथ एक बेसलाइन बनाए रखें ताकि नेटवर्क भिन्नता को CSS लाभ न समझ लिया जाए।
चरण 2: सामग्री को छोड़े जा सकने वाले यूनिट्स में चंक करें
दोहराए जाने वाले कार्डों को स्थिर सेक्शन या आर्टिकल में लपेटें ताकि ब्राउज़र व्यूपोर्ट के पास एक सबट्री का मूल्यांकन कर सके। सीमाएं वास्तविक कंटेंट यूनिट्स से मेल खानी चाहिए; बार-बार बदलने वाले एक बड़े कंटेनर को छिपाने से बचें।
चरण 3: auto के व्यवहार को समझें
content-visibility: auto लेआउट, स्टाइल और पेंट कंटेनमेंट को सक्षम करता है। जब कोई ऑफ़-स्क्रीन तत्व उपयोगकर्ता के लिए प्रासंगिक नहीं होता है, तो ब्राउज़र उसके सबट्री की रेंडरिंग को छोड़ सकता है और व्यूपोर्ट के पास फिर से शुरू कर सकता है। यह display: none नहीं है: सामग्री DOM और एक्सेसिबिलिटी ट्री में बनी रहती है और खोजने योग्य तथा फ़ोकस करने योग्य रह सकती है।
चरण 4: एक मापने योग्य इंट्रिन्सिक प्लेसहोल्डर प्रदान करें
साइज़ कंटेनमेंट ब्राउज़र को केवल बाहरी आकार की गणना करने के लिए चाइल्ड तत्वों को रेंडर करने से बचने की अनुमति देता है। बिना प्लेसहोल्डर के, कोई तत्व शून्य ऊंचाई के करीब लेआउट हो सकता है और स्क्रॉलबार में जंप ला सकता है। अनुमान के लिए contain-intrinsic-size का उपयोग करें, या auto का उपयोग करें ताकि ब्राउज़र पहले से रेंडर किए गए आकार को याद रख सके।
.card-section {
content-visibility: auto;
contain-intrinsic-size: auto 420px;
}चरण 5: रेंडरिंग को बाध्य करने वाले कोड का ऑडिट करें
लेआउट या आयामों के कुछ DOM रीड्स ब्राउज़र को छोड़े गए सबट्री को प्रोसेस करने के लिए मजबूर करते हैं। माप, सिंक्रोनस स्क्रीनशॉट, एनीमेशन और तीसरे पक्ष के विजेट की समीक्षा करें। स्क्रॉल हैंडलर में बार-बार रीड/राइट चक्रों से बचें; जहां संभव हो मापों को बैच करें या ऑब्ज़र्वर का उपयोग करें।
चरण 6: एक्सेसिबिलिटी और इंटरैक्शन को सत्यापित करें
ऑफ़-स्क्रीन कंटेंट के साथ कीबोर्ड नेविगेशन, फाइंड-इन-पेज, स्क्रीन रीडर और एंकर जंप का परीक्षण करें। auto और hidden के अलग-अलग एक्सेसिबिलिटी सिमेंटिक्स हैं, इसलिए परफ़ॉर्मेंस के लिए एक को दूसरे से न बदलें। उस कंटेंट के लिए जिसे वास्तव में छिपाया जाना चाहिए, एक स्पष्ट सिमेंटिक छिपाने की रणनीति का उपयोग करें और फ़ोकस क्रम का पुनः परीक्षण करें।
चरण 7: वर्चुअलाइज़ेशन के साथ सीमा की तुलना करें
content-visibility पूर्ण DOM को बनाए रखता है, इसलिए यह उन पेजों के लिए उपयुक्त है जहां सामग्री का आकार मध्यम है लेकिन ऑफ़-स्क्रीन रेंडरिंग महंगी है। यदि नोड गणना, लिसनर्स, या डेटा मेमोरी अपने आप में बहुत बड़ी है, तो वर्चुअलाइज़ेशन, पेजिनेशन या सर्वर-साइड चंकिंग का उपयोग करें; इन दृष्टिकोणों को पेज क्षेत्र के आधार पर संयोजित किया जा सकता है।
एक मजबूत उत्तर का उदाहरण
मैं परफ़ॉर्मेंस ट्रेस में बाधा की पुष्टि करूँगा, फिर कार्डों को चंक करूँगा और content-visibility: auto का परीक्षण करूँगा। यह ऑफ़-स्क्रीन सबट्रीज़ के लिए लेआउट और पेंट को छोड़ता है लेकिन DOM का आकार कम नहीं करता है; contain-intrinsic-size एक अनरेंडर किए गए कार्ड को शून्य-ऊंचाई वाले बॉक्स की तरह दिखने से रोकता है। मैं लेआउट रीड्स का ऑडिट करूँगा, कीबोर्ड, फाइंड-इन-पेज और स्क्रीन-रीडर व्यवहार का परीक्षण करूँगा, और फ़र्स्ट पेंट, इंटरैक्शन लेटेंसी, लेआउट शिफ्ट और मेमोरी की तुलना करूँगा। यदि DOM का आकार अभी भी मुख्य लागत है, तो मैं पेजिनेशन या वर्चुअलाइज़ेशन पर स्विच करूँगा।
सामान्य गलतियाँ
गलती: auto को वर्चुअल लिस्ट मानना
auto मुख्य रूप से ऑफ़-स्क्रीन रेंडरिंग कार्य को छोड़ता है जबकि नोड्स मौजूद रहते हैं। यह लिसनर, डेटा-मेमोरी या विशाल-DOM लागतों को स्वचालित रूप से नहीं हटाता है।
गलती: इंट्रिन्सिक-साइज़ अनुमान को छोड़ देना
साइज़ कंटेनमेंट प्लेसहोल्डर का उपयोग करके बाहरी बॉक्स का लेआउट कर सकता है। बहुत छोटा मान स्क्रॉलबार और स्क्रॉल स्थिति को बदल देता है, इसलिए वास्तविक कार्ड वितरण से अनुमान लगाएं और पुनः व्यवस्थित करें।
गलती: केवल फ़र्स्ट पेंट को मापना
कंटेंट को अभी भी व्यूपोर्ट में प्रवेश करने पर रेंडर होना पड़ता है। प्रारंभिक लोड के अतिरिक्त स्क्रॉल इंटरैक्शन लेटेंसी, लंबे टास्क, लेआउट शिफ्ट, मेमोरी और एक्सेसिबिलिटी को मापें।
गलती: hidden और auto को मिलाना
hidden सामग्री को छोड़ देता है और फाइंड-इन-पेज, फ़ोकस और चयन को प्रभावित करता है; auto ऑफ़-स्क्रीन सामग्री को उपयोगकर्ता-एजेंट सुविधाओं के लिए उपलब्ध रखता है। सिमेंटिक और इंटरैक्शन अनुबंध के आधार पर चुनें।
फ़ॉलो-अप प्रश्न और उत्तर
फ़ॉलो-अप: क्या यह नेटवर्क अनुरोधों को कम करता है?
नहीं। यह प्रॉपर्टी रेंडरिंग और कंटेनमेंट को प्रभावित करती है; डेटा और संसाधन पहले ही डाउनलोड हो चुके हो सकते हैं। नेटवर्क और मेमोरी लागत को कम करने के लिए पेजिनेशन, लेज़ी लोडिंग या सर्वर-साइड चंकिंग का उपयोग करें।
फ़ॉलो-अप: स्क्रॉल करते समय पेज जंप क्यों करता है?
तत्व को साइज़ कंटेनमेंट के तहत एक प्लेसहोल्डर के साथ लेआउट किया गया था, फिर रेंडरिंग के बाद इसकी ऊंचाई बदल गई। अनुमान में सुधार करें, contain-intrinsic-size: auto का उपयोग करें, और लेआउट-शिफ्ट मेट्रिक्स के साथ सत्यापित करें।
फ़ॉलो-अप: क्या सामग्री अभी भी एक्सेसिबिलिटी ट्री में है?
auto के साथ, ऑफ़-स्क्रीन सामग्री DOM और एक्सेसिबिलिटी ट्री में बनी रहती है और आम तौर पर खोजने योग्य और फ़ोकस करने योग्य होती है; hidden अलग है। लक्षित ब्राउज़रों और सहायक तकनीकों के साथ पुनः परीक्षण करें।
फ़ॉलो-अप: आपको इससे कब बचना चाहिए?
जब ऊँचाइयाँ अप्रत्याशित हों और अनुमान स्क्रॉलिंग को नुकसान पहुँचाते हों, घटक बार-बार लेआउट को बाध्य करते हों, या DOM का आकार पहले से ही बाधा हो, तो इस पर निर्भर रहने से बचें। इसके बजाय वर्चुअलाइज़ेशन, पेजिनेशन या चंक लोडिंग का उपयोग करें।
फ़ॉलो-अप: आप कैसे साबित करते हैं कि कोई रिग्रेशन नहीं है?
निश्चित उपकरणों और डेटा पर पहले और बाद के परीक्षण चलाएं, फ़र्स्ट पेंट, p95 इंटरैक्शन लेटेंसी, लंबे टास्क, लेआउट शिफ्ट, स्क्रॉल फ़्रेम दर, मेमोरी और एक्सेसिबिलिटी परिणामों को रिकॉर्ड करें, फिर वास्तविक ट्रैफ़िक में पर्सेंटाइल मेट्रिक्स की निगरानी करें।