ऑटोमेशन, कंप्रेस करने और कोड में बदलने का तरीका

बेहतर परफ़ॉर्म करने वाले इमेज सोर्स जनरेट करना, अपनी डेवलपमेंट प्रोसेस का आसान हिस्सा बनाएं.

इस कोर्स के सभी सिंटैक्स—इमेज डेटा को कोड में बदलने से लेकर रिस्पॉन्सिव इमेज को चलाने वाले जानकारी-सघन मार्कअप तक—मशीन के साथ इंटरैक्ट करने के तरीके हैं. आपने क्लाइंट ब्राउज़र के लिए कई तरीकों की खोज की है. इसकी मदद से, सर्वर अपनी ज़रूरतों के बारे में सर्वर को बता सकता है. साथ ही, सर्वर भी उसी तरह का जवाब दे सकता है. रिस्पॉन्सिव इमेज मार्कअप (खास तौर पर, srcset और sizes) बहुत कम वर्णों में बहुत ज़्यादा जानकारी देते हैं. बेहतर या खराब के लिए, डिज़ाइन के हिसाब से यह कम शब्दों में सटीक जानकारी है: इन सिंटैक्स को कम छोटा और पार्स करना इतना आसान बनाने से, ब्राउज़र के लिए इन्हें पार्स करना और भी मुश्किल हो सकता है. किसी स्ट्रिंग में जितनी जटिलता जोड़ी जाती है, पार्सर की गड़बड़ियों की संभावना उतनी ही ज़्यादा होती है या एक ब्राउज़र से दूसरे ब्राउज़र के व्यवहार में अनजाने में अंतर होता है.

हालांकि, इन विषयों को परेशान करने वाली चीज़ों की वजह से आपको समस्या का हल भी मिल सकता है: मशीन से आसानी से पढ़ने वाला सिंटैक्स, ज़्यादा आसानी से लिखा जाता है. वेब के उपयोगकर्ता के तौर पर, आपने करीब-करीब ऑटोमैटिक इमेज एन्कोडिंग और कंप्रेस करने के कई उदाहरणों का सामना किया होगा: सोशल मीडिया प्लैटफ़ॉर्म, कॉन्टेंट मैनेजमेंट सिस्टम (सीएमएस) से वेब पर अपलोड की गई कोई भी इमेज, यहां तक कि ईमेल क्लाइंट भी ऐसे सिस्टम से होकर गुज़रेंगे जो उनका साइज़ बदलता है, उन्हें फिर से कोड में बदलता है, और उन्हें कंप्रेस करता है.

इसी तरह, चाहे प्लगिन, बाहरी लाइब्रेरी, स्टैंडअलोन बिल्ड प्रोसेस टूल हों या क्लाइंट-साइड स्क्रिप्टिंग का ज़िम्मेदारी से इस्तेमाल किया जाए, रिस्पॉन्सिव इमेज मार्कअप खुद को ऑटोमेशन में आसानी से शामिल कर लेता है.

इमेज की परफ़ॉर्मेंस के ऑटोमेशन से जुड़ी दो मुख्य समस्याएं हैं: इमेज बनाने को मैनेज करना—उनकी एन्कोडिंग, कंप्रेस करना, और srcset एट्रिब्यूट को पॉप्युलेट करने के लिए इस्तेमाल किए जाने वाले वैकल्पिक सोर्स—और उपयोगकर्ताओं को दिखने वाला मार्कअप जनरेट करना. इस मॉड्यूल में, आप एक मॉडर्न वर्कफ़्लो के हिस्से के तौर पर, इमेज मैनेज करने के कुछ सामान्य तरीकों के बारे में जानेंगे. चाहे वे आपकी डेवलपमेंट प्रोसेस के अपने-आप काम करने वाले चरण के तौर पर हों, आपकी साइट को चलाने वाले फ़्रेमवर्क या कॉन्टेंट मैनेजमेंट सिस्टम के ज़रिए या किसी खास कॉन्टेंट डिलीवरी नेटवर्क की मदद से इन्हें पूरी तरह से हटाया गया हो.

