WebP افتراضيًا قيد الانتظار لمدة 6.1 بعد اعتراضات جديدة من مطوري WordPress الرئيسيين

في الأسبوع الماضي ، كان المساهمون في فريق الأداء يعملون على تحسين تصحيحات المتابعة الخاصة بهم لميزة mult-mime / WebP ، بعد دمج العمل الرئيسي لها في Core لـ 6.1 في نهاية يوليو. يتضمن ذلك العناصر الأصغر ذات الصلة مثل الرقاقة للمتصفحات غير الداعمة وإضافة دعم PDF ، والتي يتم التعامل معها في تذاكر منفصلة.

كان اقتراح إنشاء صور WebP افتراضيًا لعمليات تحميل صور JPEG الجديدة مثيرًا للجدل منذ البداية. في حين أن المساهمين الذين ترعاهم Google والذين يقودون المشروع قد أجروا بعض المراجعات بعد جولة أولية من التعليقات الهامة الهامة ، استمر المساهمون الآخرون في التعبير عن مخاوفهم التي قالوا إنها لم يتم النظر فيها. أبلغ العديد من المساهمين عن مشكلات تتعلق بالميزة واقترحوا أن تبدأ بالاشتراك ، وهي فكرة تم رفضها بإيجاز قبل الالتزام بالعمل الرئيسي.

في الأسبوع الماضي ، قام أندرو أوز ، المطور الرئيسي لـ WordPress ، بإبداء رأيه في التذكرة باعتراضات جديدة:

مثلMatthiasReinholz وeatingrules وآخرين أعتقد أن هذا النهج ربما يكون مفقودًا. لماذا سيكون هناك ضعف عدد ملفات الصور التي تشغل مساحة كبيرة جدًا بينما لن يتم استخدام نصفها مطلقًا في أي مكان؟

IMHO سيكون النهج الأفضل هو مجرد جعل جميع الأحجام الفرعية للصور WEBP. إذا كانت هناك حاجة بالفعل إلى ملفات JPEG ، فيمكن إنشاؤها أثناء التنقل حسب الحاجة. ليس هناك ما يدعو إلى إعاقة تخزين خوادم الويب بكل هذه الملفات غير المفيدة.

من ناحية أخرى ، إذا كانت أحجام ملفات WEBP أكبر بالفعل من ملفات JPEG ، فربما يعني ذلك الحاجة إلى أدوات أفضل ، وهذا التصحيح سابق لأوانه.

قبل ستة أسابيع ، ردًا على شكوى واحدة مفادها أن "موارد التحويل ستكون هائلة" ، أكد آدم سيلفرشتاين ، المسؤول الأساسي عن عمليات التحويل برعاية Google ، أن الموارد اللازمة لإنشاء الصور عند التحميل "ستزداد بشكل كبير".

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

هذه مشكلة أخرى ذكرها أوز في اعتراضه على هذا النهج.

قال أوز: "في الواقع ، هذه الزيادة الهائلة في استخدام الموارد عند تحميل صورة ما هي أثر جانبي سيء للغاية هنا". "هذا يعني أن الكثير من التحميلات ستفشل ، وتترك المستخدمين عالقين. كما أنه سيزيد من طلبات الدعم لكل من WordPress والشركات المضيفة بشكل كبير. لا أعتقد أن هذا مقبول. لهذا السبب ، حتى إذا كان دعم الصور المتعددة الوسائط مطلوبًا في WordPress ، فإن النهج الحالي لا يبدو كحل جيد ".

بعد حوالي 24 ساعة ، علق المساهم برعاية Google فيليكس أرنتز لإبلاغه بأن آلية WebP الاحتياطية إلى JPEG للمتصفحات الأقدم كانت جاهزة للالتزام وأنه يعتزم الالتزام بها في غضون أيام قليلة.

قال أوز "من فضلك لا تلتزم بأي كود إضافي هنا ما لم يكن ذلك لمعالجة الزيادة الهائلة في الموارد اللازمة لإنشاء أحجام فرعية للصور بعد التحميل". وكما قلت أعلاه ، فإن هذه الزيادة غير مقبولة.

"هل هناك أي بيانات حول مقدار الموارد الإضافية (الذاكرة ، ووقت المعالجة ، وما إلى ذلك) المطلوبة عند تحميل أحجام صور مختلفة؟ أي تقدير حول عدد المواقع التي قد تتأثر بذلك؟ أي اقتراحات حول كيفية التعامل معها؟ هل تعلم ماذا يحدث عندما تفشل المعالجة اللاحقة لصورة تم تحميلها؟

"بصراحة في الوقت الحالي يبدو أنه سيتعين إعادة هذا التصحيح وإعادة بنائه من أجل معالجة هذا الأمر."

استجاب آدم سيلفرشتاين لمخاوفه بتوضيح سبب اختيارهم للنهج الحالي ، تحسبًا لحالات متطرفة معينة وفي النهاية أضاف دعمًا لتنسيقات مثل AVIF بمجرد أن يتم دعمه على نطاق أوسع:

أميل إلى الموافقة على تقييمك بأنه يجب إنشاء جميع الأحجام الفرعية على أنها WebP فقط ، وكان هذا هو شكل الاقتراح الأصلي. بالنسبة للغالبية العظمى من حالات الاستخدام / المستخدمين ، سيعمل هذا بشكل أفضل. سأكون منفتحًا للنظر في هذا بالنسبة للافتراضي (مع بعض عوامل التخفيف ، انظر أدناه).

