एक लाइन में कहें तो
WebP गूगल द्वारा बनाया गया एक मॉडर्न इमेज फॉर्मेट है जो वीडियो कम्प्रेशन (video compression) की ट्रिक्स का इस्तेमाल करके तस्वीरों को JPEG या PNG के मुकाबले काफी छोटे फाइल साइज में स्क्विश (squish) कर देता है, वो भी बिल्कुल वैसी ही विजुअल क्वालिटी बनाए रखते हुए।
ये क्या प्रॉब्लम सॉल्व करता है
काफी लंबे समय तक, इंटरनेट का विजुअल डिपार्टमेंट दो कट्टर दुश्मनों: JPEG और PNG के बीच एक नाजुक से समझौते पर चल रहा था। (GIF भी वहीं कोने में शोर मचा रहा था, पर उस पर हम बाद में आएंगे)।
अगर आपके पास लाखों कलर्स वाली कोई फोटो होती, तो आप JPEG यूज़ करते। JPEG lossy था, जिसका मतलब है कि ये स्पेस बचाने के लिए वो डेटा हटा देता था जो कथित तौर पर आपकी आँखों को नहीं दिखता। अगर आपके पास कोई लोगो, क्रिस्प टेक्स्ट होता, या ट्रांसपेरेंट बैकग्राउंड चाहिए होता, तो आप PNG यूज़ करते। PNG lossless था—ये हर एक पिक्सेल को परफेक्ट रखता था, लेकिन इस वजह से फाइल साइज भयानक रूप से भारी हो सकते थे। और अगर आपको एनिमेशन चाहिए? तो आप GIF यूज़ करते, जो 1987 का एक प्राचीन फॉर्मेट है, जो हद से ज्यादा inefficient था और सिर्फ 256 कलर्स तक लिमिटेड था।
प्रॉब्लम ये थी कि एक एवरेज वेबपेज के डाउनलोड होने वाले बाइट्स (bytes) में 60% से ज़्यादा हिस्सा इमेजेज का होने लगा था। जैसे-जैसे दुनिया ब्रॉडबैंड वाले डेस्कटॉप कंप्यूटर से हटकर अनस्टेबल 3G नेटवर्क वाले मोबाइल फोन्स पर शिफ्ट हुई, ये भारी-भरकम इमेज फॉर्मेट्स एक बहुत बड़ी मुसीबत बन गए। स्लो-लोडिंग इमेजेज का मतलब था फ्रस्ट्रेटेड यूज़र्स, खाली शॉपिंग कार्ट्स, और एक ऐसा वेब जो बिल्कुल रेंगता हुआ महसूस होता था।
2010 के आसपास, गूगल को लगा कि ये डुअल-फॉर्मेट सिस्टम बकवास है। उन्होंने हाल ही में On2 Technologies नाम की कंपनी खरीदी थी, जिसने VP8 नाम का एक वीडियो कम्प्रेशन फॉर्मेट बनाया था। गूगल के इंजीनियर्स को एक 'यूरेका' मोमेंट (eureka moment) आया: एक वीडियो आखिर तेजी से चलती हुई स्टिल इमेजेज (still images) की एक सीरीज ही तो है। क्या हो अगर वो अपने कटिंग-एज VP8 वीडियो कोडेक (codec) से "स्टिल इमेज" वाला हिस्सा निकाल लें और उसे एक स्टैंडअलोन इमेज फाइल की तरह पैकेज कर दें?
और ऐसे जन्म हुआ WebP का। इसका मिशन था "सबका बाप (one format to rule them all)" बनना। ये lossy compression सपोर्ट करता था जो JPEG को पछाड़ दे, lossless compression जो PNG को मात दे, ट्रांसपेरेंसी (alpha channels), और यहाँ तक कि एनिमेशन भी, ताकि GIF को हमेशा के लिए रिटायर किया जा सके।
Under the hood ये कैसे काम करता है
WebP इतना एफिशिएंट (efficient) क्यों है, ये समझने के लिए आपको देखना होगा कि ये चीटिंग कैसे करता है। ये असल में आपकी इमेज को पिक्सेल-बाय-पिक्सेल (pixel by pixel) स्टोर नहीं करता; बल्कि ये instructions स्टोर करता है कि मैथमेटिकली कैसे गेस (guess) किया जाए कि आपकी इमेज कैसी दिखती है।
Lossy Compression: Predictive Coding
जब WebP "lossy" मोड (JPEG का रिप्लेसमेंट) में काम करता है, तो ये predictive coding का इस्तेमाल करता है, जो सीधे VP8 वीडियो कोडेक से ली गई एक ट्रिक है।
WebP आपकी इमेज को "macroblocks" में बाँट देता है—जो 16x16 या 4x4 पिक्सेल्स के ग्रिड होते हैं। एक ब्लॉक के हर पिक्सेल का कलर अलग से सेव करने के बजाय, WebP एनकोडर (encoder) मौजूदा ब्लॉक के ठीक ऊपर और बाईं ओर (left) वाले ब्लॉक्स को देखता है। ये पूछता है: "मैंने जो पिक्सेल्स पहले ही ड्रॉ कर लिए हैं, क्या उनके बेस पर मैं प्रेडिक्ट (predict) कर सकता हूँ कि ये अगला ब्लॉक कैसा दिखेगा?"
चूँकि ज़्यादातर फोटोज़ में कलर के कंटीन्यूअस एरियाज़ होते हैं (जैसे नीला आसमान, स्मूद गाल, या कोई परछाई), इसलिए ये प्रेडिक्शन अक्सर बहुत सटीक होता है। इसके बाद WebP सिर्फ residual को सेव करता है—यानी इसके प्रेडिक्शन और असली इमेज के बीच का मैथमेटिकल अंतर (mathematical difference)।
पूरे पिक्सेल डेटा के बजाय सिर्फ इन छोटे डिफरेंसेज को सेव करके, WebP फाइल के साइज़ को ड्रैस्टिकली सिकोड़ देता है।
Lossless Compression: एक बिल्कुल अलग चीज़
Lossless WebP (PNG का रिप्लेसमेंट) VP8 का इस्तेमाल नहीं करता। यह गूगल द्वारा खास तौर पर WebP के लिए डिज़ाइन की गई बिल्कुल अलग तकनीकों का सेट यूज़ करता है। यह एक मल्टी-स्टेज अप्रोच (multi-stage approach) पर निर्भर करता है:
- Spatial Prediction: अपने lossy भाई की तरह, ये भी आस-पास के पिक्सेल्स के बेस पर पिक्सेल्स को प्रेडिक्ट करने की कोशिश करता है।
- Color Transform: ये redundancies (रिपीट हो रहे डेटा) को ढूँढने के लिए कलर डेटा को अलग करता है।
- Green is King: ये ग्रीन चैनल (green channel) को बेसलाइन मानता है, और ग्रीन वैल्यूज़ के आधार पर रेड और ब्लू वैल्यूज़ को प्रेडिक्ट करता है (क्योंकि इंसानी आँखें हरे रंग के प्रति सबसे ज़्यादा सेंसिटिव होती हैं)।
- LZ77 Compression: आखिर में, ये इस पूरे ऑप्टिमाइज़ किए गए डेटा को लेता है और उसे LZ77 डिक्शनरी-बेस्ड कम्प्रेशन एल्गोरिदम (LZ77 dictionary-based compression algorithm) के एक एडवांस्ड वर्ज़न से गुज़ारता है।
फाइल स्ट्रक्चर (RIFF)
इन सबके पीछे, WebP को RIFF (Resource Interchange File Format) नाम के एक लाइटवेट कंटेनर में रैप किया जाता है। RIFF एक टैग्ड फाइल स्ट्रक्चर है, जिसका मतलब है कि WebP फाइल चंक्स (chunks) में ऑर्गेनाइज़्ड होती है। इससे फॉर्मेट कोर इमेज को तोड़े बिना आसानी से मेटाडेटा (metadata) (जैसे आपके कैमरे का EXIF डेटा) या ICC कलर प्रोफाइल्स को जोड़ (append) सकता है।
| फीचर | JPEG | PNG | GIF | WebP |
|---|---|---|---|---|
| Lossy Compression | Yes | No | No | Yes |
| Lossless Compression | No | Yes | Yes | Yes |
| Transparency (Alpha) | No | Yes | 1-bit | Yes (Lossy और Lossless दोनों) |
| Animation | No | No | Yes | Yes |
| Average Saving | Baseline | Baseline | Baseline | ~25-34% छोटी |
असली दुनिया की कहानियाँ (Real-world stories)
ई-कॉमर्स का तूफ़ान (The E-commerce Avalanche)
एक मिड-साइज़ ऑनलाइन क्लोदिंग रिटेलर ने नोटिस किया कि मोबाइल डिवाइसेस पर उनका बाउंस रेट (bounce rate) बहुत ज़्यादा था। एक ऑडिट से पता चला कि उनके प्रोडक्ट कैटलॉग पेजेस लगभग 15 मेगाबाइट के हाई-रिज़ॉल्यूशन JPEGs डाउनलोड कर रहे थे। मोबाइल ब्राउज़र अपना सारा टाइम कार्डिगन्स की विशाल इमेजेज को पार्स (parse) करने में ही बिता रहा था।
इंजीनियरिंग टीम ने सपोर्टेड ब्राउज़र्स को WebP इमेजेज सर्व करने के लिए एक ऑटोमेटेड पाइपलाइन (automated pipeline) सेटअप की। Lossy compression को एडजस्ट करके, उन्होंने कपड़े के टेक्सचर दिखाने के लिए ज़रूरी विज़ुअल क्रिस्पनेस (crispness) तो बनाए रखी, लेकिन टोटल पेज पेलोड (payload) को घटाकर 3.5 मेगाबाइट कर दिया। पेज लोड टाइम 4 सेकंड कम हो गया। नतीजतन, मोबाइल कन्वर्ज़न रेट्स (conversion rates) में 18% का उछाल आया।
सबक: इमेज बाइट्स (bytes) का रेवेन्यू के साथ उल्टा कनेक्शन (inversely correlated) होता है। जब आप छोटी फाइल्स सर्व करते हैं, तो यूज़र्स इतनी देर तक टिकते हैं कि वो सच में कुछ खरीद सकें।
ट्रांसपेरेंट हीरो इमेज (The Transparent Hero Image)
एक वेब डिज़ाइनर ने एक नए SaaS प्रोडक्ट के लिए एक शानदार लैंडिंग पेज बनाया। हीरो सेक्शन में डायनामिक, CSS-ड्रिवेन ग्रेडिएंट बैकग्राउंड (gradient background) के ऊपर हवा में तैरते हुए सर्वर रैक (server rack) का एक पेचीदा 3D इलस्ट्रेशन था। इसे काम करने के लिए, सर्वर रैक इमेज का बैकग्राउंड ट्रांसपेरेंट होना ज़रूरी था।
डिज़ाइनर ने इसे अल्फा चैनल (alpha channel) के साथ PNG-24 के रूप में एक्सपोर्ट किया। 3D रेंडर की कॉम्प्लेक्स शेडिंग और लाखों कलर्स की वजह से, इस PNG का वज़न 2.2 मेगाबाइट हो गया। इसे लोड करना ऐसा लग रहा था जैसे हम 2004 के डायल-अप कनेक्शन में वापस चले गए हों।
डेवलपर ने उस PNG को लिया और WebP में कन्वर्ट कर दिया। उन्होंने WebP की एक खास सुपरपावर का इस्तेमाल किया: lossless Alpha चैनल के साथ lossy RGB। इसका मतलब था कि कलर्स को JPEG की तरह कंप्रेस किया गया था, लेकिन ट्रांसपेरेंसी बिना किसी फटे हुए किनारों (jagged edges) के पिक्सेल-परफेक्ट रही। रिज़ल्टिंग WebP फाइल 210 किलोबाइट की थी—यानी क्वालिटी में बिना किसी कमी के फाइल साइज़ में 90% की गिरावट।
सबक: अब आपको रिच, फोटोग्राफिक कलर्स और ट्रांसपेरेंट बैकग्राउंड के बीच किसी एक को चुनने की ज़रूरत नहीं है। WebP एक साथ दोनों को हैंडल कर सकता है।
मीम-हेवी ब्लॉग (The Meme-Heavy Blog)
एक पॉपुलर पॉप-कल्चर ब्लॉग मूवी क्लिप्स और रिएक्शन्स दिखाने के लिए एनिमेटेड GIFs पर काफी निर्भर था। एक आर्टिकल में पाँच GIFs हो सकते थे, जो 20 मेगाबाइट डेटा खींचते थे और पुराने लैपटॉप्स को जेट इंजन की तरह आवाज़ करने पर मजबूर कर देते थे क्योंकि CPU उस प्राचीन फॉर्मेट को डिकोड करने में हाँफने लगता था।
उन्होंने अपनी मीडिया लाइब्रेरी को एनिमेटेड WebP पर माइग्रेट (migrate) कर दिया। चूँकि GIFs हर एक फ्रेम को एक पूरी इमेज के रूप में स्टोर करते हैं, जबकि एनिमेटेड WebP सिर्फ फ्रेम्स के बीच के differences को स्टोर करने के लिए वीडियो-जैसे कम्प्रेशन का इस्तेमाल करता है, इसलिए होने वाली बचत जबरदस्त थी। 5MB का GIF 800KB के WebP में बदल गया। CPU का यूसेज (usage) एकदम से गिर गया।
सबक: GIF फॉर्मेट म्यूज़ियम में रखे जाने के लायक है। वेब पर छोटे, लूपिंग एनिमेशन्स (looping animations) के लिए, WebP (या असली MP4/WebM वीडियो) जैसे मॉडर्न फॉर्मेट्स कहीं ज़्यादा बेहतर हैं।
सामान्य गलतियाँ और ट्रैप्स (Common mistakes and traps)
- द डबल-लॉसी ट्रैप (The Double-Lossy Trap): एक बहुत ज़्यादा कंप्रेस्ड, आर्टिफैक्ट्स (artifacts) से भरे JPEG को lossy WebP में कन्वर्ट करना एक बहुत बुरा आईडिया है। WebP का एल्गोरिदम असल में उन भद्दे JPEG ब्लॉक्स को इमेज का ही हिस्सा मानकर परफेक्टली प्रिजर्व (preserve) करने की कोशिश करेगा, जिससे फाइल साइज़ बड़ा हो सकता है या इमेज और भी ब्लर (blur) हो सकती है। हमेशा जितना हो सके हाई-क्वालिटी सोर्स (जैसे RAW फाइल, हाई-रेज़ PNG, या ओरिजिनल अनकंप्रेस्ड JPEG) से कन्वर्ट करें।
- HTML
<picture>एलिमेंट को भूल जाना: हालाँकि आज WebP को लगभग ~97% ग्लोबल ब्राउज़र सपोर्ट मिलता है, लेकिन सालों तक ये सिर्फ गूगल की ही पार्टी थी। एप्पल के सफारी (Safari) ने 2020 के अंत तक WebP सपोर्ट देने में आनाकानी की थी। अगर आपको सच में प्राचीन ब्राउज़र्स को सपोर्ट करना है, तो आप बस<img>टैग में.webpनहीं चिपका सकते। फॉलबैक (fallback) देने के लिए आपको<picture>एलिमेंट का इस्तेमाल करना ही होगा:<picture> <source srcset="image.webp" type="image/webp"> <img src="image.jpg" alt="A reliable fallback"> </picture> - यह मान लेना कि WebP हमेशा सबसे छोटा होता है: WebP शानदार है, लेकिन ये कोई जादू नहीं है। बेहद सिंपल, फ्लैट-कलर वाले वेक्टर शेप्स (जैसे कोई मिनिमलिस्ट लोगो) के लिए, SVG हमेशा छोटा और इनफिनिटली स्केलेबल (infinitely scalable) होगा। इसी तरह, नए नेक्स्ट-जेनरेशन फॉर्मेट्स जैसे AVIF प्योर कम्प्रेशन रेशियो (compression ratios) में अक्सर WebP को हरा देते हैं, हालाँकि AVIF को एनकोड (encode) करने में बहुत ज़्यादा कंप्यूटिंग पावर लगती है।
- सर्वर पर एनकोडिंग टाइम को इग्नोर करना: WebP को कंप्रेस करने में JPEG के मुकाबले काफी ज़्यादा CPU पावर लगती है। अगर आप यूज़र की रिक्वेस्ट आने पर ऑन-द-फ्लाई (on-the-fly) WebP इमेजेज जनरेट कर रहे हैं, तो इमेज को एनकोड करने में लगने वाला CPU टाइम असल में इतना डिले (delay) पैदा कर सकता है कि बैंडविड्थ की सारी बचत ही बेकार हो जाए। WebP कन्वर्ज़न पहले से करके रखना चाहिए (बिल्ड प्रोसेस के दौरान या अपलोड करते समय), ना कि पहले रेंडर (first render) पर डायनामिकली।
ये आपके रडार पर क्यों होना चाहिए
अगर आप इंटरनेट के लिए चीज़ें बनाते हैं, तो वेब परफॉरमेंस अब कोई लग्ज़री नहीं है; ये एक बेसिक ज़रूरत (fundamental requirement) है। गूगल जैसे सर्च इंजन अपनी रैंकिंग में स्लो वेबसाइट्स को एक्टिवली पेनालाइज़ (penalize) करते हैं, और Core Web Vitals (खासकर Largest Contentful Paint, या LCP) नाम के मेट्रिक्स को बहुत तवज्जो देते हैं। क्योंकि स्क्रीन पर "largest content" आमतौर पर एक इमेज ही होती है, इसलिए उस इमेज को ऑप्टिमाइज़ करना अपने SEO को सुधारने का सबसे तेज़ तरीका है।
इसके अलावा, बैंडविड्थ (bandwidth) में पैसा लगता है—आपके लिए भी (AWS डेटा इग्रेस (egress) फीस बहुत ज़्यादा होती है) और विकासशील देशों (developing nations) में लिमिटेड डेटा प्लान वाले आपके यूज़र्स के लिए भी।
जब भी आप यूज़र-अपलोडेड अवतार (avatars), भारी-भरकम मार्केटिंग लैंडिंग पेजेस, फोटो गैलरीज़, या ई-कॉमर्स कैटलॉग्स के साथ डील कर रहे हों, तो WebP 2020s की डिफ़ॉल्ट और प्रैग्मैटिक (pragmatic) चॉइस है। ये ब्रॉड ब्राउज़र सपोर्ट, बेहतरीन विज़ुअल क्वालिटी, और ड्रैमेटिक फाइल साइज़ रिडक्शन का बेस्ट बैलेंस देता है।
और गहराई में जाएँ (Go deeper)
- Google Developers: An Image Format for the Web - इसके क्रिएटर्स (creators) की तरफ से सीधे WebP फॉर्मेट का ऑफिशियल और डीप टेक्निकल डॉक्यूमेंटेशन व रेफरेंस।
- MDN Web Docs: Image file type and format guide - मोज़िला (Mozilla) का बेहतरीन ब्रेकडाउन कि WebP को दूसरे वेब इमेज फॉर्मेट्स के मुकाबले कब इस्तेमाल करना चाहिए।
- RFC 6386: VP8 Data Format and Decoding Guide - VP8 वीडियो कोडेक के लिए फाउंडेशनल IETF स्पेसिफिकेशन, वो अंडरलाइंग इंजन (underlying engine) जो lossy WebP कम्प्रेशन को चलाता है।
- CanIUse: WebP image format - ब्राउज़र कम्पैटिबिलिटी (compatibility) के लिए डेफिनिटिव ट्रैकर, जो साफ़ तौर पर दिखाता है कि ग्लोबली कौन से ब्राउज़र वर्ज़न्स WebP को सपोर्ट करते हैं।