स्वचालित संपीड़न और एन्कोडिंग

ऐसा हो सकता है कि आप ऐसी स्थिति में न हों जहां प्रोजेक्ट के लिए इस्तेमाल की जाने वाली हर इमेज के लिए, मैन्युअल तरीके से कोड में बदलने का सही तरीका और कंप्रेस करने का लेवल तय करने में ज़्यादा समय लगे और न ही आपको ऐसा करना चाहिए. इमेज ट्रांसफ़र करने का साइज़ जितना हो सके उतना छोटा रखना जितना ज़रूरी है, अपनी कंप्रेशन सेटिंग को बेहतर बनाने और प्रोडक्शन वेबसाइट के लिए तैयार हर इमेज एसेट के लिए वैकल्पिक सोर्स को फिर से सेव करने से, आपके रोज़मर्रा के काम में बहुत मुश्किल आ सकती है.

जैसा कि आपने जाना है कि अलग-अलग इमेज फ़ॉर्मैट और कंप्रेशन टाइप के बारे में पढ़ते समय, किसी इमेज को कोड में बदलने का सबसे अच्छा तरीका हमेशा उसकी सामग्री के हिसाब से तय होगा. जैसा कि आपने रिस्पॉन्सिव इमेज में जाना है, आपको अपने इमेज सोर्स के लिए अलग-अलग साइज़ की ज़रूरत होगी. आधुनिक वर्कफ़्लो में, इमेज के लिए सही डिफ़ॉल्ट का एक सेट तय करने के बजाय, आपको अलग-अलग तरीकों से इन फ़ैसलों पर काम करना होगा. इससे आपको इमेज के इस्तेमाल के हिसाब से सही और बेहतर तरीके से काम करने में मदद मिलेगी.

फ़ोटोग्राफ़िक इमेज की डायरेक्ट्री के लिए, एन्कोडिंग चुनते समय, क्वालिटी और ट्रांसफ़र साइज़ के मामले में AVIF सबसे अच्छा काम करता है. हालांकि, इस पर सीमित तौर पर काम करता है. WebP में ऑप्टिमाइज़ किया गया और मॉडर्न फ़ॉलबैक उपलब्ध है. साथ ही, JPEG सबसे भरोसेमंद डिफ़ॉल्ट है. पेज लेआउट में साइडबार को शामिल करने के लिए बनाई गई इमेज के लिए, हमें जो वैकल्पिक साइज़ बनाने होंगे वे उन इमेज से काफ़ी अलग होंगे जो हमारे सबसे ज़्यादा ब्रेकपॉइंट पर पूरे ब्राउज़र के व्यूपोर्ट को शामिल करने के लिए बनी होती हैं. कंप्रेशन सेटिंग के लिए, नतीजे देने वाली कई फ़ाइलों में से धुंधला करने और कंप्रेस करने वाले आर्टफ़ैक्ट पर ध्यान देना ज़रूरी होगा. इससे हर इमेज से हर संभावित बाइट को बनाने के लिए कम जगह मिलेगी. साथ ही, ज़्यादा लचीला और भरोसेमंद वर्कफ़्लो मिलेगा. कुल मिलाकर, इस कोर्स से आपको फ़ैसला लेने की उसी प्रोसेस का पालन करना होगा जिसे आपने समझ लिया है.

