Разработчики отказались включать по умолчанию формат WebP в WordPress 6.1

В августе участники команды Performance работали над серией патчей для функционала WebP/Multi-mime, который в конце июля был внесен в ядро для предстоящего релиза 6.1. Разработчики продумали переходное решение для неподдерживаемых браузеров, а также добавили поддержку PDF.

Предложение генерировать WebP-изображения по умолчанию для всех новых загружаемых JPEG с самого начала вызвало споры в сообществе. Одни участники (спонсируемые Google) поддержали проект, внеся некоторые исправления после первого раунда критической обратной связи, другие – возражали, что многие проблемы не учитываются и ретушируются. Участники отмечали, что с этим функционалом много сложностей, а потому лучше начать с того, чтобы сделать его необязательным, опциональным, чтобы посмотреть, как он будет работать.

Ведущий разработчик Эндрю Озз высказал тогда свои возражения:

«Я считаю, что этот подход неправильный. Зачем нам вдвое больше файлов изображений, которые занимают дополнительное место, если половина из них никогда не будет использоваться?

Как мне кажется, лучший подход – перевести все дополнительные размеры изображений в формат WEBP. Если для таких размеров потребуются JPEG, то их можно будет сгенерировать на лету. Нет смысла забивать серверное пространство этими бесполезными файлами.

С другой стороны, если дополнительные размеры в WEBP-формате будут весить больше, чем в JPEG, то нам, скорее всего, нужны более совершенные инструменты; я считаю, что патч преждевременный».

Еще раньше основной коммиттер ядра Адам Сильверстейн подтвердил, что затраты ресурсов для генерации изображений при загрузке «значительно увеличатся».

«При этом потребуется меньше ресурсов для передачи изображения», — отметил Адам. – «Загрузка изображений происходит гораздо реже, чем их передача, потому дополнительная выгода, связанная с хранением и сжатием изображений, должна окупить все это».

Есть и еще одна проблема, которую упомянул Эндрю Озз в своем комментарии.

«Резкое увеличение затрат ресурсов при загрузке изображения – плохой побочный эффект», — отметил Эндрю. – «Отсюда следует, что многие загрузки могут прерваться, что поставит пользователей в затруднительное положение. Возрастут обращения в поддержку – как самого WordPress, так и хостингов. Это неприемлемо. Да, нам требуется поддержка multi-mime в WordPress, но не такой ценой».

Сутки спустя Феликс Арнц, разработчик WordPress, отметил, что механизм отката WebP к JPEG для старых браузеров готов к использованию, и он планирует его закоммитить через пару дней.

«Пожалуйста, не надо больше вносить код, за исключением того, который связан с сокращением ресурсов, требуемых для создания дополнительных размеров изображений при загрузке», — отметил Эндрю. – «Как я уже говорил выше, увеличение ресурсов неприемлемо».

«Есть ли данные о том, насколько больше ресурсов (памяти, процессорного времени и т.д.) требуется для загрузки разных размеров изображения? Есть ли оценки того, сколько сайтов будет затронуто в результате этого нововведения? Как с этим бороться? Что будет, если произойдет сбой в процессе постобработки загруженного изображения?»

«Честно говоря, мне кажется, что этот патч придется отменить и переработать, чтобы решить все эти проблемы».

Адам Сильверстейн решил ответить на эти возражения, объяснив, почему разработчики выбрали такой подход:

«Я согласен с вашим мнением, что все дополнительные размеры должны генерироваться только в WebP, именно это и предлагалось изначально. Для подавляющего большинства пользователей/сценариев этот подход сработает лучше всего. Я бы предложил включить его по умолчанию (с некоторыми ограничениями, привожу их далее).

Почему мы решили генерировать оба формата? Сделано это с целью обратной совместимости для некоторых выявленных нами пограничных случаев, когда WebP-изображения могут не работать. К примеру, они не подойдут в качестве изображений, отправляемых по почте (старые outlook/windows-клиенты их не поддерживают), не подойдут для тегов Open Graph (некоторые сервисы не поддерживают WebP) и для старых браузеров Safari. Мы думали над тем, чтобы всегда сохранять полноразмерный JPEG и использовать его для таких пограничных случаев.

