कुल लेआउट शिफ़्ट ऑप्टिमाइज़ करें

उपयोगकर्ता अनुभव को बेहतर बनाने के लिए, लेआउट में अचानक होने वाले बदलावों से बचने का तरीका जानें

पब्लिश किया गया: 5 मई, 2020, पिछली बार अपडेट किया गया: 7 फ़रवरी, 2025

लेआउट शिफ़्ट होने में लगने वाला समय (सीएलएस), वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली तीन मेट्रिक में से एक है. इससे कॉन्टेंट की अस्थिरता का पता चलता है. इसके लिए, व्यूपोर्ट में दिखने वाले कॉन्टेंट के कितने हिस्से में बदलाव हुआ है और बदलाव वाले एलिमेंट कितनी दूर तक गए हैं, इन दोनों को मिलाया जाता है.

लेआउट शिफ़्ट की वजह से, उपयोगकर्ताओं का ध्यान भटक सकता है. मान लें कि आपने कोई लेख पढ़ना शुरू किया है. इस दौरान, पेज पर मौजूद एलिमेंट अचानक से इधर-उधर हो जाते हैं. इससे आपको लेख पढ़ने में परेशानी होती है और आपको फिर से अपनी जगह ढूंढनी पड़ती है. वेब पर ऐसा अक्सर होता है. जैसे, खबरें पढ़ते समय या 'खोजें' या 'कार्ट में जोड़ें' बटन पर क्लिक करते समय. इस तरह के अनुभव, देखने में खराब लगते हैं और इनसे झुंझलाहट होती है. ऐसा अक्सर तब होता है, जब पेज पर अचानक कोई दूसरा एलिमेंट जोड़ दिया जाता है या उसका साइज़ बदल दिया जाता है. इस वजह से, दिखने वाले एलिमेंट को अपनी जगह से हटना पड़ता है.

उपयोगकर्ताओं को अच्छा अनुभव देने के लिए, यह ज़रूरी है कि साइटों पर 75% पेज विज़िट का सीएलएस 0.1 या इससे कम हो.

सीएलएस की अच्छी वैल्यू 0.1 से कम होती है, खराब वैल्यू 0.25 से ज़्यादा होती है, और इन दोनों के बीच की वैल्यू को बेहतर बनाने की ज़रूरत होती है
सीएलएस की अच्छी वैल्यू 0.1 या इससे कम होती है. खराब वैल्यू 0.25 से ज़्यादा होती हैं.

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

इस गाइड में, हम लेआउट में बदलाव की सामान्य वजहों को ऑप्टिमाइज़ करने के बारे में बताएंगे.

सीएलएस स्कोर कम होने की सबसे आम वजहें ये हैं:

  • डाइमेंशन के बिना इमेज.
  • बिना डाइमेंशन वाले विज्ञापन, एम्बेड किए गए कॉन्टेंट, और iframe.
  • डाइनैमिक तरीके से डाला गया कॉन्टेंट, जैसे कि बिना डाइमेंशन वाले विज्ञापन, एम्बेड किए गए कॉन्टेंट, और iframe.
  • वेब फ़ॉन्ट.

लेआउट में होने वाले बदलावों की वजहों को समझना

सीएलएस से जुड़ी सामान्य समस्याओं के समाधान देखने से पहले, यह समझना ज़रूरी है कि आपका सीएलएस स्कोर क्या है और लेआउट में बदलाव कहां से हो रहे हैं.

लैब टूल बनाम फ़ील्ड में सीएलएस

डेवलपर अक्सर यह सोचते हैं कि Chrome UX Report (CrUX) से मेज़र किया गया सीएलएस गलत है, क्योंकि यह Chrome DevTools या अन्य लैब टूल का इस्तेमाल करके मेज़र किए गए सीएलएस से मेल नहीं खाता. Lighthouse जैसे वेब परफ़ॉर्मेंस लैब टूल, किसी पेज का पूरा सीएलएस नहीं दिखा सकते. ऐसा इसलिए, क्योंकि ये टूल आम तौर पर कुछ वेब परफ़ॉर्मेंस मेट्रिक को मेज़र करने के लिए, पेज को बुनियादी तौर पर लोड करते हैं. साथ ही, कुछ दिशा-निर्देश देते हैं. हालांकि, Lighthouse के उपयोगकर्ता फ़्लो की मदद से, डिफ़ॉल्ट पेज लोड ऑडिट से ज़्यादा मेज़रमेंट किया जा सकता है.

CrUX, Web Vitals प्रोग्राम का Google डेटासेट है. इसके लिए, सीएलएस को पेज के पूरे लाइफ़साइकल के दौरान मेज़र किया जाता है. इसे सिर्फ़ पेज के शुरुआती लोड के दौरान मेज़र नहीं किया जाता. लैब टूल आम तौर पर ऐसा ही करते हैं.

पेज लोड होने के दौरान लेआउट शिफ़्ट होना आम बात है, क्योंकि पेज को शुरुआती तौर पर रेंडर करने के लिए सभी ज़रूरी संसाधन फ़ेच किए जाते हैं. हालांकि, शुरुआती लोड के बाद भी लेआउट शिफ़्ट हो सकती हैं. उपयोगकर्ता के इंटरैक्शन की वजह से, लोड होने के बाद कई बार लेआउट में बदलाव हो सकता है. इसलिए, इन्हें सीएलएस स्कोर में शामिल नहीं किया जाएगा. ऐसा इसलिए, क्योंकि ये अनुमानित बदलाव हैं. हालांकि, ऐसा तब तक होगा, जब तक ये बदलाव इंटरैक्शन के 500 मिलीसेकंड के अंदर होते हैं.

