फ्रंटएंड इंटरव्यू: लेआउट शिफ्ट पैदा किए बिना content-visibility का उपयोग कैसे करें?

प्रश्न और उपयुक्त परिदृश्य

आप एक लंबी लिस्ट, आर्टिकल फीड या एडमिन वर्कस्पेस के ओनर हैं। DOM में सैकड़ों कंटेंट सेक्शन हैं; शुरुआत में केवल कुछ ही कार्ड दिखाई देते हैं, फिर भी ब्राउज़र ऑफ-स्क्रीन सब-ट्री के लिए स्टाइल, लेआउट और पेंट का काम करता रहता है। इंटरव्यू में आपसे CSS कंटेनमेंट का उपयोग करके मुख्य थ्रेड (main thread) के रेंडरिंग कार्य को कम करने के लिए कहा गया है, जबकि फाइंड-इन-पेज, फोकस और स्क्रीन-रीडर एक्सेस को बनाए रखना है।

मान लें कि पेज को स्वतंत्र कार्ड या सेक्शन में विभाजित किया जा सकता है, उनकी ऊंचाई अलग-अलग है लेकिन असीमित नहीं है, और लक्षित ब्राउज़र content-visibility: auto का समर्थन करते हैं। असमर्थित ब्राउज़रों को भी पेज को सही ढंग से रेंडर करना चाहिए।

इंटरव्यूअर क्या मूल्यांकन कर रहा है

क्या आप ऑप्टिमाइज़ करने से पहले नेटवर्क, स्क्रिप्ट और रेंडरिंग बाधाओं (bottlenecks) को अलग-अलग पहचानते हैं।
क्या आप auto द्वारा निहित लेआउट, स्टाइल और पेंट कंटेनमेंट के साथ-साथ ऑफ-स्क्रीन साइज कंटेनमेंट को समझा सकते हैं।
क्या आप प्लेसहोल्डर-साइज की गलतियों का पूर्वानुमान लगाते हैं जो स्क्रॉलबार जंप और CLS का जोखिम पैदा करती हैं।
क्या आप फोकस, फाइंड-इन-पेज, स्क्रीन-रीडर और DOM-रीड व्यवहार के साथ प्रदर्शन को मान्य करते हैं।

एक कमजोर उत्तर केवल एक CSS डिक्लेरेशन देता है। एक मजबूत उत्तर बाउंड्री, साइजिंग रणनीति, फोर्स्ड लेआउट रीड्स की लागत और फॉलबैक योजना को स्पष्ट करता है।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

क्या मंदी फर्स्ट रेंडर पर, स्क्रॉल करते समय, फ़िल्टर करने के बाद, या क्लिक के बाद होती है? यह चरण निर्धारित करता है कि आप रेंडरिंग, स्क्रिप्ट या नेटवर्क कार्य को मापते हैं।
क्या कार्ड की ऊंचाई स्थिर है? बड़ा अंतर वास्तविक मापों या contain-intrinsic-size: auto द्वारा रेंडर किए गए आकारों को याद रखने के मूल्य को बढ़ाता है।
क्या ऑफ-स्क्रीन कंटेंट को खोजने योग्य, फोकस करने योग्य और सहायक तकनीक के लिए खुला रहना चाहिए? यदि हां, तो hidden, display: none का सीधा विकल्प नहीं है।
क्या कोड हर स्क्रॉल या स्टेट अपडेट के दौरान offsetHeight या getBoundingClientRect() को पढ़ता है? इस तरह के रीड्स छोड़े गए रेंडरिंग कार्य को वापस क्रिटिकल पाथ में खींच सकते हैं।

30-सेकंड का उत्तर ढांचा

