في جملة واحدة
WebP هو صيغة صور حديثة طورتها Google بتستلف حيل من ضغط الفيديو (video compression) عشان تفعص الصور لأحجام ملفات أصغر بكتير من JPEG أو PNG، وكل ده مع الحفاظ على نفس الجودة البصرية بالظبط.
المشكلة اللي بيحلها
لفترة طويلة جداً، الإنترنت كان شغال بصرياً بهدنة هشة ومتوترة بين فصيلين متنافسين: JPEG و PNG. (طبعاً GIF كان موجود برضه، بيعمل دوشة في الركن، بس هنجيله كمان شوية).
لو عندك صورة فوتوغرافية فيها ملايين الألوان، كنت بتستخدم JPEG. الـ JPEG كان lossy (فَقُود)، يعني بيرمي شوية داتا مفترض إن عينك مش هتشوفها عشان يوفر مساحة. ولو عندك لوجو، نص واضح جداً، أو محتاج خلفية شفافة (transparent background)، كنت بتستخدم PNG. الـ PNG كان lossless (غير فَقُود)—بيحافظ على كل بيكسل بيرفكت، بس كنتيجة لده، أحجام الملفات كانت بتبقى تقيلة بشكل فلكي. طب لو عايز أنيميشن؟ كنت بتستخدم GIF، صيغة أثرية من سنة 1987 كفاءتها معدومة ومحدودة بـ 256 لون بس.
المشكلة إن الصور كبرت لدرجة إنها بقت تمثل أكتر من 60% من البايتات اللي بتتحمل في أي صفحة ويب عادية. ولما العالم بدأ يتحول من أجهزة الديسكتوب المتوصلة بـ broadband لموبايلات شغالة على شبكات 3G بتقطع، صيغ الصور المنفوخة دي بقت عبء كبير. الصور اللي بتحمل ببطء معناها مستخدمين محبطين، عربيات تسوق مهجورة، وويب تحس إنك بتمشي فيه جوة عسل أسود.
حوالي سنة 2010، Google قررت إن نظام الصيغتين ده بايظ. كانوا لسة مستحوذين على On2 Technologies، شركة عملت صيغة لضغط الفيديو اسمها VP8. مهندسين Google جاتلهم لحظة "وجدتها!": الفيديو ما هو إلا تسلسل سريع لصور ثابتة. طب إيه رأيك لو شدينا جزء "الصورة الثابتة" من الـ video codec المتطور بتاع VP8 وعبّيناه في ملف صورة مستقل؟
وهنا اتولد الـ WebP. مهمته كانت إنه يكون "الصيغة الوحيدة اللي تحكمهم كلهم". كان بيدعم ضغط lossy يتفوق على JPEG، وضغط lossless يغلب PNG، والشفافية (alpha channels)، وحتى الأنيميشن عشان أخيراً يريّح الـ GIF ويطلعه على المعاش.
إزاي بيشتغل تحت الكبوت
عشان تفهم ليه WebP كفاءته عالية كده، لازم تبص على إزاي بيغش. هو في الحقيقة مش بيخزن صورتك بيكسل ببيكسل؛ هو بيخزن تعليمات عن إزاي يخمّن رياضياً شكل صورتك عامل إزاي.
الضغط الفَقُود (Lossy Compression): التكويد التنبؤي (Predictive Coding)
لما WebP يشتغل في الـ mode الـ "lossy" (بديل الـ JPEG)، بيستخدم الـ predictive coding، دي حيلة وارثها مباشرة من الـ VP8 video codec.
الـ WebP بيقسم صورتك لـ "macroblocks"—شبكات من 16x16 أو 4x4 بيكسل. بدل ما يحفظ لون كل بيكسل في البلوك بشكل مستقل، الـ encoder بتاع WebP بيبص على البلوكات اللي فوق واللي على شمال البلوك الحالي مباشرة. وبيسأل نفسه: "بناءً على البيكسلات اللي أنا رسمتها بالفعل، أقدر أخمن البلوك اللي جاي شكله إيه؟"
ولأن معظم الصور فيها مساحات ألوان متصلة (زي سما زرقا، خد ناعم، أو ضل)، التخمين غالباً بيكون دقيق جداً. ساعتها الـ WebP بيحفظ بس الـ residual—يعني الفرق الرياضي بين التخمين بتاعه والصورة الفعلية.
وعن طريق حفظ الفروق الصغيرة دي بس بدل الداتا الكاملة للبيكسلات، WebP بيكشّ حجم الملف بشكل جذري.
الضغط غير الفَقُود (Lossless Compression): وحش من نوع تاني
الـ Lossless WebP (بديل الـ PNG) مش بيستخدم VP8. ده بيستخدم مجموعة مختلفة تماماً من التقنيات اللي صممتها Google مخصوص عشانه. وبيعتمد على طريقة متعددة المراحل:
- Spatial Prediction (التنبؤ المكاني): زي أخوه الـ lossy، بيحاول يخمن البيكسلات بناءً على جيرانها.
- Color Transform (تحويل الألوان): بيفصل داتا الألوان عشان يلاقي التكرارات (redundancies).
- الأخضر هو الملك: بيستخدم قناة اللون الأخضر كـ baseline، وبيخمن قيم الأحمر والأزرق بناءً على قيم الأخضر (عشان عين الإنسان حساسة أكتر للون الأخضر).
- LZ77 Compression: في النهاية، بياخد كل الداتا المتظبطة دي ويدخلها على نسخة متطورة من خوارزمية الضغط LZ77 اللي بتعتمد على القاموس.
هيكل الملف (RIFF)
تحت كل ده، الـ WebP متغلف في container خفيف اسمه RIFF (Resource Interchange File Format). الـ RIFF ده عبارة عن هيكل ملفات متقسم لـ tags، وده معناه إن ملف الـ WebP متقسم لـ chunks (أجزاء). ده بيسمح للصيغة إنها تلزق metadata بسهولة (زي داتا الـ EXIF من كاميرتك) أو ICC color profiles من غير ما تبوظ الصورة الأساسية.
| الخاصية (Feature) | JPEG | PNG | GIF | WebP |
|---|---|---|---|---|
| Lossy Compression | أيوه | لأ | لأ | أيوه |
| Lossless Compression | لأ | أيوه | أيوه | أيوه |
| الشفافية (Alpha) | لأ | أيوه | 1-bit | أيوه (في الـ Lossy و الـ Lossless) |
| الأنيميشن (Animation) | لأ | لأ | أيوه | أيوه |
| متوسط التوفير | الأساس | الأساس | الأساس | أصغر بحوالي 25-34% |
قصص من أرض الواقع
انهيار الـ E-commerce
متجر ملابس أونلاين متوسط الحجم لاحظ إن الـ bounce rate (معدل الارتداد) عندهم عالي جداً على الموبايلات. بعد المراجعة، اكتشفوا إن صفحات الكتالوج بتاعتهم كانت بتحمل حوالي 15 ميجابايت من صور JPEG عالية الدقة. متصفح الموبايل كان بيضيع كل وقته في إنه يعمل parsing لصور عملاقة لجواكت صوف.
الفريق الهندسي عمل pipeline أوتوماتيكي عشان يبعت صور WebP للمتصفحات اللي بتدعمه. ولما ظبطوا الـ lossy compression، قدروا يحافظوا على نفس النقاء البصري المطلوب عشان يبينوا ملمس القماش، بس نزلوا إجمالي حجم الصفحة لـ 3.5 ميجابايت. وقت تحميل الصفحة قل 4 ثواني بحالهم. وكنتيجة لده، الـ conversion rates (معدلات التحويل) على الموبايل نطت بنسبة 18%.
الدرس المستفاد: بايتات الصور بتتناسب عكسياً مع الأرباح. لما بتقدم ملفات أصغر، المستخدمين بيفضلوا قاعدين فترة أطول تكفي إنهم يشتروا حاجة بجد.
الـ Hero Image الشفافة
ويب ديزاينر صمم landing page تحفة لمنتج SaaS جديد. الـ hero section كان فيه رسمة 3D معقدة لـ server rack (كابينة سيرفرات) طايرة فوق خلفية متدرجة (gradient) ديناميكية معمولة بـ CSS. وعشان الفكرة دي تشتغل، صورة السيرفر كانت محتاجة خلفية شفافة.
الديزاينر عملها export كـ PNG-24 مع alpha channel. وبسبب التظليل المعقد وملايين الألوان اللي في الـ 3D render، حجم الـ PNG ضرب لـ 2.2 ميجابايت. تحميلها كان بيحسسك إنك رجعت بالزمن لسنة 2004.
الديفيلوبر خد الـ PNG دي وحولها لـ WebP. واستخدم قوة خارقة معينة في WebP: وهي الـ lossy RGB مع lossless Alpha channel. ده معناه إن الألوان اتضغطت زي الـ JPEG، بس الشفافية فضلت pixel-perfect من غير أي حواف مشرشرة. ملف الـ WebP اللي طلع كان حجمه 210 كيلوبايت—يعني تقليل 90% في الحجم من غير أي خسارة ملحوظة في الجودة.
الدرس المستفاد: مبقتش محتاج تختار بين الألوان الغنية بتاعة الصور الفوتوغرافية وبين الخلفية الشفافة. الـ WebP بيشيل الاتنين مع بعض في نفس الوقت.
مدونة الميمز (Memes) التقيلة
مدونة pop-culture مشهورة كانت بتعتمد بشكل كبير على الـ animated GIFs عشان تعرض مقاطع أفلام وريأكشنات. المقال الواحد ممكن يكون فيه 5 GIFs، بيسحبوا 20 ميجابايت من الداتا وبيخلوا اللابات القديمة تطلع صوت زي محركات الطيارات والـ CPU بيعافر عشان يعمل decode للصيغة الأثرية دي.
نقلوا مكتبة الميديا بتاعتهم لـ Animated WebP. ولأن الـ GIFs بتحفظ كل فريم كصورة كاملة، في حين إن Animated WebP بيستخدم ضغط شبه بتاع الفيديو عشان يحفظ بس الفروقات بين الفريمات، التوفير كان فلكي. الـ GIF اللي بـ 5 ميجا بقى WebP بـ 800 كيلوبايت. واستهلاك الـ CPU نزل لسابع أرض.
الدرس المستفاد: صيغة الـ GIF مكانها في المتحف. لو عايز أنيميشن قصير بيلوب (looping) على الـويب، الصيغ الحديثة زي WebP (أو حتى فيديوهات MP4/WebM حقيقية) بتتفوق عليها بمراحل.
غلطات شائعة وفخاخ
- فخ الـ Double-Lossy: إنك تحول صورة JPEG مضغوطة جداً ومليانة تشوهات (artifacts) لـ lossy WebP دي فكرة سيئة. خوارزمية الـ WebP هتحاول فعلياً إنها تحافظ على بلوكات الـ JPEG البشعة دي بشكل مثالي، وهتعتبرها جزء من الصورة، وده ممكن يؤدي لملف حجمه أكبر أو صورة مبكسلة ومزغللة أكتر. دايماً حول من أعلى جودة مصدر متاحة (زي ملف RAW، أو PNG عالي الدقة، أو JPEG أصلي مش مضغوط).
- نسيان عنصر الـ HTML
<picture>: رغم إن WebP دلوقتي مدعوم من حوالي 97% من المتصفحات عالمياً، بس لسنين طويلة كان الحفلة دي بتاعة Google بس. متصفح Safari بتاع Apple فضل يجرجر رجليه في دعم الـ WebP لحد أواخر 2020. لو مضطر تدعم متصفحات قديمة جداً، مش هينفع ترمي.webpفي تاج<img>وخلاص. لازم تستخدم عنصر<picture>عشان تقدم fallback (بديل احتياطي):<picture> <source srcset="image.webp" type="image/webp"> <img src="image.jpg" alt="A reliable fallback"> </picture> - افتراض إن WebP دايماً هو الأصغر: الـ WebP رائع، بس مش سحر. بالنسبة لأشكال الـ vector البسيطة جداً اللي بألوان سادة (زي لوجو بسيط)، الـ SVG تقريباً دايماً هيكون أصغر وقابل للتكبير لمالانهاية. وبالمثل، الصيغ الجديدة من الجيل القادم زي AVIF غالباً بتغلب WebP في نسب الضغط الصافية، رغم إن AVIF بيحتاج computing power أعلى بكتير عشان يتعمله encode.
- تجاهل وقت الـ encoding على السيرفر: الـ WebP بياخد قوة CPU أكبر بكتير عشان يتضغط مقارنة بالـ JPEG. لو بتعمل generate لصور WebP على الطاير (on-the-fly) وقت ما المستخدم يطلبها، وقت الـ CPU المطلوب عشان يعمل encode للصورة ممكن يسبب تأخير يضيع فايدة توفير الـ bandwidth أساساً. تحويل الـ WebP لازم يتعمل مسبقاً (أثناء الـ build process أو وقت الـ upload)، مش بشكل ديناميكي مع أول render.
ليه لازم يكون على رادارك
لو بتبني حاجات للإنترنت، أداء الويب (web performance) مبقاش رفاهية؛ ده بقى متطلب أساسي. محركات البحث زي Google بتعاقب المواقع البطيئة في ترتيبها، وبتهتم جداً بمقاييس معروفة باسم Core Web Vitals (وتحديداً الـ Largest Contentful Paint، أو LCP). ولأن "أكبر محتوى" على الشاشة بيكون عادةً صورة، فعمل optimization للصورة دي هو أسرع طريقة عشان تحسن الـ SEO بتاعك.
علاوة على كده، الـ bandwidth بيكلف فلوس—سواء ليك (مصاريف الـ data egress بتاعة AWS غالية بشكل معروف) أو للمستخدمين بتوعك اللي على باقات إنترنت محدودة في الدول النامية.
كل ما تتعامل مع avatars بيرفعها المستخدمين، landing pages تسويقية ضخمة، معارض صور، أو كتالوجات e-commerce، الـ WebP هو الاختيار الافتراضي والعملي في عشرينات القرن ده. بيقدم أفضل توازن بين دعم المتصفحات الواسع، الجودة البصرية الممتازة، والتقليل الجذري لحجم الملف.
اتعمق أكتر
- Google Developers: An Image Format for the Web - الـ documentation الرسمية والمرجع التقني العميق لصيغة WebP مباشرةً من اللي اخترعوها.
- MDN Web Docs: Image file type and format guide - تحليل ممتاز من Mozilla عن إمتى تستخدم WebP مقارنة بصيغ صور الويب التانية.
- RFC 6386: VP8 Data Format and Decoding Guide - مواصفات IETF الأساسية لـ VP8 video codec، المحرك اللي شغال تحت الكبوت وبيدي قوة للـ lossy WebP compression.
- CanIUse: WebP image format - المتتبع النهائي لتوافق المتصفحات (browser compatibility)، بيوريك بالظبط إيه إصدارات المتصفحات اللي بتدعم WebP على مستوى العالم.