هل WebP أصغر فعلاً من JPG لصور المواقع؟
قمنا بمقارنة JPG و WebP و AVIF على نفس الصورة بحجم 538.6 KB عند نفس الشريط، وحقق JPG الفوز. إليك سبب حدوث ذلك وما تظهره المقارنة العادلة.
تخبرك كل دليل أن WebP يعمل بحجم أصغر بحوالي 30% من JPG عند جودة متطابقة. دراسة جوجل الخاصة هي مصدر هذا الرقم. أجرينا المقارنة على الضاغط الخاص بنا مع صورة واحدة بحجم 3840x2160، texture.jpg بحجم 538.6 KB، وعند نفس موضع الشريط فاز JPEG: 286.1 KB مقابل 290.3 KB لـ WebP. بينما حصل AVIF، التنسيق الذي من المفترض أن يتفوق على كلاهما، على 312.7 KB.
لم يكن هناك أي خلل. تقرأ التنسيقات الثلاثة ذلك الشريط بشكل مختلف، وواحد منها يفعل ذلك عن عمد. بمجرد أن تعرف أي واحد، يعود النتيجة إلى ما تتوقعه، وتحصل على عادة تستحق أن تحملها إلى أي أداة تستخدمها بالفعل.
لماذا جاء WebP بحجم أكبر من JPG عند نفس الشريط؟
يحتوي ضاغطنا على ميزة تشترك فيها العديد من الأدوات ولا تذكرها تقريبًا. عندما يكون تنسيق الإخراج هو JPEG وكان الإدخال بالفعل JPEG، فإنه يقرأ جداول الكوانتيزات من ملف المصدر، ويقدر الجودة التي تم حفظ ذلك الملف بها، ثم يضرب شريطك مقابل ذلك التقدير. يحصل مصدر بتقييم 60 مع الشريط عند 80 على ترميز عند 48. بينما لا يحصل WebP و AVIF على مثل هذا المعاملة، لذا فإن 80 تعني 80 ويفعل المشفر ما يُطلب منه. كانت تلك العملية في الأعلى JPEG عند 48 فعالة مقابل WebP عند 80 حرفيًا. الملف المضغوط بشكل أكبر أصغر.
تستحق إعادة القياس مكانها. إعادة ترميز JPEG مضغوط بالفعل عند 80 عندما تم كتابته عند 60 تضيف بايتات دون إضافة أي تفاصيل مرة أخرى، لذا نحن نتعامل مع الشريط كنسبة مما تبقى في الملف. المشكلة الأعمق تعود إلى JPEG نفسه: المواصفة تخزن جداول الكوانتيزات الخام ولا تخزن رقم جودة، لذا فإن 75 في Photoshop و 75 في MozJPEG و 75 في بعض سكربتات PHP هي ثلاثة ملفات مختلفة. مطابقة الرقم على شريطين واستدعائه اختبارًا عادلاً لا يعمل.
كيف تبدو الأحجام عندما تقارنها بشكل صحيح؟
| ترميز | شريط | إخراج |
|---|---|---|
| مصدر texture.jpg | 538.6 KB | |
| JPEG (MozJPEG) | 80، أعيد قياسه إلى 48 | 286.1 KB |
| WebP | 80، مأخوذة حرفيًا | 290.3 KB |
| AVIF | 80، مأخوذة حرفيًا | 312.7 KB |
| WebP | 63 | 200.6 KB |
| AVIF | 63 | 186.9 KB |
عند 63، يكتب WebP 200.6 KB من ذلك المصدر 538.6 KB. AVIF عند نفس الإعداد يصل إلى 186.9 KB، و63 هو ما يختاره وضعنا الذكي لـ AVIF على أي حال، لذا فهو ليس رقمًا اخترناه لتجميل التنسيق. قم بمطابقة أحجام الإخراج أولاً، ثم افتح كلا الملفين بحجم كامل وقرر أيهما يمكنك العيش معه. هذه هي المقارنة التي تستحق أن تُجرى.
هل يجب أن أستخدم AVIF فقط إذن؟
من حيث البايتات، يفوز AVIF. من حيث الصبر، يخسر. استغرق ترميز تلك الإطار بحجم 3840x2160 إلى AVIF حوالي 10 إلى 11 ثانية في المتصفح، بينما عاد JPEG و WebP على الفور. كل هذا هو WebAssembly يعمل على جهازك الخاص، لذا فإن ذلك هو جهاز الكمبيوتر المحمول الخاص بك يقوم بترميز AV1 الداخلي، وتكاليفه تتناسب مع عدد البكسلات. هناك مشكلة ثانية تستحق المعرفة: إذا فشل مشفر WASM، نعود إلى مشفر لوحة المتصفح، ويمكن للوحة كتابة JPEG و PNG و WebP ولكن ليس لديها مسار AVIF على الإطلاق. بالنسبة لدفعة كبيرة، توصي جوجل بأداة avifenc الأصلية بدلاً من بناء WebAssembly، و ما تكلفه عشرة ترميزات AVIF في علامة تبويب واحدة يتم قياسه أيضًا.
ماذا أفقد عندما أحول JPG إلى WebP؟
ثلاثة أشياء ملموسة. تذهب البيانات الوصفية أولاً: ضغط أو تحويل الصورة يفكك الصورة إلى بكسلات خام ويعيد ترميزها، لذا فإن EXIF، إحداثيات GPS، ملف تعريف ICC والصورة المصغرة المدمجة كلها تختفي من الإخراج. تبقى الاتجاهات، لأن المتصفح يطبقها أثناء فك التشفير. إذا كنت بحاجة إلى تاريخ الالتقاط، احتفظ بالملف الأصلي. وJPEG مضغوط بشكل غير متجانس يعاد ترميزه كـ WebP غير متجانس هو جيل ثانٍ من الفقد المتراكم على الأول، لذا قم بذلك مرة واحدة من أفضل مصدر لديك.
الكروم هو الفقد الثاني. WebP غير متجانس مقيد بالتجزئة 4:2:0، دون خيار 4:4:4 في أي مكان في التنسيق، لذا يمكن أن تبدو لقطة شاشة لكود مميز أو شعار جالس على الأحمر المشبع أسوأ في WebP من JPEG بنفس الوزن. الصور لا تهتم. الترميز هو الثالث: JPEG التقدمي يرسم إطارًا كاملًا خشنًا مبكرًا ويقوم بتشديده مع وصول البايتات، و WebP ليس لديه وضع تقدمي، لذا فإن الصورة الكبيرة لا تظهر شيئًا حتى تصل كمية كافية منها. على صورة بطول عالٍ على اتصال ضعيف، يغير ذلك مدى سرعة شعور الصفحة حتى عندما يكون الملف أصغر.
هل لا يزال يفوز WebP إذا كانت الصورة تحتوي على شفافية؟
لا يمكن لـ JPEG التعامل مع الشفافية. لا يوجد قناة ألفا في أي وضع JPEG، لذا بالنسبة لشعار أو قطع، المنافسة الحقيقية هي PNG ضد WebP، و الحجة لكل من هذين التنسيقين تقاس على هذه الملفات نفسها. أرقام PNG لدينا تحدد الحد الذي يجب عليك تجاوزه: alpha.png بحجم 900x606 و 942.4 KB انخفضت إلى 383.9 KB من خلال oxipng بدون فقد عند المستوى 3، وإلى 98.3 KB بمجرد أن قلل imagequant إلى لوحة، وهو 90% مع الحفاظ على الشفافية. يخزن WebP ألفا بشكل غير متجانس حتى داخل ملف غير متجانس، لذا تظل حواف القطع نظيفة بأي طريقة. إذا كنت تقوم بإنشاء القطع في المقام الأول، فإن أداة إزالة الخلفية لدينا دائمًا تكتب PNG مع ألفا، ويمكن أن يذهب هذا PNG مباشرة إلى الضاغط بعد ذلك.
أي واحد يجب أن أضعه فعليًا على الموقع؟
استخدم WebP للصور الفوتوغرافية. كل متصفح حالي يفك تشفيره، بما في ذلك Safari، والتوفير حقيقي بمجرد أن تتوقف عن مقارنة أرقام الشريط. احتفظ بـ JPG حيث يجب فتح الملف في برامج قديمة، أو حيث يستفيد بطل كبير من الترميز التقدمي أكثر من استفادته من 30 KB. دليل تنسيق الصور في MDN هو المرجع الذي يجب التحقق منه قبل أن تلتزم بمكتبة كاملة لتنسيق واحد.
تحقق من البكسلات أولاً. صورة بحجم 3840 بكسل هي أربعة أضعاف عرض عمود المحتوى بحجم 960 بكسل الذي سيظهر أبدًا، ولا يعطيك أي ترميز ما يقدمه إعادة القياس مجانًا، لذا فإن أداة إعادة القياس مع إعداداتها 25/50/75 هي نقرة واحدة وعادة ما تتفوق على حجة التنسيق بشكل كامل. تهم سلم الجودة أكثر من التنسيق أيضًا. تلك texture.jpg نفسها انخفضت إلى 212.4 KB عند 60 و 131 KB عند 30، واستقر الوضع الذكي عند 286.1 KB، 47% أقل، دون أن يسألك عن أي شيء.
كيف يمكنني إجراء هذا الاختبار على صورتي الخاصة؟
افتح الضاغط، ضع صورتك فيه وانتقل إلى الوضع اليدوي. اختر JPG، لاحظ الحجم. قم بتغيير قائمة التنسيق إلى WebP عند نفس الشريط ولاحظ ذلك. ثم اسحب شريط WebP لأسفل حتى يجلس الملفان ضمن بضع KB من بعضهما البعض، وانظر إليهما جنبًا إلى جنب بحجم كامل، لأن هذه هي المقارنة الوحيدة التي تخبرك بأي شيء. تحدد الدفعات بحد أقصى 10 ملفات و 50 MB. إذا كنت تفضل تخطي الشريط تمامًا، فإن JPG إلى WebP يقوم بالترميز بجودة ثابتة 80 دون إعادة قياس، و WebP إلى JPG يعود بالطريقة الأخرى مع الشفافية المدمجة على الأبيض، و الدليل بصيغة PDF يغطي التحويل الوحيد الذي يجعل الملفات أكبر.