Поддержка multi-mime в данном случае подразумевает генерацию нескольких форматов изображения, чтобы сайты могли предлагать базовый формат и fallback-формат в элементе picture (и подобных ему). Для WebP это не настолько важно – он и так неплохо поддерживается. Но это будет полезно для адаптации новых форматов, таких как AVIF, в плагинах и ядре».

Адам также отметил, что возможность генерации изображений на лету требует дополнительного исследования, она выходит за рамки текущей разработки.

В ответ на жалобы о резком увеличении затраченных ресурсов для загрузки изображений Адам сказал, что разработчики планируют смягчить этот нюанс при помощи retry-механизма.

«В результате данного изменения количество повторных попыток сгенерировать изображения удвоится; время обработки увеличится, но не факт, что мы столкнемся с приростом сбоев», — отметил Адам. – «Да, в прошлом у нас были проблемы с добавлением новых размеров, но это было еще до того, как мы внедрили retry-механизм повторных попыток».

Команда, стоящая за WebP, больше сосредоточена на передаче изображений меньшего размера во фронтенде. Дополнительное использование ресурсов при загрузке изображений она считает необходимой жертвой для пользователей WordPress.

«Выделение дополнительных ресурсов в процессе загрузки надо сопоставлять с сокращением ресурсов при передаче WebP-изображения меньшего размера. Передача происходит в разы чаще, чем загрузка», — резюмировал Адам.

«Если загрузка не удалась после всех попыток, пользователь получит тот же опыт, что и сейчас: у него будет сломанное, нерабочее изображение. Да, это можно исправить, но я не думаю, что предлагаемое нами изменение увеличит процент сбоев».

Ведущий разработчик WordPress Дион Халс также опубликовал свой комментарий в соответствующем тикете:

«Похоже, все эти дополнительные преобразования webp были основной причиной сбоев при загрузке изображений в WordPress Photo Directory за последние недели. См. #meta6142 и тикеты, закрытые как дубли.

Ошибки в основном были следующего рода: «Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes)».

Были затронуты только некоторые изображения (не все). Потенциально ошибка связана со значением $quality, передаваемым для запросов webp (если я правильно помню, базовое значение 82 было оптимизировано для jpeg?)»

Дион отключил преобразование JPEG в WebP из-за этих ошибок, поскольку в каталоге фотографий в настоящий момент не используется WebP. При этом он отметил, что «создавать webp стоит только для дополнительных размеров изображений, а не для исходного файла».

Адам отметил, что разработчики изучают проблемы, о которых высказался Дион.

Эндрю Озз повторил, что лучше всего создавать дополнительные размеры по запросу, чтобы они генерировались только при необходимости. Это позволило бы сохранить свободное пространство на сервере. Механизм retry (постобработки изображения) работает «не так, как ожидалось».

«Если постобработка не удалась, то исходный загруженный файл, скорее всего, останется на сервере», — возразил Эндрю. – «В итоге он будет использоваться повсеместно, поскольку код в WP откатывается к доступным размерам, а в данном случае единственный доступный размер – это оригинальный. Следовательно, мы будем передавать огромные (по 4-8 Мб) изображения. Существенный недостаток».

Адам согласился с такими возражениями и предложил два возможных пути развития проекта:

 

1. Сохранить текущую multi-mime-инфраструктуру, но изменить базовые настройки, чтобы генерировались только WebP-файлы, причем задать для них пороговый размер, после которого будут генерироваться только JPEG. В итоге текущий прогресс будет продолжен.
2. Отказаться от multi-mime-инфраструктуры и вернуться к подходу single-mime. В этом случае формат WebP будет использоваться для изображений, не превышающих пороговый размер; для сохраняемых JPEG изображений будет задан уровень совместимости.

Команда Performance решила провести дополнительные исследования, временно приостановив прогресс по текущей реализации WebP.

Примечание: В Squarespace и Wix преобразование в webp уже происходит по умолчанию.

Источник: wptavern.com