यह उन सबसे सही तरीकों का कलेक्शन है जिनके हिसाब से 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 को ऑप्टिमाइज़ करने के लिए सीडीएन का इस्तेमाल करें
पिछले दो सुझावों में, यह पक्का करने पर फ़ोकस किया गया था कि आपके एलसीपी रिसॉर्स को जल्दी खोजा जाए और प्राथमिकता दी जाए, ताकि वह तुरंत लोड हो सके. इस पहेली का आखिरी हिस्सा यह पक्का करना है कि दस्तावेज़ का शुरुआती जवाब भी जल्द से जल्द मिले.
ब्राउज़र, शुरुआती एचटीएमएल दस्तावेज़ के रिस्पॉन्स का पहला बाइट मिलने तक किसी भी सबरिसॉर्स को लोड करना शुरू नहीं कर सकता. साथ ही, सब कुछ और भी जल्दी हो सकता है.
इस समय को टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी) कहा जाता है. टीटीएफ़बी को कम करने का सबसे अच्छा तरीका यह है:
- अपने कॉन्टेंट को उपयोगकर्ताओं के आस-पास की जगह के हिसाब से दिखाएं
- कॉन्टेंट को कैश मेमोरी में सेव करें, ताकि हाल ही में अनुरोध किया गया कॉन्टेंट फिर से जल्दी दिखाया जा सके.
इन दोनों कामों के लिए, सीडीएन का इस्तेमाल करें. सीडीएन आपके संसाधनों को, दुनिया भर में मौजूद किनारे वाले सर्वर पर डिस्ट्रिब्यूट करते हैं. इससे, इन संसाधनों को वायर के ज़रिए आपके उपयोगकर्ताओं तक पहुंचने के लिए सीमित दूरी तय करनी पड़ती है. सीडीएन में आम तौर पर कैश मेमोरी में सेव करने के कंट्रोल भी होते हैं. इन्हें अपनी साइट की ज़रूरत के हिसाब से बनाया और ऑप्टिमाइज़ किया जा सकता है.
कई डेवलपर यह जानते हैं कि स्टैटिक ऐसेट को होस्ट करने के लिए सीडीएन का इस्तेमाल किया जाता है. हालांकि, सीडीएन, एचटीएमएल दस्तावेज़ों को भी दिखा सकते हैं और कैश मेमोरी में सेव कर सकते हैं. इनमें वे दस्तावेज़ भी शामिल हो सकते हैं जो डाइनैमिक तरीके से जनरेट होते हैं.
Web Almanac के मुताबिक, एचटीएमएल दस्तावेज़ के सिर्फ़ 29% अनुरोध सीडीएन से मिले हैं. इसका मतलब है कि साइटों के पास ज़्यादा बचत करने का अच्छा-खासा मौका है.
अपने सीडीएन कॉन्फ़िगर करने के लिए कुछ सलाह यहां दी गई है:
- कॉन्टेंट को कैश मेमोरी में सेव रखने की अवधि बढ़ाएं. उदाहरण के लिए, क्या वाकई में यह ज़रूरी है कि कॉन्टेंट हमेशा नया हो? क्या यह कुछ मिनट पुराना हो सकता है?).
- कॉन्टेंट को हमेशा के लिए कैश मेमोरी में भी सेव किया जा सकता है. इसके बाद, अपडेट करने पर कैश मेमोरी को पूरी तरह मिटाया जा सकता है.
- यह देखें कि क्या ऑरिजिन सर्वर पर चल रहे डाइनैमिक लॉजिक को Edge (ज़्यादातर आधुनिक सीडीएन की सुविधा) पर ले जाया जा सकता है.
आम तौर पर, किसी भी समय सीधे तौर पर किनारे से कॉन्टेंट दिखाया जा सकता है (अपने ऑरिजिन सर्वर पर जाने से बचें). यह आपके लिए फ़ायदेमंद होगा. ऐसे मामलों में जहां आपको ऑरिजिन सर्वर पर वापस आने का काम करना पड़ता है, वहां सीडीएन को इस तरह ज़्यादा तेज़ी से काम करने के लिए ऑप्टिमाइज़ किया जाता है. इसलिए, यह दोनों ही तरीकों से सही साबित होते हैं.
कुल लेआउट शिफ़्ट (सीएलएस)
सुझावों का अगला सेट कुल लेआउट शिफ़्ट (सीएलएस) के लिए है, जो वेब पेजों पर विज़ुअल की स्थिरता को मापता है. सीएलएस ने 2020 से वेब पर काफ़ी सुधार किया है. हालांकि, करीब एक चौथाई वेबसाइट अब भी सुझाए गए थ्रेशोल्ड को पूरा नहीं करती हैं. इसलिए, अब भी कई साइटों के लिए उपयोगकर्ता अनुभव को बेहतर बनाने का एक बड़ा अवसर मौजूद है.
पेज से लोड किए गए किसी भी कॉन्टेंट के लिए, साफ़ तौर पर साइज़ सेट करें
लेआउट शिफ़्ट आम तौर पर तब होते हैं, जब मौजूदा कॉन्टेंट, अन्य कॉन्टेंट लोड होने के बाद ट्रांसफ़र होता है. इसलिए, इसे कम करने का मुख्य तरीका यह है कि जितनी हो सके उतनी जगह पहले ही बुक कर लें.
बिना साइज़ वाली इमेज की वजह से लेआउट में हुए बदलावों को ठीक करने का सबसे आसान तरीका है कि width और height एट्रिब्यूट को साफ़ तौर पर सेट करें (या इसके बराबर की सीएसएस प्रॉपर्टी). हालांकि, एचटीटीपी संग्रह के मुताबिक, 72% पेजों में कम से कम एक बिना साइज़ वाली इमेज होती है. किसी खास साइज़ के बिना, ब्राउज़र शुरुआत में 0px की डिफ़ॉल्ट ऊंचाई सेट करेंगे. इमेज लोड होने और डाइमेंशन का पता चलने पर, ब्राउज़र लेआउट में साफ़ तौर पर बदलाव कर सकते हैं. यह प्लैटफ़ॉर्म, वेब के लिए एक बहुत बड़ा अवसर है. साथ ही, इस लेख में सुझाए गए कुछ अन्य सुझावों के मुकाबले, इस सुविधा को बेहतर बनाने में बहुत कम मेहनत करनी पड़ती है.
हालांकि, यह ध्यान रखना भी ज़रूरी है कि सीएलएस में सिर्फ़ इमेज का योगदान नहीं होता है. लेआउट में बदलाव की वजह ऐसे कॉन्टेंट हो सकते हैं जो आम तौर पर, पेज के शुरू होने के बाद लोड होता है. इसमें तीसरे पक्ष के विज्ञापन या एम्बेड किए गए वीडियो भी शामिल हैं. इस समस्या को हल करने के लिए, aspect-ratio प्रॉपर्टी का इस्तेमाल करें. यह सीएसएस की एक नई सुविधा है. इसकी मदद से डेवलपर, इमेज और बिना इमेज वाले एलिमेंट का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) साफ़ तौर पर दे सकते हैं. इससे डाइनैमिक width (उदाहरण के लिए, स्क्रीन के साइज़ के आधार पर) को सेट किया जा सकता है. साथ ही, ब्राउज़र अपने-आप सही ऊंचाई का हिसाब लगा सकता है. यह बिलकुल वैसे ही होता है जैसे डाइमेंशन वाली इमेज के लिए किया जाता है.
कभी-कभी डाइनैमिक कॉन्टेंट के साइज़ का सटीक पता नहीं लगाया जा सकता, क्योंकि यह अपनी स्वाभाविकता में डाइनैमिक होता है. हालांकि, अगर आपको सटीक साइज़ की जानकारी नहीं है, तब भी लेआउट शिफ़्ट की गंभीरता को कम करने के लिए, कदम उठाए जा सकते हैं. सही min-height सेट करना, ब्राउज़र को खाली एलिमेंट के लिए 0px की डिफ़ॉल्ट ऊंचाई इस्तेमाल करने की अनुमति देने से करीब हमेशा बेहतर होता है. min-height का इस्तेमाल करना भी आम तौर पर एक आसान तरीका है, क्योंकि यह अब भी ज़रूरत के हिसाब से कंटेनर को कॉन्टेंट के आखिरी हिस्से तक पहुंचाने में मदद करता है. हालांकि, इससे बढ़ोतरी की उस संख्या में कमी आई है, जो पूरी रकम से बढ़कर उम्मीद की जाती है.
पक्का करें कि आपके पेजों पर बैक-कैश मेमोरी का इस्तेमाल किया जा सकता है
ब्राउज़र, बैक/फ़ॉरवर्ड कैश मेमोरी नाम के नेविगेशन सिस्टम का इस्तेमाल करते हैं. इसका मतलब है कि मेमोरी स्नैपशॉट से, ब्राउज़र के इतिहास में किसी पेज को पहले या बाद में तुरंत लोड किया जा सकता है.
bfcache एक ब्राउज़र-लेवल परफ़ॉर्मेंस ऑप्टिमाइज़ेशन है और यह पेज लोड के दौरान लेआउट शिफ़्ट को पूरी तरह से खत्म कर देता है, जहां ज़्यादातर साइटों का सीएलएस होता है. bfcache के लॉन्च की वजह से, सीएलएस में सबसे बड़ा सुधार हुआ. यह सुधार साल 2022 में मिला.
इसके बावजूद, बहुत सी वेबसाइटें bfcache के लिए अयोग्य होती हैं और इसलिए वे बड़ी संख्या में नेविगेशन के लिए इस मुफ़्त वेब प्रदर्शन जीत का फ़ायदा नहीं उठा पा रही हैं. अगर आपका पेज ऐसी संवेदनशील जानकारी लोड नहीं कर रहा है जिसे आप मेमोरी में वापस नहीं लाना चाहते, तो आपको यह पक्का करना होगा कि आपके पेज ज़रूरी शर्तें पूरी करते हैं.
साइट के मालिकों को यह जांच करनी चाहिए कि उनके पेज बीएफ़कैश की ज़रूरी शर्तें पूरी करते हों. साथ ही, उन्हें सही वजहों से काम करना चाहिए. Chrome में पहले से ही DevTools में एक bfcache टेस्टर है. इस साल हम टूलिंग को बेहतर बनाने की योजना बना रहे हैं. इसके लिए हम इसी तरह का टेस्ट करने वाले नए लाइटहाउस ऑडिट और फ़ील्ड में इसे मेज़र करने के लिए एक एपीआई करेंगे.
हालांकि, हमने सीएलएस सेक्शन में bfcache को शामिल किया है, लेकिन हमें पता चला है कि इसमें अब तक का सबसे बड़ा फ़ायदा मिला है. हालांकि, 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 में कवरेज टूल का इस्तेमाल करें. स्टार्टअप के दौरान ज़रूरी संसाधनों का साइज़ कम करके, यह पक्का किया जा सकता है कि आपकी वेबसाइट, कोड को पार्स और कंपाइल करने में कम समय लगे. इससे उपयोगकर्ता को शुरुआत में बेहतर अनुभव मिलता है.
- कभी-कभी कवरेज टूल का इस्तेमाल करके, जो कोड इस्तेमाल नहीं किया जाता उसे "इस्तेमाल नहीं किया गया" के तौर पर मार्क किया जाता है क्योंकि स्टार्टअप के दौरान एक्ज़ीक्यूट नहीं किया गया था. हालांकि, आने वाले समय में कुछ सुविधाओं के लिए यह अब भी ज़रूरी है. यह एक ऐसा कोड है जिसे कोड का बंटवारा की मदद से, एक अलग बंडल में ले जाया जा सकता है.
- अगर किसी Tag Manager का इस्तेमाल किया जा रहा है, तो समय-समय पर अपने टैग की जांच करके पक्का करें कि वे ऑप्टिमाइज़ किए गए हैं. यह भी हो सकता है कि टैग अब भी इस्तेमाल किए जा रहे हों. इस्तेमाल न किए गए कोड वाले पुराने टैग हटाए जा सकते हैं. इससे आपके टैग मैनेजर के JavaScript को छोटा और बेहतर तरीके से काम करने में मदद मिलती है.
रेंडरिंग को बड़े साइज़ में अपडेट करने से बचना
JavaScript ही सिर्फ़ ऐसी चीज़ नहीं है जो आपकी वेबसाइट के रिस्पॉन्सिव होने पर असर डाल सकती है. रेंडरिंग करना अपने आप में काफ़ी महंगा काम हो सकता है और जब रेंडरिंग के बड़े अपडेट हों, तो वे आपकी वेबसाइट के लिए उपयोगकर्ता के इनपुट का जवाब देने की क्षमता में रुकावट डाल सकते हैं.
रेंडरिंग के काम को ऑप्टिमाइज़ करना कोई आसान प्रोसेस नहीं है. यह अक्सर इस बात पर निर्भर करता है कि आपका लक्ष्य क्या है. इसके बावजूद, कुछ ऐसे तरीके हैं जिन्हें अपनाकर यह पक्का किया जा सकता है कि रेंडरिंग के अपडेट सही हों और लंबे टास्क में शामिल न हों:
- कोई भी ऐसा काम करने के लिए
requestAnimationFrame()का इस्तेमाल न करें जो विज़ुअल से जुड़ा न हो. इवेंट लूप को रेंडर करने के दौरान,requestAnimationFrame()कॉल मैनेज किए जाते हैं. वहीं, इस चरण के दौरान बहुत ज़्यादा काम पूरा होने पर, रेंडरिंग अपडेट में देरी हो सकती है. यह ज़रूरी है किrequestAnimationFrame()की मदद से किया जा रहा कोई भी काम, सिर्फ़ उन टास्क के लिए रिज़र्व किया गया हो जिनमें रेंडरिंग अपडेट शामिल हैं. - अपने डीओएम का साइज़ छोटा रखें. डीओएम का साइज़ और लेआउट के काम की इंटेंसिटी एक-दूसरे से जुड़ी होती है. जब रेंडरर को बहुत बड़े डीओएम के लिए लेआउट को अपडेट करना होता है, तो इसके लेआउट को फिर से कैलकुलेट करने के काम में काफ़ी बढ़ोतरी हो सकती है.
- सीएसएस कंटेनमेंट का इस्तेमाल करें. सीएसएस कंटेनमेंट, सीएसएस
containप्रॉपर्टी पर निर्भर करता है. इससे ब्राउज़र को यह निर्देश मिलता है किcontainप्रॉपर्टी को सेट किए गए कंटेनर के लिए, लेआउट काम कैसे करना है. इसमें लेआउट के स्कोप को अलग करना और डीओएम में किसी खास रूट को रेंडर करना भी शामिल है. यह प्रोसेस हमेशा आसान नहीं होती, लेकिन कॉम्प्लेक्स लेआउट वाले एरिया को अलग करके, लेआउट और रेंडरिंग से बचा जा सकता है. ऐसा करना ग़ैर-ज़रूरी है.
नतीजा
पेज की परफ़ॉर्मेंस को बेहतर बनाना बेहद मुश्किल काम लग सकता है. खास तौर पर, ऐसा इसलिए है, क्योंकि वेब पर कई तरह के निर्देश देने की ज़रूरत है. हालांकि, इन सुझावों पर ध्यान देकर, समस्या को हल किया जा सकता है और उसका मकसद तय किया जा सकता है. साथ ही, उम्मीद है कि आपकी वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी मिल जाए.
वेब की स्थिति का बारीकी से विश्लेषण करने के आधार पर, यहां दिए गए सुझाव पूरी तरह से शामिल नहीं हैं. हमारा मानना है कि ये सुझाव ऐसे सबसे असरदार तरीके हैं जिनकी मदद से, साइटें 2023 में अपनी वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी दे सकती हैं.
अगर आपको यहां दिए गए सुझावों के अलावा और भी जानकारी चाहिए, तो ज़्यादा जानकारी के लिए ये ऑप्टिमाइज़ेशन गाइड देखें:
- एलसीपी को ऑप्टिमाइज़ करना
- सीएलएस को ऑप्टिमाइज़ करें
- एफ़आईडी को ऑप्टिमाइज़ करना
- आईएनपी को ऑप्टिमाइज़ करना
नए साल पर और सभी के लिए तेज़ वेब की शुभकामनाएं! अपनी साइटों को उपयोगकर्ताओं के लिए उन सभी तरीकों से तेज़ बनाएं जो उनके लिए सबसे ज़्यादा ज़रूरी हों.
फ़ोटो: डेविन एवरी की ओर से