PNG أم WebP للمواقع؟ تجربة عملية على لقطات الشاشة والصور والرسومات الشفافة

الخلاصة السريعة

لو بتجهّز صورة لموقعك، مفيش صيغة تكسب كل مرة. جرّب WebP للصور الفوتوغرافية، لكن ما تحوّلش كل ملفات PNG تلقائيًا. احتفظ بـ PNG أو بنسخة رئيسية أخرى بلا فقدان عندما تحتاج إلى تحرير الصورة لاحقًا، أو إلى نص وحواف حادة، أو إلى تطابق دقيق للبكسلات. استخدم WebP عندما يثبت القياس أنه أصغر من غير تشوه بصري غير مقبول، وعندما يسمح بذلك نطاق المتصفحات الذي تستهدفه.

التجربة نفسها أوضحت الصورة أفضل من أي قاعدة عامة. الصورة الشبيهة بالفوتوغراف أصبحت أصغر بنسبة 83.02% عند quality 92 وأصغر بنسبة 88.75% عند quality 80. لقطة الواجهة أصبحت أكبر بنسبة 88.36% عند quality 92 وأكبر بنسبة 28.63% عند quality 80. أما الرسم الشفاف فأصبح أكبر بنسبة 9.13% عند quality 92، ثم أصغر بنسبة 7.80% عند quality 80. التحويلان في التجربة استخدما lossy WebP داخل المتصفح عند هذين الإعدادين؛ لم نختبر تحويل WebP بلا فقدان. لذلك، WebP خيار جيد للتسليم أحيانًا، وليس وعدًا بحجم أصغر دائمًا.

تختار PNG أم WebP في أي حالة؟

| الحالة | نقطة بداية مناسبة | السبب | ماذا تراجع قبل النشر؟ | |---|---|---|---| | الصور الفوتوغرافية والتفاصيل الغنية | WebP عند quality 80–92 | الصورة الاختبارية الفوتوغرافية انخفض حجمها كثيرًا مع بقاء المقاسات | افحص التفاصيل وقارن عدد البايتات | | لقطات الشاشة والرسومات والنصوص الصغيرة | PNG أو WebP بعد اختبار فعلي | PNG بلا فقدان، ولقطة الواجهة في التجربة كانت أصغر بصيغة PNG | كبّر النص والخطوط الرفيعة والأيقونات والحواف ذات اللون الواحد | | الشعارات والرسومات الشفافة | قارن WebP وPNG جنبًا إلى جنب | WebP يدعم الشفافية، والرسم الشفاف حافظ على alpha بعد فك الترميز في هذه التجربة | راجع الحواف والظلال فوق الخلفية الفعلية | | التحرير والأرشفة أو حفظ المصدر كما هو | نسخة رئيسية بلا فقدان، غالبًا PNG | النسخة الرئيسية تبقى منفصلة عن نسخ العرض والتسليم | تأكد أن نسخة التسليم ليست هي المصدر الوحيد | | تطابق البكسلات بعد فك الترميز | نسخة رئيسية بلا فقدان مع PNG أو ترميز بلا فقدان تم التحقق منه | مخرجات هذه التجربة كانت lossy WebP، فلا تصلح كمرجع تطابق بكسلي | قارن البكسلات المفكوكة عندما تكون المساواة التامة مطلوبة | | المتصفحات أو البرامج الأقدم | PNG كبديل مع WebP عند الحاجة | دعم WebP واسع، لكنه ليس هو نفسه التوافق الشامل التاريخي لـ PNG | اختبر أقل بيئة دعم ومسار البديل |

استخدم الجدول كنقطة بداية، لا كحكم يصلح لكل صورة. قرار الصيغة يتغير حسب محتوى الصورة، وجمهور الموقع، والنتيجة المقاسة.

ماذا تقدّم كل صيغة فعلًا؟

تصف مواصفة W3C الحالية PNG بأنه تنسيق بلا فقدان لتخزين الصور النقطية، مع دعم قناة alpha اختيارية.[1] معنى بلا فقدان هنا أن الترميز لا يتعمد التخلص من معلومات البكسلات. لو كان التطابق الدقيق مهمًا، احتفظ بنسخة رئيسية بلا فقدان، واستخدم PNG أو ترميزًا آخر أثبتَّ أنه بلا فقدان لمسار التسليم المطلوب. هذه التجربة لم تختبر WebP بلا فقدان؛ كل مخرجات WebP فيها كانت lossy.

WebP مرن، لكنه مش بديل أفضل في كل موقف. توضح MDN أنه يدعم الضغط بفقدان وبلا فقدان، والشفافية، والتحريك، مع دعم واسع في إصدارات المتصفحات الحالية.[2] وتشرح RFC 9649 مكوّنات WebP الخاصة بالحاوية، والضغط lossy، والضغط lossless، والتحريك، وalpha.[3] النتيجة العملية بسيطة: يمكن أن يناسب WebP صورة فوتوغرافية أو رسمًا شفافًا، لكن طريقة الترميز والإعدادات هي التي تحدد المقابل بين الحجم والتفاصيل.