जहां तक प्रोसेसिंग की बात है, वहां बड़ी संख्या में ओपन सोर्स इमेज प्रोसेसिंग लाइब्रेरी मौजूद हैं जो इमेज को बैच में बदलने, उनमें बदलाव करने, और उनमें बदलाव करने के तरीके देती हैं. इनकी मदद से स्पीड, परफ़ॉर्मेंस, और विश्वसनीयता को लेकर प्रतिस्पर्धा की जाती है. ये प्रोसेसिंग लाइब्रेरी आपको इमेज की पूरी डायरेक्ट्री पर एन्कोडिंग और कंप्रेस करने की सेटिंग एक ही बार में लागू करने देंगी. आपको इमेज एडिटिंग सॉफ़्टवेयर खोलने की ज़रूरत नहीं होगी. साथ ही, इनसे आपके मूल इमेज सोर्स को सुरक्षित रखने में भी मदद मिलेगी. इन्हें आपके लोकल डेवलपमेंट एनवायरमेंट से लेकर वेब सर्वर तक, अलग-अलग तरह के कॉन्टेक्स्ट के लिए इस्तेमाल किया जाता है. उदाहरण के लिए, Node.js के लिए कंप्रेशन पर फ़ोकस करने वाले ImageMin को प्लगिन की मदद से खास ऐप्लिकेशन के मुताबिक बनाया जा सकता है. वहीं, क्रॉस-प्लैटफ़ॉर्म ImageMagick और Sharp पर आधारित Node.js में, ये सुविधाएं काफ़ी बड़ी हैं.

इन इमेज प्रोसेसिंग लाइब्रेरी की मदद से डेवलपर, ऐसे टूल बना सकते हैं जो आपके स्टैंडर्ड डेवलपमेंट प्रोसेस के तहत, इमेज को आसानी से ऑप्टिमाइज़ करने के लिए काम करते हैं. इससे यह पक्का होता है कि आपका प्रोजेक्ट हमेशा प्रोडक्शन के लिए तैयार इमेज सोर्स का इस्तेमाल करता रहेगा.

लोकल डेवलपमेंट टूल और वर्कफ़्लो

ग्रंट, Gulp या Webpack जैसे टास्क चलाने वाले और बंडलर का इस्तेमाल, इमेज एसेट को ऑप्टिमाइज़ करने के साथ-साथ परफ़ॉर्मेंस से जुड़े दूसरे सामान्य कामों के साथ-साथ सीएसएस और JavaScript को छोटा करने जैसे कामों के लिए भी किया जा सकता है. इसे समझने के लिए, हम इस्तेमाल के एक आसान उदाहरण की बात करते हैं: आपके प्रोजेक्ट की एक डायरेक्ट्री में एक दर्जन फ़ोटोग्राफ़िक इमेज होती हैं. इसे किसी सार्वजनिक वेबसाइट पर इस्तेमाल किया जाता है.

सबसे पहले, आपको यह पक्का करना होगा कि इन इमेज को कोड में बदलने का तरीका एक जैसा और कारगर हो. जैसा कि आपने पिछले मॉड्यूल में जाना है, WebP फ़ॉर्मैट, फ़ोटोग्राफ़िक इमेज के लिए एक बेहतर डिफ़ॉल्ट विकल्प है. WebP, क्वालिटी और फ़ाइल साइज़, दोनों के मामलों में बेहतर होता है. WebP अच्छी तरह काम करता है, लेकिन दुनिया भर में काम नहीं करता. इसलिए, आपको प्रोग्रेसिव JPEG के रूप में, फ़ॉलबैक शामिल करना होगा. इसके बाद, इन एसेट की बेहतर डिलीवरी के लिए srcset एट्रिब्यूट का इस्तेमाल करने के लिए, आपको हर एन्कोडिंग के लिए कई वैकल्पिक साइज़ बनाने होंगे.

