هفته گذشته همکاران تیم Performance در حال کار بر روی اصلاح وصله های بعدی خود برای ویژگی multi-mime/WebP بودند، پس از اینکه کار اصلی برای آن انجام شد. برای نسخه 6.1 در هسته ادغام شد در پایان جولای این شامل موارد مرتبط کوچکتر مانند شیم برای مرورگرهای غیرپشتیبانی کننده و افزودن پشتیبانی PDF است که در تیکت های جداگانه بررسی می شوند.
پیشنهاد تولید تصاویر WebP به طور پیش فرض برای آپلود تصاویر جدید JPEG از همان ابتدا بحث برانگیز بوده است. در حالی که مشارکت‌کنندگان تحت حمایت گوگل که پروژه را هدایت می‌کنند، پس از دور اولیه بازخوردهای مهم انتقادی، برخی بازنگری‌ها را انجام داده‌اند، سایر مشارکت‌کنندگان همچنان نگرانی‌هایی را ابراز می‌کنند که می‌گویند در نظر گرفته نشده است. چندین مشارکت‌کننده مشکلات مربوط به این ویژگی را گزارش کردند و پیشنهاد کردند که باید با انتخاب کردن شروع شود، ایده‌ای که به طور خلاصه قبل از انجام کار اصلی رد شد.
هفته گذشته، اندرو اوز، توسعه‌دهنده اصلی وردپرس، این بلیط را بررسی کرد اعتراضات جدید:
پسندیدن@MatthiasReinholz،@eatingrulesو دیگرانی که فکر می‌کنم شاید این رویکرد وجود نداشته باشد. چرا دو برابر تعداد فایل های تصویری فضای اضافی زیادی را اشغال می کند در حالی که نیمی از آنها هرگز در هیچ کجا استفاده نمی شوند؟
یک رویکرد بهتر IMHO این است که فقط همه اندازه‌های تصویر را WEBP کنیم. اگر واقعاً به JPEG نیاز دارید، می‌توان آنها را در لحظه در صورت نیاز تولید کرد. هیچ فایده ای برای مسدود کردن فضای ذخیره سازی سرورهای وب با این همه فایل های بی فایده وجود ندارد.
از طرف دیگر، اگر اندازه فایل WEBP واقعا بزرگتر از JPEG باشد، احتمالاً به این معنی است که ابزارهای بهتری مورد نیاز است و این وصله زودرس است.
شش هفته پیش، در پاسخ به یک شکایت مبنی بر اینکه «منابع برای تبدیل فوق‌العاده خواهد بود»، آدام سیلورستاین، متعهد اصلی Google تأیید کرد که منابع تولید تصاویر در آپلود «به‌طور چشمگیری افزایش می‌یابد».
سیلورستاین گفت: “با این حال منابع برای ارائه یک تصویر کاهش می یابد.” “از آنجایی که آپلود تصویر در مقایسه با ارائه تصویر بسیار نادر است، تلاش اضافی برای فشرده سازی و ذخیره تصاویر باید ارزشش را داشته باشد.”
این مشکل دیگری است که اوز در اعتراض خود به این رویکرد به آن اشاره کرد.
اوز گفت: «در واقع افزایش چشمگیر استفاده از منابع هنگام آپلود یک تصویر یک عارضه جانبی بسیار بد در اینجا است. این بدان معناست که بسیاری از آپلودها با شکست مواجه می شوند و کاربران را سرگردان می کنند. همچنین درخواست های پشتیبانی برای وردپرس و شرکت های میزبان را به طور چشمگیری افزایش می دهد. فکر نکنید این قابل قبول است. به همین دلیل، حتی اگر به پشتیبانی چند میم تصویر در وردپرس نیاز باشد، رویکرد فعلی راه حل خوبی به نظر نمی رسد.
تقریباً 24 ساعت بعد، فلیکس آرنتز، مشارکت کننده تحت حمایت گوگل نظر داد به شما توصیه می کند که مکانیسم بازگشتی WebP به JPEG برای مرورگرهای قدیمی برای commit آماده است و او قصد دارد تا چند روز دیگر آن را انجام دهد.
Ozz گفت: “لطفاً هیچ کد دیگری را در اینجا وارد نکنید، مگر اینکه برای رسیدگی به افزایش چشمگیر منابع مورد نیاز برای ایجاد اندازه های فرعی تصویر پس از بارگذاری باشد.” همانطور که در بالا گفتم چنین افزایشی غیرقابل قبول است.
آیا اطلاعاتی در مورد اینکه چه مقدار منابع بیشتری (حافظه، زمان پردازش و غیره) هنگام آپلود اندازه های مختلف تصویر مورد نیاز است وجود دارد؟ برآوردی در مورد چند سایت ممکن است تحت تأثیر آن قرار گیرد؟ پیشنهادی در مورد نحوه برخورد با آن دارید؟ آیا می دانید وقتی پس پردازش تصویر آپلود شده با شکست مواجه می شود چه اتفاقی می افتد؟
صراحتا در حال حاضر به نظر می رسد که این وصله باید برگردانده شود و برای رفع این مشکل اصلاح شود.
آدام سیلورستاین به نگرانی‌های خود پاسخ داد و توضیح داد که چرا آنها رویکرد فعلی را انتخاب کرده‌اند، با پیش‌بینی موارد لبه خاص و در نهایت پشتیبانی از فرمت‌هایی مانند AVIF پس از پشتیبانی گسترده‌تر:
من تمایل دارم با ارزیابی شما موافق باشم که همه اندازه های فرعی باید فقط به عنوان WebP تولید شوند، این شکل طرح اولیه بود. برای اکثریت قریب به اتفاق موارد/کاربران، این بهترین کار خواهد کرد. من برای در نظر گرفتن این مورد برای حالت پیش فرض آماده هستم (با برخی از کاهش ها، به زیر مراجعه کنید).
دلیلی که تصمیم گرفتیم هر دو فرمت را تولید کنیم، ملاحظات سازگاری با عقب برای چند مورد لبه ای بود که شناسایی کردیم که در آن تصاویر WebP ممکن است کار نکنند: یعنی تصاویر ایمیل شده (برخی مشتریان قدیمی outlook/windows)، برچسب های Open Graph (برخی از سرویس ها پشتیبانی نمی کنند. WebP) و مرورگرهای قدیمی سافاری. یکی از امکان‌هایی که در نظر گرفتیم این است که فقط JPEG با اندازه کامل را نگه داریم تا همیشه برای آن موارد لبه در دسترس باشد.
پشتیبانی «مولتی مایک» در اینجا برای تولید فرمت‌های متعدد ساخته شده است، بنابراین سایت‌های شما می‌توانند یک قالب اولیه و بازگشتی را با چیزی شبیه به
pictureعنصر این برای WebP اهمیت کمتری دارد زیرا به طور گسترده پشتیبانی می شود، اما برای استفاده از قالب های جدیدتر مانند AVIF توسط افزونه ها یا هسته مفید خواهد بود.
سیلورستاین همچنین گفت که گزینه تولید تصاویر در حال پرواز چیزی است که آنها باید کشف کنند اما “احساس می‌کنند که این تلاش خارج از محدوده است.”
در پاسخ به شکایت در مورد افزایش چشمگیر منابع برای آپلود تصاویر، سیلورستاین گفت که آنها برای کاهش این مشکل به مکانیسم “تلاش مجدد” تکیه می کنند.
او گفت: «این تغییر همچنین تعداد دفعاتی را که وردپرس بازسازی تصویر را دوباره امتحان می‌کند، دو برابر می‌کند، بنابراین در حالی که زمان پردازش افزایش می‌یابد، فکر نمی‌کنم لزوماً شاهد جهش در خرابی‌ها باشیم». می‌دانم که در گذشته برای افزودن اندازه‌های جدید با مشکل مواجه بودیم، اما این قبل از افزودن مکانیسم امتحان مجدد بود.
تیم پشت پروژه به‌طور پیش‌فرض WebP بیشتر بر روی ارائه اندازه‌های کوچکتر تصویر در قسمت جلویی تمرکز دارد و استفاده از منابع اضافی در آپلود را قربانی ضروری برای کاربران وردپرس می‌داند.
سیلورستاین گفت: «منابع اضافی در زمان آپلود باید با منابع کاهش یافته ارائه تصویر کوچکتر WebP سنجیده شود، به ویژه از آنجایی که سرویس دهی معمولاً چندین مرتبه بیشتر از بارگذاری انجام می شود.
«اگر آپلود پس از تمام تلاش‌های مجدد ناموفق باشد، کاربر همان تجربه فعلی را دارد: تصویری شکسته و غیرقابل استفاده برای او باقی می‌ماند. احتمالاً می‌توان آن را برطرف کرد، اگرچه من فکر نمی‌کنم این تغییر نرخ شکست را افزایش دهد.»
دیون هالس، توسعه‌دهنده اصلی وردپرس نیز نظر داد در بلیط گزارش مشکلات مربوط به تبدیل WebP در فهرست عکس وردپرس:
فقط به این نکته توجه داشته باشید که به نظر می‌رسد این تبدیل‌های وب اضافی در هفته‌های اخیر علت اصلی خرابی آپلود در فهرست عکس وردپرس بوده است. دیدن#meta6142و بلیط ها به عنوان تکراری از آن بسته شد.
خطاها به طور کلی در امتداد خطوط بودند
Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes(بدیهی است با مقادیر بایت) هنگام تلاش برای انجام تبدیل اولیه jpeg در اندازه اصلی -> webp.تاثیری نداشته استهر بارگذاری، فقط تصاویر خاص. بالقوه مربوط به
$qualityمقدار ارسال شده برای درخواست های webp (IIRC پیش فرض 82 برای jpeg بهینه شده است؟).
هالس تبدیل JPEG به WebP را غیرفعال کرد در نتیجه این خطاها، از آنجایی که دایرکتوری عکس در حال حاضر از WebP استفاده نمی‌کند، اما اشاره کرد که «ممکن است نشانه‌ای از این باشد که شاید ارزش آن را داشته باشد که webpها را فقط برای تصاویر تغییر‌یافته به جای فایل اصلی در نظر بگیرید.»
Silverstein گفت که آنها در حال بررسی مسائلی هستند که Hulse گزارش کرده است، زیرا ممکن است یک باگ را فاش کرده باشد.
اوز دور برگشت به توصیه که ساخت سایزهای فرعی در صورت تقاضا رویکرد بهتری خواهد بود که پردازش سریع‌تر تصاویر آپلود شده و فضای مورد نیاز را کاهش می‌دهد، زیرا تصاویر JPEG اضافی تولید نمی‌شوند مگر اینکه نیاز باشد. او همچنین خاطرنشان کرد که “تلاش مجدد” برای پس از پردازش تصویر “آنطور که انتظار می رود کار نمی کند.”
اوز گفت: «خبر بد این است که اگر پردازش پست با شکست مواجه شود، به احتمال زیاد فایل بارگذاری شده اولیه باقی خواهد ماند. سپس در همه جا مورد استفاده قرار می گیرد زیرا بیشتر کدهای WP به اندازه های موجود برمی گردند و تنها اندازه اصلی خواهد بود. این بدان معناست که ما تصاویر عظیم (متوسط 4 مگابایت – 8 مگابایت) را ارائه خواهیم کرد. یک عیب جدی.»
سیلورستاین به پیشنهادات اوز پاسخ داد و با بسیاری موافق بود و دو مسیر بالقوه برای پروژه پیشنهاد کرد:
- زیرساخت چند میم فعلی را حفظ کنید، اما پیش‌فرض‌ها را تغییر دهید تا فقط فایل‌های WebP تولید شوند، احتمالاً تا حد آستانه‌ای که فراتر از آن فقط JPEG تولید می‌شود. بیشتر کارهای موجود ادامه خواهند داشت. ممکن است فیلتر محتوا حذف شود.
- زیرساخت چند میم را برگردانید و به یک رویکرد mime تک بازگردید، با استفاده از WebP برای تصاویر تا اندازه آستانه و تنظیم لایه سازگاری برای استفاده از JPEG هایی که نگه می داریم.
تیم Performance در حال انجام تحقیقات بیشتر است و به طور موقت انجام هر چیز دیگری را تا دریافت بازخورد در مورد جهت بعدی پروژه متوقف کرده است.
