इमेज और <iframe>
एलिमेंट, अक्सर अन्य तरह के संसाधनों के मुकाबले ज़्यादा बैंडविड्थ का इस्तेमाल करते हैं. <iframe>
एलिमेंट के मामले में, उनमें मौजूद पेजों को लोड करने और रेंडर करने में ज़्यादा प्रोसेसिंग समय लग सकता है.
इमेज को धीरे-धीरे लोड करने की सुविधा के मामले में, शुरुआती व्यूपोर्ट के बाहर मौजूद इमेज को लोड होने में देरी करने से, शुरुआती व्यूपोर्ट में मौजूद ज़्यादा ज़रूरी रिसॉर्स के लिए बैंडविड्थ के इस्तेमाल में कमी आ सकती है. इससे, कुछ मामलों में पेज के सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) को बेहतर बनाया जा सकता है. ऐसा तब होता है, जब नेटवर्क कनेक्शन खराब होते हैं. साथ ही, फिर से बांटा गया बैंडविड्थ, एलसीपी कैंडिडेट को तेज़ी से लोड और पेंट करने में मदद कर सकता है.
<iframe>
एलिमेंट के मामले में, पेज के रिस्पॉन्स में लगने वाले समय (आईएनपी) को स्टार्टअप के दौरान बेहतर किया जा सकता है. इसके लिए, एलिमेंट को लेज़ी लोड करें. ऐसा इसलिए है, क्योंकि <iframe>
एक अलग एचटीएमएल दस्तावेज़ है, जिसमें अपने सब-रिसॉर्स होते हैं.
<iframe>
एलिमेंट को अलग प्रोसेस में चलाया जा सकता है. हालांकि, यह आम बात है कि वे अन्य थ्रेड के साथ प्रोसेस शेयर करते हैं. इससे ऐसी स्थितियां बन सकती हैं जहां पेज, उपयोगकर्ता के इनपुट के लिए कम रिस्पॉन्सिव हो जाते हैं.
इसलिए, ऑफ़-स्क्रीन इमेज और <iframe>
एलिमेंट को लोड करने में देरी करना एक ऐसी तकनीक है जिसे आज़माना चाहिए. साथ ही, परफ़ॉर्मेंस के मामले में बेहतर नतीजे पाने के लिए, ज़्यादा मेहनत करने की ज़रूरत नहीं होती. इस मॉड्यूल में, पेज के शुरू होने के दौरान उपयोगकर्ता को बेहतर अनुभव देने के लिए, इन दो तरह के एलिमेंट को धीरे-धीरे लोड करने के बारे में बताया गया है.
loading
एट्रिब्यूट की मदद से, इमेज को लेज़ी लोड करना
<img>
एलिमेंट में loading
एट्रिब्यूट जोड़ा जा सकता है, ताकि ब्राउज़र को यह बताया जा सके कि उन्हें कैसे लोड किया जाना चाहिए:
"eager"
, ब्राउज़र को बताता है कि इमेज को तुरंत लोड किया जाना चाहिए, भले ही वह शुरुआती व्यूपोर्ट से बाहर हो. यहloading
एट्रिब्यूट के लिए भी डिफ़ॉल्ट वैल्यू है."lazy"
, किसी इमेज को तब तक लोड नहीं करता, जब तक वह दिखने वाले व्यूपोर्ट से तय दूरी के अंदर न हो. यह दूरी, ब्राउज़र के हिसाब से अलग-अलग होती है. हालांकि, इसे अक्सर इतना बड़ा सेट किया जाता है कि जब उपयोगकर्ता उस पर स्क्रोल करता है, तब तक इमेज लोड हो जाती है.
यह भी ध्यान देने वाली बात है कि अगर <picture>
एलिमेंट का इस्तेमाल किया जा रहा है, तो loading
एट्रिब्यूट को उसके चाइल्ड <img>
एलिमेंट पर लागू किया जाना चाहिए, न कि <picture>
एलिमेंट पर. ऐसा इसलिए होता है, क्योंकि <picture>
एलिमेंट एक कंटेनर होता है. इसमें अलग-अलग इमेज के लिए, <source>
एलिमेंट होते हैं. ब्राउज़र जिस इमेज को चुनता है उसे सीधे तौर पर उसके चाइल्ड <img>
एलिमेंट पर लागू किया जाता है.
शुरुआती व्यूपोर्ट में मौजूद इमेज को लेज़ी लोड न करें
आपको सिर्फ़ उन <img>
एलिमेंट में loading="lazy"
एट्रिब्यूट जोड़ना चाहिए जो शुरुआती व्यूपोर्ट के बाहर होते हैं. हालांकि, पेज रेंडर होने से पहले, व्यूपोर्ट में किसी एलिमेंट की सटीक स्थिति जानना मुश्किल हो सकता है. अलग-अलग व्यूपोर्ट साइज़, आसपेक्ट रेशियो, और डिवाइसों को ध्यान में रखना होगा.
उदाहरण के लिए, डेस्कटॉप व्यूपोर्ट, मोबाइल फ़ोन के व्यूपोर्ट से काफ़ी अलग हो सकता है. ऐसा इसलिए, क्योंकि डेस्कटॉप व्यूपोर्ट में वर्टिकल स्पेस ज़्यादा होता है. इस वजह से, शुरुआती व्यूपोर्ट में ऐसी इमेज फ़िट हो सकती हैं जो छोटे डिवाइस के शुरुआती व्यूपोर्ट में नहीं दिखतीं. पोर्ट्रेट ओरिएंटेशन में इस्तेमाल किए जाने वाले टैबलेट पर भी, वर्टिकल स्पेस काफ़ी होता है. यह स्पेस, शायद कुछ डेस्कटॉप डिवाइसों से भी ज़्यादा हो.
हालांकि, कुछ मामलों में यह साफ़ तौर पर पता चलता है कि आपको loading="lazy"
लागू करने से बचना चाहिए. उदाहरण के लिए, आपको हीरो इमेज या इमेज के इस्तेमाल के ऐसे अन्य मामलों में, <img>
एलिमेंट से loading="lazy"
एट्रिब्यूट को ज़रूर हटा देना चाहिए जहां <img>
एलिमेंट, किसी भी डिवाइस पर फ़ोल्ड के ऊपर या लेआउट के सबसे ऊपर दिख सकते हैं. ऐसी इमेज के लिए यह और भी ज़्यादा ज़रूरी है जो एलसीपी के लिए चुनी जा सकती हैं.
लेज़ी लोड की गई इमेज को ब्राउज़र के लेआउट पूरा होने का इंतज़ार करना पड़ता है, ताकि यह पता चल सके कि इमेज की फ़ाइनल पोज़िशन व्यूपोर्ट में है या नहीं. इसका मतलब है कि अगर दिखने वाले व्यूपोर्ट में किसी <img>
एलिमेंट में loading="lazy"
एट्रिब्यूट है, तो सभी सीएसएस डाउनलोड होने, पार्स होने, और पेज पर लागू होने के बाद ही इसका अनुरोध किया जाता है. इसके बजाय, रॉ मार्कअप में प्रीलोड स्कैनर से पता चलने के तुरंत बाद फ़ेच किया जाता है.
<img>
एलिमेंट पर मौजूद loading
एट्रिब्यूट, सभी मुख्य ब्राउज़र पर काम करता है. इसलिए, इमेज को लेज़ी लोड करने के लिए JavaScript का इस्तेमाल करने की ज़रूरत नहीं है. ऐसा इसलिए, क्योंकि ब्राउज़र में पहले से मौजूद सुविधाएं देने के लिए, पेज में अतिरिक्त JavaScript जोड़ने से, पेज की परफ़ॉर्मेंस के दूसरे पहलुओं पर असर पड़ता है. जैसे, INP.
इमेज की लेज़ी लोडिंग का डेमो
<iframe>
एलिमेंट को लेज़ी लोड करना
<iframe>
एलिमेंट को तब तक लेज़ी लोड करने पर, जब तक वे व्यूपोर्ट में न दिखें, तब तक अहम डेटा को सेव किया जा सकता है. साथ ही, टॉप-लेवल पेज को लोड करने के लिए ज़रूरी रिसॉर्स को लोड करने की प्रोसेस को बेहतर बनाया जा सकता है. इसके अलावा, <iframe>
एलिमेंट, मुख्य तौर पर किसी टॉप-लेवल दस्तावेज़ में लोड किए गए पूरे एचटीएमएल दस्तावेज़ होते हैं. इसलिए, इनमें काफ़ी सारे सब-रिसॉर्स शामिल हो सकते हैं. खास तौर पर, JavaScript. अगर उन फ़्रेम में मौजूद टास्क को प्रोसेस करने में काफ़ी समय लगता है, तो इससे पेज के INP पर काफ़ी असर पड़ सकता है.
<iframe>
एलिमेंट के लिए, तीसरे पक्ष के एम्बेड का इस्तेमाल आम तौर पर किया जाता है. उदाहरण के लिए, एम्बेड किए गए वीडियो प्लेयर या सोशल मीडिया पोस्ट में आम तौर पर <iframe>
एलिमेंट का इस्तेमाल किया जाता है. साथ ही, उन्हें अक्सर कई सब-रिसॉर्स की ज़रूरत होती है. इससे, टॉप-लेवल पेज के रिसॉर्स के लिए बैंडविड्थ की कमी भी हो सकती है. उदाहरण के लिए, YouTube वीडियो को लेज़ी लोड करने पर, पेज लोड होने के दौरान 500 कि॰ब॰ से ज़्यादा डेटा बचता है. वहीं, Facebook के 'पसंद करें' बटन वाले प्लग इन को लेज़ी लोड करने पर, 200 कि॰ब॰ से ज़्यादा डेटा बचता है. इसमें ज़्यादातर डेटा, JavaScript का होता है.
किसी भी तरह से, जब भी आपके पास किसी पेज पर फ़ोल्ड के नीचे <iframe>
हो, तो आपको इसे धीरे-धीरे लोड करने पर विचार करना चाहिए. ऐसा तब करें, जब इसे शुरुआत में लोड करना ज़रूरी न हो. ऐसा करने से, उपयोगकर्ता अनुभव को काफ़ी बेहतर बनाया जा सकता है.
<iframe>
एलिमेंट के लिए loading
एट्रिब्यूट
<iframe>
एलिमेंट पर loading
एट्रिब्यूट का इस्तेमाल, सभी मुख्य ब्राउज़र में किया जा सकता है. loading
एट्रिब्यूट की वैल्यू और उनके व्यवहार, loading
एट्रिब्यूट का इस्तेमाल करने वाले <img>
एलिमेंट के जैसे ही होते हैं:
"eager"
डिफ़ॉल्ट वैल्यू है. यह ब्राउज़र को<iframe>
एलिमेंट के एचटीएमएल और उसके सब-रिसॉर्स को तुरंत लोड करने के लिए कहता है."lazy"
,<iframe>
एलिमेंट के एचटीएमएल और उसके सब-रिसॉर्स को तब तक लोड नहीं करता, जब तक वह व्यूपोर्ट से तय की गई दूरी के अंदर न आ जाए.
iframe की लेज़ी लोडिंग का डेमो
किसी इमारत का बाहरी हिस्सा
पेज लोड होने के दौरान एम्बेड को तुरंत लोड करने के बजाय, उपयोगकर्ता के इंटरैक्शन के जवाब में, उसे मांग पर लोड किया जा सकता है. ऐसा करने के लिए, कोई इमेज या कोई दूसरा सही एचटीएमएल एलिमेंट तब तक दिखाएं, जब तक उपयोगकर्ता उससे इंटरैक्ट न कर ले. जब उपयोगकर्ता एलिमेंट से इंटरैक्ट करता है, तो उसे तीसरे पक्ष के एम्बेड से बदला जा सकता है. इस तकनीक को फ़ेसेड कहा जाता है.
फ़ेसेड का इस्तेमाल करने का एक आम उदाहरण, तीसरे पक्ष की सेवाओं से वीडियो को एम्बेड करना है. इसमें, वीडियो कॉन्टेंट के साथ-साथ, कई और सब-रिसॉर्स भी लोड किए जा सकते हैं. जैसे, JavaScript. ये सब-रिसॉर्स, आम तौर पर महंगे होते हैं. ऐसे में, वीडियो को चलाने से पहले उपयोगकर्ता को वीडियो एम्बेड के साथ इंटरैक्ट करना होगा. इसके लिए, उसे 'चलाएं' बटन पर क्लिक करना होगा. हालांकि, ऐसा तब ही करना होगा, जब वीडियो को अपने-आप चलने की ज़रूरत हो.
यह एक ऐसा मौका है जब एम्बेड किए गए वीडियो से मिलती-जुलती स्टैटिक इमेज दिखाई जा सकती है. इससे बैंडविड्थ की बचत होती है. जब उपयोगकर्ता इमेज पर क्लिक करता है, तो उसे असल <iframe>
एम्बेड से बदल दिया जाता है. इससे तीसरे पक्ष के <iframe>
एलिमेंट का एचटीएमएल और उसके सब-रिसॉर्स डाउनलोड होने लगते हैं.
पेज के शुरुआती लोड में सुधार के अलावा, इसकी एक और अहम खासियत यह है कि अगर उपयोगकर्ता कभी वीडियो नहीं चलाता है, तो उसे डिलीवर करने के लिए ज़रूरी रिसॉर्स कभी डाउनलोड नहीं किए जाते. यह एक अच्छा पैटर्न है, क्योंकि इससे यह पक्का होता है कि उपयोगकर्ता सिर्फ़ वही डाउनलोड करता है जो उसे वाकई चाहिए. साथ ही, उपयोगकर्ता की ज़रूरतों के बारे में गलत अनुमान लगाने से भी बचा जा सकता है.
फ़ेसेड तकनीक का इस्तेमाल करने का एक और बेहतरीन उदाहरण, चैट विजेट हैं. ज़्यादातर चैट विजेट, ज़्यादा JavaScript डाउनलोड करते हैं. इससे पेज लोड होने में ज़्यादा समय लग सकता है और उपयोगकर्ता के इनपुट का जवाब देने में पेज को ज़्यादा समय लग सकता है. किसी भी चीज़ को पहले से लोड करने पर, लोड होने के समय लागत आती है. हालांकि, चैट विजेट के मामले में, हर उपयोगकर्ता का यह मकसद नहीं होता कि वह उससे इंटरैक्ट करे.
दूसरी ओर, फ़साड की मदद से, तीसरे पक्ष के "चैट शुरू करें" बटन को नकली बटन से बदला जा सकता है. जब उपयोगकर्ता उससे सही तरीके से इंटरैक्ट करता है, जैसे कि उस पर कुछ समय के लिए कर्सर घुमाना या उस पर क्लिक करना, तो उपयोगकर्ता की ज़रूरत पड़ने पर, असल और काम का चैट विजेट स्लॉट में दिखने लगता है.
अपने फ़ेसेड बनाने का विकल्प ज़रूर है. हालांकि, तीसरे पक्ष के ज़्यादा लोकप्रिय प्लैटफ़ॉर्म के लिए, ओपन सोर्स के विकल्प उपलब्ध हैं. जैसे, YouTube वीडियो के लिए lite-youtube-embed
, Vimeo वीडियो के लिए lite-vimeo-embed
, और चैट विजेट के लिए React Live Chat loader.
JavaScript की लेज़ी लोडिंग लाइब्रेरी
अगर आपको <video>
एलिमेंट, <video>
एलिमेंट poster
इमेज,
सीएसएस background-image
प्रॉपर्टी से लोड की गई इमेज या काम न करने वाले अन्य एलिमेंट को धीरे-धीरे लोड करना है, तो ऐसा lazysizes या yall.js जैसे JavaScript पर आधारित धीरे-धीरे लोड करने वाले टूल की मदद से किया जा सकता है. ऐसा इसलिए, क्योंकि इस तरह के रिसॉर्स को धीरे-धीरे लोड करने की सुविधा, ब्राउज़र-लेवल की सुविधा नहीं है.
खास तौर पर, ऑडियो ट्रैक के बिना <video>
एलिमेंट को अपने-आप चलने और लूप करने की सुविधा, ऐनिमेटेड GIF का इस्तेमाल करने के मुकाबले ज़्यादा असरदार विकल्प है. अक्सर, यह सुविधा, वीडियो क्वालिटी के बराबर विज़ुअल क्वालिटी वाले वीडियो रिसॉर्स से कई गुना बड़ी हो सकती है. इसके बावजूद, ये वीडियो बैंडविड्थ के लिहाज़ से अब भी अहम हो सकते हैं. इसलिए, इन्हें धीरे-धीरे लोड करने की सुविधा, एक और ऑप्टिमाइज़ेशन है. इससे बैंडविड्थ के गलत इस्तेमाल को कम करने में काफ़ी मदद मिल सकती है.
इनमें से ज़्यादातर लाइब्रेरी, Intersection Observer API का इस्तेमाल करके काम करती हैं. साथ ही, अगर पेज का एचटीएमएल शुरुआती लोड के बाद बदलता है, तो Mutation Observer API का भी इस्तेमाल किया जाता है. इससे यह पता चलता है कि कोई एलिमेंट, उपयोगकर्ता के व्यूपोर्ट में कब आता है. अगर इमेज दिख रही है या व्यूपोर्ट के करीब आ रही है, तो JavaScript लाइब्रेरी, गैर-स्टैंडर्ड एट्रिब्यूट (आम तौर पर data-src
या मिलता-जुलता एट्रिब्यूट) को सही एट्रिब्यूट से बदल देती है. जैसे, src
.
मान लें कि आपके पास एक ऐसा वीडियो है जो ऐनिमेटेड GIF की जगह लेता है, लेकिन आपको JavaScript के समाधान की मदद से उसे धीरे-धीरे लोड करना है. यह yall.js की मदद से किया जा सकता है. इसके लिए, मार्कअप पैटर्न इस तरह का होना चाहिए:
<!-- The autoplay, loop, muted, and playsinline attributes are to
ensure the video can autoplay without user intervention. -->
<video class="lazy" autoplay loop muted playsinline width="320" height="480">
<source data-src="video.webm" type="video/webm">
<source data-src="video.mp4" type="video/mp4">
</video>
डिफ़ॉल्ट रूप से, yall.js उन सभी एलिमेंट को देखता है जो ज़रूरी शर्तें पूरी करते हैं और जिनकी क्लास "lazy"
है. जब पेज पर yall.js लोड और लागू हो जाता है, तब वीडियो तब तक लोड नहीं होता, जब तक उपयोगकर्ता उसे व्यूपोर्ट में स्क्रोल नहीं करता. इस दौरान, <video>
एलिमेंट के चाइल्ड <source>
एलिमेंट पर मौजूद data-src
एट्रिब्यूट को src
एट्रिब्यूट से बदल दिया जाता है. इससे वीडियो डाउनलोड करने का अनुरोध भेजा जाता है और वह अपने-आप चलने लगता है.
अपने ज्ञान को परखें
<img>
और <iframe>
, दोनों एलिमेंट के लिए loading
एट्रिब्यूट की डिफ़ॉल्ट वैल्यू क्या है?
"eager"
"lazy"
JavaScript पर आधारित, लेज़ी लोडिंग के समाधानों का इस्तेमाल कब करना चाहिए?
loading
एट्रिब्यूट काम नहीं करता. जैसे, ऐनिमेशन वाली इमेज को बदलने के लिए अपने-आप चलने वाले वीडियो या <video>
एलिमेंट की पोस्टर इमेज को लेज़ी लोड करने के लिए.
फ़ेसेड का इस्तेमाल कब किया जा सकता है?
अगला लेख: प्रीफ़ेच करना और प्रीरेंडरिंग
अब आपके पास इमेज और <iframe>
एलिमेंट को धीरे-धीरे लोड करने की सुविधा है. इससे, यह पक्का किया जा सकता है कि पेज तेज़ी से लोड हों और उपयोगकर्ताओं की ज़रूरतों को ध्यान में रखा जाए. हालांकि, कुछ मामलों में संसाधनों को पहले से लोड करना ज़रूरी हो सकता है. अगले मॉड्यूल में, पहले से लोड करने और पहले से रेंडर करने के बारे में जानें. साथ ही, यह भी जानें कि इन तकनीकों का ध्यान से इस्तेमाल करने पर, अगले पेजों को पहले से लोड करके, उन पर नेविगेट करने की स्पीड को काफ़ी तेज़ कैसे किया जा सकता है.