अगर इमेज एडिटिंग सॉफ़्टवेयर का इस्तेमाल करके यह काम बार-बार किया जाता है, तो इसमें बहुत समय लगता है. हालांकि, Gulp जैसे टास्क रनर को, इस तरह के दोहराव को ऑटोमेट करने के लिए डिज़ाइन किया गया है. gulp-responsive प्लगिन, शार्प का इस्तेमाल करता है. यह एक जैसे पैटर्न का इस्तेमाल करने वाले कई विकल्पों में से एक है: सोर्स डायरेक्ट्री में सभी फ़ाइलों को इकट्ठा करना, उन्हें फिर से कोड में बदलना, और इमेज फ़ॉर्मैट और कंप्रेशन में बताए गए उसी स्टैंडर्ड "क्वालिटी" के आधार पर उन्हें कंप्रेस करना. इसके बाद, मिलने वाली फ़ाइलें आपके तय किए गए पाथ पर आउटपुट के तौर पर बनती हैं. ये फ़ाइलें, उपयोगकर्ता को दिखने वाले आपके img एलिमेंट के src एट्रिब्यूट में रेफ़रंस के लिए तैयार रहती हैं. इससे, आपकी मूल फ़ाइलों में कोई बदलाव नहीं होता.

const { src, dest } = require('gulp');
const respimg = require('gulp-responsive');

exports.webp = function() {
  return src('./src-img/*')
    .pipe(respimg({
      '*': [{
        quality: 70,
        format: ['webp', 'jpeg'],
        progressive: true
      }]
  }))
  .pipe(dest('./img/'));
}

इस तरह की प्रक्रिया को लागू करने से, प्रोडक्शन एनवायरमेंट को कोई नुकसान नहीं होगा. अगर प्रोजेक्ट में मौजूद किसी व्यक्ति ने गलती से, ओरिजनल इमेज सोर्स वाली डायरेक्ट्री में एक बहुत बड़े ट्रूकलर PNG के तौर पर एन्कोड की गई फ़ोटो जोड़ दी हो, तो ओरिजनल इमेज की एन्कोडिंग के बावजूद, यह टास्क एक असरदार WebP और भरोसेमंद प्रोग्रेसिव JPEG फ़ॉलबैक जनरेट करेगा. साथ ही, कंप्रेस करने के इस लेवल को कभी भी, कहीं भी आसानी से अडजस्ट किया जा सकता है. बेशक, यह प्रक्रिया यह भी पक्का करती है कि आपकी मूल इमेज फ़ाइलें, प्रोजेक्ट के डेवलपमेंट एनवायरमेंट में बनी रहेंगी. इसका मतलब है कि इन सेटिंग में किसी भी समय बदलाव किया जा सकता है. साथ ही, सिर्फ़ ऑटोमेटेड आउटपुट को ओवरराइट किया जा सकता है.

कई फ़ाइलों को आउटपुट करने के लिए, आपको कई कॉन्फ़िगरेशन ऑब्जेक्ट साथ में पास करना होता है—सिर्फ़ width कुंजी और पिक्सल में वैल्यू को छोड़कर:

const { src, dest } = require('gulp');
const respimg = require('gulp-responsive');

exports.default = function() {
  return src('./src-img/*')
    .pipe(respimg({
    '*': [{
            width: 1000,
            format: ['jpeg', 'webp'],
            progressive: true,
            rename: { suffix: '-1000' }
            },
            {
            width: 800,
            format: ['jpeg', 'webp'],
            progressive: true,
            rename: { suffix: '-800' }
            },
            {
            width: 400,
            format: ['jpeg', 'webp'],
            progressive: true,
            rename: { suffix: '-400' },
        }]
        })
    )
    .pipe(dest('./img/'));
}

ऊपर दिए गए उदाहरण के मामले में, मूल इमेज (monarch.png) का साइज़ 3.3 एमबी से ज़्यादा था. इस टास्क (मोनार्क-1000.jpeg) के ज़रिए जनरेट की गई सबसे बड़ी फ़ाइल करीब 150 केबी की है. सबसे छोटा मोनार्क-400.web सिर्फ़ 32 केबी का है.

