Год назад в WordPress 5.8 появилась поддержка WebP, что позволило пользователям загружать и использовать изображения WebP в своем контенте. В марте 2022 года команда Performance Team решила расширить основную поддержку формата изображений, предложив в WordPress включить WebP по умолчанию.
Предложение включало в себя генерацию изображений WebP для новых загрузок JPEG и использование изображений WebP в содержимом сайта. В апреле это спорное предложение было приостановлено после значительного количества критических отзывов.
После нескольких месяцев исследований команда пересмотрела свой подход и подвела итоги. Беспокойство по поводу совместимости с WebP не кажется оправданным, поскольку исследования показывают, что более 97% веб-браузеров, как и более 97% почтовых клиентов, совместимы с этим форматом.
Мобильные приложения имеют хорошую совместимость: iOS 14+ поддерживает WebP (в более старых версиях будут передаваться JPEG), а Android поддерживает WebP нативно, начиная с Android 4.0. Команда обнаружила, что все ведущие программы для чтения RSS поддерживают WebP. Единственным исключением в совместимости являются потребители Open Graph, что имеет смешанную поддержку.
Одним из главных поводов для беспокойства в предыдущих отзывах было то, что предложение потенциально может удвоить объем дискового пространства, используемого для изображений, поскольку оно будет генерировать миниатюры WebP в дополнение к уменьшенным размерам JPEG. Участник команды Performance Адам Сильверштейн поделился результатами опроса хостинговых компаний:
Чтобы оценить общее влияние генерации WebP-изображений на хранение данных на сайте, команда опросила хостинг-провайдеров. В общей сложности 17 ответов показали, что количество хранимых файлов, как правило, не является проблемой для большинства хостингов/сайтов, хотя место для хранения может стать проблемой для некоторых пользователей со временем. Тем не менее, для крупных хостеров (с 1 000 и более размещенных сайтов) подавляющее большинство сайтов (> 86%) не пострадают, даже если их требования к хранилищу удвоятся. Мы также узнали, что некоторые дешевые хостинг-планы с ограниченным хранилищем также не имеют поддержки WebP в своем хостинг-стеке, что означает, что для них не будет дополнительной генерации изображений.
Возможно, в утверждении о том, что "количество хранимых файлов обычно не является проблемой для большинства хостов/сайтов", заложено несколько предположений. Ответы на опрос команды показали, что 58% пользователей не пострадают от удвоения требований к хранилищу. В опросе участвовали только 17 хостеров, и названия компаний не были включены в данные. Даже с учетом того, что, по оценкам, 14% сайтов находятся в зоне риска, это может повлиять на миллионы сайтов WordPress.
Команда Performance предлагает несколько заметных изменений для решения проблем, включая предоставление сниппета JavaScript, который определяет браузеры, не поддерживающие WebP, и загружает вместо них JPEG. Дополнительные изменения WebP по умолчанию включают следующее:
- В версии 6.1 по умолчанию автоматическая генерация WebP-версии только основных размеров изображений. Для получения автоматически генерируемых WebP-версий пользовательских размеров изображений придется изначально согласиться на их использование, или отказаться, если они используются исключительно в особых случаях, когда WebP не выгоден или не поддерживается.
- Сохранение вторичных (WebP) вспомогательных размеров только в том случае, если они меньше первичного MIME-типа.
- Генерирование WebP-изображений только для тех размеров изображений, которые предназначены для использования в пользовательском внешнем контенте. Это позволяет избежать траты пространства для хранения WebP-изображений, которые никогда не будут использоваться.
- Внедрение фильтра для управления генерацией дополнительных типов MIME на основе дополнительных размеров изображений. Это позволяет разработчикам исключить определенные размеры изображений, например, те, которые не используются во внешнем контенте.
Предложение о WebP по умолчанию будет касаться только новых изображений, загруженных после его включения в ядро. Оно не будет автоматически генерировать WebP-изображения для существующих загрузок. Пользователи, которые хотят конвертировать загруженные ранее изображения, должны будут использовать WP-CLI или плагин типа Regenerate Thumbnails.
Изменения, внесенные в предложение, пока получили неоднозначную реакцию. Некоторые решительно поддерживают новый подход, другие призывают команду рассмотреть некоторые практические последствия для пользователей, которые могут возникнуть.
"Нельзя просто сказать, что это нормально, потому что "подавляющее большинство сайтов (> 86%) не пострадает. Во-первых, 14% с точки зрения WordPress - это очень много. Нам как-то нужно продолжать поддерживать 2,8% сайтов, все еще работающих на PHP 5.6, а получается, что 14% нам не так уж и важны?. Здесь нужно подумать не только о том, ЕСЛИ, но и о том, КАК это отразится на 14% сайтов, причем не только сегодня, но и в будущем. Будут ли сайты просто плавно обновлять хранилище, или же у них закончится дисковое пространство и произойдет сбой? Или резервное копирование внезапно начнет давать сбои?"
- сказал разработчик WordPress Джон Браун
Несколько участников в комментариях предложили WordPress рассмотреть возможность принятия более современного формата AVIF, который имеет лучшее качество и сжатие по сравнению с WebP.
"Поскольку эта инициатива по сути является прогрессивным усовершенствованием, не имеет ли больший смысл вместо этого поддерживать форматы следующего поколения, такие как AVIF, при этом изящно отступая? Тогда браузеры сами подтянутся, добавив поддержку со временем. Переход на поддержку WebP похож на то, как если бы WordPress добавил REST API, в то время как все начали переходить на GraphQL. REST - это здорово, как и WebP, но это технология текущего поколения, и она быстро устареет".
- сказал разработчик JavaScript Кевин Батдорф
Участник команды по производительности Бетани Чобанян Ланг сказала, что AVIF находится в их поле зрения, но его браузерная поддержка все еще отсутствует менее чем в 70% веба.
Обсуждения продолжаются в комментариях к обновлению, и Сильверштейн также призвал к участию в тикете Trac для пересмотра подхода. Участники команды по производительности намерены объединить это изменение в начале цикла выпуска 6.1, чтобы получить больше тестов.