رقم الجودة ليس مقياسًا عالميًا لجودة الصورة. في محول صيغ الصور في QuickShed، يرسم المتصفح الصورة المختارة على canvas ثم يستدعي canvas.toBlob() بقيمة quality / 100 عند التحويل إلى WebP. في هذه التجربة أنتج quality 92 وquality 80 مخرجات WebP بفقدان. الرقم يصف استدعاء هذا المشفّر داخل هذا المسار، ولا يضمن أن مشفّرًا آخر أو متصفحًا آخر سيعطي الحجم أو النتيجة البصرية نفسيهما.

وتوضح إرشادات صيغ الصور في MDN مفاضلة التوافق أيضًا: WebP مناسب للصور والصور المتحركة، بينما يظل PNG مفيدًا عندما تكون إعادة الإنتاج الدقيقة أو الشفافية أولوية.[2] إذا كان جمهورك يضم بيئة لا تفك WebP، قدّم بديلًا بدل أن يتحول اختيار الصيغة إلى صورة لا تظهر.

ماذا اختبرت؟

اختبرت ثلاث صور PNG اصطناعية، من غير استخدام صور خارجية:

• صورة شبيهة بواجهة مستخدم: 1,440 × 900، فيها خطوط تشبه النص، وأيقونات، ومساحات مسطحة، وخطوط بعرض 1px، وحواف عالية التباين.
• صورة شبيهة بالفوتوغراف: 1,600 × 1,067، فيها تدرج ولون ونسيج محدد باستخدام seed هو 20260830.
• رسم شفاف: 1,200 × 800، فيه أشكال معتمة وشبه شفافة، وحواف حادة، وظل ناعم، وتدرجات alpha.

مرّت كل صورة عبر محول صيغ الصور في QuickShed داخل المتصفح. حوّلت كل PNG إلى lossy WebP عند quality 92 وquality 80، ولم أشغّل تحويل WebP بلا فقدان. قارنت أبعاد المخرج بعد فك ترميزه في المتصفح بأبعاد المصدر، ثم حسبت متوسط الخطأ المطلق في RGB، واختصاره MAE، وكذلك MAE لقناة alpha. هذه المقاييس مقارنة هندسية لهذه الصور الثلاث، وليست مقياسًا إدراكيًا عامًا لجودة كل صورة.

شكل المخرجات

الصور التالية هي مخرجات WebP الستة بفقدان من تشغيل المتصفح نفسه. تظل ملفات PNG الأصلية هي خط الأساس لأحجام البايتات في الجدول التالي.

لقطة الواجهة

| quality 92 | quality 80 | |---|---| | | |

الصورة الشبيهة بالفوتوغراف

| quality 92 | quality 80 | |---|---| | | |

الرسم الشفاف

| quality 92 | quality 80 | |---|---| | | |

النتائج المقاسة

| الصورة الاختبارية | حجم PNG بالبايت | WebP quality | حجم WebP بالبايت | النتيجة | RGB MAE | Alpha MAE | الأبعاد | |---|---:|---:|---:|---|---:|---:|---| | لقطة الواجهة | 13,706 | 92 | 25,816 | أكبر بنسبة 88.36% | 0.608 | 0 | 1,440 × 900 | | لقطة الواجهة | 13,706 | 80 | 17,630 | أكبر بنسبة 28.63% | 0.738 | 0 | 1,440 × 900 | | الصورة الشبيهة بالفوتوغراف | 4,805,954 | 92 | 815,922 | أصغر بنسبة 83.02% | 1.738 | 0 | 1,600 × 1,067 | | الصورة الشبيهة بالفوتوغراف | 4,805,954 | 80 | 540,810 | أصغر بنسبة 88.75% | 3.240 | 0 | 1,600 × 1,067 | | الرسم الشفاف | 8,857 | 92 | 9,666 | أكبر بنسبة 9.13% | 0.447 | 0 | 1,200 × 800 | | الرسم الشفاف | 8,857 | 80 | 8,166 | أصغر بنسبة 7.80% | 0.490 | 0 | 1,200 × 800 |

لقطة الواجهة هي التحذير الأوضح من استخدام نسبة ثابتة لكل الصور. ملف PNG الأصلي كان قابلًا للضغط بدرجة كبيرة لأنه يحتوي على مساحات واسعة مسطحة وأنماط متكررة. الرسم الشفاف أظهر أثرًا مشابهًا لكن أصغر عند quality 92؛ أما quality 80 فقلّل حجمه قليلًا، وظلت قيمة alpha MAE مساوية للصفر في فك الترميز الذي جرى داخل المتصفح.

