Поддерживать WebP с использованием изображения HTML или на стороне сервера через заголовки http?

Кажется, есть два способа показать изображения WebP браузерам, которые его поддерживают.

  1. Используйте элемент HTML Picture

<picture> <source srcset="image.webp" type="image/webp"> <img src="image.jpg"> </picture>

  1. Обнаружить на HTTP-сервере. Таким образом, запрос / изображение, и сервер определяет через заголовки HTTP-запроса, поддерживает ли клиент webp или нет, обслуживает ли он изображение webp, если он не обслуживает изображение jpg.

Какой подход лучше, каковы плюсы и минусы каждого?


http webp
person AndrewHarvey    schedule 07.11.2018    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Обновить ответ (на основе комментариев к ответу):

В целом оба подхода дадут одинаковый выигрыш в производительности. Какой из двух вариантов лучше, зависит от вашей ситуации (подробно описано ниже):

  1. Подход №1 (тег ‹picture›)

Преимущество использования тегов ‹picture› в том, что никаких изменений на стороне сервера не требуется. Итак, в настройках, где изменение конфигурации сервера / CDN является проблемой - это должно помочь.

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

  1. Подход № 2 (изменение формата изображения, доставляемого на основе заголовков http)

Основное преимущество этого подхода - отсутствие изменения кода в вашем HTML.

При таком подходе следует соблюдать осторожность: вы должны быть уверены, что ваша серверная среда и CDN поддерживают доставку различных форматов изображений на основе HTTP-заголовка.

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

Для получения дополнительной информации посетите https://www.tezify.com/how-to/using_webp_images/

Исходный ответ:

Подход №1 (использование элемента) имеет больший смысл. В первую очередь потому, что по мере улучшения браузером поддержки webp новые браузеры будут загружать изображения webp.

В случае подхода № 2 (с использованием обнаружения на стороне сервера через строку агента-пользователя) вам либо придется обновить код обнаружения, либо улучшенная поддержка webp не отразится на вашем решении для загрузки изображений.

person Punit S    schedule 29.11.2018
comment
Подход № 2 вообще не использует пользовательский агент, он основан на заголовке Accept developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept - person AndrewHarvey; 29.11.2018
comment
Понятно, в этом случае проблема, о которой я говорил с # 2, не существует. Для № 2, будет ли сервер обслуживать другой HTML (один с изображениями webp в IMG SRC), если webp будет принят? - person Punit S; 30.11.2018
comment
Идея заключалась в том, чтобы поместить URL-адрес типа / image / 1 в src и заставить веб-сервер обслуживать либо webp, либо jpg на основе заголовка Accept. Так что HTML для всех одинаковый. Таким образом, если кто-то решит щелкнуть изображение правой кнопкой мыши и скопировать URL-адрес, а затем поделиться им, получатель никогда не получит ссылку на формат, который он не может открыть, что, на мой взгляд, является недостатком b # 1. Обратной стороной # 2 является то, что вы, вероятно, не можете сделать это с S3 и т. Д., Но через конфигурацию вашего собственного веб-сервера вы можете. - person AndrewHarvey; 30.11.2018
comment
Кроме того, если вы используете CDN, подход / image / 1 может не работать. Итак - ваши запросы изображений должны всегда обслуживаться веб-сервером. - person Punit S; 30.11.2018

arrow_upward
1
arrow_downward

Решение HTML5 <picture> или поддержка JavaScript Определение поддержки WebP лучше, потому что загрузка веб-сайта выполняется быстрее (меньше запросов). Решение JavaScript, возможно, является лучшим решением, учитывая тот факт, что по соображениям производительности такие фреймворки, как React или Vue, заполняют динамические фрагменты веб-сайта через JS, а HTML - это только «скелет страницы», который позволяет кэшировать все ресурсы для еще большей производительности (поэтому только API должен быть загруженным и обновленным). Плохая сторона HTML-решения - <picture> в старом браузере может отображаться не так, как ожидалось. Вы также можете найти эту статью полезной.

person Zydnar    schedule 16.11.2018
comment
Я не понимаю, почему меньше запросов с использованием ‹picture› поверх заголовка Accept для определения поддержки developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation/ - person AndrewHarvey; 17.11.2018
comment
@AndrewHarvey Это зависит от архитектуры, но в любом случае это быстрее, потому что серверу не нужно компилировать шаблоны или выбирать между скомпилированными представлениями. - person Zydnar; 17.11.2018
comment
Нет никаких компилируемых шаблонов, это просто веб-сервер, выбирающий, какой формат изображения обслуживать. - person AndrewHarvey; 18.11.2018

arrow_upward
1
arrow_downward

Я бы сказал, что если это имеет смысл для вашего приложения, лучше обнаружить его на стороне сервера, изучив заголовок 'Accept', поскольку он не зависит от поддержки тега <picture>, с которым можно ознакомиться здесь. Большинство современных браузеров поддерживают его, но не старые версии.

Причина, по которой я могу думать об этом на стороне клиента, заключается в том, что это статическое приложение или у вас нет контроля над сервером.

person learn2day    schedule 28.06.2020