WebP बनाम PNG बनाम JPG: वेबसाइट SEO के लिए कौन-सा फ़ॉर्मेट सबसे अच्छा है?

पहले सीधी बात

कोई भी सर्च इंजन किसी पेज को सिर्फ़ इसलिए बोनस नहीं देता कि वह WebP में सर्व हो रहा है। फ़ॉर्मेट रैंकिंग फ़ैक्टर नहीं है। मापा यह जाता है कि पेज खोलने वाले व्यक्ति के लिए पेज कितनी जल्दी काम का बनता है, और ज़्यादातर पेजों पर इन दो पलों के बीच सबसे भारी चीज़ इमेज ही होती हैं। फ़ॉर्मेट इसलिए मायने रखता है क्योंकि बाइट मायने रखते हैं, इसके अलावा कोई वजह नहीं।

यह लेख डिलीवरी के बारे में है: कौन-सा फ़ॉर्मेट सर्व करें, उसे कैसे सर्व करें, और किन बातों की चिंता छोड़ दें। अगर आपका असली सवाल यह है कि किस तरह की तस्वीर के लिए कौन-सा फ़ॉर्मेट ठीक रहता है, तो JPG, PNG और WebP की आसान गाइड सीधे उसी का जवाब देती है, और उसे यहाँ दोहराने का कोई मतलब नहीं।

इमेज आपके पेज के मेट्रिक्स पर कहाँ असर डालती है

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

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

WebP से आपको असल में क्या मिलता है

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

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

बिना कुछ तोड़े इसे कैसे सर्व करें

picture एलिमेंट इसी काम के लिए है। अपनी इमेज को इसके अंदर रखें, एक source एलिमेंट जोड़ें जिसका type image/webp हो और जो नए फ़ॉर्मेट वाली फ़ाइल की ओर इशारा करे, और अंदर फ़ॉलबैक के तौर पर एक सामान्य img टैग रहने दें, जिसके src में JPEG हो। जो ब्राउज़र WebP समझते हैं, वे पहला मेल खाने वाला विकल्प लेते हैं, जो नहीं समझते वे img पर आ जाते हैं, और दोनों ही हालात में इमेज ठीक से दिखती है। सर्च क्रॉलर भी वही नियम मानते हैं जो ब्राउज़र मानता है, इसलिए कुछ भी अनोखा कॉन्फ़िगर नहीं करना पड़ता।

जब आप यह मार्कअप बदल ही रहे हैं, तो तीन काम और कर लें। img पर width और height एट्रिब्यूट साफ़ तौर पर लिखें, ताकि फ़ाइल आने से पहले ही ब्राउज़र सही जगह रिज़र्व कर सके। एक srcset जोड़ें, ताकि फ़ोन डेस्कटॉप साइज़ की फ़ाइल डाउनलोड न करे। और एक असली alt एट्रिब्यूट लिखें, क्योंकि इमेज सर्च के नतीजों में इमेज दिख सकती है या नहीं, इस पर असल में यही असर डालता है।

PNG और JPG की जगह अब भी कहाँ है

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

जब आपको ऐसी फ़ाइल चाहिए जिसे दुनिया का हर क्लाइंट खोल सके, तो फ़ोटो के लिए JPEG अब भी सुरक्षित डिफ़ॉल्ट है, और picture एलिमेंट की फ़ॉलबैक वाली जगह के लिए भी यही सही है। जो नहीं करना चाहिए, वह है किसी फ़ोटो को PNG के रूप में सर्व करना। किसी पेज के ज़रूरत से कई मेगाबाइट भारी हो जाने की सबसे आम वजह यही है।

AVIF के बारे में एक बात

फ़ाइल साइज़ में AVIF आमतौर पर WebP से आगे रहता है, खासकर फ़ोटो वाले कंटेंट में। इसकी कीमत है धीमी एन्कोडिंग, और ऐसा सपोर्ट जो मौजूदा ब्राउज़र में अच्छा है, पर उतना व्यापक नहीं। अगर आपकी बिल्ड पाइपलाइन इसे बना सकती है, तो picture एलिमेंट में यह सबसे पहले आता है, उसके बाद WebP और आखिर में JPEG। इस साइट के कन्वर्टर AVIF आउटपुट नहीं करते, इसलिए यह काम यहाँ नहीं, आपके बिल्ड टूल्स में होना चाहिए।

फ़ॉर्मेट बदलने से क्या ठीक नहीं होगा

• 700 पिक्सेल के कॉलम में दिखाई जा रही 4000 पिक्सेल चौड़ी इमेज। WebP उसे छोटा कर देता है, फिर भी वह ज़रूरत से कहीं ज़्यादा बड़ी रहती है। पहले उसे रीसाइज़ करें, फिर कन्वर्ट करें।
• ऐसी हीरो इमेज जिसका डाउनलोड कई रेंडर-ब्लॉकिंग स्क्रिप्ट के खत्म होने के बाद ही शुरू होता है। जब रिक्वेस्ट ही अभी तक नहीं गई, तो फ़ॉर्मेट से कोई फ़र्क नहीं पड़ता।
• alt टेक्स्ट का न होना, IMG_4471 जैसा फ़ाइल नाम, या ऐसा पेज जिस पर काम की कोई बात लिखी ही न हो। इमेज सर्च इमेज के आसपास के पेज पर निर्भर करती है, उस कोडेक पर नहीं जिससे इमेज एन्कोड की गई थी।

अभी कुछ फ़ाइलें कन्वर्ट करनी हों तो

यहाँ के JPG से WebP और PNG से WebP कन्वर्टर इमेज की एक कतार लेते हैं और आपको एक ZIP लौटाते हैं, और एन्कोडिंग किसी और के सर्वर पर नहीं, आपके ब्राउज़र में होती है। अगर आप क्वालिटी और साइज़ के बीच का संतुलन खुद तय करना चाहें, तो यूनिवर्सल कन्वर्टर में एक क्वालिटी स्लाइडर भी है। ध्यान रखें कि नए सिरे से एन्कोड करने पर EXIF ब्लॉक हट जाता है, इसलिए WebP में कैमरे का वह डेटा नहीं रहता जो ओरिजिनल फ़ाइल में था।

फिर भी, जो साइट नियमित रूप से पब्लिश करती है, उसके लिए यह काम आपके बिल्ड स्टेप या CDN पर होना चाहिए। जो पाइपलाइन हर अपलोड के लिए कई चौड़ाइयाँ और फ़ॉर्मेट बनाती है, वह किसी भी मैनुअल तरीके से बेहतर रहेगी, क्योंकि व्यस्त हफ़्ते में भी वह छूटती नहीं। किसी खास पेज को ठीक कर रहे हों, तो हाथ से कन्वर्ट करें। पूरी साइट ठीक कर रहे हों, तो इसे ऑटोमेट करें।