वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने के सबसे असरदार तरीके

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

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

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

• असल दुनिया में सबसे ज़्यादा असर डालने वाले
• ज़्यादातर साइटों के लिए काम के और लागू हों
• ज़्यादातर डेवलपर के लिए उन्हें लागू करना

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

पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी)

Core Web Vitals की नई मेट्रिक के तौर पर, पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी) में सुधार करने के कई बड़े अवसर हैं. हालांकि, पुराने वर्शन की तुलना में, "अच्छा" अनुभव देने के लिए ज़रूरी थ्रेशोल्ड को बहुत कम साइटें पार कर रही हैं. इसलिए, हो सकता है कि आप उन कई डेवलपर में से एक हों जो इंटरैक्शन रिस्पॉन्सिवनेस को ऑप्टिमाइज़ करने का तरीका पहली बार सीख रहे हों. आईएनपी को बेहतर बनाने के सबसे असरदार तरीकों के बारे में जानने के लिए, इन तकनीकों के बारे में जानें.

1. लंबे टास्क को ब्रेक करने के लिए अक्सर फ़ायदा मिलता है

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

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

Scheduler API की मदद से, प्राथमिकता वाले सिस्टम का इस्तेमाल करके, काम की सूची बनाई जा सकती है. खास तौर पर, scheduler.yield() एपीआई की मदद से, लंबे टास्क को अलग-अलग किया जाता है. साथ ही, यह पक्का किया जाता है कि टास्क की सूची में अपनी जगह छोड़े बिना इंटरैक्शन को मैनेज किया जा सके.

लंबे टास्क को अलग-अलग करने से, ब्राउज़र को उपयोगकर्ताओं को ब्लॉक करने वाले अहम काम करने के ज़्याद�� मौके मिलते हैं.

2. ग़ैर-ज़रूरी JavaScript का इस्तेमाल न करें

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

हालांकि, यह समस्या हल की जा सकती है. इसके लिए, आपके पास ये विकल्प हैं:

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

3. रेंडरिंग से जुड़े बड़े अपडेट से बचना

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

रेंडरिंग की प्रोसेस को ऑप्टिमाइज़ करना आसान नहीं है. यह इस बात पर न��र्भर करता है कि आपको क्या हासिल करना है. इसके बावजूद, यहां कुछ ऐसे तरीके बताए गए हैं जिनकी मदद से यह पक्का किया जा सकता है कि रेंडरिंग टास्क लंबे न हों:

• जबरन लेआउट और लेआउट थ्रैशिंग से बचने के लिए, अपने JavaScript कोड में DOM रीड और राइट्स को फिर से व्यवस्थित करें.
• डीओएम का साइज़ छोटा रखें. डीओएम साइज़ और लेआउट के काम की तीव्रता का आपस में संबंध होता है. जब रेंडरर को बहुत बड़े डीओएम के लिए लेआउट को अपडेट करना होता है, तो इसके लेआउट को फिर से कैलकुलेट करने के काम में काफ़ी बढ़ोतरी हो सकती है.
• ऑफ़-स्क्रीन डीओएम कॉन्टेंट को लेज़ी तरीके से रेंडर करने के लिए, सीएसएस कंटेनमेंट का इस्तेमाल करें. यह हमेशा आसान नहीं होता, लेकिन जटिल लेआउट वाले एरिया को अलग करके, लेआउट और रेंडरिंग के काम से बचा जा सकता है.

सबसे बड़ा कॉन्टेंटफ़ुल पेंट (एलसीपी)

सबसे बड़ा कॉन्टेंटफ़ुल पेंट (एलसीपी), वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली ऐसी मेट्रिक है जिसे डेवलपर को सबसे ज़्यादा मुश्किल से पूरा करना पड़ता है. Chrome UX रिपोर्ट में मौजूद 40% साइटें, उपयोगकर्ताओं को बेहतर अनुभव देने के लिए सुझाई गई एलसीपी थ्रेशोल्ड को पूरा नहीं करती हैं. Chrome टीम, एलसीपी को बेहतर बनाने के सबसे असरदार तरीको�� के तौर पर इन तकनीकों का सुझाव देती है.

1. पक्का करें कि एलसीपी संसाधन, एचटीएमएल सोर्स से खोजा जा सकता हो और उसे प्राथमिकता दी गई हो

Chrome की टीम को वेब पर एलसीपी के बारे में ये बातें पता चली हैं:

• एचटीटीपी संग्रह के 2022 Web Almanac के मुताबिक, 72% मोबाइल पेजों पर एलसीपी एलिमेंट के तौर पर इमेज मौजूद है.
• Chrome से मिले रीयल-यूज़र डेटा के विश्लेषण से पता चलता है कि एलसीपी की परफ़ॉर्मेंस खराब होने वाले ज़्यादातर ऑरिजिन, एलसीपी इमेज को डाउनलोड करने में, 75% एलसीपी समय का 10% से भी कम खर्च करते हैं.
• खराब एलसीपी वाले पेजों में, क्लाइंट पर 75वें पर्सेंटाइल में उनकी एलसीपी इमेज लोड होने में 1,290 मिलीसेकंड की देरी होती है. यह तेज़ अनुभव के लिए बजट के आधे से ज़्यादा है.
• जिन पेजों पर एलसीपी एलिमेंट इमेज थी उनमें से 39% इमेज के सोर्स यूआरएल, शुरुआती एचटीएमएल रिस्पॉन्स (जैसे, <img src="..."> या <link rel="preload" href="...">) में नहीं दिख रहे थे. इससे ब्राउज़र के प्रीलोड स्कैनर को इन्हें जल्द से जल्द ढूंढने में मदद मिलती.
• Web Almanac के मुताबिक, संसाधनों को ज़्यादा प्राथमिकता देने के लिए, ज़रूरी शर्तें पूरी करने वाले सिर्फ़ 0.03% पेज fetchpriority एचटीएमएल एट्रिब्यूट का फ़ायदा पा रहे थे. इनमें वे पेज भी शामिल थे जो कम मेहनत में पेज के एलसीपी को बेहतर बना सकते थे.

इन आंकड़ों से पता चलता है कि डेवलपर के पास एलसीपी इमेज के लिए, संसाधन लोड होने में देरी और संसाधन लोड होने की अव��ि, दोनों को कम करने का एक बड़ा मौका है.

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

अगर आपका एलसीपी एलिमेंट कोई इमेज है, तो इमेज के यूआरएल को एचटीएमएल रिस्पॉन्स में खोजा जा सकता है. इससे, संसाधन लोड होने में लगने वाले समय को कम किया जा सकता है. ऐसा करने के लिए, ये सुझाव अपनाएं:

• src या srcset एट्रिब्यूट के साथ <img> एलिमेंट का इस्तेमाल करके इमेज लोड करें. data-src जैसे गैर-स्टैंडर्ड एट्रिब्यूट का इस्तेमाल न करें. इन एट्रिब्यूट को रेंडर करने के लिए, JavaScript की ज़रूरत होती है. इसलिए, ये हमेशा धीमे होते हैं. 9% पेज, data-src के पीछे अपनी एलसीपी इमेज छिपा देते हैं.
• क्लाइंट-साइड रेंडरिंग (सीएसआर) के बजाय, सर्वर-साइड रेंडरिंग (एसएसआर) का इस्तेमाल करें, क्योंकि एसएसआर का मतलब है कि एचटीएमएल सोर्स में पूरा पेज मार्कअप (इमेज के साथ) मौजूद है. सीएसआर (ग्राहक सेवा प्रतिनिधि) के समाधानों के लिए, इमेज का पता लगाने से पहले JavaScript को चलाना ज़रूरी है.
• अगर आपकी इमेज का रेफ़रंस किसी बाहरी सीएसएस या JS फ़ाइल से देना है, तो <link rel="preload"> टैग का इस्तेमाल करके उसे एचटीएमएल सोर्स में शामिल किया जा सकता है. ध्यान दें कि इनलाइन स्टाइल से रेफ़र की गई इमेज, ब्राउज़र के प्रीलोड स्कैनर से नहीं मिलती हैं. इसलिए, भले ही वे एचटीएमएल सोर्स में मिल जाएं, लेकिन अन्य संसाधनों के लोड होने पर उन्हें ढूंढने पर रोक लगाई जा सकती है. इसलिए, इन मामलों में प्रीलोड करने से मदद मिल सकती है.

इसके अलावा, एलसीपी रिसॉर्स को जल्दी और ज़्यादा प्राथमिकता से लोड करके, किसी रिसॉर्स के लोड होने में लगने वाले समय को कम किया जा सकता है:

• अपनी एलसीपी इमेज के <img> या <link rel="preload"> टैग में fetchpriority="high" एट्रिब्यूट जोड़ें. इससे इमेज रिसॉर्स की प्राथमिकता बढ़ जाती है, ताकि वह जल्दी लोड हो सके.
• अपनी एलसीपी इमेज के <img> टैग से loading="lazy" एट्रिब्यूट हटाएं. यह इमेज के व्यूपोर्ट में या उसके आस-पास दिखने की पुष्टि करने की वजह से लोड होने में होने वाली देरी से बचा जा सकता है.
• अगर हो सके, तो ग़ैर-ज़रूरी संसाधनों को बाद में इस्तेमाल करें. इन संसाधनों को अपने दस्तावेज़ के आखिर में ले जाने, लेज़ी-लोड होने वाली इमेज या iframe में बदलाव करने या JavaScript का इस्तेमाल करके उन्हें एसिंक्रोनस रूप से लोड करने से, एलसीपी इमेज जैसे अहम संसाधनों को तेज़ी से लोड होने में मदद मिलेगी.

2. झट���ट नेविगेशन का लक्ष्य बनाएं

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

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