"मैं सबसे पहले परफॉर्मेंस पैनल का उपयोग करके पुष्टि करूंगा कि ऑफ-स्क्रीन सब-ट्री को रेंडर करना ही मुख्य बाधा है। मैं फीड को स्वतंत्र सेक्शनों में विभाजित करूंगा, गैर-महत्वपूर्ण सेक्शनों पर content-visibility: auto लागू करूंगा, और एक यथार्थवादी contain-intrinsic-size प्रदान करूंगा ताकि साइज कंटेनमेंट उन्हें खाली न दिखाए। फिर मैं फोकस, फाइंड-इन-पेज और सहायक तकनीक के व्यवहार का परीक्षण करूंगा, और लेआउट को बाध्य करने वाले DOM रीड्स का ऑडिट करूंगा। अंत में, मैं एक कंट्रोल के मुकाबले फर्स्ट रेंडर, स्क्रॉलिंग, INP, CLS और असमर्थित-प्रॉपर्टी फॉलबैक की तुलना करूंगा।"

चरण-दर-चरण विस्तृत उत्तर

1. रेंडरिंग सीमाएं (boundaries) स्थापित करें

लंबे पेज को स्वतंत्र सेक्शनों या कार्डों में विभाजित करें। एक बाउंड्री के अंदर लेआउट परिवर्तन से असंबंधित क्षेत्रों पर प्रभाव नहीं पड़ना चाहिए; अन्यथा कंटेनमेंट वास्तविक निर्भरता को छिपा सकता है और गलत लेआउट उत्पन्न कर सकता है।

css

.story {
  content-visibility: auto;
  contain-intrinsic-size: auto 720px;
}

जब कोई सेक्शन व्यूपोर्ट से दूर होता है, तो auto ब्राउज़र को डिसेंडेंट स्टाइल, लेआउट और पेंट कार्य के कुछ हिस्सों को छोड़ने की अनुमति देता है; जैसे ही यह व्यूपोर्ट के करीब आता है, ब्राउज़र इसे मांग पर रेंडर करता है। DOM में यह मौजूद रहता है।

2. एक साइज प्लेसहोल्डर प्रदान करें

एक ऑफ-स्क्रीन सेक्शन को उसकी सामग्री की जांच किए बिना अस्थायी रूप से आकार दिया जाता है। स्पष्ट ऊंचाई या इंट्रिन्सिक साइज के बिना, यह एक बहुत छोटे खाली बॉक्स जैसा दिख सकता है, जिससे स्क्रॉलबार की लंबाई और उपयोगकर्ता की स्क्रॉल स्थिति बदल जाती है।

contain-intrinsic-size: auto 720px एक प्रारंभिक अनुमान प्रदान करता है। रेंडरिंग के बाद, ब्राउज़र वास्तविक आकार को याद रख सकता है। केवल सजावटी संख्या चुनने के बजाय उत्पादन नमूनों से अनुमान प्राप्त करें। बड़े अंतर के लिए, कंटेंट प्रकारों को समूहित (bucket) करें या डेटा के साथ एक साइज हिंट प्रदान करें।

3. auto, hidden, और display none में अंतर समझें

auto: ऑफ-स्क्रीन रेंडरिंग को छोड़ देता है और व्यूपोर्ट के पास फिर से शुरू करता है; सामग्री DOM और एक्सेसिबिलिटी ट्री में बनी रहती है।
hidden: रेंडरिंग को हमेशा छोड़ते हुए रेंडरिंग स्थिति बनाए रखता है; यह एक निष्क्रिय व्यू के लिए उपयुक्त है, हर एक्सेसिबिलिटी-छिपाने की आवश्यकता के लिए नहीं।
display: none: लेआउट और रेंडरिंग स्थिति को हटा देता है, इसलिए इसे दिखाने के लिए उस स्थिति को फिर से बनाना पड़ता है।

यदि सामग्री सहायक तकनीक के लिए अदृश्य होनी चाहिए, तो सिमेंटिक रूप से सही aria-hidden का उपयोग करें या इसे DOM से हटा दें, और सुनिश्चित करें कि फोकस छिपे हुए क्षेत्र में प्रवेश न कर सके।