كان السبب في أننا قررنا إنشاء كلا التنسيقين هو اعتبارات التوافق العكسي لحالات الحافة القليلة التي حددناها حيث قد لا تعمل صور WebP: أي الصور المرسلة عبر البريد الإلكتروني (بعض عملاء Outlook / windows الأقدم) ، وعلامات Open Graph (بعض الخدمات لا تدعم WebP) ومتصفحات Safari الأقدم. أحد الاحتمالات التي أخذناها في الاعتبار هو الاحتفاظ بحجم JPEG بالحجم الكامل فقط بحيث يكون متاحًا دائمًا لحالات الحافة تلك.

تم إنشاء دعم "multi-mime" هنا لإنشاء تنسيقات متعددة حتى تتمكن المواقع من توفير تنسيق أساسي واحتياطي بشيء مثل عنصر picture . هذا أقل أهمية بالنسبة لـ WebP نظرًا لأنه مدعوم على نطاق واسع ، ولكنه سيكون مفيدًا في اعتماد تنسيقات أحدث مثل AVIF بواسطة المكونات الإضافية أو الأساسية.

قال سيلفرشتاين أيضًا إن خيار إنشاء صور أثناء الطيران كان شيئًا يحتاجون إلى اكتشافه ولكن "شعروا أنه خارج نطاق هذا الجهد".

ردًا على الشكوى المتعلقة بالزيادة الهائلة في موارد تحميل الصور ، قال سيلفرشتاين إنهم يعتمدون على آلية "إعادة المحاولة" للتخفيف من هذه المشكلة.

وقال: "يضاعف هذا التغيير أيضًا عدد المرات التي سيعيد فيها WordPress محاولة" إعادة إنشاء الصورة ، لذلك بينما سيزداد وقت المعالجة ، لا أعتقد أننا سنرى قفزة في حالات الفشل بالضرورة ". "أعلم أننا واجهنا مشكلة في إضافة أحجام جديدة في الماضي ، ولكن كان ذلك قبل أن نضيف آلية إعادة المحاولة."

يركز الفريق الذي يقف وراء مشروع WebP افتراضيًا بشكل أكبر على تقديم أحجام صور أصغر على الواجهة الأمامية وينظر في استخدام الموارد الإضافية عند تحميل تضحية ضرورية لمستخدمي WordPress.

قال سيلفرشتاين: "يجب موازنة الموارد الإضافية في وقت التحميل مقابل الموارد المخفضة لخدمة صورة WebP الأصغر ، خاصة وأن العرض يحدث عادةً مرات عديدة من حيث الحجم بشكل متكرر أكثر من التحميل".

"إذا فشل التحميل بعد كل محاولات إعادة المحاولة ، فسيكون لدى المستخدم نفس التجربة كما هو الحال حاليًا: تُترك مع صورة مكسورة وغير قابلة للاستخدام. ربما يمكن إصلاح ذلك ، على الرغم من أنني لا أعتقد أن هذا التغيير سيزيد من معدلات الفشل ".

علق مطور WordPress الرئيسي Dion Hulse أيضًا على التذكرة للإبلاغ عن مشكلات تحويلات WebP في دليل صور WordPress:

نشير هنا فقط إلى أن تحويلات صفحات الويب الإضافية هذه على ما يبدو كانت السبب الرئيسي لفشل التحميل على دليل صور WordPress في الأسابيع الأخيرة. انظر # meta6142 والتذاكر مغلقة كنسخة مكررة منها.

كانت الأخطاء بشكل عام على طول خطوط Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes (من الواضح مع قيم البايت) أثناء محاولة تنفيذ jpeg الأصلي بالحجم الكامل -> تحويل webp.

لم يؤثر على كل تحميل ، فقط صور معينة. يحتمل أن يكون مرتبطًا $quality التي يتم تمريرها لطلبات الويب (IIRC ، تم تحسين الإعداد الافتراضي 82 لـ jpeg؟).

قام Hulse بتعطيل تحويل JPEG إلى WebP نتيجة لهذه الأخطاء ، حيث لا يستخدم دليل الصور WebP حاليًا ولكنه أشار إلى أنه "قد يكون علامة على أنه قد يكون من المفيد التفكير فقط في إنشاء صفحات ويب للصور التي تم تغيير حجمها ، بدلاً من الملف الأصلي أيضًا ".

قال سيلفرشتاين إنهم يحققون في المشكلات التي أبلغ عنها Hulse ، لأنها ربما تكون قد كشفت عن خطأ.

أعاد Ozz إلى الوراء ليوصي بأن جعل الأحجام الفرعية عند الطلب سيكون أسلوبًا أفضل يحتوي على معالجة أسرع للصور التي تم تحميلها ومتطلبات مساحة أقل ، نظرًا لأن صور JPEG الإضافية لن يتم إنشاؤها إلا إذا لزم الأمر. وأشار أيضًا إلى أن "إعادة المحاولة" للمعالجة اللاحقة للصور "لا تعمل بالشكل المتوقع".

وقال أوز "النبأ السيئ هو أنه إذا فشلت المعالجة اللاحقة ، فستظل فرص الملف الأصلي الذي تم تحميله". "بعد ذلك سيتم استخدامه في كل مكان حيث أن معظم الكود في WP يعود إلى الأحجام المتوفرة ، وسيكون الحجم الوحيد هو الحجم الأصلي. هذا يعني أننا سنعرض صورًا ضخمة (متوسط ​​4 ميجابايت - 8 ميجابايت). عيب خطير ".

استجاب سيلفرشتاين لمقترحات Ozz ، ووافق على العديد من المقترحات ، واقترح مسارين محتملين للمضي قدمًا للمشروع:

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

يقوم فريق الأداء بإجراء المزيد من الأبحاث وقد أوقف مؤقتًا الالتزام بأي شيء آخر حتى يتلقوا ملاحظات حول الاتجاه التالي للمشروع.