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