4. ऑप्टिमाइज़ेशन को विफल करने वाले रीड्स का ऑडिट करें

content-visibility सेक्शन पर बार-बार लेआउट रीड्स ब्राउज़र को छोड़े गए सब-ट्री की समय से पहले गणना करने के लिए मजबूर कर सकते हैं। केवल आवश्यकता होने पर ही मापें, राइट्स से पहले रीड्स को बैच करें, और सिंक्रोनस लेआउट को ट्रिगर करने वाले बारी-बारी से रीड्स और राइट्स से बचें।

requestAnimationFrame(() => {
  const height = card.getBoundingClientRect().height;
  card.style.setProperty('--measured-height', `${height}px`);
});

यह समय (timing) को दर्शाता है, कोई सार्वभौमिक नुस्खा नहीं है। किसी रीड को हटाने से पहले यह साबित करने के लिए परफॉर्मेंस रिकॉर्डिंग का उपयोग करें कि वह रीड एक लॉन्ग टास्क बना रहा है।

5. उपयोगकर्ता-उन्मुख मेट्रिक्स के साथ सत्यापित करें

कम से कम, इनका परीक्षण करें:

फर्स्ट रेंडर और कुल रेंडरिंग समय, यह साबित करने के लिए कि ऑफ-स्क्रीन कार्य कम हो गया था।
INP या क्लिक-टाइम लॉन्ग टास्क, यह देखने के लिए कि क्या मुख्य थ्रेड को हेडरूम मिला है।
CLS और स्क्रॉल स्थिति, प्लेसहोल्डर-साइज के जंप को पकड़ने के लिए।
कीबोर्ड Tab, फाइंड-इन-पेज, और एक स्क्रीन रीडर, auto एक्सेसिबिलिटी व्यवहार को सत्यापित करने के लिए।
एक असमर्थित ब्राउज़र, यह सुनिश्चित करने के लिए कि डिफ़ॉल्ट visible व्यवहार अभी भी सभी सामग्री को रेंडर करता है।

web.dev के उदाहरण ने एक विशेष पेज के रेंडरिंग समय को 232ms से घटाकर 30ms कर दिया। इसे एक प्रयोग के परिणाम के रूप में मानें, हर साइट के लिए वादा नहीं; आपका निष्कर्ष आपके अपने कंट्रोल और ट्रीटमेंट मापों से आना चाहिए।

उच्च-गुणवत्ता वाला नमूना उत्तर

मैं इस लक्षण को ऑफ-स्क्रीन कंटेंट के लिए अत्यधिक रेंडरिंग कार्य के रूप में परिभाषित करूंगा, फिर परफॉर्मेंस पैनल में पुष्टि करूंगा कि स्टाइल, लेआउट या पेंट मुख्य थ्रेड पर हावी है। पुष्टि के बाद, मैं पेज को स्वतंत्र सेक्शनों में विभाजित करूंगा, content-visibility: auto सेट करूंगा, और प्रतिनिधि सामग्री से contain-intrinsic-size का अनुमान लगाऊंगा। ब्राउज़र तब DOM और सहायक-तकनीक एक्सेस को बरकरार रखते हुए ऑफ-स्क्रीन डिसेंडेंट रेंडरिंग को छोड़ सकता है।

मैं केवल फर्स्ट-रेंडर समय पर नहीं रुकूंगा। मैं स्क्रॉलबार मूवमेंट, फोकस और फाइंड-इन-पेज की जांच करूंगा, और स्क्रॉलिंग या स्टेट अपडेट के दौरान लेआउट को बाध्य करने वाले getBoundingClientRect या offsetHeight रीड्स की खोज करूंगा। मैं फर्स्ट रेंडर, स्क्रॉल लॉन्ग टास्क, INP, CLS और वास्तविक-उपयोगकर्ता डेटा की तुलना करूंगा। यदि कार्ड की ऊंचाई बहुत अधिक बदलती है या सीमाओं में क्रॉस-सेक्शन लेआउट निर्भरताएं हैं, तो मैं विभाजन और साइजिंग रणनीति को संशोधित करूंगा। असमर्थित ब्राउज़रों को डिफ़ॉल्ट visible व्यवहार मिलता है, इसलिए ऑप्टिमाइज़ेशन प्रोग्रेसिव एन्हांसमेंट बना रहता है।