हालांकि, लोड होने के बाद होने वाले अन्य लेआउट शिफ़्ट शामिल किए जा सकते हैं. ये ऐसे शिफ़्ट होते हैं जिनके बारे में उपयोगकर्ता को पता नहीं होता और जहां कोई ज़रूरी इंटरैक्शन नहीं हुआ होता. उदाहरण के लिए, अगर पेज पर आगे स्क्रोल करने पर लेज़ी-लोड किया गया कॉन्टेंट लोड होता है और इससे लेआउट शिफ़्ट होते हैं. लोड होने के बाद सीएलएस की अन्य सामान्य वजहें, ट्रांज़िशन के इंटरैक्शन पर होती हैं. उदाहरण के लिए, सिंगल पेज ऐप्लिकेशन पर, जो 500 मिलीसेकंड की ग्रेस अवधि से ज़्यादा समय लेते हैं.

PageSpeed Insights, "जानें कि इंटरनेट की परफ़ॉर्मेंस को लेकर आपके उपयोगकर्ताओं को कैसा अनुभव मिल रहा है" सेक्शन में, किसी यूआरएल के लिए उपयोगकर्ता को दिखने वाला सीएलएस दिखाता है. साथ ही, "परफ़ॉर्मेंस से जुड़ी समस्याओं का पता लगाएं" सेक्शन में, लैब में जांच के आधार पर लोड सीएलएस दिखाता है. इन वैल्यू के बीच अंतर, पोस्ट-लोड सीएलएस की वजह से हो सकता है.

PageSpeed Insights में यूआरएल-लेवल का डेटा दिखाया गया है. इसमें असली उपयोगकर्ता के सीएलएस को हाइलाइट किया गया है, जो Lighthouse के सीएलएस से काफ़ी ज़्यादा है
इस उदाहरण में, CrUX ने Lighthouse की तुलना में बहुत ज़्यादा सीएलएस मेज़र किया है.

लोड होने के दौरान होने वाले सीएलएस से जुड़ी समस्याओं का पता लगाना

जब PageSpeed Insights के CrUX और Lighthouse के सीएलएस स्कोर एक जैसे होते हैं, तो आम तौर पर इसका मतलब होता है कि लोड सीएलएस से जुड़ी कोई समस्या है. इस समस्या का पता Lighthouse ने लगाया है. इस मामले में, Lighthouse दो ऑडिट में आपकी मदद करेगा. इससे आपको उन इमेज के बारे में ज़्यादा जानकारी मिलेगी जिनकी वजह से सीएलएस की समस्या हो रही है. ऐसा इसलिए हो रहा है, क्योंकि इमेज की चौड़ाई और ऊंचाई की जानकारी मौजूद नहीं है. साथ ही, Lighthouse उन सभी एलिमेंट की सूची भी दिखाएगा जो पेज लोड होने के दौरान शिफ़्ट हुए हैं. साथ ही, यह भी बताएगा कि सीएलएस में उनका कितना योगदान है. सीएलएस ऑडिट को फ़िल्टर करके, इन ऑडिट को देखा जा सकता है:

Lighthouse के स्क्रीनशॉट में सीएलएस ऑडिट दिख रहे हैं. इनमें सीएलएस से जुड़ी समस्याओं की पहचान करने और उन्हें ठीक करने के लिए ज़्यादा जानकारी दी गई है
Lighthouse की मदद से, सीएलएस की गड़बड़ी की पूरी जानकारी.

DevTools में मौजूद परफ़ॉर्मेंस पैनल से, लेआउट में होने वाले बदलावों के बारे में काफ़ी जानकारी मिलती है:

Chrome DevTools के परफ़ॉर्मेंस पैनल में लेआउट शिफ़्ट के रिकॉर्ड दिखाए जा रहे हैं.
परफ़ॉर्मेंस पैनल में नया ट्रेस रिकॉर्ड करने के बाद, नतीजों के लेआउट में बदलाव ट्रैक में बैंगनी रंग के बार दिखते हैं. इनमें Layout Shift क्लस्टर दिखते हैं. डायमंड पर क्लिक करने से, बदलाव का ऐनिमेशन दिखता है. साथ ही, खास जानकारी पैनल में बदलाव की जानकारी दिखती है.

लेआउट शिफ़्ट को लेआउट शिफ़्ट ट्रैक में हाइलाइट किया जाता है. बैंगनी रंग की लाइन, शिफ़्ट क्लस्टर में ग्रुप की जाती है. साथ ही, डायमंड से उस क्लस्टर में अलग-अलग शिफ़्ट दिखती हैं. डायमंड का साइज़, शिफ़्ट के साइज़ के हिसाब से होता है. इससे आपको सबसे बड़े शिफ़्ट पर फ़ोकस करने में मदद मिलती है.

किसी शिफ़्ट पर क्लिक करने से, एक पॉप-अप दिखता है. इसमें शिफ़्ट का ऐनिमेशन होता है. साथ ही, पर्पल रंग में हाइलाइट किए गए एलिमेंट की शिफ़्ट दिखती है.

इसके अलावा, Layout Shift रिकॉर्ड के लिए खास जानकारी वाले व्यू में, बदलाव शुरू होने का समय, बदलाव का स्कोर, और बदले गए एलिमेंट शामिल होते हैं. इससे लोड सीएलएस की समस्याओं के बारे में ज़्यादा जानकारी मिलती है. ऐसा इसलिए, क्योंकि इसे रीलोड परफ़ॉर्मेंस प्रोफ़ाइल के साथ आसानी से दोहराया जा सकता है.

