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