सामान्य गलतियां

गलती → पूरे पेज पर content-visibility: auto जोड़ना → यह विफल क्यों होता है → अस्पष्ट सीमाएं लेआउट निर्भरता को छिपाती हैं और एट्रिब्यूशन को असंभव बनाती हैं → सुधार → स्वतंत्र सेक्शनों को विभाजित करें और पहले एक बेसलाइन रिकॉर्ड करें।
गलती → इंट्रिन्सिक साइजिंग छोड़ देना → यह विफल क्यों होता है → साइज कंटेनमेंट सेक्शन की ऊंचाई को कम आंक सकता है, जिससे स्क्रॉल और CLS खराब हो जाते हैं → सुधार → नमूनों से अनुमान लगाएं और वास्तविक स्क्रॉल स्थिति का निरीक्षण करें।
गलती → hidden को aria-hidden के समानार्थी के रूप में उपयोग करना → यह विफल क्यों होता है → विज़ुअल छिपाव और एक्सेसिबिलिटी सिमेंटिक्स भिन्न होते हैं → सुधार → उत्पाद सिमेंटिक्स के अनुसार DOM हटाना, aria-hidden, या संरक्षित सामग्री चुनें।
गलती → प्रदर्शन से संबंधित प्रत्येक DOM रीड को हटा देना → यह विफल क्यों होता है → कुछ माप आवश्यक होते हैं और बिना सोचे-समझे हटाने से व्यवहार टूट जाता है → सुधार → उन रीड्स की पहचान करने के लिए एक रिकॉर्डिंग का उपयोग करें जो वास्तव में लेआउट को बाध्य करते हैं।

फॉलो-अप प्रश्न और उत्तर

क्या आप एक ही इंट्रिन्सिक साइज का उपयोग करेंगे जब कार्ड की ऊंचाई में पांच गुना अंतर हो?

नहीं। एक अनुमान कुछ कार्डों को नाटकीय रूप से बहुत छोटा या बहुत लंबा बना देगा। मैं कंटेंट प्रकारों को बकेट में बांटूंगा, याद रखे गए रेंडर किए गए आकारों को प्राथमिकता दूंगा, और यदि आवश्यक हो, तो सर्वर से साइज हिंट वापस लाऊंगा। मैं यह तय करने के लिए CLS और स्क्रॉल एरर का उपयोग करूंगा कि क्या अतिरिक्त बकेटिंग जटिलता फायदेमंद है।

क्या content-visibility पर्याप्त है यदि उत्पाद को ऑफ-स्क्रीन वीडियो डिकोडिंग को पूरी तरह से रोकने की आवश्यकता है?

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

आप उन ब्राउज़रों के लिए कैसे शिप करेंगे जो इस प्रॉपर्टी का समर्थन नहीं करते हैं?

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

आप कैसे साबित करते हैं कि लाभ छोटे DOM के बजाय इस प्रॉपर्टी से आया है?

समान डेटा और DOM संरचना रखें और स्थानीय या A/B कंट्रोल में केवल CSS प्रॉपर्टी को बदलें। रेंडरिंग समय, लॉन्ग टास्क, INP और CLS रिकॉर्ड करें। यदि पेजिनेशन, इमेज लेज़ी लोडिंग, या स्क्रिप्ट शेड्यूलिंग भी बदल गई है, तो परिणाम को एक प्रॉपर्टी के लिए जिम्मेदार नहीं ठहराया जा सकता है।