यह बाईं ओर मौजूद अहम जानकारी पैनल में दिखने वाली, लेआउट में बदलाव करने वाले एलिमेंट की अहम जानकारी से भी लिंक होता है. इसमें सबसे ऊपर कुल सीएलएस के साथ-साथ, लेआउट में बदलाव होने की संभावित वजहें भी दिखती हैं.

पेज लोड होने के बाद होने वाली सीएलएस की समस्याओं का पता लगाना

CrUX और Lighthouse के सीएलएस स्कोर में अंतर होने का मतलब अक्सर पोस्ट-लोड सीएलएस होता है. फ़ील्ड डेटा के बिना, इन बदलावों को ट्रैक करना मुश्किल हो सकता है. फ़ील्ड डेटा इकट्ठा करने के बारे में जानकारी पाने के लिए, फ़ील्ड में सीएलएस एलिमेंट मेज़र करना लेख पढ़ें.

परफ़ॉर्मेंस पैनल की लाइव मेट्रिक व्यू सुविधा की मदद से, पेज के साथ इंटरैक्ट किया जा सकता है. साथ ही, सीएलएस स्कोर को मॉनिटर किया जा सकता है. इससे उन इंटरैक्शन का पता लगाया जा सकता है जिनकी वजह से लेआउट में बड़े बदलाव होते हैं.

Chrome DevTools के परफ़ॉर्मेंस पैनल की लाइव मेट्रिक स्क्रीन में, लेआउट शिफ़्ट के रिकॉर्ड दिखाए जा रहे हैं.
परफ़ॉर्मेंस पैनल की लाइव मेट्रिक व्यू सुविधा की मदद से, किसी वेब पेज के साथ इंटरैक्ट करते समय उसके सीएलएस स्कोर की निगरानी की जा सकती है.

DevTools के बजाय, अपने वेब पेज को ब्राउज़ किया जा सकता है. इसके लिए, कंसोल में चिपकाए गए परफ़ॉर्मेंस ऑब्ज़र्वर का इस्तेमाल करके लेआउट शिफ़्ट रिकॉर्ड करें.

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

ज़्यादा जानकारी के लिए, लेआउट में होने वाले बदलावों को डीबग करना लेख पढ़ें.

सीएलएस की सामान्य वजहों का पता लगाने के बाद, Lighthouse के टाइमस्पैन यूज़र फ़्लो मोड का इस्तेमाल करके यह पक्का किया जा सकता है कि लेआउट में बदलाव की वजह से, सामान्य यूज़र फ़्लो में कोई रुकावट न आए.

फ़ील्ड में मौजूद सीएलएस एलिमेंट को मेज़र करना

फ़ील्ड में सीएलएस को मॉनिटर करने से, यह पता लगाने में मदद मिल सकती है कि सीएलएस किन परिस्थितियों में होता है. साथ ही, इसकी संभावित वजहों का पता लगाया जा सकता है. ज़्यादातर लैब टूल की तरह, फ़ील्ड टूल सिर्फ़ उन एलिमेंट को मेज़र करते हैं जो अपनी जगह से हट गए हैं. हालांकि, इससे आम तौर पर यह पता चल जाता है कि ऐसा क्यों हुआ. सीएलएस फ़ील्ड मेज़रमेंट का इस्तेमाल करके, यह भी पता लगाया जा सकता है कि किन समस्याओं को ठीक करना सबसे ज़्यादा ज़रूरी है.

web-vitals लाइब्रेरी में एट्रिब्यूशन फ़ंक्शन होते हैं. इनकी मदद से, यह अतिरिक्त जानकारी इकट्ठा की जा सकती है. ज़्यादा जानकारी के लिए, फ़ील्ड में परफ़ॉर्मेंस को डीबग करना लेख पढ़ें. अन्य आरयूएम प्रोवाइडर भी इसी तरह से इस डेटा को इकट्ठा और प्रज़ेंट कर रहे हैं.

सीएलएस की सामान्य वजहें

सीएलएस की वजहों का पता लगाने के बाद, समस्याओं को ठीक करने पर काम किया जा सकता है. इस सेक्शन में, हम सीएसएल की कुछ सामान्य वजहें बताएंगे. साथ ही, इनसे बचने के तरीके भी बताएंगे.

ऐसी इमेज जिनके डाइमेंशन नहीं दिए गए हैं

अपनी इमेज और वीडियो एलिमेंट में, width और height साइज़ एट्रिब्यूट की वैल्यू हमेशा शामिल करें. इसके अलावा, सीएसएस aspect-ratio या इसी तरह के किसी अन्य तरीके का इस्तेमाल करके, ज़रूरी जगह रिज़र्व करें. इस तरीके से यह पक्का किया जाता है कि इमेज लोड होने के दौरान, ब्राउज़र दस्तावेज़ में सही जगह दे सके.

ऐसी इमेज जिनकी चौड़ाई और लंबाई नहीं बताई गई है.
चौड़ाई और ऊंचाई के साथ इमेज.
Lighthouse रिपोर्ट में, इमेज पर डाइमेंशन सेट करने के बाद, लेआउट में हुए बदलाव के असर को दिखाया गया है
Lighthouse 6.0 में, इमेज के डाइमेंशन सेट करने से सीएलएस पर पड़ने वाला असर.

इमेज पर width और height एट्रिब्यूट के इतिहास की जानकारी

वेब की शुरुआत में, डेवलपर अपने <img> टैग में width और height एट्रिब्यूट जोड़ते थे. इससे यह पक्का किया जाता था कि ब्राउज़र के इमेज फ़ेच करना शुरू करने से पहले, पेज पर ज़रूरत के मुताबिक जगह मिल जाए. इससे रीफ़्लो और री-लेआउट कम हो जाएगा.