[10:30:54] Starting 'default'...
[10:30:54] gulp-responsive: monarch.png -> monarch-400.jpeg
[10:30:54] gulp-responsive: monarch.png -> monarch-800.jpeg
[10:30:54] gulp-responsive: monarch.png -> monarch-1000.jpeg
[10:30:54] gulp-responsive: monarch.png -> monarch-400.webp
[10:30:54] gulp-responsive: monarch.png -> monarch-800.webp
[10:30:54] gulp-responsive: monarch.png -> monarch-1000.webp
[10:30:54] gulp-responsive: Created 6 images (matched 1 of 1 image)
[10:30:54] Finished 'default' after 374 ms

बेशक, आपको दिखने वाले कंप्रेस करने से जुड़े आर्टफ़ैक्ट के नतीजों की ध्यान से जांच करनी चाहिए या ज़्यादा बचत करने के लिए, कंप्रेस करना हो सकता है. इस टास्क से कोई नुकसान नहीं होता, इसलिए इन सेटिंग को आसानी से बदला जा सकता है.

सभी जानते हैं कि कुछ किलोबाइट के बदले, मैन्युअल माइक्रो-ऑप्टिमाइज़ेशन के ज़रिए मैन्युअल तरीके से ऑप्टिमाइज़ किया जा सकता है. इससे, आपको एक ऐसी प्रोसेस मिलती है जो न सिर्फ़ असरदार है, बल्कि ज़रूरत के हिसाब से काम करने वाली भी है. यह एक ऐसा टूल है जो बेहतरीन परफ़ॉर्मेंस वाली इमेज एसेट की आपकी जानकारी को बिना किसी मैन्युअल रुकावट के पूरे प्रोजेक्ट पर आसानी से लागू कर देता है.

रिस्पॉन्सिव इमेज मार्कअप इस्तेमाल करना

आम तौर पर, srcset एट्रिब्यूट को भरना आसान मैन्युअल प्रोसेस होगी. ऐसा इसलिए है, क्योंकि एट्रिब्यूट असल में सिर्फ़ उस कॉन्फ़िगरेशन के बारे में जानकारी इकट्ठा करता है जिसे आपने सोर्स जनरेट करते समय पहले ही कर दिया है. ऊपर दिए गए टास्क में, हमने फ़ाइल के नाम और चौड़ाई की जानकारी दी है, जिसे हमारा एट्रिब्यूट फ़ॉलो करेगा:

srcset="filename-1000.jpg 1000w, filename-800.jpg 800w, filename-400.jpg 400w"

याद रखें कि srcset एट्रिब्यूट का कॉन्टेंट जानकारी देने वाला हो, डॉक्टर के पर्चे के बिना नहीं. किसी srcset एट्रिब्यूट को ओवरलोड करने से कोई नुकसान नहीं होता, अगर हर सोर्स का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) एक जैसा हो. srcset एट्रिब्यूट में, सर्वर से जनरेट किए गए हर वैकल्पिक कट का यूआरआई और उसकी चौड़ाई शामिल हो सकती है. इस वजह से, कोई गैर-ज़रूरी अनुरोध नहीं होता. हम रेंडर की गई इमेज के लिए जितने ज़्यादा सोर्स उपलब्ध कराते हैं, ब्राउज़र उतनी ही बेहतर तरीके से अनुरोध तैयार कर पाएगा.

जैसा कि आपने रिस्पॉन्सिव इमेज में जाना, आपको WebP या JPEG फ़ॉलबैक पैटर्न को आसानी से हैंडल करने के लिए <picture> एलिमेंट का इस्तेमाल करना होगा. इस मामले में, srcset के कॉन्सर्ट में type एट्रिब्यूट का इस्तेमाल किया जाएगा.

<picture>
  <source type="image/webp" srcset="filename-1000.webp 1000w, filename-800.webp 800w, filename-400.webp 400w">
  <img srcset="filename-1000.jpg 1000w, filename-800.jpg 800w, filename-400.jpg 400w" sizes="…" alt="…">
</picture>

