Chrome DevRel टीम के हिसाब से, यह सबसे सही तरीकों का कलेक्शन है. साल 2023 में, इन सबसे सही तरीकों को अपनाकर वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक को बेहतर बनाया जा सकता है.
पिछले कुछ सालों में, Google में हमने वेब डेवलपर को परफ़ॉर्मेंस को बेहतर बनाने के लिए बहुत से सुझाव दिए हैं.
हालांकि, इनमें से हर सुझाव अलग-अलग, कई साइटों की परफ़ॉर्मेंस को बेहतर कर सकता है, लेकिन सुझावों का पूरा सेट वाकई शानदार है और असल में ऐसा नहीं है कि कोई व्यक्ति या साइट उन सभी को फ़ॉलो कर सके.
जब तक वेब परफ़ॉर्मेंस आपके रोज़ के काम का नहीं है, तब तक शायद आपको यह पता न चले कि किन सुझावों का आपकी साइट पर सबसे बड़ा सकारात्मक असर होगा. उदाहरण के लिए, आपने पढ़ा होगा कि ज़रूरी सीएसएस लागू करने से लोड परफ़ॉर्मेंस बेहतर हो सकती है. साथ ही, आपने यह भी सुना होगा कि इमेज को ऑप्टिमाइज़ करना ज़रूरी है. लेकिन, अगर आपके पास दोनों कामों को करने का समय न हो, तो आप यह कैसे तय करेंगे कि दोनों में से किसे चुनना है?
Chrome की टीम में, हमने पिछले साल इस सवाल का जवाब देने की कोशिश की: उपयोगकर्ताओं के परफ़ॉर्मेंस को बेहतर बनाने में उनकी मदद करने के लिए, हम डेवलपर को कौनसे सबसे अहम सुझाव दे सकते हैं?
इस सवाल का सही जवाब देने के लिए, हमें न सिर्फ़ किसी सुझाव की तकनीकी खूबियों को ध्यान में रखना होगा, बल्कि संगठन के काम करने वाले लोगों और उन चीज़ों को भी ध्यान में रखना होगा जो इस बात की संभावना को प्रभावित करती हैं कि डेवलपर इन सुझावों को असल में अपना पाएंगे. दूसरे शब्दों में, सिद्धांत के तौर पर कुछ सुझाव बेहद असरदार हो सकते हैं, लेकिन असल में कुछ ही साइटों के पास उन्हें लागू करने के लिए समय या संसाधन ही होंगे. इसी तरह, कुछ सुझाव अहम हैं, लेकिन ज़्यादातर वेबसाइटें पहले ही इन तरीकों का पालन कर रही हैं.
कम शब्दों में कहें, तो हम चाहते थे कि वेब की परफ़ॉर्मेंस बेहतर करने से जुड़े सुझावों की सूची में इन चीज़ों पर ध्यान दिया जाए:
- हमारे हिसाब से, इन सुझावों से असल दुनिया में सबसे ज़्यादा असर पड़ेगा
- ऐसे सुझाव जो ज़्यादातर साइटों पर काम के और लागू होते हैं
- ऐसे सुझाव जिन्हें ज़्यादातर डेवलपर लागू कर सकें
पिछले साल, हमने परफ़ॉर्मेंस से जुड़े सभी सुझावों को ऑडिट करने में काफ़ी समय लगाया है. हम ऊपर दिए गए तीन मापदंडों के हिसाब से उनमें से हर एक का आकलन और आकलन करते रहते हैं.
इस पोस्ट में, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी की हर मेट्रिक की परफ़ॉर्मेंस को बेहतर बनाने के लिए, हमारे सबसे ज़रूरी सुझावों के बारे में बताया गया है. अगर वेब परफ़ॉर्मेंस आपके लिए नया है या आपको यह फ़ैसला करना है कि आपकी कमाई में कहां कमी आएगी, तो हमारा मानना है कि इन सुझावों से आपको शुरुआत करनी चाहिए.
सबसे बड़ा कॉन्टेंटफ़ुल पेंट (एलसीपी)
हमारे सुझावों का पहला सेट, सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) के लिए है. इससे पेज की लोड परफ़ॉर्मेंस का पता चलता है. वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली तीन मेट्रिक में से, एलसीपी वह मेट्रिक है जिसे सबसे ज़्यादा साइटें नुकसान पहुंचा रही हैं. फ़िलहाल, वेब पर मौजूद कुल साइटों में से सिर्फ़ करीब आधी ही सुझाए गए थ्रेशोल्ड को पूरा करती हैं. इसलिए, चलिए इसी के साथ शुरू करते हैं.
पक्का करें कि एलसीपी रिसॉर्स को एचटीएमएल सोर्स से खोजा जा सके
एचटीटीपी संग्रह की ओर से उपलब्ध कराए गए, 2022 के Web Almanac के मुताबिक, मोबाइल पेजों में से 72% मोबाइल पेजों पर एलसीपी एलिमेंट के तौर पर इमेज मौजूद होती है. इसका मतलब है कि ज़्यादातर साइटों को अपने एलसीपी को ऑप्टिमाइज़ करने के लिए, यह पक्का करना होगा कि वे इमेज तेज़ी से लोड हो सकें.
कई डेवलपर को यह साफ़ तौर पर पता नहीं होता कि इमेज लोड करने में लगने वाला समय, किसी चुनौती का सिर्फ़ एक हिस्सा है. एक और अहम हिस्सा है इमेज के लोड होने से पहले का समय और एचटीटीपी संग्रह के डेटा से पता चलता है कि इसी समय कई साइटों को लोड किया जाता है.
असल में, जिन पेजों पर एलसीपी एलिमेंट एक इमेज था उनमें से 39% इमेज के सोर्स यूआरएल, एचटीएमएल दस्तावेज़ के सोर्स से खोजे नहीं जा सकते थे. दूसरे शब्दों में, वे यूआरएल स्टैंडर्ड एचटीएमएल एट्रिब्यूट (जैसे कि <img src="..."> या <link rel="preload" href="...">) में नहीं मिले, जिससे ब्राउज़र उन्हें तुरंत खोज सकेगा और तुरंत लोड करना शुरू कर सकेगा.
अगर किसी पेज को सीएसएस या JavaScript फ़ाइलों के पूरी तरह से डाउनलोड होने, पार्स होने, और प्रोसेस होने तक इंतज़ार करना है, तो इमेज के लोड होने से पहले ही, लोड होने में बहुत देरी हो सकती है.
सामान्य नियम के हिसाब से, अगर आपका एलसीपी एलिमेंट कोई इमेज है, तो इमेज के यूआरएल को हमेशा एचटीएमएल सोर्स से खोजा जाना चाहिए. इसे संभव बनाने के लिए कुछ सुझाव हैं:
srcयाsrcsetएट्रिब्यूट वाले<img>एलिमेंट का इस्तेमाल करके, इमेज लोड करें.data-srcजैसे नॉन-स्टैंडर्ड एट्रिब्यूट इस्तेमाल न करें जिन्हें रेंडर करने के लिए JavaScript की ज़रूरत होती है. ऐसा इसलिए, क्योंकि ये एट्रिब्यूट हमेशा धीरे काम करते हैं. 9% पेज,data-srcके पीछे अपनी एलसीपी इमेज को छिपा देते हैं.क्लाइंट-साइड रेंडरिंग (सीएसआर) के बजाय सर्वर-साइड रेंडरिंग (एसएसआर) को प्राथमिकता दें, क्योंकि एसएसआर का मतलब है कि एचटीएमएल सोर्स में पूरा पेज मार्कअप (इमेज के साथ) मौजूद है. सीएसआर समाधानों के लिए JavaScript चलाना ज़रूरी है, ताकि इमेज खोजी जा सके.
अगर आपकी इमेज को किसी बाहरी सीएसएस या JS फ़ाइल से रेफ़र करने की ज़रूरत है, तो इसे
<link rel="preload">टैग के ज़रिए एचटीएमएल सोर्स में अब भी शामिल किया जा सकता है. ध्यान दें कि इनलाइन स्टाइल से रेफ़र की गई इमेज, ब्राउज़र के प्रीलोड स्कैनर से नहीं खोजी जा सकतीं. इसलिए, हो सकता है कि अन्य रिसॉर्स को लोड करते समय भी उन्हें खोजा जा सके. इसलिए, इन मामलों में पहले से लोड करने की सुविधा से मदद मिल सकती है.
आपकी एलसीपी इमेज को खोजने में कोई समस्या है या नहीं, यह समझने में आपकी मदद करने के लिए, लाइटहाउस 10.0 वर्शन में एक नया ऑडिट रिलीज़ करेगा. आम तौर पर, ऐसा जनवरी 2023 में किया जाता है.
यह पक्का करने से कि एलसीपी संसाधन एचटीएमएल सोर्स से खोजा जा सके, कई सुधार किए जा सकते हैं. साथ ही, इससे संसाधन को प्राथमिकता देने के और मौके भी मिलते हैं. हमारा अगला सुझाव है कि हम संसाधन को प्राथमिकता दें.
पक्का करना कि एलसीपी रिसॉर्स को प्राथमिकता दी गई हो
यह पक्का करने का पहला अहम कदम है कि एलसीपी रिसॉर्स को एचटीएमएल सोर्स से खोजा जा सके. इससे यह पक्का होता है कि एलसीपी रिसॉर्स समय से पहले लोड हो सके. हालांकि, एक और ज़रूरी चरण यह पक्का करना है कि रिसॉर्स की लोडिंग प्राथमिकता हो और यह ज़्यादा ज़रूरी संसाधनों के पीछे न हो.
उदाहरण के लिए, भले ही आपकी एलसीपी इमेज, स्टैंडर्ड <img> टैग का इस्तेमाल करके एचटीएमएल सोर्स में मौजूद हो, लेकिन अगर आपके पेज में उस <img> टैग से पहले, आपके दस्तावेज़ के <head> में एक दर्जन <script> टैग शामिल हैं, तो इमेज रिसॉर्स को लोड होने में कुछ समय लग सकता है.
इस समस्या को हल करने का सबसे आसान तरीका है कि ब्राउज़र को इस बारे में संकेत दें कि कौनसे संसाधन सबसे ज़्यादा प्राथमिकता वाले हैं. इसके लिए, आपको एलसीपी इमेज लोड करने वाले <img> या <link> टैग पर, नया fetchpriority="high" एट्रिब्यूट सेट करना होगा. यह ब्राउज़र को स्क्रिप्ट के पूरा होने का इंतज़ार करने के बजाय, उन्हें पहले लोड करने का निर्देश देता है.
Web Almanac के मुताबिक, ज़रूरी शर्तें पूरी करने वाले सिर्फ़ 0.03% पेज ही इस नए एपीआई का इस्तेमाल कर रहे हैं. इसका मतलब है कि वेब पर मौजूद ज़्यादातर साइटों के पास, बहुत कम मेहनत में एलसीपी को बेहतर बनाने के काफ़ी मौके हैं. फ़िलहाल, fetchpriority एट्रिब्यूट सिर्फ़ Chromium का इस्तेमाल करने वाले ब्राउज़र में काम करता है. हालांकि, यह एपीआई लगातार बेहतर बनाने के लिए एक बेहतर सुविधा है, जिसे दूसरे ब्राउज़र अनदेखा कर देते हैं. इसलिए, हमारा सुझाव है कि डेवलपर अभी इसका इस्तेमाल करें.
अगर Chromium का इस्तेमाल नहीं करने वाले ब्राउज़र के लिए, एलसीपी संसाधन को अन्य संसाधनों के ऊपर प्राथमिकता दी जाए, तो इसका मतलब सिर्फ़ दस्तावेज़ में पहले उसका रेफ़रंस देना है. दस्तावेज़ के <head> में मौजूद बहुत से <script> टैग वाली साइट का उदाहरण फिर से इस्तेमाल करें. अगर आपको यह पक्का करना है कि आपके एलसीपी संसाधन को उन स्क्रिप्ट संसाधनों से पहले प्राथमिकता दी जाए, तो उनमें से किसी भी स्क्रिप्ट से पहले <link rel="preload"> टैग जोड़ें. इसके अलावा, बाद में <body> में उन स्क्रिप्ट को <img> के नीचे ले जाया जा सकता है. हालांकि, यह तरीका कारगर साबित होता है, लेकिन fetchpriority का इस्तेमाल करने के मुकाबले यह काम कम आसान है. इसलिए, हमें उम्मीद है कि अन्य ब्राउज़र से यह सुविधा जल्द ही काम करेगी.
एलसीपी संसाधन को प्राथमिकता देने का एक और अहम पहलू यह है कि आप कोई भी ऐसी गतिविधि न करें जिसकी वजह से प्राथमिकता न दी जा रही हो. जैसे, loading="lazy" एट्रिब्यूट जोड़ना. फ़िलहाल, 10% पेजों ने अपनी एलसीपी इमेज पर loading="lazy" सेट किया है. इमेज ऑप्टिमाइज़ेशन के ऐसे तरीकों से सावधान रहें जो सभी इमेज पर धीरे-धीरे लेज़ी लोडिंग लागू करते हैं. अगर वे इस तरीके को बदलने का तरीका उपलब्ध कराते हैं, तो एलसीपी इमेज के लिए इसका इस्तेमाल करें. अगर आपको नहीं पता कि कौनसी इमेज एलसीपी होगी, तो सही उम्मीदवार चुनने के लिए अनुभव के आधार पर कोशिश करें.
गैर-ज़रूरी संसाधनों को रोककर रखना, एलसीपी संसाधन की मौजूदा प्राथमिकता को बढ़ाने का एक और तरीका है. उदाहरण के लिए, ऐसी स्क्रिप्ट जो यूज़र इंटरफ़ेस को बेहतर नहीं बनाती हैं (जैसे कि Analytics स्क्रिप्ट या सोशल विजेट) को load इवेंट के ट्रिगर होने तक, सुरक्षित तरीके से रोका जा सकता है. इससे यह पक्का होता है कि वे नेटवर्क बैंडविड्थ के लिए, एलसीपी संसाधन जैसे अन्य ज़रूरी संसाधनों के साथ मुकाबला नहीं कर पाएंगी.
कम शब्दों में कहें, तो यह पक्का करने के लिए कि एलसीपी रिसॉर्स को जल्दी और ज़्यादा प्राथमिकता पर लोड किया जाए, आपको इन सबसे सही तरीकों का इस्तेमाल करना चाहिए:
- अपनी एलसीपी इमेज के
<img>टैग मेंfetchpriority="high"जोड़ें. अगर एलसीपी रिसॉर्स को<link rel="preload">टैग से लोड किया गया है, तो चिंता न करें, क्योंकि आपके पास उस परfetchpriority="high"को सेट करने का विकल्प भी है! - अपनी एलसीपी इमेज के
<img>टैग परloading="lazy"को कभी सेट न करें. ऐसा करने से, आपकी इमेज रुक जाएगी और इमेज लोड होने में देरी हो जाएगी. - ज़रूरी होने पर ही, गैर-ज़रूरी संसाधनों को रोकें. इसके लिए, उन्हें अपने दस्तावेज़ के आखिर में ले जाएं. इसके लिए, इमेज या iframe या JavaScript की मदद से एसिंक्रोनस रूप से लोड करने के लिए, नेटिव लेज़ी-लोडिंग का इस्तेमाल करें.
दस्तावेज़ और संसाधन TTFB को ऑप्टिमाइज़ करने के लिए CDN का इस्तेमाल करें
पिछले दो सुझावों में, यह पक्का किया गया था कि आपका एलसीपी रिसॉर्स जल्दी खोजा जा सके और उसे प्राथमिकता दी जाए, ताकि यह तुरंत लोड हो सके. इस पहेली का आखिरी हिस्सा यह पक्का करना है कि दस्तावेज़ का शुरुआती जवाब जल्द से जल्द मिल जाए.
ब्राउज़र तब तक किसी भी सबरिसॉर्स को लोड करना शुरू नहीं कर सकता, जब तक कि उसे शुरुआती एचटीएमएल दस्तावेज़ रिस्पॉन्स का पहला बाइट नहीं मिल जाता, और जितनी जल्दी होती है, बाकी सब कुछ भी जल्दी शुरू हो सकता है.
इस समय को टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी) कहा जाता है. टीटीएफ़बी को कम करने का सबसे अच्छा तरीका यह है:
- अपने कॉन्टेंट को भौगोलिक रूप से अपने उपयोगकर्ताओं के आस-पास दिखाएं
- उस कॉन्टेंट को कैश मेमोरी में सेव करें, ताकि हाल ही में अनुरोध किया गया कॉन्टेंट फिर से तुरंत दिखाया जा सके.
इन दोनों चीज़ों को करने का सबसे अच्छा तरीका है कि आप सीडीएन का इस्तेमाल करें. सीडीएन आपके संसाधनों को दुनिया भर में फैले किनारे के सर्वर में बांटते हैं. इस तरह, वे संसाधनों के लिए एक तार से ज़्यादा की जाने वाली दूरी को आपके उपयोगकर्ताओं तक सीमित कर देते हैं. आम तौर पर, सीडीएन को कैश मेमोरी में सेव करने की बेहतर सुविधा मिलती है. इसे आपकी साइट की ज़रूरतों के हिसाब से बनाया और ऑप्टिमाइज़ किया जा सकता है.
कई डेवलपर को स्टैटिक ऐसेट होस्ट करने के लिए सीडीएन इस्तेमाल करने के बारे में जानकारी है. हालांकि, सीडीएन, डाइनैमिक तौर पर जनरेट होने वाले एचटीएमएल दस्तावेज़ों के साथ-साथ, एचटीएमएल दस्तावेज़ों को कैश मेमोरी में सेव भी कर सकते हैं और कैश मेमोरी में सेव कर सकते हैं.
Web Almanac के मुताबिक, सिर्फ़ 29% एचटीएमएल दस्तावेज़ अनुरोध सीडीएन से भेजे गए थे. इसका मतलब है कि साइटों के लिए, अतिरिक्त बचत का दावा करने की काफ़ी संभावना है.
सीडीएन कॉन्फ़िगर करने के लिए कुछ सलाह यहां दी गई है:
- अपने कॉन्टेंट को कैश मेमोरी में सेव किए जाने की अवधि को बढ़ाएं. उदाहरण के लिए, क्या यह वाकई ज़रूरी है कि कॉन्टेंट हमेशा नया हो? या क्या यह कुछ मिनट पुराना हो सकता है?).
- कॉन्टेंट को हमेशा के लिए कैश मेमोरी में सेव करने के बारे में सोचें. इसके बाद, अगर/जब आप कोई अपडेट करते हैं, तो कैश मेमोरी को पूरी तरह मिटा दें.
- यह देखें कि आपके ऑरिजिन सर्वर पर अभी चल रहे डाइनैमिक लॉजिक को एज (ज़्यादातर आधुनिक सीडीएन की सुविधा) पर ले जाया जा सकता है या नहीं.
आम तौर पर, किसी भी समय सीधे किनारे से कॉन्टेंट पेश किया जा सकता है (अपने मूल सर्वर पर जाने से बचने के लिए) यह एक परफ़ॉर्मेंस जीत है. अगर आपको अपने मूल सर्वर पर वापस जाना ज़रूरी है, तो भी सीडीएन को तेज़ी से काम करने के लिए ऑप्टिमाइज़ किया जाता है. इसलिए, यह आपके लिए भी फ़ायदेमंद है.
कुल लेआउट शिफ़्ट (सीएलएस)
सुझावों का अगला सेट कुल लेआउट शिफ़्ट (सीएलएस) के लिए है. इससे वेब पेजों पर विज़ुअल स्टैबिलिटी का पता चलता है. हालांकि, 2020 से अब तक वेब पर सीएलएस से काफ़ी बेहतर हुआ है. हालांकि, करीब एक चौथाई वेबसाइटें अब भी सुझाए गए थ्रेशोल्ड को पूरा नहीं कर पा रही हैं. इसलिए, कई साइटों के लिए उनके उपयोगकर्ता अनुभव को बेहतर बनाने का एक बड़ा अवसर है.
पेज से लोड किए गए किसी भी कॉन्टेंट पर, साफ़ तौर पर साइज़ सेट करें
आम तौर पर, लेआउट शिफ़्ट तब होते हैं, जब अन्य कॉन्टेंट के लोड होने के बाद, मौजूदा कॉन्टेंट में बदलाव होता है. इसलिए, इसे कम करने का पहला तरीका यह है कि जितनी जगह हो सके उतनी जगह पहले से बुक कर लें.
साइज़ न बदलने वाली इमेज की वजह से होने वाले लेआउट शिफ़्ट को ठीक करने का सबसे आसान तरीका है, width और height एट्रिब्यूट को साफ़ तौर पर सेट करना या ऐसी सीएसएस प्रॉपर्टी को साफ़ तौर पर सेट करना. हालांकि, एचटीटीपी संग्रह के मुताबिक 72% पेजों में कम से कम एक बिना साइज़ की इमेज होती है. तय साइज़ के बिना, ब्राउज़र शुरुआत में 0px की डिफ़ॉल्ट ऊंचाई सेट करेंगे. साथ ही, इमेज के लोड होने और डाइमेंशन खोजे जाने पर, लेआउट शिफ़्ट दिख सकता है. यह सामूहिक वेब के लिए एक बड़े अवसर को दर्शाता है और इस लेख में सुझाए गए अन्य सुझावों की तुलना में इस अवसर के लिए बहुत कम मेहनत की ज़रूरत है.
यह ध्यान रखना भी ज़रूरी है कि सीएलएस में सिर्फ़ इमेज का योगदान नहीं है. लेआउट शिफ़्ट ऐसे अन्य कॉन्टेंट की वजह से भी हो सकता है जो आम तौर पर, पेज के रेंडर होने के बाद लोड होता है. इसमें तीसरे पक्ष के विज्ञापन या एम्बेड किए गए वीडियो भी शामिल हैं. aspect-ratio प्रॉपर्टी की मदद से, इस समस्या को हल किया जा सकता है. यह सीएसएस की नई सुविधा है. इसकी मदद से, डेवलपर साफ़ तौर पर इमेज और बिना इमेज वाले एलिमेंट का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) बता सकते हैं. इससे आपको डाइनैमिक width (उदाहरण के लिए, स्क्रीन के साइज़ के आधार पर) सेट करने की सुविधा मिलेगी. साथ ही, ब्राउज़र अपने-आप सही ऊंचाई का हिसाब लगा सकेगा. यह ठीक उसी तरह, जिस तरह डाइमेंशन वाली इमेज के लिए किया जाता है.
कई बार डाइनैमिक कॉन्टेंट का सटीक साइज़ पता नहीं किया जा सकता, क्योंकि यह अपने-आप में डाइनैमिक होता है. हालांकि, भले ही आपको सही साइज़ पता न हो, फिर भी लेआउट शिफ़्ट की गंभीरता कम करने का तरीका अपनाया जा सकता है. ब्राउज़र को किसी खाली एलिमेंट के लिए 0px की डिफ़ॉल्ट ऊंचाई का इस्तेमाल करने की अनुमति देने के बजाय, सही min-height को सेट करना, हमेशा बेहतर होता है. आम तौर पर, min-height का इस्तेमाल करना भी एक आसान तरीका है, क्योंकि इससे कंटेनर को ज़रूरत पड़ने पर कॉन्टेंट की पूरी ऊंचाई तक बढ़ाया जा सकता है. इससे, ग्रोथ के उस लेवल को भी कम किया जा सकता है जो काफ़ी हद तक कम हो गया है. हमें उम्मीद है कि यह बढ़ोतरी आसानी से देखने लायक होगी.
पक्का करें कि पेजों को बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा के लिए इस्तेमाल किया जा सकता है
किसी पेज को सीधे मेमोरी स्नैपशॉट से, ब्राउज़र के इतिहास में तुरंत या बाद में लोड करने के लिए ब्राउज़र, बैक/फ़ॉरवर्ड कैश मेमोरी या बैक अप के तौर पर सेव की गई कैश मेमोरी का इस्तेमाल करते हैं.
bfcache ब्राउज़र-लेवल की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए एक अहम टूल है. साथ ही, यह पेज लोड होने के दौरान लेआउट शिफ़्ट को पूरी तरह खत्म कर देता है. कई साइटों का ज़्यादातर सीएलएस वहां होता है. बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा के लॉन्च होने की वजह से, सीएलएस में सबसे ज़्यादा सुधार हुआ, जो हमें 2022 में मिला.
इसके बावजूद, कई वेबसाइटें बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा का इस्तेमाल नहीं कर सकतीं. इसलिए, वेब पर अच्छी परफ़ॉर्मेंस वाली इस मुफ़्त परफ़ॉर्मेंस की वजह से, उन्हें बड़ी संख्या में नेविगेशन का फ़ायदा नहीं मिल रहा है. अगर आपका पेज ऐसी संवेदनशील जानकारी लोड नहीं करता है जिसे आपको मेमोरी से वापस नहीं लाना है, तो पक्का करें कि आपके पेज ज़रूरी शर्तों को पूरा करते हों.
साइट के मालिकों को यह जांच करनी चाहिए कि उनके पेज, bfcache की ज़रूरी शर्तें पूरी करते हैं या नहीं. साथ ही, उन्हें ऐसा न करने की वजहों पर भी काम करना चाहिए. Chrome में पहले से ही DevTools में bfcache टेस्टर मौजूद है. इस साल, हम इस टूल को बेहतर बनाने के लिए इस तरह की जांच करने वाले एक नए लाइटहाउस ऑडिट और फ़ील्ड में इसे मेज़र करने के लिए एक एपीआई लाने की योजना बना रहे हैं.
हमने सीएलएस सेक्शन में बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा को शामिल किया है, क्योंकि हमें इसमें अब तक का सबसे ज़्यादा फ़ायदा मिला है. हालांकि, बैक-फ़ॉरवर्ड कैश मेमोरी की सुविधा से, वेबसाइट की परफ़ॉर्मेंस की अन्य जानकारी भी बेहतर होगी. यह पेज नेविगेशन को बहुत बेहतर बनाने के लिए उपलब्ध कई इंस्टैंट नेविगेशन में से एक है.
ऐसे ऐनिमेशन/ट्रांज़िशन से बचें जो लेआउट देने वाली सीएसएस प्रॉपर्टी का इस्तेमाल करते हैं
एलिमेंट का ऐनिमेशन होना भी लेआउट शिफ़्ट का एक और आम सोर्स है. उदाहरण के लिए, कुकी बैनर या सूचना देने वाले अन्य बैनर, जो ऊपर या नीचे से स्लाइड होते हैं, अक्सर सीएलएस में योगदान देते हैं. इससे खास तौर पर तब समस्या होती है, जब ये बैनर अन्य कॉन्टेंट को किसी और कॉन्टेंट से हटा देते हैं. हालांकि, ऐसा न करने पर भी, ऐनिमेशन से सीएलएस पर असर पड़ सकता है.
हालांकि, एचटीटीपी संग्रह के डेटा में साफ़ तौर पर ऐनिमेशन को लेआउट शिफ़्ट से कनेक्ट नहीं किया जा सकता. हालांकि, डेटा से यह पता चलता है कि जिन पेजों की वजह से लेआउट पर असर डालने वाली किसी भी सीएसएस प्रॉपर्टी को ऐनिमेट किया जाता है उनके सीएलएस "अच्छे" होने की संभावना 15% कम होती है. कुछ प्रॉपर्टी, दूसरों की तुलना में खराब सीएलएस से जुड़ी होती हैं. उदाहरण के लिए, margin या border चौड़ाई वाले ऐनिमेट किए गए पेजों का सीएलएस "खराब" सीएलएस होता है, जो कि सभी पेजों के खराब आंकने की दर के मुकाबले दोगुना होता है.
इसमें कोई हैरानी की बात नहीं है. लेआउट में बदलाव करने वाली किसी सीएसएस प्रॉपर्टी को जब भी ट्रांज़िशन या ऐनिमेट किया जाता है, तो लेआउट शिफ़्ट होते हैं. अगर ये लेआउट शिफ़्ट, उपयोगकर्ता के इंटरैक्शन के 500 मिलीसेकंड के अंदर नहीं हैं, तो इनका सीएलएस पर असर पड़ेगा.
कुछ डेवलपर को हैरानी की बात यह है कि एलिमेंट को उन मामलों में भी लागू किया जाता है जहां एलिमेंट को दस्तावेज़ के सामान्य फ़्लो से बाहर ले जाया जाता है. उदाहरण के लिए, top या left को ऐनिमेट करने वाले पूरी तरह से पोज़िशन किए गए एलिमेंट की वजह से लेआउट शिफ़्ट हो सकते हैं, भले ही वे दूसरे कॉन्टेंट को पुश न कर रहे हों. हालांकि, अगर top या left को ऐनिमेट करने के बजाय, transform:translateX() या transform:translateY() को ऐनिमेट किया जाता है, तो ब्राउज़र, पेज का लेआउट अपडेट नहीं करेगा और इससे लेआउट में कोई बदलाव नहीं होगा.
ब्राउज़र के कंपोज़िटर थ्रेड पर अपडेट की जा सकने वाली सीएसएस प्रॉपर्टी के ऐनिमेशन को प्राथमिकता देना, लंबे समय से परफ़ॉर्मेंस के लिए सबसे सही तरीका रहा है, क्योंकि यह जीपीयू पर काम करता है और मुख्य थ्रेड से बाहर निकलता है. सामान्य परफ़ॉर्मेंस के अलावा, यह सीएलएस को बेहतर बनाने में भी मदद कर सकता है.
सामान्य नियम के हिसाब से, ऐसी किसी भी सीएसएस प्रॉपर्टी को कभी ऐनिमेट या ट्रांसफ़र न करें जिसके लिए ब्राउज़र को पेज लेआउट अपडेट करने की ज़रूरत होती है. ऐसा तब तक न करें, जब तक उपयोगकर्ता के टैप करने या बटन को दबाने (हालांकि, hover नहीं) की वजह से ऐसा किया जा रहा हो. साथ ही, जहां भी हो सके, सीएसएस transform प्रॉपर्टी का इस्तेमाल करके ट्रांज़िशन और ऐनिमेशन का इस्तेमाल करें.
जब कोई पेज संभावित रूप से धीमी सीएसएस प्रॉपर्टी को ऐनिमेट करता है, तो लाइटहाउस ऑडिट कंपोज़िट नहीं किए गए ऐनिमेशन से बचें चेतावनी देगा.
फ़र्स्ट इनपुट डिले (एफ़आईडी)
सुझावों का आखिरी सेट फ़र्स्ट इनपुट डिले (एफ़आईडी) के बारे में है. इससे यह पता चलता है कि किसी पेज से उपयोगकर्ता के इंटरैक्शन का रिस्पॉन्स मिलने में कितना समय लगा. फ़िलहाल, वेब पर मौजूद ज़्यादातर साइटों को एफ़आईडी मेट्रिक में बहुत अच्छा स्कोर मिलता है. हालांकि, हमने पहले भी एफ़आईडी मेट्रिक की कमियों के दस्तावेज़ दर्ज किए हैं. हमारा मानना है कि अब भी ऐसी बहुत सी जगहें हैं जिनके ज़रिए साइटें, उपयोगकर्ता की गतिविधियों से इंटरैक्ट करने के तरीके को बेहतर बना सकती हैं.
इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी) की नई मेट्रिक, एफ़आईडी का संभावित जवाब है. यहां दिए गए सभी सुझाव, एफ़आईडी और आईएनपी, दोनों पर समान रूप से लागू होते हैं. यह देखते हुए कि "अच्छा" एफ़आईडी होने के बावजूद, साइटें आईएनपी पर साइटों की परफ़ॉर्मेंस खराब हैं, खास तौर पर मोबाइल पर. हम डेवलपर को सुझाव देते हैं कि वे रिस्पॉन्स पाने के तरीकों के इन सुझावों पर गंभीरता से विचार करें.
लंबे टास्क से बचना या उन्हें तोड़ना
टास्क अलग से किए जाने वाले ऐसे काम होते हैं जिन्हें ब्राउज़र करता है. इन कामों में स्क्रिप्ट को रेंडर करना, लेआउट करना, पार्स करना, कंपाइल, और एक्ज़ीक्यूट करना शामिल है. जब टास्क, लंबे टास्क यानी 50 मिलीसेकंड या उससे लंबे टास्क बन जाते हैं, तब वे मुख्य थ्रेड को उपयोगकर्ता के इनपुट का तुरंत जवाब देने से रोकते हैं.
वेब कैलेंडर के मुताबिक, ऐसे कई सबूत हैं जिनसे पता चलता है कि डेवलपर अपने लंबे टास्क से बचने या उन्हें तोड़ने के लिए और भी कोशिश कर सकते हैं. ऐसा हो सकता है कि लंबे टास्क को ग्रुप करना, इस लेख में दिए गए अन्य सुझावों जितना आसान न हो. हालांकि, इस लेख में नहीं दी गई अन्य तकनीकों के मुकाबले इसे कम मेहनत में पूरा किया जा सकता है.
JavaScript में आपको हमेशा जितना हो सके उतना कम काम करना चाहिए. हालांकि, लंबे टास्क को छोटे-छोटे टास्क में बांटकर, मुख्य थ्रेड की बहुत मदद की जा सकती है. ऐसा अक्सर मुख्य थ्रेड में जाकर किया जा सकता है, ताकि रेंडरिंग अपडेट और अन्य उपयोगकर्ता इंटरैक्शन ज़्यादा तेज़ी से हो सकें.
इसके अलावा, isInputPending और Scheduler API जैसे एपीआई का इस्तेमाल भी किया जा सकता है. isInputPending एक ऐसा फ़ंक्शन है जो एक बूलियन वैल्यू दिखाता है. इससे पता चलता है कि उपयोगकर्ता का इनपुट बाकी है या नहीं. अगर यह true दिखाता है, तो मुख्य थ्रेड में गतिविधि की जा सकती है, ताकि यह उपयोगकर्ता के उन इनपुट को मैनेज कर सके जिन्हें मंज़ूरी मिलनी बाकी है.
Scheduler API एक बेहतर तरीका है, जिससे आप प्राथमिकताओं के उस सिस्टम के आधार पर काम को शेड्यूल कर सकते हैं, जिसमें यह ध्यान में रखा जाता है कि किया जा रहा काम उपयोगकर्ता को दिखाई दे रहा है या बैकग्राउंड में है.
लंबे टास्क को अलग-अलग करके, ब्राउज़र को उपयोगकर्ताओं को दिखने वाले अहम काम के ज़्यादा मौके दिए जा सकते हैं. जैसे, इंटरैक्शन और रेंडरिंग अपडेट करना.
गै़र-ज़रूरी JavaScript से बचना
इसमें कोई शक नहीं है: वेबसाइटें पहले से कहीं ज़्यादा JavaScript भेज रही हैं और ऐसा नहीं लगता कि ट्रेंड जल्द ही बदलने वाला है. बहुत ज़्यादा JavaScript भेजने का मतलब है कि एक ऐसा एनवायरमेंट बन गया है जिसमें टास्क, मुख्य थ्रेड पर फ़ोकस करने के लिए प्रतिस्पर्धा कर रहे हैं. इससे आपकी वेबसाइट की प्रतिक्रिया पर असर पड़ सकता है, खास तौर पर उस अहम स्टार्टअप अवधि के दौरान.
हालांकि, यह समस्या हल नहीं की जा सकती. आपके पास कुछ विकल्प हैं:
- अपनी वेबसाइट के संसाधनों में इस्तेमाल न होने वाले कोड ढूंढने के लिए Chrome DevTools में कवरेज टूल का इस्तेमाल करें. स्टार्टअप के दौरान अपनी ज़रूरत के हिसाब से संसाधनों का साइज़ कम करके, यह पक्का किया जा सकता है कि आपकी वेबसाइट, कोड को पार्स और कंपाइल करने में कम समय लेती है. इससे, उपयोगकर्ता को पहले से बेहतर अनुभव मिलता है.
- कभी-कभी कवरेज टूल का इस्तेमाल करके, इस्तेमाल न होने वाले कोड को "इस्तेमाल नहीं किया गया" के तौर पर मार्क किया जाता है, क्योंकि इसे स्टार्टअप के दौरान नहीं चलाया गया था. हालांकि, आने वाले समय में यह कुछ फ़ंक्शन के लिए ज़रूरी है. इस कोड को कोड स्प्लिटिंग की मदद से किसी अलग बंडल में ले जाया जा सकता है.
- अगर टैग मैनेजर का इस्तेमाल किया जा रहा है, तो समय-समय पर अपने टैग की जांच करके यह पक्का करें कि उन्हें ऑप्टिमाइज़ किया गया है. इसके अलावा, भले ही उनका इस्तेमाल अब भी किया जा रहा हो. इस्तेमाल न किए गए कोड वाले पुराने टैग को हटाकर, अपने टैग मैनेजर के JavaScript को छोटा और ज़्यादा असरदार बनाया जा सकता है.
बड़े रेंडरिंग अपडेट से बचें
JavaScript के अलावा कोई और चीज़ नहीं है, जो आपकी वेबसाइट के रिस्पॉन्स पर असर डाल सकती है. रेंडरिंग अपने-आप में एक तरह का महंगा काम हो सकता है—और जब रेंडरिंग में बड़े बदलाव होते हैं, तो इसकी वजह से आपकी वेबसाइट, उपयोगकर्ता के इनपुट का जवाब नहीं दे पाती.
रेंडरिंग के काम को ऑप्टिमाइज़ करना आसान प्रक्रिया नहीं है. आम तौर पर, यह इस बात पर निर्भर करता है कि आपको क्या हासिल करना है. इसके बावजूद, यहां कुछ ऐसी बातें बताई गई हैं जिन्हें अपनाकर, यह पक्का किया जा सकता है कि रेंडरिंग से जुड़े अपडेट सही हैं और उन्हें लंबे टास्क में शामिल नहीं किया जा सकता:
- बिना विज़ुअल वाले काम के लिए,
requestAnimationFrame()का इस्तेमाल करने से बचें. इवेंट लूप के रेंडरिंग फ़ेज़ के दौरानrequestAnimationFrame()कॉल हैंडल किए जाते हैं. अगर इस चरण में बहुत ज़्यादा काम पूरा हो जाता है, तो रेंडरिंग अपडेट में देरी हो सकती है. यह ज़रूरी है किrequestAnimationFrame()के साथ किए जा रहे काम को सिर्फ़ उन कामों के लिए रिज़र्व रखा जाए जिनमें अपडेट रेंडर करना शामिल है. - अपने डीओएम का साइज़ छोटा रखें. DOM साइज़ और लेआउट के काम की इंटेंसिटी, दोनों एक-दूसरे से जुड़ी हैं. जब रेंडरर को बहुत बड़े डीओएम के लिए लेआउट अपडेट करना होता है, तो इसके लेआउट को फिर से कैलकुलेट करने के लिए ज़रूरी काम काफ़ी बढ़ सकता है.
- सीएसएस कंटेनमेंट का इस्तेमाल करें. सीएसएस कंटेनमेंट, सीएसएस
containप्रॉपर्टी पर निर्भर करता है. इससे ब्राउज़र को निर्देश मिलते हैं किcontainप्रॉपर्टी को सेट किए गए कंटेनर के लिए, लेआउट का काम कैसे किया जाए. इसमें, लेआउट के स्कोप को अलग करना और डीओएम में किसी खास रूट के लिए रेंडरिंग भी शामिल है. यह प्रक्रिया हमेशा आसान नहीं होती, लेकिन जटिल लेआउट वाले क्षेत्रों को अलग करके, आप लेआउट और रेंडरिंग जैसे काम करने से बच सकते हैं, जिनकी ज़रूरत नहीं है.
नतीजा
पेज की परफ़ॉर्मेंस को बेहतर बनाना मुश्किल काम लग सकता है. ऐसा इसलिए है, क्योंकि पूरे वेब पर कई दिशा-निर्देशों की ज़रूरत होती है. हालांकि, इन सुझावों पर ध्यान देकर, फ़ोकस और मकसद से जुड़ी समस्या का हल निकाला जा सकता है. साथ ही, हो सकता है कि आपकी वेबसाइट की वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली रणनीति का इस्तेमाल किया जा सके.
वेब की स्थिति का बारीकी से विश्लेषण करने पर, हम मानते हैं कि यहां दिए गए सुझावों में पूरी जानकारी नहीं है. हालांकि, हम मानते हैं कि ये सुझाव, 2023 में अपनी वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी को बेहतर बनाने के सबसे असरदार तरीके हैं.
अगर आपको यहां दिए गए सुझावों के अलावा अन्य जानकारी भी चाहिए, तो ज़्यादा जानकारी के लिए ये ऑप्टिमाइज़ेशन गाइड देखें:
- एलसीपी को ऑप्टिमाइज़ करें
- सीएलएस को ऑप्टिमाइज़ करें
- एफ़आईडी को ऑप्टिमाइज़ करना
- आईएनपी को ऑप्टिमाइज़ करना
सभी के लिए तेज़ वेब और नए साल की शुभकामनाएं! हो सकता है कि आपकी साइटें उपयोगकर्ताओं के लिए हर तरीके से तेज़ी से लोड हों.
डेविन एवरी की फ़ोटो