<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

इस उदाहरण में width और height में यूनिट शामिल नहीं हैं. इन "पिक्सल" डाइमेंशन से यह पक्का होगा कि ब्राउज़र ने पेज के लेआउट में 640x360 का एरिया रिज़र्व किया है. इमेज को इस जगह के हिसाब से स्ट्रेच किया जाएगा. भले ही, इमेज के ओरिजनल डाइमेंशन इससे मेल खाते हों या नहीं.

रिस्पॉन्सिव वेब डिज़ाइन की सुविधा शुरू होने के बाद, डेवलपर ने width और height को हटाना शुरू कर दिया. इसके बजाय, उन्होंने इमेज का साइज़ बदलने के लिए सीएसएस का इस्तेमाल करना शुरू कर दिया:

img {
  width: 100%; /* or max-width: 100%; */
  height: auto;
}

हालांकि, इमेज का साइज़ तय नहीं किया गया है. इसलिए, जब तक ब्राउज़र इसे डाउनलोड करना शुरू नहीं करता और इसके डाइमेंशन का पता नहीं लगा लेता, तब तक इसके लिए जगह नहीं दी जा सकती. इमेज लोड होने पर, टेक्स्ट पेज पर नीचे की ओर शिफ़्ट हो जाता है, ताकि इमेज के लिए जगह बन सके. इससे, उपयोगकर्ता को भ्रम होता है और उसे परेशानी होती है.

ऐसे में, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) काम आता है. किसी इमेज का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) उसकी चौड़ाई और ऊंचाई का अनुपात होता है. आम तौर पर, इसे दो संख्याओं के तौर पर दिखाया जाता है. इन संख्याओं को कोलन से अलग किया जाता है. उदाहरण के लिए, 16:9 या 4:3. x:y आसपेक्ट रेशियो के लिए, इमेज x यूनिट चौड़ी और y यूनिट ऊंची होती है.

इसका मतलब है कि अगर हमें किसी एक डाइमेंशन के बारे में पता है, तो दूसरे डाइमेंशन का पता लगाया जा सकता है. 16:9 के आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) के लिए:

  • अगर puppy.jpg की ऊंचाई 360 पिक्सल है, तो चौड़ाई 360 x (16 / 9) = 640 पिक्सल होगी
  • अगर puppy.jpg की चौड़ाई 640 पिक्सल है, तो ऊंचाई 640 x (9 / 16) = 360 पिक्सल होगी

किसी इमेज का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) जानने से, ब्राउज़र को इमेज की ऊंचाई और उससे जुड़े हिस्से के लिए ज़रूरी जगह का हिसाब लगाने और उसे रिज़र्व करने में मदद मिलती है.

इमेज के डाइमेंशन सेट करने का नया सबसे सही तरीका

आधुनिक ब्राउज़र, इमेज के width और height एट्रिब्यूट के आधार पर, इमेज का डिफ़ॉल्ट आसपेक्ट रेशियो सेट करते हैं. इसलिए, इमेज पर इन एट्रिब्यूट को सेट करके और अपनी स्टाइल शीट में ऊपर दी गई सीएसएस को शामिल करके, लेआउट में होने वाली गड़बड़ियों को रोका जा सकता है.

<!-- set a 640:360 i.e a 16:9 aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

इसके बाद, सभी ब्राउज़र एलिमेंट की मौजूदा width और height एट्रिब्यूट के आधार पर, डिफ़ॉल्ट आसपेक्ट रेशियो जोड़ देंगे.

यह इमेज लोड होने से पहले, width और height एट्रिब्यूट के आधार पर आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) का हिसाब लगाता है. यह जानकारी, लेआउट के हिसाब से जगह तय करने की प्रोसेस की शुरुआत में ही मिल जाती है. जब किसी इमेज की चौड़ाई तय कर दी जाती है (उदाहरण के लिए, width: 100%), तो आसपेक्ट रेशियो का इस्तेमाल करके उसकी ऊंचाई का हिसाब लगाया जाता है.

इस aspect-ratio वैल्यू का हिसाब, मुख्य ब्राउज़र तब लगाते हैं, जब एचटीएमएल प्रोसेस किया जाता है. ऐसा डिफ़ॉल्ट उपयोगकर्ता एजेंट स्टाइल शीट के साथ नहीं किया जाता है. इस पोस्ट में, इसकी वजह के बारे में ज़्यादा जानकारी दी गई है. इसलिए, वैल्यू थोड़ी अलग तरीके से दिखती है. उदाहरण के लिए, Chrome इसे एलिमेंट पैनल के स्टाइल सेक्शन में इस तरह दिखाता है:

img[Attributes Style] {
  aspect-ratio: auto 640 / 360;
}

Safari भी इसी तरह काम करता है. इसके लिए, वह एचटीएमएल एट्रिब्यूट स्टाइल सोर्स का इस्तेमाल करता है. Firefox, Inspector पैनल में इस कैलकुलेट किए गए aspect-ratio को बिल्कुल भी नहीं दिखाता है. हालांकि, लेआउट के लिए इसका इस्तेमाल करता है.

ऊपर दिए गए कोड का auto हिस्सा ज़रूरी है. इसकी वजह यह है कि इमेज डाउनलोड होने के बाद, यह इमेज के डाइमेंशन को डिफ़ॉल्ट आसपेक्ट रेशियो से बदल देता है. अगर इमेज के डाइमेंशन अलग-अलग हैं, तो इमेज लोड होने के बाद भी लेआउट में कुछ बदलाव होता है. हालांकि, इससे यह पक्का होता है कि एचटीएमएल गलत होने पर भी, इमेज उपलब्ध होने पर उसके आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) का इस्तेमाल किया जाए. अगर असल आसपेक्ट रेशियो, डिफ़ॉल्ट आसपेक्ट रेशियो से अलग है, तब भी इससे लेआउट में कम बदलाव होता है. ऐसा तब होता है, जब इमेज का डिफ़ॉल्ट साइज़ 0x0 होता है और उसके डाइमेंशन नहीं दिए जाते.