आपको पता चला कि WebP के साथ काम करने वाले ब्राउज़र, type एट्रिब्यूट के कॉन्टेंट की पहचान करेंगे. इसके बाद, वे <source> एलिमेंट के srcset एट्रिब्यूट को, इमेज के उम्मीदवारों की सूची के तौर पर चुनेंगे. जो ब्राउज़र image/webp की पहचान मान्य मीडिया टाइप के तौर पर नहीं करते, वे इस <source> को अनदेखा करेंगे. इसके बजाय, वे अंदरूनी <img> एलिमेंट के srcset एट्रिब्यूट का इस्तेमाल करेंगे.

ब्राउज़र पर काम करने के मामले में एक और बात ध्यान देने वाली बात है: जिन ब्राउज़र में कोई भी रिस्पॉन्सिव इमेज मार्कअप काम नहीं करता उन्हें इस्तेमाल करने से पहले भी फ़ॉलबैक की ज़रूरत होगी. ऐसा न करने पर, हमें खास तौर पर पुराने ब्राउज़िंग कॉन्टेक्स्ट में इमेज खराब होने का जोखिम हो सकता है. <picture>, <source>, और srcset को इन ब्राउज़र में अनदेखा किया जाता है. इसलिए, हमें <img> के src एट्रिब्यूट में डिफ़ॉल्ट सोर्स के बारे में बताना होगा.

किसी इमेज को नीचे की ओर स्केल करने पर दिखने में कोई रुकावट नहीं आती. साथ ही, JPEG एन्कोडिंग दुनिया भर में काम करती है. इसलिए, सबसे बड़ा JPEG चुनना बेहतर विकल्प है.

<picture>
  <source type="image/webp" srcset="filename-1000.webp 1000w, filename-800.webp 800w, filename-400.webp 400w">
  <img src="filename-1000.jpg" srcset="filename-1000.jpg 1000w, filename-800.jpg 800w, filename-400.jpg 400w" sizes="…" alt="…">
</picture>

sizes के साथ काम करना थोड़ा मुश्किल हो सकता है. जैसा कि आपने सीखा है, sizes ज़रूरी है कि आपका कॉन्टेंट उसी हिसाब से हो, जब तक आपको यह पता न चले कि इमेज को रेंडर किए गए लेआउट में जगह लेने के लिए, एट्रिब्यूट को पॉप्युलेट नहीं किया जा सकता. सबसे असरदार अनुरोधों के लिए, असली उपयोगकर्ता की ओर से अनुरोध करते समय हमारे मार्कअप में एक सटीक sizes एट्रिब्यूट होना ज़रूरी है. पेज लेआउट को कंट्रोल करने वाली स्टाइल का अनुरोध करते समय, यह ज़रूरी है. sizes को पूरी तरह शामिल न करने से न सिर्फ़ एचटीएमएल से जुड़ी शर्तों का उल्लंघन होता है, बल्कि डिफ़ॉल्ट रूप से sizes="100vw" के बराबर काम करता है. इससे ब्राउज़र को पता चलता है कि यह इमेज सिर्फ़ व्यूपोर्ट की मदद से सीमित होती है. इस वजह से, उम्मीदवारों के सबसे बड़े सोर्स चुने जा सकते हैं.

वेब डेवलपमेंट के किसी भी मुश्किल टास्क की तरह ही, sizes एट्रिब्यूट को मैन्युअल तौर पर लिखने की प्रोसेस को दूर करने के लिए, कई टूल बनाए गए हैं. respImageLint कोड का एक ज़रूरी स्निपेट है, जो आपके sizes एट्रिब्यूट की जांच करता है. इससे यह पता चलता है कि एट्रिब्यूट कितना सटीक है. साथ ही, इसमें सुधार के लिए सुझाव भी दिए जाते हैं. यह बुकमार्कलेट की तरह काम करता है. यह एक ऐसा टूल है जिसे ब्राउज़र में चलाया जाता है. साथ ही, यह पूरी तरह से रेंडर किए गए उस पेज पर ले जाता है जिसमें इमेज एलिमेंट शामिल होते हैं. ऐसे संदर्भ में जहां ब्राउज़र को पेज लेआउट की पूरी जानकारी होती है, उसे उस जगह के बारे में पिक्सल-परफ़ेक्ट जानकारी भी होगी जहां इमेज को हर संभावित व्यूपोर्ट साइज़ के हिसाब से लेआउट में शामिल किया जाना है.