बैक/फ़ॉरवर्ड कैश मेमोरी (bfcache) की मदद से, पहले देखे गए पेजों को वापस लाया जा सकता है. इसका इस्तेमाल करने के लिए, आपको यह पक्का करना होगा कि आपके पेज, bfcache की ज़रूरी शर्तें पूरी करते हों. आम तौर पर, पेजों को bfcache के लिए मंज़ूरी नहीं दी जाती, क्योंकि उन्हे�� no-store कैश मेमोरी में सेव करने के निर्देशों के साथ दिखाया जाता है या उनमें unload इवेंट लिसनर होते हैं.

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

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

3. टीटीएफ़बी को ऑप्टिमाइज़ करने के लिए, सीडीएन का इस्तेमाल करना

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

इस समय को टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी) के नाम से जाना जाता है. टीटीएफ़बी को कम करने के सबसे सही तरीके ये हैं:

• अपने कॉन्टेंट को उपयोगकर्ताओं के जितना हो सके उतना करीब से दिखाएं.
• उस कॉन्टेंट को कैश मेमोरी में सेव करें, ताकि आने वाले समय में फिर से अनुरोध किए जाने पर उसे तुरंत दिखाया जा सके.

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

सीडीएन, एचटीएमएल दस्तावेज़ों को दिखाने और कैश मेमोरी में सेव करने की सुविधा भी देते हैं. हालांकि, वेब अल्मनैक के मुताबिक, एचटीएमएल दस्तावेज़ के सिर्फ़ 29% अनुरोधों को सीडीएन से दिखाया गया. इसका मतलब है कि साइटों के पास ज़्यादा बचत करने का एक अहम मौका है.

सीडीएन कॉन्फ़िगर करने के लिए, यहां कुछ सलाह दी गई हैं:

• स्टैटिक एचटीएमएल दस्तावेज़ों को थोड़े समय के लिए भी कैश मेमोरी में सेव किया जा सकता है. उदाहरण के लिए, क्या यह ज़रूरी है कि कॉन्टेंट हमेशा नया हो? क्या यह कुछ मिनट पुराना हो सकता है?
• दे��ें कि आपके पास अपने ऑरिजिन सर्वर पर चल रहे डाइनैमिक लॉजिक को एज पर ले जाने का विकल्प है या नहीं. यह सुविधा, ज़्यादातर आधुनिक सीडीएन की होती है.

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

कुल लेआउट शिफ़्ट (सीएलएस)

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

1. पेज से लोड किए गए किसी भी कॉन्टेंट के लिए, साफ़ तौर पर साइज़ सेट करना

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

बिना साइज़ वाली इमेज की वजह से लेआउट में हुए बदलावों को ठीक करने का सबसे अच्छा तरीका यह है कि width और height एट्रिब्यूट को साफ़ तौर पर सेट करें या उनकी मिलती-जुलती सीएसएस प्रॉपर्टी को सेट करें. 72% पेजों पर कम से कम एक ऐसी इमेज है जिसका साइज़ नहीं दिया गया है. साफ़ तौर पर साइज़ न होने पर, इन इमेज की शुरुआती ऊंचाई 0px होती है. इस वजह से, इन इमेज के लोड होने और ब्राउज़र के डाइमेंशन खोजने पर, लेआउट शिफ़्ट हो सकते हैं. यह, वेब पर एक साथ काम करने के लिए एक बहुत बड़ा अवसर है. इस अवसर को पाने के लिए, इस गाइड में बताए गए कुछ अन्य सुझावों के मुकाबले कम मेहनत करनी पड़ती है.

सीएलएस में सिर्फ़ इमेज ही योगदान नहीं देती हैं. लेआउट में बदलाव, आम तौर पर पेज के रेंडर होने के बाद लोड होने वाले दूसरे कॉन्टेंट की वजह से हो सकता है. इसमें तीसरे पक्ष के विज्ञापन या एम्बेड किए गए वीडियो शामिल हैं. यहां aspect-ratio प्रॉपर्टी आपकी मदद कर सकती है. यह सीएसएस की एक ऐसी सुविधा है जो बड़े पैमाने पर उपलब्ध है. इसकी मदद से, डेवलपर इमेज के साथ-साथ नॉन-इमेज एलिमेंट पर भी आसपेक्ट रेशियो को साफ़ तौर पर सेट कर सकते हैं. इससे, डाइनैमिक width (उदाहरण के लिए, स्क्रीन साइज़ के आधार पर) सेट किया जा सकता है. साथ ही, ब्राउज़र सही ऊंचाई का हिसाब अपने-आप लगा लेता है. यह ठीक उसी तरह होता है जिस तरह डाइमेंशन वाली इमेज के लिए होता है.

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

2. पक्का करें कि आपके पेजों पर बैक-कैश मेमोरी का इस्तेमाल किया जा सकता है

जैसा कि इस गाइड में पहले बताया गया है, बैक/फ़ॉरवर्ड कैश मेमोरी (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

यह सुझावों की शुरुआती सूची है:

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

वीडियो की खास जानकारी पाने के लिए, 2023 के Google I/O प्रज़ेंटेशन को भी देखा जा सकता है.