आसपेक्ट रेशियो के बारे में ज़्यादा जानने के लिए, मीडिया के आसपेक्ट रेशियो की मदद से, पेज को बिना किसी रुकावट के लोड करना लेख पढ़ें. इसमें रिस्पॉन्सिव इमेज के बारे में भी बताया गया है.

अगर आपकी इमेज किसी कंटेनर में है, तो सीएसएस का इस्तेमाल करके इमेज का साइज़ बदलकर, उसे कंटेनर की चौड़ाई के हिसाब से सेट किया जा सकता है. हमने height: auto; को इसलिए सेट किया है, ताकि इमेज की ऊंचाई के लिए तय वैल्यू का इस्तेमाल न किया जा सके.

img {
  height: auto;
  width: 100%;
}

रिस्पॉन्सिव इमेज के बारे में क्या जानकारी है?

रिस्पॉन्सिव इमेज का इस्तेमाल करते समय, srcset यह तय करता है कि ब्राउज़र को किन इमेज में से चुनने की अनुमति है और हर इमेज का साइज़ क्या है. यह पक्का करने के लिए कि <img> की चौड़ाई और ऊंचाई के एट्रिब्यूट सेट किए जा सकते हैं, हर इमेज में एक ही आसपेक्ट रेशियो का इस्तेमाल किया जाना चाहिए.

<img
  width="1000"
  height="1000"
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
  alt="Puppy with balloons"
/>

आर्ट डायरेक्शन के हिसाब से, आपकी इमेज के आसपेक्ट रेशियो भी बदल सकते हैं. उदाहरण के लिए, हो सकता है कि आपको छोटे व्यूपोर्ट के लिए, इमेज का काटा गया हिस्सा शामिल करना हो और डेस्कटॉप पर पूरी इमेज दिखानी हो:

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" />
</picture>

Chrome, Firefox, और Safari अब किसी <picture> एलिमेंट में मौजूद <source> एलिमेंट पर width और height सेट करने की सुविधा देते हैं:

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" width="480" height="400" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" width="800" height="400" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" width="800" height="400" />
</picture>

विज्ञापन, एम्बेड किए गए कॉन्टेंट, और देर से लोड होने वाले अन्य कॉन्टेंट

लेआउट शिफ़्ट सिर्फ़ इमेज की वजह से नहीं होते. विज्ञापन, एम्बेड किए गए कॉन्टेंट, iframe, और डाइनैमिक तरीके से जोड़े गए अन्य कॉन्टेंट की वजह से, इनके बाद दिखने वाला कॉन्टेंट नीचे की ओर खिसक सकता है. इससे आपके सीएलएस में बढ़ोतरी हो सकती है.

वेब पर लेआउट शिफ़्ट होने की सबसे बड़ी वजहों में से एक विज्ञापन हैं. विज्ञापन नेटवर्क और पब्लिशर, अक्सर विज्ञापन के डाइनैमिक साइज़ के साथ काम करते हैं. विज्ञापन के साइज़ बढ़ाने से, परफ़ॉर्मेंस और रेवेन्यू में बढ़ोतरी होती है. इसकी वजह यह है कि क्लिक मिलने की दर ज़्यादा होती है और नीलामी में ज़्यादा विज्ञापन हिस्सा लेते हैं. हालांकि, ऐसा करने से उपयोगकर्ता का अनुभव खराब हो सकता है. इसकी वजह यह है कि विज्ञापन, पेज पर दिखने वाले कॉन्टेंट को नीचे की ओर ले जाते हैं.

एम्बेड किए जा सकने वाले विजेट की मदद से, अपने पेज पर पोर्टेबल वेब कॉन्टेंट शामिल किया जा सकता है. जैसे, YouTube के वीडियो, Google Maps के मैप, और सोशल मीडिया पोस्ट. हालांकि, लोड होने से पहले इन विजेट को अक्सर यह पता नहीं होता कि उनका कॉन्टेंट कितना बड़ा है. इस वजह से, एम्बेड करने की सुविधा देने वाले प्लैटफ़ॉर्म, अपने विजेट के लिए हमेशा जगह रिज़र्व नहीं करते. इसलिए, जब विजेट लोड होते हैं, तो लेआउट में बदलाव होता है.

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

देर से लोड होने वाले कॉन्टेंट के लिए जगह रिज़र्व करना

कॉन्टेंट फ़्लो में देर से लोड होने वाला कॉन्टेंट डालते समय, लेआउट में बदलाव से बचा जा सकता है. इसके लिए, शुरुआती लेआउट में उनके लिए जगह रिज़र्व करें.

जगह रिज़र्व करने के लिए, min-height सीएसएस नियम जोड़ा जा सकता है. इसके अलावा, रिस्पॉन्सिव कॉन्टेंट (जैसे कि विज्ञापन) के लिए, aspect-ratio सीएसएस प्रॉपर्टी का इस्तेमाल किया जा सकता है. इसका इस्तेमाल उसी तरह से किया जाता है जिस तरह से ब्राउज़र, डाइमेंशन वाली इमेज के लिए इसका इस्तेमाल अपने-आप करते हैं.