अपने sizes एट्रिब्यूट को लिंटिंग करने का टूल काफ़ी काम का है, लेकिन एक टूल के तौर पर इसकी ज़्यादा वैल्यू है. इसकी मदद से, थोक में एट्रिब्यूट जनरेट किए जा सकते हैं. जैसा कि आपको पता है, srcset और sizes सिंटैक्स का मकसद, इमेज एसेट के अनुरोधों को आसानी से ऑप्टिमाइज़ करना है. हालांकि, इसे प्रोडक्शन में कभी इस्तेमाल नहीं किया जाना चाहिए, लेकिन लोकल डेवलपमेंट एनवायरमेंट में पेज के लेआउट पर काम करते समय, 100vw की डिफ़ॉल्ट sizes प्लेसहोल्डर वैल्यू का इस्तेमाल करना बिलकुल सही होता है. लेआउट स्टाइल तय हो जाने के बाद, respImageLint चलाने से आपको खास तौर पर तैयार किए गए sizes एट्रिब्यूट मिलेंगे. इन्हें कॉपी करके अपने मार्कअप में चिपकाया जा सकता है. ऐसा, हाथ से लिखे गए किसी भी लेवल की जानकारी से कहीं ज़्यादा होगा:

हालांकि, सर्वर-रेंडर किए गए मार्कअप से शुरू किए गए इमेज के अनुरोध, JavaScript के लिए क्लाइंट-साइड sizes एट्रिब्यूट को जनरेट करने में बहुत जल्दी होते हैं, अगर उन अनुरोधों को क्लाइंट-साइड पर शुरू किया गया, तो यही वजह लागू नहीं होती. उदाहरण के लिए, Lazysizes प्रोजेक्ट, आपको लेआउट बनने तक, इमेज के अनुरोधों को पूरी तरह से रोकने की सुविधा देता है. इसकी मदद से, JavaScript हमारे लिए sizes वैल्यू जनरेट कर पाता है. यह आपके लिए एक बड़ी सुविधा है और आपके उपयोगकर्ताओं को सबसे बेहतर अनुरोध करने की गारंटी दी जाती है. हालांकि, ध्यान रखें कि इस तरीके का मतलब, सर्वर के रेंडर किए गए मार्कअप और ब्राउज़र में बनाए गए स्पीड ऑप्टिमाइज़ेशन की विश्वसनीयता को खत्म करना है. साथ ही, इन अनुरोधों को पेज के रेंडर होने के बाद ही शुरू करने से, आपके एलसीपी स्कोर पर बहुत बुरा असर पड़ेगा.

बेशक, अगर आप React या Vue जैसे क्लाइंट-साइड रेंडरिंग फ़्रेमवर्क पर निर्भर हैं, तो यह ऐसा क़र्ज़ है जिस पर आप पहले से ही हैं—और ऐसे मामलों में, Lazysizes का इस्तेमाल करने का मतलब है कि अपने sizes एट्रिब्यूट को पूरी तरह से हटाया जा सकता है. बेहतर स्थिति: जैसा कि लेज़ी लोडिंग वाली इमेज पर sizes="auto" को सहमति और नेटिव इंप्लीमेंटेशन मिलते हैं, वैसे ही Lazysizes ब्राउज़र के उस नए स्टैंडर्ड बिहेवियर के लिए, असरदार तरीके से पॉलीफ़िल बन जाएगा.