पिछले कुछ सालों में, वेब कम्यूनिटी ने वेब परफ़ॉर्मेंस ऑप्टिमाइज़ेशन के बारे में काफ़ी जानकारी हासिल की है. किसी एक ऑप्टिमाइज़ेशन से कई साइटों की परफ़ॉर्मेंस बेहतर हो सकती है. हालांकि, एक साथ सभी ऑप्टिमाइज़ेशन लागू करने पर, आपको परेशानी हो सकती है. असल में, किसी भी साइट पर सिर्फ़ कुछ ऑप्टिमाइज़ेशन लागू होते हैं.
अगर वेब पर साइट की परफ़ॉर्मेंस को बेहतर बनाना आपका मुख्य काम नहीं है, तो हो सकता है कि आपको यह पता न हो कि आपकी साइट के लिए कौनसे ऑप्टिमाइज़ेशन सबसे ज़्यादा असरदार होंगे. हो सकता है कि आपके पास इन सभी को आज़माने का समय न हो. इसलिए, यह ज़रूरी है कि आप खुद से पूछें कि उपयोगकर्ताओं के लिए परफ़ॉर्मेंस को बेहतर बनाने के लिए, सबसे असरदार ऑप्टिमाइज़ेशन कौनसे हैं?
परफ़ॉर्मेंस ऑप्टिमाइज़ेशन के बारे में सच यह है कि सिर्फ़ तकनीकी खूबियों के आधार पर इनका आकलन नहीं किया जा सकता. आपको मानवीय और संगठन से जुड़े उन फ़ैक्टर पर भी ध्यान देना होगा जिनसे यह तय होता है कि किसी भी ऑप्टिमाइज़ेशन को लागू करने की संभावना कितनी है. परफ़ॉर्मेंस में किए गए कुछ सुधार, सिद्धांत रूप से काफ़ी असरदार हो सकते हैं. हालांकि, असल में कुछ ही डेवलपर के पास उन्हें लागू करने के लिए समय या संसाधन होंगे. दूसरी ओर, परफ़ॉर्मेंस को बेहतर बनाने के ऐसे सबसे सही तरीके भी हो सकते हैं जिनका इस्तेमाल, ज़्यादातर लोग पहले से ही कर रहे हैं. इस गाइड में, वेब परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के उन तरीकों के बारे में बताया गया है जो:
- असल दुनिया में सबसे ज़्यादा असर डालने वाले हों
- ज़्यादातर साइटों के लिए काम के और लागू हों
- ज़्यादातर डेवलपर के लिए लागू करना आसान हो
इन तरीकों को एक साथ इस्तेमाल करके, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी वाली मेट्रिक को बेहतर बनाया जा सकता है. ये सबसे असरदार और काम के तरीके हैं. अगर आपने वेब पर अपनी साइट की परफ़ॉर्मेंस को बेहतर बनाने के बारे में अभी तक नहीं सोचा है या आपको यह तय करना है कि आपको निवेश पर सबसे ज़्यादा रिटर्न कैसे मिलेगा, तो यह सबसे सही जगह है.
पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी)
Core Web Vitals की नई मेट्रिक के तौर पर, पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी) में सुधार करने के कई बड़े अवसर हैं. हालांकि, पुराने वर्शन की तुलना में, "अच्छा" अनुभव देने के लिए ज़रूरी थ्रेशोल्ड को बहुत कम साइटें पार कर रही हैं. इसलिए, हो सकता है कि आप उन कई डेवलपर में से एक हों जो इंटरैक्शन रिस्पॉन्सिवनेस को ऑप्टिमाइज़ करने का तरीका पहली बार सीख रहे हों. इनपुट नतीजों की परफ़ॉर्मेंस को बेहतर बनाने के सबसे असरदार तरीकों के बारे में जानने के लिए, इन ज़रूरी तकनीकों से शुरुआत करें.
1. लंबे टास्क को अलग-अलग करने के लिए, अक्सर Yield का इस्तेमाल करना
टास्क, ब्राउज़र के अलग-अलग काम होते हैं. जैसे, रेंडरिंग, लेआउट, पार्सिंग, कंपाइल करना या स्क्रिप्ट को लागू करना. जब किसी टास्क को पूरा करने में 50 मिलीसेकंड से ज़्यादा समय लगता है, तो उसे लंबा टास्क माना जाता है. लंबे टास्क की वजह से समस्याएं आ सकती हैं, क्योंकि वे मुख्य थ्रेड को उपयोगकर्ता के इंटरैक्शन का तुरंत जवाब देने से रोक सकते हैं.
आपको JavaScript में कम से कम काम करना चाहिए. हालांकि, लंबे टास्क को अलग-अलग हिस्सों में बांटकर, मुख्य थ्रेड को बेहतर बनाया जा सकता है. ऐसा करने के लिए, मुख्य थ्रेड को बार-बार सबमिट करें, ताकि रेंडरिंग अपडेट और उपयोगकर्ता के अन्य इंटरैक्शन जल्दी हो सकें.
Scheduler API की मदद से, प्राथमिकताओं के सिस्टम का इस्तेमाल करके, काम को लाइन में लगाया जा सकता है. खास तौर पर, scheduler.yield() एपीआई लंबे टास्क को बांट देता है. साथ ही, यह पक्का करता है कि टास्क की सूची में अपनी जगह छोड़े बिना इंटरैक्शन को मैनेज किया जा सके.
लंबे टास्क को अलग-अलग हिस्सों में बांटकर, ब्राउज़र को ज़्यादा मौके मिलते हैं. इससे, वह उपयोगकर्ताओं को ब्लॉक करने वाले ज़रूरी कामों को पूरा कर पाता है.
2. ग़ैर-ज़रूरी JavaScript का इस्तेमाल न करें
वेबसाइटें पहले से ज़्यादा JavaScript शिप कर रही हैं और ऐसा लगता है कि इस रुझान में कोई बदलाव नहीं होगा. ज़्यादा JavaScript शिप करने पर, ऐसा माहौल बनता है जहां टास्क, मुख्य थ्रेड का ध्यान पाने के लिए एक-दूसरे से प्रतिस्पर्धा करते हैं. इससे आपकी वेबसाइट की परफ़ॉर्मेंस पर असर पड़ सकता है. खास तौर पर, वेबसाइट के शुरू होने के दौरान.
हालांकि, यह समस्या हल की जा सकती है. इसके लिए, आपके पास ये विकल्प हैं:
- JavaScript पर आधारित, ग़ैर-ज़रूरी तरीके के बजाय, बेसलाइन वेब प्लैटफ़ॉर्म की सुविधाओं का इस्तेमाल करें. ये सुविधाएं ज़्यादातर जगहों पर उपलब्ध हैं.
- अपनी स्क्रिप्ट में इस्तेमाल न किए गए कोड को ढूंढने के लिए, Chrome DevTools में कवरेज टूल का इस्तेमाल करें. स्टार्टअप के दौरान ज़रूरी रिसॉर्स का साइज़ कम करके, यह पक्का किया जा सकता है कि पेजों को कोड को पार्स और कंपाइल करने में कम समय लगे. इससे उपयोगकर्ताओं को शुरुआती अनुभव बेहतर मिलता है.
- कोड को अलग-अलग हिस्सों में बांटने की सुविधा का इस्तेमाल करके, शुरुआती रेंडर के लिए ज़रूरी नहीं, लेकिन बाद में इस्तेमाल किए जाने वाले कोड के लिए अलग बंडल बनाएं.
- अगर टैग मैनेजर का इस्तेमाल किया जा रहा है, तो समय-समय पर अपने टैग ऑप्टिमाइज़ करें. इस्तेमाल न किए गए कोड वाले पुराने टैग हटाए जा सकते हैं, ताकि आपके Tag Manager के JavaScript फ़ुटप्रिंट को कम किया जा सके.
3. रेंडरिंग से जुड़े बड़े अपडेट से बचना
JavaScript को लागू करने से, आपकी वेबसाइट की रिस्पॉन्सिविटी पर असर पड़ता है. रेंडरिंग एक तरह का महंगा काम है. साथ ही, बड़े रेंडरिंग अपडेट के दौरान, आपकी वेबसाइट उपयोगकर्ता के इंटरैक्शन का जवाब देना और भी धीमा कर सकती है.
रेंडरिंग की प्रोसेस को ऑप्टिमाइज़ करना आसान नहीं है. यह इस बात पर निर्भर करता है कि आपको क्या हासिल करना है. इसके बावजूद, रेंडरिंग टास्क लंबे न हों, यह पक्का करने के लिए ये काम किए जा सकते हैं:
- जबरन लेआउट और लेआउट थ्रैशिंग से बचने के लिए, अपने JavaScript कोड में DOM रीड और राइट्स को फिर से व्यवस्थित करें.
- डीओएम का साइज़ छोटा रखें. डीओएम साइज़ और लेआउट के काम की तीव्रता का आपस में संबंध होता है. जब रेंडरर को बहुत बड़े डीओएम के लेआउट को अपडेट करना होता है, तो उसके लेआउट का फिर से हिसाब लगाने में काफ़ी ज़्यादा समय लग सकता है.
- ऑफ़-स्क्रीन डीओएम कॉन्टेंट को धीरे-धीरे रेंडर करने के लिए, सीएसएस कंटेनमेंट का इस्तेमाल करें. यह हमेशा आसान नहीं होता, लेकिन जटिल लेआउट वाले हिस्सों को अलग करके, लेआउट और रेंडरिंग के ग़ैर-ज़रूरी काम से बचा जा सकता है.
सबसे बड़ा कॉन्टेंटफ़ुल पेंट (एलसीपी)
सबसे बड़ा कॉन्टेंटफ़ुल पेंट (एलसीपी), वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली ऐसी मेट्रिक है जिसे डेवलपर को सबसे ज़्यादा मुश्किल से पूरा करना पड़ता है. Chrome यूज़र एक्सपीरियंस रिपोर्ट में मौजूद 40% साइटें, उपयोगकर्ताओं को बेहतर अनुभव देने के लिए सुझाई गई एलसीपी थ्रेशोल्ड को पूरा नहीं करती हैं. Chrome की टीम, एलसीपी को बेहतर बनाने के लिए, यहां दी गई तकनीकों का सुझाव देती है.
1. पक्का करें कि एलसीपी संसाधन, एचटीएमएल सोर्स से खोजा जा सकता हो और उसे प्राथमिकता दी गई हो
Chrome की टीम को वेब पर एलसीपी के बारे में ये बातें पता चली हैं:
- एचटीटीपी आर्काइव के 2024 वेब अल्मनैक के मुताबिक, 73% मोबाइल पेजों में, इमेज को एलसीपी एलिमेंट के तौर पर इस्तेमाल किया जाता है.
- Chrome से मिले रीयल-यूज़र डेटा के विश्लेषण से पता चलता है कि एलसीपी की परफ़ॉर्मेंस खराब होने वाले ज़्यादातर ऑरिजिन, एलसीपी इमेज को डाउनलोड करने में, p75 एलसीपी के समय का 10%से भी कम हिस्सा खर्च करते हैं.
- खराब एलसीपी वाले पेजों में, क्लाइंट पर 75वें पर्सेंटाइल में उनकी एलसीपी इमेज लोड होने में 1,290 मिलीसेकंड की देरी होती है. यह तेज़ अनुभव के लिए बजट के आधे से ज़्यादा है.
- जिन पेजों पर एलसीपी एलिमेंट इमेज थी उनमें से 35% इमेज के सोर्स यूआरएल, शुरुआती एचटीएमएल रिस्पॉन्स (जैसे,
<img src="...">
या<link rel="preload" href="...">
) में नहीं दिख रहे थे. इससे ब्राउज़र के प्रीलोड स्कैनर को इन्हें जल्द से जल्द खोजने में मदद मिलती. - वेब अल्मनैक के मुताबिक, ज़रूरी शर्तें पूरी करने वाले 15% पेजों पर,
fetchpriority
एचटीएमएल एट्रिब्यूट का इस्तेमाल करके, संसाधनों को ज़्यादा प्राथमिकता दी जा रही थी. इनमें ऐसे संसाधन भी शामिल थे जिनसे पेज के एलसीपी को कम प्रयासों के साथ बेहतर बनाया जा सकता था.
इन आंकड़ों से पता चलता है कि डेवलपर के पास एलसीपी इमेज के लिए, संसाधन लोड होने में लगने वाले समय और संसाधन लोड होने में लगने वाले कुल समय, दोनों को कम करने का एक बड़ा मौका है.
अगर रिसॉर्स लोड होने में देरी की समस्या है, तो यह याद रखना ज़रूरी है कि अगर किसी पेज को इमेज लोड होने से पहले, सीएसएस या JavaScript के पूरी तरह लोड होने का इंतज़ार करना पड़ता है, तो हो सकता है कि अच्छा एलसीपी हासिल करने के लिए बहुत देर हो चुकी हो. इसके अलावा, एलसीपी इमेज के संसाधन को फिर से प्राथमिकता देकर, उसके लोड होने में लगने वाले समय को कम किया जा सकता है. इससे उसे ज़्यादा बैंडविड्थ मिलती है और fetchpriority
एचटीएमएल एट्रिब्यूट का इस्तेमाल करके, वह तेज़ी से लोड होती है.
अगर आपका एलसीपी एलिमेंट कोई इमेज है, तो इमेज के यूआरएल को एचटीएमएल रिस्पॉन्स में खोजा जा सकता है. इससे, संसाधन लोड होने में लगने वाले समय को कम किया जा सकता है. ऐसा करने के लिए, ये सुझाव अपनाएं:
src
याsrcset
एट्रिब्यूट के साथ<img>
एलिमेंट का इस्तेमाल करके इमेज लोड करें.data-src
जैसे गैर-स्टैंडर्ड एट्रिब्यूट का इस्तेमाल न करें. इन एट्रिब्यूट को रेंडर करने के लिए, JavaScript की ज़रूरत होती है. इसलिए, ये हमेशा धीमे होते हैं. 7% पेजों पर एलसीपी इमेज कोdata-src
के पीछे छिपाया गया है.- क्लाइंट-साइड रेंडरिंग (सीएसआर) के बजाय, सर्वर-साइड रेंडरिंग (एसएसआर) का इस्तेमाल करें, क्योंकि एसएसआर का मतलब है कि एचटीएमएल सोर्स में पूरा पेज मार्कअप (इमेज के साथ) मौजूद है. सीएसआर (ग्राहक सेवा प्रतिनिधि) के समाधानों के लिए, इमेज का पता लगाने से पहले JavaScript को चलाना ज़रूरी है.
- अगर आपकी इमेज को किसी बाहरी सीएसएस या JS फ़ाइल से रेफ़रंस करना है, तो भी उसे
<link rel="preload">
टैग का इस्तेमाल करके एचटीएमएल सोर्स में शामिल किया जा सकता है. ध्यान दें कि इनलाइन स्टाइल से रेफ़र की गई इमेज, ब्राउज़र के प्रीलोड स्कैनर से नहीं मिलती हैं. इसलिए, भले ही वे एचटीएमएल सोर्स में मिल जाएं, लेकिन अन्य संसाधनों के लोड होने पर उन्हें ढूंढने पर रोक लगाई जा सकती है. इसलिए, इन मामलों में प्रीलोड करने से मदद मिल सकती है.
इसके अलावा, किसी रिसॉर्स के लोड होने में लगने वाले समय को कम किया जा सकता है. इसके लिए, यह पक्का करें कि एलसीपी रिसॉर्स को जल्दी और ज़्यादा प्राथमिकता के साथ लोड किया जाए:
- अपनी एलसीपी इमेज के
<img>
या<link rel="preload">
टैग मेंfetchpriority="high"
एट्रिब्यूट जोड़ें. इससे इमेज रिसॉर्स की प्राथमिकता बढ़ जाती है, ताकि वह जल्दी लोड हो सके. - अपनी एलसीपी इमेज के
<img>
टैग सेloading="lazy"
एट्रिब्यूट हटाएं. इससे, इमेज के व्यूपोर्ट में या उसके आस-पास दिखने की पुष्टि करने से होने वाली लोडिंग में लगने वाली देरी से बचा जा सकता है. - अगर हो सके, तो ग़ैर-ज़रूरी संसाधनों को बाद में इस्तेमाल करें. इन रिसॉर्स को अपने दस्तावेज़ के आखिर में ले जाने, इमेज को धीरे-धीरे लोड करने या iframes का इस्तेमाल करने या JavaScript का इस्तेमाल करके उन्हें अलग-अलग समय पर लोड करने से, ज़्यादा अहम रिसॉर्स को तेज़ी से लोड करने में मदद मिलेगी. जैसे, एलसीपी इमेज.
2. तुरंत नेविगेट करने की सुविधा
उपयोगकर्ता अनुभव को बेहतर बनाने के लिए, यह ज़रूरी है कि पेज लोड होने में ज़्यादा समय न लगे. एलसीपी एलिमेंट के लोड होने और रेंडर होने में लगने वाले समय को कम करने के लिए, एलसीपी को ऑप्टिमाइज़ किया जा सकता है. जैसे, रिसॉर्स को खोजने की सुविधा और प्राथमिकता तय करना. हालांकि, नेटवर्क पर उन बाइट के लोड होने और पेज पर रेंडर होने में लगने वाले समय की एक तय सीमा होती है. इस सीमा तक पहुंचने से पहले, कुछ और मिलीसेकंड कम करने के लिए बहुत ज़्यादा मेहनत करनी पड़ती है. इसलिए, तुरंत नेविगेट करने के लिए, हमें एक अलग तरीका अपनाना होगा.
इंस्टैंट नेविगेशन, उपयोगकर्ता के नेविगेट करने से पहले पेज को लोड और रेंडर करने की कोशिश करते हैं. इस तरह, पहले से रेंडर किया गया पेज तुरंत दिखाया जा सकता है. साथ ही, इस पेज का एलसीपी (लोडिंग में लगने वाला समय) भी शून्य के करीब होता है. ऐसा करने के दो तरीके हैं: वीडियो को पहले जैसा करना और अनुमान लगाना. जब कोई उपयोगकर्ता पहले देखे गए पेज पर वापस या आगे जाता है, तो उसे मेमोरी कैश से तुरंत वापस लाया जा सकता है. ऐसा करने पर, पेज ठीक उसी तरह दिखता है जिस तरह उपयोगकर्ता ने उसे छोड़ा था. इसके अलावा, वेब ऐप्लिकेशन यह अनुमान लगा सकते हैं कि उपयोगकर्ता अगला पेज कहां खोलेगा. अगर अनुमान सही होता है, तो उपयोगकर्ता के अगले पेज पर जाने से पहले ही, वह पेज लोड और रेंडर हो जाएगा.
बैक/फ़ॉरवर्ड कैश मेमोरी (bfcache) की मदद से, पहले देखे गए पेजों को वापस लाया जा सकता है. इसका इस्तेमाल करने के लिए, आपको यह पक्का करना होगा कि आपके पेज bfcache की ज़रूरी शर्तों को पूरा करते हों. आम तौर पर, पेजों को bfcache के लिए मंज़ूरी नहीं दी जाती, क्योंकि उन्हें no-store
कैश मेमोरी में सेव करने के निर्देशों के साथ दिखाया जाता है या उनमें unload
इवेंट लिसनर होते हैं.
पूरी तरह से रेंडर किए गए पेजों को वापस लाने से, पेज लोड होने की परफ़ॉर्मेंस ही नहीं, बल्कि लेआउट की स्थिरता भी बेहतर होती है. पक्का करें कि पेज, bfcache की ज़रूरी शर्तें पूरी करते हों सेक्शन में, bfcache के बारे में ज़्यादा जानें. साथ ही, यह भी जानें कि सीएलएस को बेहतर बनाने में यह कितना असरदार है.
उपयोगकर्ता के अगले पेज पर जाने से पहले उसे रेंडर करना, एलसीपी की परफ़ॉर्मेंस को बेहतर बनाने का एक और असरदार तरीका है. ऐसा संदिग्धता के नियमों वाले एपीआई की मदद से किया जा सकता है. हालांकि, इन फ़ायदों को पाने के लिए, पक्का करें कि सही पेज पहले से रेंडर किए गए हों. गलत अनुमान से, सर्वर और क्लाइंट, दोनों पर संसाधनों की बर्बादी होती है. इससे परफ़ॉर्मेंस पर असर पड़ सकता है. इसलिए, अगला पेज कैसा होगा, इस बारे में जितना कम भरोसा होगा, उसे पहले से रेंडर करने के लिए उतना ही कम इस्तेमाल करना चाहिए. अगर आपको कोई संदेह है, तो आपके आंकड़ों के डेटा से आपको यह भरोसा मिल सकता है कि अगले पेज पर जाने की सबसे ज़्यादा संभावना वाले पेजों को पहले से रेंडर किया जा सकता है.
3. टीटीएफ़बी को ऑप्टिमाइज़ करने के लिए, सीडीएन का इस्तेमाल करना
पिछले सुझाव में, इंस्टैंट नेविगेशन पर फ़ोकस किया गया था. इससे उपयोगकर्ताओं को बेहतरीन अनुभव मिलता है. हालांकि, ऐसी स्थितियां हो सकती हैं जिनमें bfcache और अनुमानित लोडिंग तकनीकें लागू न हों. मान लें कि कोई उपयोगकर्ता आपकी साइट पर क्रॉस-ऑरिजिन लिंक का इस्तेमाल करके आया है. यहां शुरुआती एचटीएमएल दस्तावेज़ का रिस्पॉन्स, एलसीपी को असरदार तरीके से ब्लॉक करता है. जब तक ब्राउज़र को जवाब का पहला बाइट नहीं मिलता, तब तक वह कोई भी सब-रिसॉर्स लोड नहीं कर सकता. यह काम जितना जल्दी पूरा होगा, बाकी काम भी उतनी ही जल्दी शुरू हो पाएंगे.
इस समय को टाइम टू फ़र्स्ट बाइट (TTFB) कहा जाता है. TTFB को कम करने के सबसे अच्छे तरीके ये हैं:
- अपने कॉन्टेंट को उपयोगकर्ताओं के जितना हो सके उतना करीब से दिखाएं.
- उस कॉन्टेंट को कैश मेमोरी में सेव करें, ताकि आने वाले समय में फिर से अनुरोध किए जाने पर उसे तुरंत दिखाया जा सके.
इन दोनों कामों को करने का सबसे अच्छा तरीका, सीडीएन का इस्तेमाल करना है. सीडीएन, आपके रिसॉर्स को दुनिया भर के एज सर्वर पर डिस्ट्रिब्यूट करते हैं. इससे, उपयोगकर्ताओं तक उन रिसॉर्स को पहुंचने में कम समय लगता है. आम तौर पर, सीडीएन में कैश मेमोरी से जुड़े बेहतर कंट्रोल होते हैं. इन कंट्रोल में बदलाव करके, अपनी साइट की ज़रूरतों के हिसाब से कैश मेमोरी को मैनेज किया जा सकता है.
सीडीएन, एचटीएमएल दस्तावेज़ों को दिखा और कैश मेमोरी में सेव भी कर सकते हैं. हालांकि, वेब अल्मनैक के मुताबिक, एचटीएमएल दस्तावेज़ के सिर्फ़ 33% अनुरोधों को सीडीएन से दिखाया गया. इसका मतलब है कि साइटों के पास ज़्यादा बचत करने का एक अहम मौका है.
सीडीएन कॉन्फ़िगर करने के लिए, यहां कुछ सलाह दी गई हैं:
- स्टैटिक एचटीएमएल दस्तावेज़ों को थोड़े समय के लिए भी कैश मेमोरी में सेव करें. उदाहरण के लिए, क्या यह ज़रूरी है कि कॉन्टेंट हमेशा नया हो? क्या यह कुछ मिनट पुराना हो सकता है?
- देखें कि आपके पास अपने ऑरिजिन सर्वर पर चल रहे डाइनैमिक लॉजिक को एज पर ले जाने का विकल्प है या नहीं. यह सुविधा, ज़्यादातर आधुनिक सीडीएन की होती है.
जब भी सीधे एज से कॉन्टेंट दिखाया जा सकता है और ऑरिजिन सर्वर पर जाने से बचा जा सकता है, तो परफ़ॉर्मेंस बेहतर होती है. ऐसे मामलों में भी जहां आपको ऑरिजिन तक जाना पड़ता है, सीडीएन को आम तौर पर तेज़ी से काम करने के लिए ऑप्टिमाइज़ किया जाता है. इसलिए, दोनों ही मामलों में फ़ायदा होता है.
कुल लेआउट शिफ़्ट (सीएलएस)
कुल लेआउट शिफ़्ट (सीएलएस), किसी वेब पेज के विज़ुअल स्टैबिलिटी का मेज़र है. सीएलएस एक ऐसी मेट्रिक है जिस पर ज़्यादातर साइटों की परफ़ॉर्मेंस अच्छी होती है. हालांकि, उनमें से करीब एक चौथाई साइटें अब भी सुझाई गई सीमा को पूरा नहीं करती हैं. इसलिए, कई साइटों के पास अपने उपयोगकर्ता अनुभव को बेहतर बनाने का बड़ा मौका है.
1. पेज से लोड किए गए किसी भी कॉन्टेंट के लिए, साफ़ तौर पर साइज़ सेट करना
लेआउट में बदलाव आम तौर पर तब होता है, जब दूसरे कॉन्टेंट के लोड होने के बाद मौजूदा कॉन्टेंट का क्रम बदल जाता है. सीएलएस को बेहतर बनाने का मुख्य तरीका यह है कि ज़रूरत के मुताबिक स्टोरेज को पहले से ही बुक कर लें.
बिना साइज़ वाली इमेज की वजह से लेआउट में होने वाले बदलावों को ठीक करने का सबसे अच्छा तरीका, width
और height
एट्रिब्यूट को साफ़ तौर पर सेट करना या उनकी सीएसएस प्रॉपर्टी का इस्तेमाल करना है. 66% पेजों में कम से कम एक ऐसी इमेज है जिसका साइज़ नहीं दिया गया है. साइज़ के बारे में साफ़ तौर पर बताए बिना, इन इमेज की शुरुआती ऊंचाई 0px
होती है. इस वजह से, जब ये इमेज लोड होती हैं और ब्राउज़र उनके डाइमेंशन का पता लगाता है, तो लेआउट में बदलाव हो सकता है. यह, वेब पर एक साथ काम करने के लिए एक बड़ा अवसर है. इस अवसर को पाने के लिए, इस गाइड में बताए गए कुछ अन्य सुझावों के मुकाबले कम मेहनत करनी पड़ती है.
सीएलएस में सिर्फ़ इमेज ही योगदान नहीं देती हैं. लेआउट में बदलाव, आम तौर पर पेज के रेंडर होने के बाद लोड होने वाले दूसरे कॉन्टेंट की वजह से हो सकता है. इसमें तीसरे पक्ष के विज्ञापन या एम्बेड किए गए वीडियो शामिल हैं. aspect-ratio
प्रॉपर्टी से इस काम में मदद मिल सकती है. यह सीएसएस की एक ऐसी सुविधा है जो आम तौर पर उपलब्ध है. इसकी मदद से, डेवलपर इमेज के साथ-साथ नॉन-इमेज एलिमेंट पर भी आसपेक्ट रेशियो को साफ़ तौर पर सेट कर सकते हैं. इससे, डाइनैमिक width
(उदाहरण के लिए, स्क्रीन साइज़ के आधार पर) सेट किया जा सकता है. साथ ही, ब्राउज़र सही ऊंचाई का हिसाब अपने-आप लगा लेता है. यह ठीक उसी तरह होता है जिस तरह डाइमेंशन वाली इमेज के लिए होता है.
हालांकि, डाइनैमिक कॉन्टेंट का सटीक साइज़ हमेशा पता नहीं चलता. भले ही, आपको साइज़ की सटीक जानकारी न हो, लेकिन लेआउट में होने वाले बदलावों की गंभीरता को कम किया जा सकता है. ज़रूरत के मुताबिक min-height
सेट करना, खाली एलिमेंट के लिए ब्राउज़र को 0px
की डिफ़ॉल्ट ऊंचाई का इस्तेमाल करने की अनुमति देने से हमेशा बेहतर होता है. min-height
का इस्तेमाल करके भी, आम तौर पर इस समस्या को आसानी से ठीक किया जा सकता है. ऐसा करने पर, ज़रूरत पड़ने पर कंटेनर को फ़ाइनल कॉन्टेंट की ऊंचाई तक बढ़ने की अनुमति मिलती है. हालांकि, इसकी वजह से कंटेनर की ऊंचाई में हुई बढ़ोतरी को कम कर दिया जाता है, ताकि यह ज़्यादा सहनीय हो सके.
2. पक्का करें कि पेज, bfcache की ज़रूरी शर्तें पूरी करते हों
जैसा कि इस गाइड में पहले बताया गया है, बैक/फ़ॉरवर्ड कैश मेमोरी (bfcache) की सुविधा, ब्राउज़र इतिहास में मौजूद किसी पेज को तुरंत लोड कर देती है. इसके लिए, मेमोरी के स्नैपशॉट का इस्तेमाल किया जाता है. बैक/फ़ॉरवर्ड कैश मेमोरी, ब्राउज़र-लेवल पर परफ़ॉर्मेंस को ऑप्टिमाइज़ करने का एक अहम तरीका है. इससे एलसीपी बेहतर होता है. साथ ही, लेआउट शिफ़्ट पूरी तरह से खत्म हो जाते हैं. असल में, साल 2022 में bfcache की सुविधा लॉन्च करने की वजह से, सीएलएस में सबसे ज़्यादा सुधार हुआ.
इसके बावजूद, काफ़ी वेबसाइटें bfcache का इस्तेमाल नहीं कर सकतीं. इसलिए, वे वेब की परफ़ॉर्मेंस को बेहतर बनाने के इस मुफ़्त फ़ायदे से वंचित रह जाती हैं. अगर आपका पेज ऐसी संवेदनशील जानकारी लोड नहीं कर रहा है जिसे आपको मेमोरी से वापस नहीं लाना है, तो पक्का करें कि आपके पेज, bfcache का इस्तेमाल करने की ज़रूरी शर्तें पूरी करते हों.
साइट के मालिकों को यह देखना चाहिए कि पेज bfcache के लिए ज़रूरी शर्तें पूरी करते हैं या नहीं. अगर नहीं, तो इसकी वजहों को ठीक करें. Chrome में DevTools में bfcache टेस्टर है. साथ ही, फ़ील्ड में ज़रूरी शर्तें पूरी न होने की वजहों का पता लगाने के लिए, Not Restored Reasons API का भी इस्तेमाल किया जा सकता है.
3. ऐसे ऐनिमेशन और ट्रांज़िशन इस्तेमाल करने से बचें जो लेआउट में बदलाव करने वाली सीएसएस प्रॉपर्टी का इस्तेमाल करते हैं
लेआउट शिफ़्ट की एक और आम वजह यह है कि एलिमेंट ऐनिमेशन में हों. उदाहरण के लिए, कुकी बैनर या सूचना वाले ऐसे अन्य बैनर जो ऊपर या नीचे से स्लाइड इन करते हैं, अक्सर सीएलएस में योगदान देते हैं. यह समस्या तब खास तौर पर होती है, जब ये बैनर दूसरे कॉन्टेंट को छिपा देते हैं. हालांकि, अगर ऐसा नहीं होता है, तब भी ऐनिमेशन का इस्तेमाल करने से सीएलएस पर असर पड़ सकता है.
एचटीटीपी आर्काइव का डेटा, ऐनिमेशन को लेआउट में होने वाले बदलावों से पूरी तरह से नहीं जोड़ सकता. हालांकि, डेटा से पता चलता है कि जिन पेजों पर लेआउट पर असर डालने वाली किसी भी सीएसएस प्रॉपर्टी को ऐनिमेट किया जाता है उनके "अच्छा" सीएलएस होने की संभावना, अन्य पेजों के मुकाबले 15% कम होती है. कुछ प्रॉपर्टी, दूसरों की तुलना में खराब सीएलएस से जुड़ी होती हैं. उदाहरण के लिए, margin
या border
चौड़ाई वाले ऐनिमेशन वाले पेजों का सीएलएस, "खराब" होता है. यह दर, कुल पेजों के खराब के तौर पर आकलन किए जाने की दर से करीब दो गुना होती है.
शायद आपको इस बात से कोई हैरानी न हो, क्योंकि जब भी लेआउट में बदलाव करने वाली किसी सीएसएस प्रॉपर्टी को ट्रांज़िशन या ऐनिमेट किया जाता है, तो लेआउट में बदलाव होता है. अगर ये लेआउट शिफ़्ट, उपयोगकर्ता इंटरैक्शन के 500 मिलीसेकंड के अंदर नहीं होते हैं, तो इनका सीएलएस पर असर पड़ेगा.
कुछ डेवलपर को यह जानकर हैरानी हो सकती है कि यह तब भी लागू होता है, जब एलिमेंट को सामान्य दस्तावेज़ फ़्लो से बाहर ले जाया जाता है. उदाहरण के लिए, top
या left
को ऐनिमेट करने वाले एलिमेंट, लेआउट में बदलाव करते हैं. भले ही, वे दूसरे कॉन्टेंट को आगे-पीछे न कर रहे हों. हालांकि, अगर top
या left
के बजाय transform:translateX()
या transform:translateY()
को ऐनिमेट किया जाता है, तो ब्राउज़र पेज लेआउट को अपडेट नहीं करेगा. इससे लेआउट में बदलाव नहीं होगा.
ब्राउज़र की कंपोजिट थ्रेड पर अपडेट की जा सकने वाली सीएसएस प्रॉपर्टी के ऐनिमेशन को प्राथमिकता देना, परफ़ॉर्मेंस के लिए सबसे सही तरीका है. ऐसा इसलिए है, क्योंकि इससे उस काम को मुख्य थ्रेड से जीपीयू पर ले जाया जाता है. यह परफ़ॉर्मेंस को बेहतर बनाने का सबसे सही तरीका है. साथ ही, इससे सीएलएस को बेहतर बनाने में भी मदद मिल सकती है.
आम तौर पर, ऐसी सीएसएस प्रॉपर्टी को ऐनिमेट या ट्रांज़िशन न करें जिनके लिए ब्राउज़र को पेज लेआउट अपडेट करना पड़ता है. ऐसा तब तक न करें, जब तक कि उपयोगकर्ता के टैप या बटन दबाने पर ऐसा न किया जा रहा हो (हालांकि, hover
नहीं). जब भी हो सके, सीएसएस transform
प्रॉपर्टी का इस्तेमाल करके ट्रांज़िशन और ऐनिमेशन करें.
कंपोज़िट नहीं किए गए ऐनिमेशन से बचें Lighthouse ऑडिट की चेतावनी तब मिलती है, जब कोई पेज ऐसी सीएसएस प्रॉपर्टी को ऐनिमेट करता है जो धीमी हो सकती हैं.
नतीजा
पेज की परफ़ॉर्मेंस को बेहतर बनाना मुश्किल लग सकता है. खास तौर पर, तब जब वेब पर इस बारे में बहुत सारे दिशा-निर्देश मौजूद हों. हालांकि, सबसे असरदार सबसे सही तरीकों की इस छोटी सूची पर फ़ोकस करके, समस्या को नए सिरे से ठीक किया जा सकता है. उम्मीद है कि इससे आपकी वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी में सुधार होगा.
अगर आपको यहां दिए गए ऑप्टिमाइज़ेशन के अलावा और भी ऑप्टिमाइज़ेशन करने हैं, तो ज़्यादा जानकारी के लिए ये गाइड पढ़ें:
- आईएनपी मेट्रिक की मदद से साइट को ऑप्टिमाइज़ करना
- एलसीपी को ऑप्टिमाइज़ करना
- सीएलएस को ऑप्टिमाइज़ करना
अपेंडिक्स: बदलाव लॉग
इस दस्तावेज़ में किए गए बड़े बदलावों को यहां ट्रैक किया जाएगा. इससे यह समझने में मदद मिलेगी कि टॉप सुझाव कब और क्यों बदले हैं.
अक्टूबर 2024
साल 2024 का अपडेट:
- आईएनपी
- हमने इस मेट्रिक को एफ़आईडी से आईएनपी पर स्विच कर दिया है. ऐसा, आईएनपी को वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक के तौर पर लॉन्च करने के हिसाब से किया गया है. साथ ही, हमने इसे सूची में सबसे ऊपर की मेट्रिक बना दिया है.
- हमने लंबे टास्क को छोटे-छोटे टास्क में बांटने के लिए,
isInputPending
एपीआई का इस्तेमाल करने का सुझाव वापस ले लिया है. लंबे टास्क ऑप्टिमाइज़ करना लेख में, इस फ़ैसले के पीछे की वजह के बारे में ज़्यादा जानें.
- एलसीपी
- हमने खोजे जाने और प्राथमिकता तय करने के सुझावों को एक साथ जोड़ दिया है.
- हमने तुरंत नेविगेट करने के लिए एक नया सुझाव जोड़ा है.
जनवरी 2023
सुझावों की शुरुआती सूची यहां दी गई है:
- एलसीपी
- पक्का करें कि एलसीपी संसाधन, एचटीएमएल सोर्स से खोजा जा सकता हो
- पक्का करें कि एलसीपी रिसॉर्स को प्राथमिकता दी गई हो
- दस्तावेज़ और संसाधन के टीटीएफ़बी को ऑप्टिमाइज़ करने के लिए, सीडीएन का इस्तेमाल करना
- सीएलएस
- पेज से लोड किए गए किसी भी कॉन्टेंट के लिए, साफ़ तौर पर साइज़ सेट करना
- पक्का करें कि पेज, bfcache की ज़रूरी शर्तें पूरी करते हों
- ऐसे ऐनिमेशन और ट्रांज़िशन इस्तेमाल करने से बचें जो लेआउट में बदलाव करने वाली सीएसएस प्रॉपर्टी का इस्तेमाल करते हैं
- एफ़आईडी
- लंबे टास्क से बचना या उन्हें छोटे-छोटे हिस्सों में बांटना
- ग़ैर-ज़रूरी JavaScript का इस्तेमाल न करें
- रेंडरिंग से जुड़े बड़े अपडेट से बचना
खास जानकारी वाले वीडियो के तौर पर, Google I/O 2023 का यह प्रज़ेंटेशन भी देखा जा सकता है.