तीन मोबाइल डिवाइसों में सिर्फ़ टेक्स्ट कॉन्टेंट दिखाया गया है. पहले डिवाइस में टेक्स्ट कॉन्टेंट सबसे ऊपर है, दूसरे डिवाइस में यह नीचे की ओर खिसक गया है, और तीसरे डिवाइस में टेक्स्ट कॉन्टेंट के लिए जगह रिज़र्व की गई है. इसलिए, यह नीचे की ओर नहीं खिसका है
विज्ञापनों के लिए जगह रिज़र्व करने से लेआउट में बदलाव को रोका जा सकता है

आपको मीडिया क्वेरी का इस्तेमाल करके, अलग-अलग डिवाइसों के हिसाब से विज्ञापन या प्लेसहोल्डर के साइज़ में मामूली अंतर को ध्यान में रखना पड़ सकता है.

ऐसे कॉन्टेंट के लिए, लेआउट शिफ़्ट को पूरी तरह से हटाने के लिए ज़रूरी जगह रिज़र्व नहीं की जा सकती जिसकी ऊंचाई तय नहीं होती. जैसे, विज्ञापन. अगर छोटा विज्ञापन दिखाया जाता है, तो पब्लिशर लेआउट में बदलाव से बचने के लिए, बड़े कंटेनर को स्टाइल कर सकता है. इसके अलावा, वह पुराने डेटा के आधार पर विज्ञापन स्लॉट के लिए सबसे सही साइज़ चुन सकता है. इस तरीके से, पेज पर खाली जगह बढ़ जाती है.

इसके बजाय, शुरुआती साइज़ को सबसे छोटे साइज़ पर सेट किया जा सकता है. साथ ही, बड़े कॉन्टेंट के लिए कुछ हद तक बदलाव स्वीकार किया जा सकता है. min-height का इस्तेमाल करने से, पैरंट एलिमेंट को ज़रूरत के हिसाब से बड़ा किया जा सकता है. साथ ही, लेआउट शिफ़्ट के असर को कम किया जा सकता है. ऐसा इसलिए, क्योंकि खाली एलिमेंट का डिफ़ॉल्ट साइज़ 0 पिक्सल होता है.

अगर कोई विज्ञापन नहीं दिखाया जाता है, तो प्लेसहोल्डर दिखाकर रिज़र्व किए गए स्पेस को छोटा करने से बचें. कॉन्टेंट डालने की वजह से जितना सीएलएस होता है उतना ही, एलिमेंट के लिए तय की गई जगह को हटाने की वजह से भी हो सकता है.

देर से लोड होने वाले कॉन्टेंट को व्यूपोर्ट में नीचे की ओर रखें

आम तौर पर, व्यूपोर्ट के सबसे ऊपर डाइनैमिक तरीके से इंजेक्ट किए गए कॉन्टेंट की वजह से, लेआउट में बदलाव ज़्यादा होते हैं. ऐसा इसलिए होता है, क्योंकि व्यूपोर्ट में नीचे की ओर इंजेक्ट किए गए कॉन्टेंट की वजह से, लेआउट में बदलाव कम होते हैं. हालांकि, व्यूपोर्ट में कहीं भी कॉन्टेंट डालने से अब भी कुछ बदलाव होता है. अगर आपको इंजेक्ट किए गए कॉन्टेंट के लिए जगह रिज़र्व करने का विकल्प नहीं मिलता है, तो हमारा सुझाव है कि आप उसे पेज पर बाद में रखें. इससे पेज के सीएलएस पर पड़ने वाले असर को कम किया जा सकेगा.

उपयोगकर्ता की अनुमति के बिना नया कॉन्टेंट न डालें

जब कोई साइट लोड की जाती है, तब व्यूपोर्ट के सबसे ऊपर या सबसे नीचे दिखने वाले यूज़र इंटरफ़ेस (यूआई) की वजह से, आपको लेआउट में बदलाव का सामना करना पड़ सकता है. विज्ञापनों की तरह, ऐसा अक्सर बैनर और फ़ॉर्म के साथ होता है. इनसे पेज के बाकी कॉन्टेंट की जगह बदल जाती है:

डाइनैमिक कॉन्टेंट के लिए जगह रिज़र्व नहीं की गई है.

अगर आपको इस तरह के यूज़र इंटरफ़ेस (यूआई) दिखाने हैं, तो व्यू पोर्ट में इसके लिए पहले से ही काफ़ी जगह रिज़र्व करें. उदाहरण के लिए, प्लेसहोल्डर या स्केलेटन यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके. इससे जब यह लोड होगा, तो पेज पर मौजूद कॉन्टेंट अचानक इधर-उधर नहीं होगा. इसके अलावा, यह पक्का करें कि एलिमेंट, दस्तावेज़ के फ़्लो का हिस्सा न हो. इसके लिए, कॉन्टेंट को उस जगह पर ओवरले करें जहां यह सही हो. इस तरह के कॉम्पोनेंट के बारे में ज़्यादा सुझाव पाने के लिए, कुकी नोटिस के लिए सबसे सही तरीके पोस्ट देखें.

