फ़िलहाल, ट्रांसफ़र का कुल साइज़ और हर पेज पर अनुरोधों की संख्या, दोनों के हिसाब से इमेज वेब की सबसे बड़ी ऐसेट हैं. मीडियन वाले वेबपेज का कुल ट्रांसफ़र साइज़, जून 2022 तक 2 एमबी है. इसमें से करीब-करीब आधे हिस्से में सिर्फ़ इमेज का इस्तेमाल किया गया है. यह कहना कोई बड़ी बात नहीं होगी कि इमेज के अनुरोधों को ऑप्टिमाइज़ करना, परफ़ॉर्मेंस को ऑप्टिमाइज़ करने का सबसे बड़ा तरीका हो सकता है.
बाद में, आपको यह पता चलेगा कि सभी इवेंट के लिए एक इमेज दिखाने की कोशिश करने से समस्याओं को हल करने के लिए रिस्पॉन्सिव इमेज कैसे विकसित हुई हैं. इस सेक्शन में, इमेज से जुड़ी मुख्य परफ़ॉर्मेंस मेट्रिक देखें. साथ ही, यह भी जानें कि इमेज को बेहतर कैसे बनाया जा सकता है.
इमेज के अनुरोध रोके जा रहे हैं
कुछ ऐसे तरीके जानें जिनसे यह पक्का किया जा सके कि इमेज से जुड़े अनुरोध छोटे और असरदार हों. फिर भी, इमेज के लिए सबसे तेज़ अनुरोध वही होगा जो कभी नहीं किया जाता. इसलिए, हम आपको सबसे पहले यह बताना चाहते हैं कि अपने उपयोगकर्ताओं को इमेज एसेट डिलीवर करने के तरीके में, आपके लिए सबसे असरदार बदलाव क्या है: loading="lazy" एट्रिब्यूट.
<img src="image.jpg" loading="lazy" alt="…">
यह एट्रिब्यूट पक्का करता है कि इमेज के लिए अनुरोध तब तक न किए जाएं, जब तक वे उपयोगकर्ता के व्यूपोर्ट के करीब न हो जाएं. अनुरोध तब तक न किए जाएं, जब तक कि वे उपयोगकर्ता के व्यूपोर्ट के करीब न हो जाएं. इस तरह के अनुरोध तब तक नहीं किए जाते, जब तक ब्राउज़र सबसे व्यस्त रहता है. इसके बाद, अनुरोध को ज़रूरी रेंडरिंग पाथ से हटा दिया जाता है.
आसान इस्तेमाल के मामले में, इस एट्रिब्यूट का इस्तेमाल करने से परफ़ॉर्मेंस पर काफ़ी सकारात्मक असर पड़ सकता है: ऐसी इमेज जो कभी भी उपयोगकर्ता के व्यूपोर्ट में नहीं आती उसका अनुरोध नहीं किया जाएगा. साथ ही, ऐसी इमेज के लिए ऐसी कोई भी बैंडविड्थ इस्तेमाल नहीं की जाएगी जो उपयोगकर्ता को कभी नहीं दिखेगी.
हालांकि, इसमें एक समस्या है: उन अनुरोधों को रोकने का मतलब है कि इमेज का अनुरोध करने के लिए, ब्राउज़र की बहुत ही ऑप्टिमाइज़ की गई प्रोसेस का फ़ायदा न उठाना. अगर loading="lazy" का इस्तेमाल लेआउट में सबसे ऊपर की ओर img एलिमेंट पर किया जाता है—और पेज के पहली बार लोड होने पर उपयोगकर्ता के व्यूपोर्ट में होने की संभावना ज़्यादा होती है, तो असली उपयोगकर्ता को ये इमेज धीमी लग सकती हैं.
प्राथमिकता पाएं
loading एट्रिब्यूट, वेब स्टैंडर्ड की एक बड़ी कोशिश का उदाहरण है. इसका मकसद, डेवलपर को यह तय करना है कि वेब ब्राउज़र, अनुरोधों को प्राथमिकता कैसे दें.
शायद आपको ब्राउज़र की प्राथमिकता फ़ेच करने के बुनियादी तरीकों के बारे में पता होगा:
उदाहरण के लिए, किसी दस्तावेज़ के <head> में बाहरी सीएसएस फ़ाइल का अनुरोध, रेंडर को ब्लॉक करने के लिए काफ़ी माना जाता है. वहीं, </body> के ठीक ऊपर की JavaScript फ़ाइल के लिए किए गए अनुरोध को रेंडर होने तक टाला जाएगा. अगर <img> पर loading एट्रिब्यूट की वैल्यू 'लेज़ी' है, तो संबंधित इमेज के अनुरोध को तब तक के लिए रोका जाएगा, जब तक ब्राउज़र यह तय नहीं कर लेता कि यह उपयोगकर्ता को दिखाया जाएगा. नहीं तो, इमेज की वही प्राथमिकता होगी जो
पेज पर मौजूद किसी भी दूसरी इमेज की है.
fetchpriority एट्रिब्यूट का मकसद,
डेवलपर को ऐसेट की प्राथमिकता पर पूरा कंट्रोल देना है. इससे, एक जैसे संसाधनों के मुकाबले, संसाधनों को 'ज़्यादा' और 'कम' प्राथमिकता के तौर पर फ़्लैग किया जा सकता है. fetchpriority के लिए इस्तेमाल के उदाहरण, loading एट्रिब्यूट जैसे होते हैं. हालांकि, ये ज़्यादा बड़े होते हैं. उदाहरण के लिए, किसी ऐसी इमेज पर fetchpriority="low" का इस्तेमाल किया जा सकता है जो उपयोगकर्ता के इंटरैक्शन के बाद ही दिखती है (चाहे वह इमेज उपयोगकर्ता के व्यूपोर्ट में आती हो या नहीं), ताकि पेज पर कहीं और दिखने वाली इमेज को प्राथमिकता दी जा सके. इसके अलावा, पेज के रेंडर होते ही, आपकी जानकारी वाले किसी इमेज को प्राथमिकता देने के लिए fetchpriority="high" का इस्तेमाल किया जा सकता है.
ध्यान दें कि fetchpriority, loading से अलग है, क्योंकि यह ब्राउज़र के व्यवहार को बुनियादी तौर पर नहीं बदलता. यह ब्राउज़र को कुछ ऐसेट को दूसरों से पहले लोड करने का निर्देश नहीं देता है, बल्कि ऐसेट के लिए अनुरोध करने से जुड़े फ़ैसलों की ज़रूरी जानकारी देता है.
इमेज के असर को मापना
इमेज एसेट को ऑप्टिमाइज़ करते समय, ट्रांसफ़र के कुल साइज़ के मुकाबले, अनुमानित परफ़ॉर्मेंस को मेज़र करना अक्सर ज़्यादा अहम होता है और इसे मेज़र करना ज़्यादा मुश्किल होता है.
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक, उपयोगकर्ताओं को वेब पर बेहतर अनुभव देने के लिए, मेज़र की जा सकने वाली मेट्रिक और दिशा-निर्देश देती है. इनमें वेब सर्वर से देर से जवाब मिलने, रेंडरिंग से जुड़ी समस्याएं, और बातचीत में देरी जैसी समस्याएं हाइलाइट होती हैं. वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी, इन लक्ष्यों का सबसेट है और उपयोगकर्ता के सीधे तौर पर किसी पेज के अनुभव पर फ़ोकस किया जाता है. यह तकनीकी मापों का एक सेट है, जो साथ मिलकर यह तय करता है कि किसी उपयोगकर्ता को अनुभव कितनी तेज़ी से मिलेगा.
कुल लेआउट शिफ़्ट
कुल लेआउट शिफ़्ट (सीएलएस) विज़ुअल स्टैबिलिटी का माप है. इस मेट्रिक से यह कैप्चर किया जाता है कि एसेट के लोड होने और पेज के रेंडर होने पर, पेज पर मौजूद कॉन्टेंट का लेआउट कितना बदल जाता है. वेब को इस्तेमाल करने में काफ़ी समय बिताने वाला कोई भी व्यक्ति, पेज पर "जंपिंग" करने से, बहुत समय तक टेक्स्ट में अपनी जगह खो देता है. ऐसा इसलिए होता है, क्योंकि एक देर से आने वाला वेबफ़ॉन्ट या इमेज का सोर्स अचानक रेंडर होता है या आपके पॉइंटर से कोई इंटरैक्टिव एलिमेंट अचानक हट जाता है. ज़्यादा सीएलएस से सबसे ज़्यादा परेशानी होती है और वह उपयोगकर्ता की गड़बड़ी की सबसे भी वजह है—"रद्द करें" बटन, जो उस जगह पर शिफ़्ट हो जाता है जहां पहले "पुष्टि करें" बटन मौजूद होता है, जैसा कि उपयोगकर्ता के क्लिक करने पर होता है.
इमेज लोड होने में ज़्यादा समय लगता है और वे लेआउट में ज़्यादा जगह ले सकते हैं. इसकी वजह यह है कि इमेज की एक आम वजह, ज़्यादा सीएलएस स्कोर होना है.
आधुनिक ब्राउज़र में हाल ही में हुए बदलावों की वजह से, इमेज की वजह से ज़्यादा सीएलएस स्कोर से बचना आसान है.
अगर आप कुछ सालों से फ़्रंटएंड पर काम कर रहे हैं, तो आपको <img> पर width और height एट्रिब्यूट के बारे में जानकारी होगी:
सीएसएस के बड़े पैमाने पर इस्तेमाल होने से पहले, इमेज के साइज़ को कंट्रोल करने के लिए सिर्फ़ यही एक तरीका था.
<img src="image.jpg" height="200" width="400" alt="…">
हमारी स्टाइल से जुड़ी समस्याओं को हमारे मार्कअप से अलग रखने की वजह से इन एट्रिब्यूट का इस्तेमाल कम हो गया. खास तौर पर, रिस्पॉन्सिव वेब डिज़ाइन की वजह से सीएसएस के ज़रिए प्रतिशत-आधारित साइज़ तय करना ज़रूरी हो गया था. रिस्पॉन्सिव वेब डिज़ाइन के शुरुआती दिनों में, "इस्तेमाल नहीं किए गए width और height एट्रिब्यूट हटाएं" एक आम सलाह थी. इसकी वजह यह थी कि हमारी सीएसएस, max-width: 100% और height: auto में बताई गई वैल्यू, उन्हें बदल देती थीं.
<img src="image.jpg" alt="…">
img {
max-width: 100%;
height: auto;
}
पिछले उदाहरण की तरह height और width एट्रिब्यूट हटाने के बाद, इस स्थिति में इमेज की ऊंचाई तय करने का सिर्फ़ एक तरीका ब्राउज़र के पास है. सोर्स का अनुरोध करना, उसे पार्स करना, और उसे उसके स्वाभाविक आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) में रेंडर करना है. इस प्रोसेस की ज़्यादातर प्रोसेस, पेज को रेंडर किए जाने के बाद होती है.
नई कैलकुलेट की गई ऊंचाई की वजह से, लेआउट में और भी बदलाव होते हैं.
2019 से, width और height एट्रिब्यूट को अलग-अलग तरीके से मैनेज करने के लिए, ब्राउज़र के काम करने के तरीके को अपडेट किया गया था. लेआउट में img एलिमेंट का तय और पिक्सल के मुताबिक साइज़ तय करने के लिए, इन एट्रिब्यूट की वैल्यू का इस्तेमाल करने के बजाय, इन एट्रिब्यूट को इमेज का आसपेक्ट रेशियो दिखाया जा सकता है. हालांकि, सिंटैक्स एक जैसा ही होता है. मॉडर्न ब्राउज़र, इन वैल्यू को एक-दूसरे से अलग करके, पेज के रेंडर होने से पहले img एलिमेंट का आसपेक्ट रेशियो तय करते हैं. इससे, लेआउट रेंडर होने के दौरान, इमेज के लिए तय की गई जगह को तय किया जा सकता है.
नियम के मुताबिक, आपको <img> पर हमेशा height और width एट्रिब्यूट इस्तेमाल करने चाहिए. साथ ही, उनकी वैल्यू आपके इमेज सोर्स के स्वाभाविक साइज़ से मैच करनी चाहिए, ताकि आप यह पक्का कर लें कि आपने एचटीएमएल एट्रिब्यूट की ऊंचाई को बदलने के लिए, max-width: 100% के साथ-साथ height: auto भी तय किया हो.
<img src="image.jpg" height="200" width="400" alt="…">
img {
max-width: 100%;
height: auto;
}
अपने <img> एलिमेंट पर width और height एट्रिब्यूट का इस्तेमाल करके, इमेज की वजह से ज़्यादा सीएलएस स्कोर से बचा जा सकता है.
ध्यान रखें कि इस तरीके में कोई कमी नहीं है, क्योंकि यह ब्राउज़र के लंबे समय से काम करने के तरीके पर निर्भर करता है. बेसिक सीएसएस के साथ काम करने वाला कोई भी ब्राउज़र, हमेशा की तरह ही काम करेगा. आपके मार्कअप में मौजूद height और width एट्रिब्यूट, आपकी स्टाइल से बदल जाते हैं.
हालांकि, width और height एट्रिब्यूट आपकी इमेज के लिए ज़रूरी लेआउट स्पेस को रिज़र्व करके, सीएलएस से जुड़ी समस्याओं से बच सकते हैं. हालांकि, इमेज के ट्रांसफ़र और रेंडर होने का इंतज़ार करते समय, लोगों को खाली गैप या खराब क्वालिटी वाले प्लेसहोल्डर के साथ दिखाना भी सही नहीं है. धीमी गति से लोड होने वाली इमेज के मेज़र किए जा सकने वाले और दिखने वाले असर को कम करने के लिए, कई तरीके अपनाए जा सकते हैं. हालांकि, पूरी तरह रेंडर की गई इमेज को उपयोगकर्ता के सामने तेज़ी से पेश करने के लिए, उसका ट्रांसफ़र साइज़ कम किया जा सकता है.
सबसे बड़ा कॉन्टेंटफ़ुल पेंट
सबसे बड़ा कॉन्टेंटफ़ुल पेंट (एलसीपी) वह समय मापता है जो उपयोगकर्ता के व्यूपोर्ट में दिखने वाले सबसे बड़े “कॉन्टेंटफ़ुल” एलिमेंट को रेंडर करने में लगता है—वह कॉन्टेंट एलिमेंट जो दिखने वाले पेज का सबसे बड़ा प्रतिशत होता है. ऐसा लग सकता है कि यह पेज पर किसी बहुत ही खास मेट्रिक का हिस्सा है, लेकिन उपयोगकर्ता के नज़रिए से यह एलिमेंट उस पॉइंट के लिए एक प्रैक्टिकल प्रॉक्सी के रूप में काम करता है जहां पेज का ज़्यादातर हिस्सा रेंडर किया गया है. एलसीपी, परफ़ॉर्मेंस का एक अहम आकलन है.
DOMContentLoaded या window.onload इवेंट जैसी मेट्रिक यह तय करने में मददगार हो सकती हैं कि मौजूदा पेज को लोड करने की प्रोसेस तकनीकी रूप से कब पूरी हुई. हालांकि, यह ज़रूरी नहीं है कि वे उपयोगकर्ता के पेज के अनुभव से मेल खाएं. अगर किसी एलिमेंट को उपयोगकर्ता के व्यूपोर्ट से बाहर रेंडर किया जा रहा है, तो हो सकता है कि थोड़ी सी भी देरी को इनमें से किसी भी मेट्रिक में शामिल किया जाए. हालांकि, ऐसा हो सकता है कि कोई उपयोगकर्ता इसकी पहचान न कर पाए.
लंबे एलसीपी का मतलब है कि उपयोगकर्ता को पेज का पहला इंप्रेशन यानी कि मौजूदा व्यूपोर्ट के अंदर सबसे ज़रूरी कॉन्टेंट यह होता है कि पेज धीमा है या पूरा टूटा हुआ है.
एलसीपी के ज़रिए कैप्चर किए गए, उपयोगकर्ता के अनुभव का सीधा असर उपयोगकर्ता अनुभव पर पड़ता है. पिछले साल, Vodafone के किए गए प्रयोग से पता चला है कि एलसीपी में 31% की बढ़ोतरी होने से न सिर्फ़ 8% ज़्यादा बिक्री हुई—यह अपने-आप ही एक मज़बूत नतीजा था—बल्कि उनके उपयोगकर्ताओं की कुल संख्या में से, वेबसाइट पर आने वाले संभावित लोगों की संख्या में 15% सुधार हुआ. साथ ही, कार्ट पर जाने वाले उपयोगकर्ताओं की संख्या में 11% की बढ़ोतरी देखने को मिली ("कार्ट विज़िट करने वाले उपयोगकर्ताओं की संख्या").
70% से ज़्यादा वेबपेजों पर, शुरुआती व्यूपोर्ट में सबसे बड़े एलिमेंट में इमेज शामिल होती है. यह एलिमेंट अकेले <img> एलिमेंट या बैकग्राउंड इमेज वाला एलिमेंट होता है. दूसरे शब्दों में,
70% पेजों के एलसीपी स्कोर, इमेज की परफ़ॉर्मेंस पर आधारित होते हैं. इसकी वजह जानने में ज़्यादा मेहनत नहीं लगती: बड़ी, ध्यान खींचने वाली
इमेज और लोगो के "पेज के ऊपरी हिस्से" में दिखने की संभावना बहुत ज़्यादा होती है.
एलसीपी में देरी से बचने के लिए, ये कदम उठाए जा सकते हैं: सबसे पहले, "फ़ोल्ड के ऊपर" इमेज पर loading="lazy" का ज़िक्र न करें, क्योंकि पेज के रेंडर होने तक अनुरोध में देरी होने से आपके एलसीपी स्कोर पर बहुत खराब असर पड़ सकता है.
दूसरा, fetchpriority="high" का इस्तेमाल करने से ब्राउज़र को यह जानकारी मिल सकती है कि इस इमेज के ट्रांसफ़र को, पेज पर कहीं भी इमेज के ऊपर प्राथमिकता दी जानी चाहिए.
इन नियमों को ध्यान में रखते हुए, किसी पेज के एलसीपी स्कोर को बढ़ाने का सबसे ज़रूरी तरीका यह है कि इमेज को ट्रांसफ़र और रेंडर करने में लगने वाला समय कम किया जाए. ऐसा करने के लिए, आपको अपने इमेज सोर्स को जितना हो सके उतना छोटा और असरदार रखना होगा (बेशक, उनकी क्वालिटी से समझौता किए बिना). साथ ही, यह पक्का करना होगा कि उपयोगकर्ताओं को सिर्फ़ वही इमेज एसेट मिलें जो उनके ब्राउज़िंग कॉन्टेक्स्ट को बेहतर बनाने का सबसे ज़्यादा फ़ायदा देती हों.
नतीजा
इमेज एसेट, आपके उपयोगकर्ताओं के बैंडविड्थ को बहुत ज़्यादा खर्च करती हैं—जिस बैंडविड्थ को किसी पेज को रेंडर करने के लिए ज़रूरी हर दूसरी एसेट के ट्रांसफ़र होने से लिया जाता है. इमेज में आस-पास के पेज के लेआउट रेंडर होने के दौरान और उसके बाद, दोनों ही मामलों में अनुमानित परफ़ॉर्मेंस के लिहाज़ से अहम समस्याएं होती हैं. कम शब्दों में कहें: इमेज एसेट नुकसान पहुंचाती हैं.
हालांकि, "वेब पर कम इमेज होने पर, वेब पर बेहतर अनुभव मिलेगा" यह चुनौती भरा काम नहीं होगा. परफ़ॉर्मेंस के मामले में यह शर्त पूरी तरह से सही होगी. हालांकि, इससे उपयोगकर्ताओं को ज़बरदस्ती नाखुश करना पड़ेगा. इमेज, वेब का एक अहम हिस्सा हैं और सिर्फ़ परफ़ॉर्मेंस के लिए, आपको काम के कॉन्टेंट की क्वालिटी से समझौता नहीं करना चाहिए.
इस कोर्स के बाकी हिस्से में, आपको उन टेक्नोलॉजी के बारे में पता चलेगा जो हमारी इमेज एसेट और तकनीकों को बेहतर बनाती हैं. इनकी मदद से, परफ़ॉर्मेंस पर पड़ने वाले असर को कम किया जा सकता है और क्वालिटी पर समझौता किए बिना ऐसा किया जा सकता है.