WebP за замовчуванням призупинено для версії 6.1 після нових заперечень провідних розробників WordPress – WP Tavern

WebP за замовчуванням призупинено для версії 6.1 після нових заперечень провідних розробників WordPress – WP Tavern

ви можете скористатись послугами веб-студії філандор, Замовити Сайт тут. Студія не перший рік надає послуги.

Минулого тижня учасники команди Performance працювали над удосконаленням своїх наступних виправлень для функції multi-mime/WebP після того, як наприкінці липня основну роботу над нею було об’єднано в ядро ​​для 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 Діон Халс також прокоментував заявку на повідомлення про проблеми з перетвореннями WebP у каталозі фотографій WordPress:

Відзначимо лише те, що ці додаткові перетворення webp, здається, були основною причиною збоїв завантаження в каталог фотографій WordPress за останні тижні. Перегляньте #meta6142 і квитки закриті як його дублікат.

Помилки, як правило, були такими Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes (очевидно, з байтовими значеннями) під час спроби виконати початкове перетворення повнорозмірного оригіналу jpeg -> webp.

Це не вплинуло кожне завантаження, лише для певних зображень. Потенційно пов’язані з $quality значення, яке передається для запитів webp (IIRC за умовчанням 82 було оптимізовано для jpeg?).

Hulse вимкнув перетворення JPEG у WebP через ці помилки, оскільки каталог фотографій наразі не використовує WebP, але зауважив, що це «може бути ознакою того, що, можливо, варто розглянути можливість створення webp лише для зображень зі зміненим розміром, а не для оригінальний файл також».

Сільверстейн сказав, що вони досліджують проблеми, про які повідомив Hulse, оскільки, можливо, виявлено помилку.

Озз повернувся, щоб порекомендувати, що створення додаткових розмірів на вимогу було б кращим підходом, який передбачає швидшу обробку завантажених зображень і менші потреби в просторі, оскільки додаткові зображення JPEG не створюватимуться без необхідності. Він також зазначив, що «повторна спроба» для постобробки зображень «працює не так добре, як очікувалося».

«Погана новина полягає в тому, що якщо постобробка не вдасться, швидше за все, початково завантажений файл залишиться», — сказав Озз. «Тоді його використовуватимуть скрізь, оскільки більшість коду в WP повертається до доступних розмірів, і єдиним розміром буде оригінальний. Це означає, що ми обслуговуватимемо величезні (в середньому 4 МБ – 8 МБ) зображення. Серйозний недолік».

Сільверстейн відповів на пропозиції Озза, погодившись з багатьма, і запропонував два потенційних шляхи розвитку проекту:

  1. Збережіть поточну інфраструктуру multi-mime, але змініть параметри за замовчуванням, щоб генерувалися лише файли WebP, можливо, до граничного розміру, за яким генеруватимуться лише файли JPEG. Більшість існуючих робіт буде продовжено; фільтрацію вмісту можна видалити.
  2. Відновіть інфраструктуру мультиміми та поверніться до єдиного підходу mime, використовуючи WebP для зображень до порогового розміру та налаштовуючи рівень сумісності для використання файлів JPEG, які ми зберігаємо.

Команда Performance проводить додаткові дослідження та тимчасово призупинила будь-які інші дії, доки не отримає відгук щодо наступного напрямку проекту.

Джерело: https://wptavern.com/webp-by-default-on-hold-for-6-1-after-new-objections-from-wordpress-lead-developers

Related posts