सबसे तेज़ और सबसे अच्छी तरह से ऑप्टिमाइज़ किया गया संसाधन वह है जिसे नहीं भेजा गया है. आपको अपने ऐप्लिकेशन से ग़ैर-ज़रूरी संसाधन हटाने चाहिए. अपनी टीम के साथ, साफ़ तौर पर और चुपचाप की गई मान्यताओं पर सवाल पूछना और समय-समय पर उन पर फिर से विचार करना एक अच्छा तरीका है. यहां कुछ उदाहरण दिए गए हैं:
- आपने अपने पेजों पर हमेशा संसाधन X को शामिल किया है, लेकिन क्या इसे डाउनलोड और दिखाने की लागत, उपयोगकर्ता को मिलने वाली वैल्यू से मेल खाती है? क्या इसकी वैल्यू को मेज़र करके, उसकी पुष्टि की जा सकती है?
- क्या संसाधन (खास तौर पर, अगर यह तीसरे पक्ष का संसाधन है) लगातार अच्छी परफ़ॉर्मेंस देता है? क्या यह संसाधन क्रिटिकल पाथ में है या इसे वहां होना चाहिए? अगर रिसॉर्स क्रिटिकल पाथ में है, तो क्या यह साइट के लिए सिंगल पॉइंट ऑफ़ फ़ेल्योर हो सकता है? इसका मतलब है कि अगर रिसॉर्स उपलब्ध नहीं है, तो क्या इससे आपके पेजों की परफ़ॉर्मेंस और उपयोगकर्ता अनुभव पर असर पड़ता है?
- क्या इस संसाधन के लिए एसएलए की ज़रूरत है या उसके पास एसएलए है? क्या यह संसाधन, परफ़ॉर्मेंस के सबसे सही तरीकों का पालन करता है: कंप्रेस करने, कैश मेमोरी में सेव करने वगैरह?
अक्सर, पेजों में ऐसे संसाधन शामिल होते हैं जो ज़रूरी नहीं होते या इससे भी बुरा, पेज की परफ़ॉर्मेंस पर असर पड़ता है. इससे, पेज पर आने वाले लोगों या उस साइट को कोई फ़ायदा नहीं मिलता जिस पर पेज होस्ट किया गया है. यह फ़र्स्ट पार्टी और तीसरे पक्ष के संसाधनों और विजेट पर भी लागू होता है:
- साइट A ने अपने होम पेज पर फ़ोटो कैरसेल दिखाने का फ़ैसला किया है, ताकि वेबसाइट पर आने वाले लोग एक ही क्लिक में कई फ़ोटो की झलक देख सकें. पेज लोड होने के बाद, सभी फ़ोटो लोड हो जाती हैं और उपयोगकर्ता उन्हें देख सकता है.
- सवाल: क्या आपने यह मेज़र किया है कि कैरसेल में कितने उपयोगकर्ता एक से ज़्यादा फ़ोटो देखते हैं? हो सकता है कि आपने ऐसे संसाधन डाउनलोड किए हों जिन्हें ज़्यादातर विज़िटर कभी न देखें.
- साइट B ने मिलता-जुलता कॉन्टेंट दिखाने, सोशल मीडिया पर यूज़र ऐक्टिविटी बढ़ाने या कोई अन्य सेवा देने के लिए, तीसरे पक्ष का विजेट इंस्टॉल करने का फ़ैसला लिया है.
- सवाल: क्या आपने ट्रैक किया है कि कितने लोग विजेट का इस्तेमाल करते हैं या विजेट पर दिए गए कॉन्टेंट पर क्लिक करते हैं? क्या इस विजेट से मिलने वाली यूज़र ऐक्टिविटी, इसके खर्च के हिसाब से सही है? इसके अलावा, क्या आपके पास लोड करने की रणनीति का इस्तेमाल करने का विकल्प है, ताकि यह पक्का किया जा सके कि स्क्रिप्ट तब तक लोड न हो, जब तक उसकी ज़रूरत न हो?
यह तय करने के लिए कि अनचाहे डाउनलोड हटाने हैं या नहीं, अक्सर बहुत सावधानी से सोचने और मेज़रमेंट करने की ज़रूरत होती है. सबसे अच्छे नतीजे पाने के लिए, अपने पेजों पर मौजूद हर ऐसेट के लिए, समय-समय पर इन सवालों को इन्वेंट्री करें और फिर से देखें.
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी पर असर
Google ने वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली रिपोर्ट को लॉन्च किया था. इससे, मेट्रिक का एक सेट मिलता है. इससे पता चलता है कि वेब का इस्तेमाल करने पर, उपयोगकर्ताओं को कैसा अनुभव मिल रहा है. वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक को ऑप्टिमाइज़ करने के कई तरीके हैं. हालांकि, यह सवाल पूछने पर कि किसी पेज पर कोई खास रिसॉर्स लोड करना है या नहीं, आपको अपनी वेबसाइट पर इन मेट्रिक को बेहतर बनाने का रास्ता मिल सकता है. यहां कुछ उदाहरण दिए गए हैं. इन्हें हर वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी वाली मेट्रिक के हिसाब से ग्रुप किया गया है. इन पर ध्यान देने की ज़रूरत है. हालांकि, यह उदाहरणों की पूरी सूची नहीं है. इसमें और भी उदाहरण शामिल किए जा सकते हैं. इन उदाहरणों को पढ़कर, आपको कुछ अहम जानकारी मिल सकती है.
सबसे बड़ा कॉन्टेंटफ़ुल पेंट (एलसीपी)
सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) से पता चलता है कि सबसे बड़ा कॉन्टेंट (उदाहरण के लिए, हीरो इमेज या हेडलाइन) कब लोड हुआ. इसे उपयोगकर्ता के अनुभव से जुड़ी अहम मेट्रिक माना जाता है. इससे उपयोगकर्ता को यह अहसास होता है कि साइट तेज़ी से लोड हो रही है.
आम तौर पर, कम रिसॉर्स डाउनलोड करने का मतलब है कि उपयोगकर्ता के पास मौजूद बैंडविड्थ को कम रिसॉर्स के बीच बांटा जाएगा. इससे, एलसीपी में सुधार हो सकता है. लेज़ी लोडिंग का उदाहरण सबसे अच्छा है. इसमें पेज लोड होने के दौरान, व्यूपोर्ट से बाहर की इमेज तब तक डाउनलोड नहीं की जाएंगी, जब तक ब्राउज़र यह तय नहीं कर लेता कि उपयोगकर्ता उन्हें देख सकता है. अगर आपके पास 50 इमेज की बड़ी थंबनेल गैलरी है, तो उनमें से शीर्ष 10 को छोड़कर सभी को लेज़ी लोड करने का मतलब है कि ब्राउज़र, अपने पास मौजूद बैंडविड्थ का ज़्यादा बेहतर तरीके से इस्तेमाल कर सकता है. साथ ही, उपयोगकर्ता को दिखने वाली पहली इमेज ज़्यादा तेज़ी से लोड होंगी.
हालांकि, यह सिर्फ़ कम इमेज लोड करने के बारे में नहीं है. ब्राउज़र में प्राथमिकता तय करने की एक इंटरनल स्कीम होती है. इससे यह तय होता है कि हर रिसॉर्स को कितना बैंडविड्थ मिलना चाहिए. हालांकि, इसके बावजूद सभी संसाधनों, खास तौर पर ज़्यादा प्राथमिकता वाले संसाधनों की वजह से, संभावित एलसीपी एलिमेंट के डिपेंडेंट रिसॉर्स को ऐक्सेस करने में समस्या आ सकती है. यह बात खास तौर पर धीमे इंटरनेट कनेक्शन पर लागू होती है. यह निर्भर रिसॉर्स, पेज के एलसीपी एलिमेंट को दिखाने वाली इमेज फ़ाइल हो सकती है. हालांकि, यह वेब फ़ॉन्ट रिसॉर्स भी हो सकता है, जिसे ब्राउज़र को किसी टेक्स्ट नोड को रेंडर करने के लिए ज़रूरत होती है. इस टेक्स्ट नोड को पेज के एलसीपी एलिमेंट के तौर पर तय किया जा सकता है.
अगर आपकी वेबसाइट पर टेक्स्ट काफ़ी ज़्यादा है, तो हो सकता है कि पेज का एलसीपी एलिमेंट कोई टेक्स्ट नोड हो. फ़ॉन्ट को ऑप्टिमाइज़ करने और लोड करने की कई अच्छी रणनीतियां मौजूद हैं. हालांकि, यह देखना ज़रूरी है कि आपकी वेबसाइट की ज़रूरतों के लिए सिस्टम फ़ॉन्ट काफ़ी है या नहीं. इससे, टेक्स्ट नोड वाले एलसीपी एलिमेंट, वेब फ़ॉन्ट संसाधन पर निर्भर किए बिना लोड हो सकते हैं और सर्वर से सीएसएस और एचटीएमएल आने के तुरंत बाद पेंट हो सकते हैं.
कुल लेआउट शिफ़्ट (सीएलएस)
आपके लोड किए गए हर रिसॉर्स से, पेज के कुल लेआउट शिफ़्ट (सीएलएस) में योगदान मिल सकता है. ऐसा तब होता है, जब शुरुआती पेंट के समय तक रिसॉर्स डाउनलोड नहीं हो पाता. इमेज के लिए, सीएलएस से बचने के लिए, एक्सप्लिसिट डाइमेंशन सेट करने जैसे तरीकों का इस्तेमाल न करें. फ़ॉन्ट के लिए, फ़ॉन्ट लोड करने और फ़ॉलबैक फ़ॉन्ट मैचिंग को मैनेज करने से, वेब फ़ॉन्ट के स्वैप होने के दौरान होने वाले बदलावों को कम किया जा सकता है. JavaScript के लिए, यह मैनेज किया जा सकता है कि स्क्रिप्ट डीओएम में किस तरह बदलाव करती है, ताकि लेआउट में होने वाले बदलावों को कम किया जा सके.
पेज के सीएलएस में योगदान देने वाले हर रिसॉर्स के लिए, कुछ काम करना ज़रूरी है. इससे यह पक्का किया जा सकता है कि पेज का लेआउट पूरी तरह से स्थिर है. यह पूछकर कि आपको किसी खास रिसॉर्स की ज़रूरत है या नहीं, न सिर्फ़ पेज लोड होने में लगने वाला समय कम होता है, बल्कि लेआउट को स्थिर रखने के लिए ज़रूरी संज्ञानात्मक प्रयास भी कम हो जाता है. इससे, उपयोगकर्ताओं को बेहतर अनुभव मिलता है. साथ ही, डेवलपर को भी बेहतर अनुभव मिलता है, क्योंकि उनके पास अपने प्रोजेक्ट के अन्य लक्ष्यों को पूरा करने के लिए ज़्यादा समय होता है.
पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी)
पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी) मेट्रिक से, यह पता चलता है कि किसी पेज पर उपयोगकर्ता के इनपुट का जवाब देने में कितना समय लगता है. किसी पेज के INP पर, उस पर लोड होने वाले JavaScript का काफ़ी असर पड़ सकता है. इसकी वजह यह है कि वेब पर ज़्यादातर इंटरैक्शन, JavaScript की वजह से होता है. खास तौर पर, पेज लोड होने के दौरान डाउनलोड किए गए स्क्रिप्ट रिसॉर्स की संख्या, स्क्रिप्ट के आकलन और कंपाइलेशन से जुड़े संभावित तौर पर महंगे काम को शुरू कर सकती है. स्टार्टअप के दौरान जितना कम JavaScript लोड किया जाता है, पेज पर उपयोगकर्ताओं के इंटरैक्ट करने के दौरान ब्राउज़र को उतना ही कम काम करना पड़ता है.
स्टार्टअप के दौरान डाउनलोड किए गए JavaScript रिसॉर्स के साइज़ को कम करने के लिए, कोड को अलग-अलग करने और ट्री शेकिंग जैसी रणनीतियां अपनाई जा सकती हैं. हालांकि, अपने प्रोजेक्ट में इस्तेमाल किए जाने वाले पैकेज की ऑडिटिंग करना ज़रूरी है, ताकि यह पता चल सके कि वे ज़रूरी हैं या नहीं. उदाहरण के लिए, lodash में कई ऐसे तरीके हैं जो आज भी काम के हैं. हालांकि, इसमें वे तरीके भी शामिल हैं जो ब्राउज़र में पहले से मौजूद होते हैं. जैसे, मैपिंग, कम करने, और फ़िल्टर करने के लिए Array-खास फ़ंक्शन और अन्य कई फ़ंक्शन.
प्रोग्रेसिव बेहतर बनाने की सुविधा, JavaScript के लिए भी एक काम का तरीका है. इसकी मदद से, उपयोगकर्ताओं को बेसलाइन (लेकिन काम करने वाला) अनुभव दिया जा सकता है. साथ ही, ज़्यादा बेहतर डिवाइसों और तेज़ नेटवर्क कनेक्शन वाले उपयोगकर्ताओं के लिए, इस अनुभव को बेहतर बनाया जा सकता है. प्रगतिशील बेहतर बनाने के सिद्धांत का पालन किया जाए या नहीं, यह बात ज़रूरी है: हर उस JavaScript रिसॉर्स को डाउनलोड करने से बचा जा सकता है जिससे उपयोगकर्ता इंटरैक्शन पर तेज़ी से जवाब मिल सकता है. यह वेब की परफ़ॉर्मेंस का एक अहम पहलू है.
नतीजा
उपयोगकर्ताओं को तेज़ी से अनुभव देने के लिए, अपनी वेबसाइट को अनचाहे डाउनलोड के लिए ऑडिट करना एक तरीका हो सकता है. हालांकि, यह एक ऐसा तरीका है जिससे काफ़ी असर पड़ सकता है. ज़रूरी बातों पर फिर से एक नज़र:
- अपने पेजों पर अपनी और तीसरे पक्ष की ऐसेट की इन्वेंट्री बनाएं.
- हर ऐसेट की परफ़ॉर्मेंस का आकलन करें: उसकी वैल्यू और उसकी तकनीकी परफ़ॉर्मेंस.
- यह पता लगाएं कि रिसॉर्स ज़रूरत के हिसाब से काम के हैं या नहीं.
- Core Web Vitals और इससे जुड़ी मेट्रिक पर, ग़ैर-ज़रूरी डाउनलोड का असर समझें.
कॉन्टेंट को इस तरह ऑप्टिमाइज़ करने से, न सिर्फ़ परफ़ॉर्मेंस बेहतर होती है, बल्कि उपयोगकर्ताओं के बैंडविड्थ को भी बर्बाद होने से बचाया जा सकता है. साथ ही, उपयोगकर्ता-केंद्रित मेट्रिक को बेहतर बनाने और उपयोगकर्ता अनुभव को बेहतर बनाने में भी मदद मिलती है.