पेज पर 1920 पिक्सेल चौड़ी इमेज फ़ोन यूज़र भी पूरी डाउनलोड करते हैं, और फिर वह स्क्रीन पर 390 पिक्सेल में सिकोड़कर दिखाई जाती है — बेवजह पाँच गुना बैंडविड्थ और धीमा लोड। srcset ब्राउज़र को स्क्रीन के हिसाब से सही वर्शन चुनने देता है, बशर्ते आपने वे वर्शन बनाए हों।
एक इमेज काफ़ी क्यों नहीं है
Core Web Vitals में LCP का आँकड़ा अक्सर फ़ोल्ड के ऊपर वाली बड़ी इमेज से आता है। फ़ोन को 1920 चौड़ी, 400KB की फ़ाइल भेजें तो LCP मुश्किल से 2.5 सेकंड के भीतर आता है; उसी कनेक्शन पर 480 चौड़ा, 40KB का वर्शन एक दर्जा ज़्यादा तेज़ है। Google का पेज-एक्सपीरियंस सिग्नल यही आँकड़ा सीधे पढ़ता है।
उलटे, बड़े डेस्कटॉप पर 768 चौड़ी इमेज धुँधली दिखती है। इसलिए कई साइज़ चाहिए, जिन्हें ब्राउज़र खुद चुनता है।
व्यावहारिक ब्रेकपॉइंट टेबल
ब्रेकपॉइंट पेज पर इमेज की रेंडर होने वाली चौड़ाई के हिसाब से तय होते हैं, व्यूपोर्ट के हिसाब से नहीं। दो आम मामलों के लिए — फ़ुल-विड्थ बैनर और आर्टिकल की इमेज:
- फ़ुल-विड्थ इमेज (हीरो, बैनर): 480, 768, 1200, 1920। फ़ोन, टैबलेट, लैपटॉप, बड़ा डिस्प्ले।
- आर्टिकल की इमेज (कंटेंट कॉलम करीब 800 तक): 400, 800, 1200; 1200 वाला 1.5x–2x स्क्रीन को सँभालता है।
- थंबनेल और कार्ड (करीब 300 पर रेंडर): 300 और 600।
ज़्यादा स्टेप का मतलब बेहतर नहीं होता। हर स्टेप एक और एक्सपोर्ट और एक और फ़ाइल है जिसे सँभालना पड़े, और ब्राउज़र थोड़ी बेमेल चौड़ाई सहन कर लेते हैं, इसलिए स्टेप के बीच 1.5–2x का अंतर सबसे अच्छा रहता है। चार स्टेप दस में से नौ से ज़्यादा डिवाइस कॉम्बिनेशन को कवर करते हैं।
क्या 2x वर्शन चाहिए?
Retina और ज़्यादातर फ़ोन स्क्रीन 2x–3x डेंसिटी पर चलती हैं; 400 चौड़ी रेंडर होने वाली इमेज को वहाँ साफ़ दिखने के लिए 800 पिक्सेल चाहिए। टेबल के बड़े स्टेप पहले से छोटे वाले के 2x वर्शन का काम करते हैं — 768 वाला 390 चौड़े फ़ोन का 2x है, और 1200 वाला 600 चौड़े कॉलम का 2x।
तो अलग से “@2x” सेट बनाने की ज़रूरत नहीं। स्टेप के बीच मोटे तौर पर 2x का फ़ासला रखें, ब्राउज़र डेंसिटी देखकर ऊँचा वाला खुद उठा लेगा।
फ़ॉर्मेट: पहले WebP, फ़ॉलबैक में JPG
बराबर क्वालिटी पर WebP, JPG से 25–35 प्रतिशत छोटा होता है और हर आधुनिक ब्राउज़र उसे सपोर्ट करता है। हर साइज़ पर WebP एक्सपोर्ट करें और पुराने ब्राउज़र के लिए picture एलिमेंट से JPG फ़ॉलबैक रखें; अगर आपके ऑडियंस में 2020 से पहले के ब्राउज़र अब मायने नहीं रखते, तो अकेला WebP काफ़ी है।
AVIF और भी छोटा होता है, पर ब्राउज़र में उसका एन्कोडिंग बहुत धीमा है, जो बड़े बैच में खलता है। इन समझौतों की विस्तार से चर्चा AVIF बनाम WebP बनाम JPEG में है।
पूरा सेट बैच में एक्सपोर्ट करना
सोर्स इमेज बैच इमेज प्रोसेसिंग में डालें और हर स्टेप के लिए एक बार चलाएँ, हर बार चौड़ाई और सफ़िक्स बदलते हुए:
- Size: चौड़ाई 480, Allow upscaling बंद, आउटपुट WebP 80 प्रतिशत, सफ़िक्स -480।
- यही सेटिंग 768 पर सफ़िक्स -768 के साथ; फिर 1200; फिर 1920।
- JPG फ़ॉलबैक के लिए आउटपुट JPG करें, सफ़िक्स वही रखें, फिर चलाएँ।
हर रन में कुछ ही सेकंड लगते हैं और ZIP में पहले से hero-480.webp, hero-768.webp वगैरह मिल जाते हैं, जो सीधे images फ़ोल्डर में रखने लायक हैं। Allow upscaling बंद रखें, ताकि 1000 पिक्सेल की ओरिजिनल इमेज कभी 1920 तक खींची न जाए।
एक इमेज पर हर स्टेप का साइज़ फ़र्क देखना हो तो एक फ़ाइल पर इमेज रीसाइज़र आज़माएँ।
HTML कैसे लिखें
फ़ुल-विड्थ इमेज के लिए:
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">आर्टिकल की इमेज के लिए sizes में असली चौड़ाई रखें, जैसे sizes="(max-width: 840px) 100vw, 800px"। width और height हमेशा दें, ताकि ब्राउज़र जगह पहले से रिज़र्व कर ले और पेज उछले नहीं।
यह हो जाए, तो इमेज को तेज़ लोड कैसे करें की लेज़ी-लोडिंग और कंप्रेशन वाली सलाह जोड़ लें, और आपके परफ़ॉर्मेंस स्कोर में इमेज वाला हिस्सा लगभग पूरा भर जाएगा।