WebP по умолчанию приостановлен для 6.1 после новых возражений от ведущих разработчиков WordPress

На прошлой неделе участники группы производительности работали над уточнением своих последующих исправлений для функции multi-mime/WebP после того, как в конце июля основная работа над ней была объединена с ядром версии 6.1. Это включает в себя более мелкие связанные элементы, такие как прокладка для неподдерживающих браузеров и добавление поддержки PDF, которые обрабатываются в отдельных заявках.

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

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

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

ИМХО, лучшим подходом было бы просто сделать все изображения меньшего размера 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 Photo Directory в последние недели. См. #meta6142 и заявки, закрытые как его дубликат.

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

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

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

Сильверштейн сказал, что они исследуют проблемы, о которых сообщил Hulse, поскольку это могло выявить ошибку.

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

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

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

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

Команда Performance проводит дополнительные исследования и временно приостановила выполнение каких-либо действий до тех пор, пока не получит отзыв о следующем направлении проекта.