कुछ मामलों में, डाइनैमिक तरीके से कॉन्टेंट जोड़ना, उपयोगकर्ता अनुभव का एक अहम हिस्सा होता है. उदाहरण के लिए, आइटम की सूची में ज़्यादा प्रॉडक्ट लोड करते समय या लाइव फ़ीड के कॉन्टेंट को अपडेट करते समय. इन मामलों में लेआउट में अचानक होने वाले बदलावों से बचने के कई तरीके हैं:

  • पुराने कॉन्टेंट को तय साइज़ वाले कंटेनर में नए कॉन्टेंट से बदलें. इसके अलावा, कैरसेल का इस्तेमाल करें और ट्रांज़िशन के बाद पुराने कॉन्टेंट को हटा दें. जब तक ट्रांज़िशन पूरा नहीं हो जाता, तब तक सभी लिंक और कंट्रोल बंद करना न भूलें. इससे नया कॉन्टेंट लोड होने के दौरान, गलती से क्लिक या टैप होने से रोका जा सकेगा.
  • उपयोगकर्ता को नया कॉन्टेंट लोड करने की सुविधा दें, ताकि उसे बदलाव के बारे में पता हो. उदाहरण के लिए, "ज़्यादा लोड करें" या "रीफ़्रेश करें" बटन का इस्तेमाल करें. हमारा सुझाव है कि उपयोगकर्ता के इंटरैक्शन से पहले ही कॉन्टेंट को प्रीफ़ेच कर लें, ताकि वह तुरंत दिख जाए. हम आपको याद दिलाना चाहते हैं कि उपयोगकर्ता के इनपुट के 500 मिलीसेकंड के अंदर होने वाली लेआउट शिफ़्ट को सीएलएस में नहीं गिना जाता.
  • कॉन्टेंट को ऑफ़स्क्रीन पर आसानी से लोड करें और उपयोगकर्ता को एक सूचना दिखाएं कि यह उपलब्ध है. उदाहरण के लिए, "सबसे ऊपर स्क्रोल करें" बटन के साथ.
Twitter और Chloé की वेबसाइट पर, लेआउट में अचानक बदलाव किए बिना डाइनैमिक कॉन्टेंट लोड होने के उदाहरण
लगातार अपडेट होने वाले कॉन्टेंट को लोड करने के उदाहरण, जिनसे लेआउट में अचानक बदलाव नहीं होता. बाईं ओर: Twitter पर लाइव फ़ीड का कॉन्टेंट लोड हो रहा है. दाईं ओर: Chloé की वेबसाइट पर "ज़्यादा लोड करें" का उदाहरण. देखें कि YNAP की टीम ने ज़्यादा कॉन्टेंट लोड करते समय, सीएलएस को कैसे ऑप्टिमाइज़ किया.

ऐनिमेशन

सीएसएस प्रॉपर्टी की वैल्यू में बदलाव करने पर, ब्राउज़र को इन बदलावों पर प्रतिक्रिया देनी पड़ सकती है. कुछ वैल्यू, जैसे कि box-shadow और box-sizing, फिर से लेआउट, पेंट, और कंपोज़िट को ट्रिगर करती हैं. top और left प्रॉपर्टी बदलने से भी लेआउट शिफ़्ट होते हैं. भले ही, मूव किया जा रहा एलिमेंट अपनी लेयर पर हो. इन प्रॉपर्टी का इस्तेमाल करके ऐनिमेशन न बनाएं.

री-लेआउट को ट्रिगर किए बिना, सीएसएस की अन्य प्रॉपर्टी में बदलाव किया जा सकता है. इनमें, एलिमेंट को ट्रांसलेट, स्केल, रोटेट या स्क्यू करने के लिए transform ऐनिमेशन का इस्तेमाल करना शामिल है.

translate का इस्तेमाल करके बनाए गए कंपोज़िट ऐनिमेशन से, अन्य एलिमेंट पर कोई असर नहीं पड़ता. इसलिए, इन्हें सीएलएस में नहीं गिना जाता. कंपोज़िट नहीं किए गए ऐनिमेशन से भी लेआउट में बदलाव नहीं होता. कौनसी सीएसएस प्रॉपर्टी की वजह से लेआउट में बदलाव होता है, इस बारे में ज़्यादा जानने के लिए ज़्यादा परफ़ॉर्मेंस वाली ऐनिमेशन देखें.

वेब फ़ॉन्ट

वेब फ़ॉन्ट डाउनलोड होने से पहले, उन्हें डाउनलोड और रेंडर करने का काम आम तौर पर दो तरीकों से किया जाता है:

  • फ़ॉलबैक फ़ॉन्ट को वेब फ़ॉन्ट से बदल दिया जाता है. इससे बिना स्टाइल वाले टेक्स्ट का फ़्लैश (FOUT) होता है.
  • जब तक वेब फ़ॉन्ट उपलब्ध नहीं हो जाता, तब तक "अदृश्य" टेक्स्ट को फ़ॉलबैक फ़ॉन्ट का इस्तेमाल करके दिखाया जाता है. इसके बाद, टेक्स्ट दिखने लगता है (एफ़ओआईटी—फ़्लैश ऑफ़ इनविज़िबल टेक्स्ट).

दोनों तरीकों से लेआउट शिफ़्ट हो सकता है. टेक्स्ट न दिखने पर भी, उसे फ़ॉलबैक फ़ॉन्ट का इस्तेमाल करके लेआउट किया जाता है. इसलिए, जब वेब फ़ॉन्ट लोड होता है, तो टेक्स्ट ब्लॉक और उसके आस-पास का कॉन्टेंट, दिखने वाले फ़ॉन्ट की तरह ही बदल जाता है.