الصورة الشبيهة بالفوتوغراف أعطت نتيجة مختلفة. النسيج الموجود فيها سمح لـ lossy WebP بتقليل عدد البايتات مقابل فقدان أكبر في دقة بعض البكسلات. عند quality 80 زاد التوفير بمقدار 5.72 نقطة مئوية مقارنةً بـ quality 92، لكن RGB MAE ارتفع أيضًا من 1.738 إلى 3.240. هل هذا مقبول أم لا؟ يتوقف على الصورة وحجم عرضها؛ عدد البايتات وحده لا يجيب عن السؤال.

طريقة عملية لاختيار الصيغة

1. افصل المصدر عن نسخة التسليم

لا تجعل نسخة WebP هي المصدر الوحيد لصورة قد تعدّلها لاحقًا. احتفظ بالأصل أو بنسخة رئيسية أخرى بلا فقدان في مسار التحرير والأرشفة. بعد ضبط المقاسات، أنشئ WebP للتسليم وراجعه بالحجم الذي سيظهر به للزائر.

2. طابق الإعداد مع نوع الصورة

ابدأ بـ WebP للصورة الفوتوغرافية، وقارن إعدادين أو ثلاثة. راجع التدرجات والمناطق الداكنة والتفاصيل الدقيقة، لا المعاينة العامة فقط. مع لقطة شاشة أو رسم، كبّر النص والخطوط الرفيعة والأيقونات والألوان المسطحة. إذا كان WebP أكبر أو ترك حوافًا مزعجة، احتفظ بـ PNG لذلك الموضع.

مع الشفافية، شاهد الصورة فوق الخلفيات التي تهمك فعلًا. قد يكون الخطأ العددي صغيرًا، ومع ذلك يظهر هالة حول شعار أو ظل. كانت Alpha MAE صفرًا في إعدادي الرسم الشفاف هنا، لكن هذه نتيجة تخص هذه الصورة ومسار فك الترميز هذا، وليست ضمانًا لكل حافة شفافة.

3. راجع المقاسات والبايتات

المخرج الذي يغيّر الأبعاد بصمت ليس نسخة مكافئة. تأكد من العرض والارتفاع، ثم قِس حجم الملف المحفوظ. لا تفترض أن WebP أصغر بعد كل تحويل؛ سجّل النتيجة لكل asset أو لكل فئة ممثلة من الصور.

4. اجعل التوافق قرارًا معلنًا

إذا كان جمهورك يستخدم متصفحات أقدم أو عارضات مضمّنة أو أدوات تحرير غير واضحة الدعم، استخدم مسارًا بديلًا. يتيح عنصر <picture> تقديم WebP أولًا ثم PNG عند الحاجة. البديل جزء من اتفاقية التسليم، وليس سببًا لرفض اختبار الصيغ الحديثة.

5. لا تجعل حجم الصورة وعدًا SEO

الصور الأصغر قد تقلل البيانات المنقولة، لكن هذه التجربة لم تقس الترتيب أو قابلية الزحف أو Core Web Vitals. كما أنها لم تقارن كل الصيغ ولا كل الأجهزة. اعتبر الضغط عاملًا واحدًا في الأداء، وقِس الصفحة داخل تخطيطها وطريقة تحميلها الحقيقية. تغيير امتداد الملف لا يضمن ظهورًا أفضل في البحث أو ترتيبًا أعلى.

ماذا أثبت QuickShed في هذه التجربة؟

يقبل محول QuickShed ملف صورة، ويقرأه عبر FileReader.readAsDataURL()، ويرسمه على HTML canvas، ثم يرمّز الصيغة المختارة عبر canvas.toBlob() ويعرض النتيجة باستخدام browser object URL. تصف metadata الأداة بأنها file-only وoffline: full وretention: none؛ ولا يحتوي مكوّن التحويل على استدعاءات fetch أو XHR أو WebSocket أو beacon أو تخزين.

في تشغيل المتصفح لم نرصد طلب HTTP خارجيًا بعد اختيار الملف أو بعد التحويل، ولم يظهر طلب يحمل POST data. عناوين data: وblob: المستخدمة للمدخل والمعاينة هي مراجع موارد داخل المتصفح. نُزّلت المخرجات الست من واجهة المتصفح وحُسبت بصماتها محليًا. هذه ملاحظة عن هذا التشغيل المحدد، وليست ادعاءً عن كل إعدادات المتصفحات.

استخدمت QuickShed هنا كأداة اختبار محلية، لكن المخرجات الست ليست benchmark عامًا. القاعدة العملية أبسط: قِس asset الحقيقي، احتفظ بمصدر بلا فقدان عندما تحتاجه، اختر WebP عندما يفوز في الحجم من غير تغير بصري غير مقبول، واحتفظ ببديل عندما يتطلب جمهورك ذلك.

المراجع

1. W3C — Portable Network Graphics (PNG) Specification, Third Edition
2. MDN — Image file type and format guide
3. IETF RFC 9649 — WebP Image Format

نطاق التجربة: أرقام البايتات وMAE تخص هذه الصور الاصطناعية الثلاث، ومسار QuickShed داخل المتصفح، والتشغيل المؤرخ 2026-08-30. لم نختبر مخرج WebP بلا فقدان.