इन टूल की मदद से, टेक्स्ट के अपनी जगह से हटने की समस्या को कम किया जा सकता है:

  • font-display: optional लेआउट को फिर से बनाने से बच सकता है, क्योंकि वेब फ़ॉन्ट का इस्तेमाल सिर्फ़ तब किया जाता है, जब वह शुरुआती लेआउट के समय उपलब्ध हो.
  • पक्का करें कि फ़ॉलबैक फ़ॉन्ट का सही तरीके से इस्तेमाल किया गया हो. उदाहरण के लिए, font-family: "Google Sans", sans-serif; का इस्तेमाल करने से यह पक्का किया जा सकेगा कि "Google Sans" लोड होने के दौरान, ब्राउज़र के sans-serif फ़ॉलबैक फ़ॉन्ट का इस्तेमाल किया जाए. सिर्फ़ font-family: "Google Sans" का इस्तेमाल करके फ़ॉलबैक फ़ॉन्ट तय न करने का मतलब है कि डिफ़ॉल्ट फ़ॉन्ट का इस्तेमाल किया जाएगा. Chrome पर यह "Times" होता है. यह एक सेरिफ़ फ़ॉन्ट है, जो डिफ़ॉल्ट sans-serif फ़ॉन्ट से ज़्यादा मेल नहीं खाता.
  • बेहतर फ़ॉन्ट फ़ॉलबैक पोस्ट में बताए गए नए size-adjust, ascent-override, descent-override, और line-gap-override एपीआई का इस्तेमाल करके, फ़ॉलबैक फ़ॉन्ट और वेब फ़ॉन्ट के साइज़ के बीच के अंतर को कम करें.
  • Font Loading API की मदद से, ज़रूरी फ़ॉन्ट लोड होने में लगने वाला समय कम किया जा सकता है.
  • <link rel=preload> का इस्तेमाल करके, अहम वेब फ़ॉन्ट को जल्द से जल्द लोड करें. प्रीलोड किए गए फ़ॉन्ट से, फ़र्स्ट पेंट को पूरा करने में मदद मिलती है. ऐसे में, लेआउट में बदलाव नहीं होता.

फ़ॉन्ट इस्तेमाल करने के अन्य सबसे सही तरीकों के बारे में जानने के लिए, फ़ॉन्ट इस्तेमाल करने के सबसे सही तरीके लेख पढ़ें.

यह पक्का करें कि पेज, बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा के लिए ज़रूरी शर्तें पूरी करते हों, ताकि सीएलएस को कम किया जा सके

सीएलएस स्कोर को कम रखने के लिए, यह पक्का करना ज़रूरी है कि आपके वेब पेज, बैक/फ़ॉरवर्ड कैश मेमोरी (बीएफ़कैश) के लिए ज़रूरी शर्तें पूरी करते हों. यह एक बहुत असरदार तरीका है.

बैक/फ़ॉरवर्ड कैश मेमोरी, ब्राउज़र की मेमोरी में पेजों को कुछ समय के लिए सेव रखती है. ऐसा तब होता है, जब आप किसी पेज से दूसरे पेज पर जाते हैं. इसलिए, अगर आप उन पेजों पर वापस आते हैं, तो वे उसी स्थिति में दिखेंगे जैसे आपने उन्हें छोड़ा था. इसका मतलब है कि पूरी तरह से लोड हुआ पेज तुरंत उपलब्ध हो जाता है. इसमें लेआउट में कोई बदलाव नहीं होता. आम तौर पर, ऊपर बताई गई किसी भी वजह से पेज लोड होने के दौरान लेआउट में बदलाव हो सकता है.

इसका मतलब यह है कि पेज लोड होने के दौरान लेआउट में बदलाव हो सकते हैं. हालांकि, जब कोई उपयोगकर्ता पेजों पर वापस जाता है, तो उसे बार-बार लेआउट में बदलाव नहीं दिखते. आपको हमेशा यह कोशिश करनी चाहिए कि शुरुआती लोड पर भी लेआउट में बदलाव न हो. हालांकि, अगर इस समस्या को पूरी तरह से ठीक करना मुश्किल हो, तो कम से कम bfcache नेविगेशन पर लेआउट में बदलाव न होने दें. इससे लेआउट में बदलाव के असर को कम किया जा सकता है.

कई साइटों पर, पीछे और आगे जाने के लिए नेविगेशन का इस्तेमाल आम है. उदाहरण के लिए, कॉन्टेंट वाले पेज, कैटगरी वाले पेज या खोज नतीजों पर वापस जाना.

जब इसे Chrome पर लॉन्च किया गया, तब हमने सीएलएस में काफ़ी सुधार देखा.

बैक/फ़ॉरवर्ड कैश मेमोरी का इस्तेमाल सभी ब्राउज़र डिफ़ॉल्ट रूप से करते हैं. हालांकि, कई वजहों से कुछ साइटें बैक/फ़ॉरवर्ड कैश मेमोरी की सुविधा का इस्तेमाल नहीं कर सकतीं. bfcache की गाइड पढ़ें. इसमें, bfcache की सुविधा को इस्तेमाल करने से रोकने वाली किसी भी समस्या की जांच करने और उसे पहचानने के बारे में ज़्यादा जानकारी दी गई है. इससे यह पक्का किया जा सकता है कि आप इस सुविधा का पूरा फ़ायदा ले रहे हैं, ताकि आपकी साइट के लिए कुल सीएलएस स्कोर को बेहतर बनाया जा सके.

नतीजा

सीएलएस का पता लगाने और उसे बेहतर बनाने के लिए, कई तकनीकें उपलब्ध हैं. इनके बारे में इस गाइड में पहले बताया गया है. वेबसाइट की परफ़ॉर्मेंस से जुड़ी अहम जानकारी में कुछ छूट दी गई हैं. इसलिए, अगर आप सीएलएस को पूरी तरह से नहीं हटा पाते हैं, तो इन तकनीकों का इस्तेमाल करके इसके असर को कम किया जा सकता है. हमें उम्मीद है कि इससे आपको इन सीमाओं के अंदर रहने में मदद मिलेगी. साथ ही, इससे आपकी वेबसाइट के उपयोगकर्ताओं को बेहतर अनुभव मिलेगा.