company_banner

Использование современных графических форматов в веб-проектах

Автор оригинала: Joshua Comeau
  • Перевод
Эдди Османи, в статье «Цена JavaScript в 2018 году», озвучил одну ценную мысль: время, необходимое на обработку скрипта размером 200 Кб, и на обработку изображения, имеющего такой же размер, серьёзно различается. Дело в том, что при обработке кода браузеру нужно проделать более масштабную работу, чем при подготовке к использованию изображений. Вот что об этом говорится в статье:

JPEG-изображение нужно декодировать, растеризовать и вывести на экран. А JS-бандл надо, если рассматривать это упрощённо, загрузить, распарсить, скомпилировать, выполнить. На самом же деле движку приходится решать и другие задачи в процессе обработки JS-кода. В целом, стоит учитывать, что на обработку JavaScript-кода, размеры которого, в байтах, сопоставимы с размерами других материалов, тратится гораздо больше системных ресурсов.

Эти слова были написаны в 2018 году, но они до сих пор более чем справедливы. Правда, учитывая текущую обстановку, высказанная здесь мысль сегодня воспринимается немного иначе.



Принимая во внимание то, что в мире сейчас разразилась пандемия, я заметил, что моё интернет-соединение стало работать нестабильно. К нашему счастью, благодаря тому, что на страже благополучия интернета стоят прекрасные специалисты, не знающие усталости, большая часть Всемирной сети до сих пор работает нормально. Но в интернете, определённо, что-то происходит. Я пользуюсь соединением на 100 Мбит/с, но у меня возникает такое ощущение, будто я сижу на 3G-модеме.

Это вносит некоторые изменения в вышеприведённые рассуждения. Дело в том, что наши устройства могут парсить и компилировать JavaScript с той же скоростью, с которой они могли это делать пару недель назад. Но данные теперь путешествуют по сетям медленнее. В результате в настоящий момент крайне важно то, какой именно объём данных, представляющих некий ресурс, передаётся по сети при загрузке этого ресурса.

А на сайтах обычно имеется гораздо больше, чем 200 Кб изображений. Страница с несколькими мегабайтами картинок — это обычно дело. Многие разработчики (и я тоже!), как правило, совсем не задумываются о размерах медиа-материалов.

Но, что очень хорошо, оптимизировать изображения, используемые на веб-страницах, не так уж и сложно. В этом материале мы поговорим о том, как пользоваться современными графическими форматами вроде WebP. Изображения, сохранённые в таких форматах, часто оказываются в 2-3 раза меньше, чем те, для хранения которых используются всем известные и всеми любимые старые форматы (вроде JPG и PNG). Применение новых форматов может серьёзно изменить ситуацию в лучшую сторону.

Общий обзор современных графических форматов


Для улучшения работы с веб-графикой мы можем воспользоваться следующими тремя форматами:

  • JPEG 2000 — формат, представляющий собой улучшенный вариант обычного JPG. Этот формат был разработан в 1997 году, преимущественно для использования в кинематографе и в медицине. Он позволяет сжимать изображения сильнее, чем JPEG, но с меньшим количеством артефактов.
  • JPEG XR — это формат, родственный JPEG 2000. Он разработан компанией Microsoft в 2009 году.
  • WebP — формат, созданный Google в 2010 году для веб. Основная цель его разработки заключалась в использовании продвинутых способов оптимизации изображений ради уменьшения размеров файлов. WebP поддерживает прозрачность и даже анимацию.

Здесь мы, в основном, будем говорить о WebP. Форматы, родственные JPEG, мы обсудим там, где будет поднят вопрос браузерной совместимости.

Много ли можно выиграть, пользуясь альтернативными графическими форматами?


Несколько месяцев назад я использовал в одном материале следующее изображение.


Изображение, использованное в одном материале

Я провёл некоторые эксперименты, рассмотрев использование форматов JPG и PNG для хранения исходного изображения. Я оптимизировал варианты изображения с использованием imagemin для того чтобы узнать о том, что мне может дать применение WebP вместо этих «ретро»-форматов.

Результаты оказались прямо-таки невероятными.
Особенности изображения Оригинал WebP
Файл в формате .png (из Photoshop) 742 Кб 61 Кб! (на 92% меньше)
Оптимизированный файл в формате .png (после Imagemin) 178 Кб 58 Кб! (на 67% меньше)
Файл в формате .jpg (из Photoshop) 242 Кб 50 Кб! (на 79% меньше)
Оптимизированный файл в формате .jpg (после imagemin) 151 Кб 50 Кб! (на 67% меньше)

Я проводил подобные эксперименты с множеством изображений. Практически всегда оказывалось, что WebP-файлы были на 30-70% меньше чем даже оптимизированные версии графических файлов других форматов.

Тут может возникнуть вопрос о том, как преобразование в WebP может повлиять на SVG-изображения. Я подобных экспериментов с SVG не проводил. SVG — это векторный формат. Это значит, что изображения в нём строятся на основе математических инструкций, а не на основе сведений о цвете отдельных пикселей. Преобразовать SVG-изображение в WebP — значит отказаться от возможностей по масштабированию SVG-изображений, что, полагаю, недопустимо. К тому же, я подозреваю, что подобное преобразование, в большинстве случаев, приведёт к увеличению размеров файлов.

Браузерная совместимость


Для того чтобы узнать о том, как те или иные графические форматы поддерживаются браузерами, заглянем на caniuse.com.

Формат WebP пользуется поддержкой большинства браузеров.


Поддержка формата WebP браузерами

Хоть уровень поддержки этого формата и весьма высок, очень плохо то, что его не поддерживают Safari и Internet Explorer.

А вот — сведения о поддержке JPEG 2000.


Поддержка формата JPEG 2000 браузерами

Так, теперь Safari на нашей стороне, а вот Internet Explorer опять остался не у дел.

А как насчёт JPEG XR?


Поддержка формата JPEG XR браузерами

А тут отличился именно Internet Explorer. В результате, пользуясь этими тремя форматами, мы перекрываем все существующие браузеры (KaiOS Browser не поддерживает ни один из этих форматов, и я приношу ему свои извинения за то, что обхожу его вниманием, но я даже не знаю о том, что это за браузер).

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

Элемент picture спешит на помощь


В HTML есть два элемента, предназначенных для вывода изображений. Первый можно сравнить с международной поп-звездой вроде Мадонны. Это — img. А второй — это как новая группа, известная лишь в узких кругах любителей музыки. Это — элемент picture.

Элемент picture появился в HTML гораздо позже, чем img. Главная цель этого нового элемента заключается в том, чтобы позволить разработчикам загружать различные графические ресурсы в зависимости от разрешения экрана, или в зависимости от того, поддерживает ли браузер некий графический формат.

Вот как выглядит HTML-код, в котором применяется элемент picture:

<picture>
  <source srcset="/images/cereal-box.webp" type="image/webp" />
  <source srcset="/images/cereal-box.jp2" type="image/jp2" />
  <img src="/images/cereal-box.jxr" type="image/vnd.ms-photo" />
</picture>

Элемент picture может включать в себя множество дочерних элементов source и один элемент img. Браузер последовательно парсит эти элементы, подбирая, на основе атрибута typemedia), тот из них, которым сможет воспользоваться. Когда такой элемент будет найден, браузер выясняет адрес изображения, пользуясь атрибутом srcset, после чего выводит это изображение с помощью элемента img.

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

В Chrome, например, после обработки вышеприведённой разметки, браузер придёт к чему-то, более или менее эквивалентному следующему коду:

<picture>
  <img src="/images/cereal-box.webp" />
</picture>

Использование набора следующих друг за другом элементов source означает, что в каждом браузере подходящим окажется хотя бы один из них. Так, большинство браузеров используют webp-изображение, Safari загрузит jp2-изображение, IE — jxr-изображение.

Тут уместно вспомнить о том, что Internet Explorer не поддерживает элемент picture. Этот элемент — слишком нов для данного браузера. Но, несмотря на это, вышеприведённый фрагмент разметки и в IE сработает так, как ожидается.

Дело в том, что когда браузер натыкается на неизвестный ему элемент, он рассматривает его как элемент div. В результате при разборе нашего кода IE видит множество элементов div, а также — один тег <img>, который содержит путь к jxr-изображению. А это, как оказывается, тот самый формат, который поддерживает Internet Explorer.

Упрощённая альтернатива


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

Если создавать такие изображения самостоятельно — придётся вложить в это много ручного труда. Если же генерировать их автоматически — это может значительно увеличить время сборки проекта. Обработка графики, как известно, становится весьма медленным процессом в том случае, если речь идёт о множестве изображений.

Лишь очень немногие посетители моего блога пользуются Internet Explorer (за последние 7 дней его попытались посмотреть лишь 3 человека с IE, что составило 0.02% трафика). Поэтому я решил воспользоваться упрощённым вариантом вышеописанного решения:

<picture>
  <source srcset="/images/cereal-box.webp" />
  <img src="/images/cereal-box.jpg" />
</picture>

Я отдаю компактное webp-изображение тем браузерам, которые поддерживают этот формат (Chrome, Firefox, Edge), а браузерам, которые этого формат не поддерживают (IE, Safari), предлагаю наследие прошлого — jpeg-картинку.

С моей точки зрения это — пример прогрессивного улучшения. Проект остаётся работоспособным на старых браузерах, хотя загрузка изображений и занимает больше времени. Это — компромисс, который меня устраивает. (Правда, я надеюсь, что поддержка WebP скоро появится и в браузерах от Apple).

Проверка работоспособности решения


Инструменты разработчика всегда будут полагать, что в изображении содержится то, что изначально было записано в атрибут src тега img. Если проверить элемент, воспользовавшись вкладкой Elements, то можно увидеть, что на странице используется jpg-изображение.

Для того, чтобы проверить работоспособность всего этого, лучше всего, как мне кажется, щёлкнуть правой кнопкой мыши по картинке и выбрать в появившемся меню пункт Сохранить изображение как… В Chrome при выполнении этой команды система должна предложить сохранить файл с расширением .webp. А вот в Safari это будет jpeg-файл.

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

Преобразование графических файлов в формат WebP


Компания Google создала набор инструментов, направленный на работу с webp-файлами. Один из таких инструментов называется cwebp. Он позволяет преобразовывать в WebP графические файлы других форматов.

Если вы пользуетесь MacOS, установить этот набор инструментов можно с помощью Homebrew:

brew install webp

На других платформах, полагаю, нужно будет загрузить подходящий libwebp-пакет из репозитория.

После установки инструментов пользоваться ими можно так:

cwebp -q 80 cereal.png -o cereal.webp

Рассмотрим эту команду:

  • Флаг -q 80 позволяет задать качество изображения. Его значение изменяется от 1 (наихудшее качество) до 100 (наилучшее). Можете поэкспериментировать с различными значениями. Я выяснил, что лучше всего задавать тут что-то в районе 70-80.
  • Имя файла cereal.jpg — это исходное изображение, которое нужно преобразовать в webp.
  • Конструкция -o cereal.webp задаёт путь к выходному файлу.

Никто не захочет тратить время, вводя подобные команды вручную. Эту задачу, к счастью, можно автоматизировать.

Использование современных графических форматов в React-приложениях


Компонент — это прекрасный способ абстрагироваться от некоторых странностей элемента <picture>. Я пользуюсь для этого React-компонентами. На мой взгляд, это очень удобно. Вот как это выглядит:

const ImgWithFallback = ({
  src,
  fallback,
  type = 'image/webp',
  ...delegated
}) => {
  return (
    <picture>
      <source srcSet={src} type={type} />
      <img src={fallback} {...delegated} />
    </picture>
  );
};

Использование компонента ImgWithFallback очень похоже на работу с обычным тегом img:

<ImgWithFallback
  src="/images/cereal.webp"
  fallback="/images/cereal.png"
  alt="A photo showing the expiration date on a box of Lucky Charms"
/>

Применение современных графических форматов со стилизованными компонентами


Если вы пользуетесь библиотеками styled-components или emotion, то вы, возможно, привыкли к особому оформлению изображений:

const FancyImg = styled.img`
  whatever: stuff;
`

Очень хорошо то, что это работает и с нашим компонентом ImgWithFallback. Заключить его в соответствующую обёртку можно так же, как любой другой компонент:

const FancyImg = styled(ImgWithFallback)`
  whatever: stuff;
`

Причина работоспособности этой конструкции заключается в том, как именно работает вспомогательная конструкция styled. Она генерирует класс и внедряет его в таблицу стилей документа. Затем имя сгенерированного класса передаётся компоненту в виде свойства:

<ImgWithFallback className="sc-some-generated-thing" />

Мы делегируем все свойства дочернему тегу <img>, в результате к изображению применяются, как это обычно происходит, правильные стили. Всё работает именно так, как можно ожидать.

Использование пакета gatsby-image


Если вы применяете Gatsby, то знайте, что пакет gatsby-image, при его обычном использовании, уже задействует множество оптимизаций изображений. Сюда входит и преобразование изображений в формат webp (хотя, для этого нужно включить соответствующий параметр).

Пакет gatsby-image не претендует на то, чтобы стать заменой img. Его использование может оказаться не таким уж и простым, его внутренние механизмы могут приводить к появлению неожиданностей, осложняющих разработчику жизнь.

Если этот пакет вам интересен — взгляните на его документацию.

Минусы WebP


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

Большинство настольных пакетов для работы с изображениями пока его не поддерживают. Например, я не могу открывать webp-файлы в Preview на MacOS. Это значит, скажем, что если я сохраню webp-изображение с веб-страницы, я не смогу просмотреть его на компьютере!

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

Итоги


Мне очень нравится то, что благодаря использованию webp удалось сократить размер изображений в моём блоге примерно на 50%. Помимо того, что в наше непростое время это улучшает впечатления пользователей от работы с ним, я ещё надеюсь на то, что это позволит мне немного сэкономить на оплате трафика.

Конечно, идея ручного преобразования графических файлов в формат webp выглядит весьма непрактичной. Я уже занимаюсь изучением вопроса о том, как автоматически конвертировать в этот формат jpg- и png-файлы. В идеале этот процесс должен происходить совершенно незаметно для разработчика, во время сборки сайта.

Создатели веб-проектов обычно не особенно интересуются особенностями применения новых графических форматов. Но я полагаю, что разбираться в этом вопросе весьма полезно. Ведь использование WebP — это, вероятно, самый простой способ сократить размеры веб-проекта на сотни килобайт.

Уважаемые читатели! Пользуетесь ли вы форматом WebP?

RUVDS.com
RUVDS – хостинг VDS/VPS серверов

Комментарии 17

    0

    Начали использовать webp недавно на своем проекте, порой в размере получаем выигрыш и более 70%, порой уменьшение размера по сравнению с JPEG — 2-3 и более кратное.


    Проблема поддержки в safari и ie решается просто и на фронте, если браузер их не поддерживает, фронт запрашивает картинку в формате png или jpeg.


    Картинки в webp конвертируются на лету специальным java бэкенд сервисом и кешируются cdn-ном. Сервис использует официальную консольную утилиту webp от google, иного варианта не нашли. Формат еще плохо поддерживается языками на уровне либ. Для java просто нет адекватной.

      0

      Жаль в статье рассмотрен только веб. На мобильных платформах с WebP тоже всё совсем неоднозначно.

        0
        Мне кажется более правильно будет переложить работу с webp на сторону веб-сервера. Это умеет делать модуль Pagespeed для Nginx, а также легко реализуется в виде Middleware. Веб-сервер проверяет по заголовку accept, поддерживает ли браузер формат webp, генерит картинку и складывает в кэш. Если не поддерживается и при первом обращении возвращает оригинал. Через атрибут srcset всё-таки лучше решать задачу с картинками под разные экраны.
          +5
          Все эти статьи забывают сообщить очень важную деталь, про потерю качества в webp. Оригинальное изображение и два обработанных через webp, одно из них с q80, другое с q100. И здесь внезапно оказывается, что если мы хотим сохранить качество изображения в lossless, то у webp преимуществ нет и пользоваться им нельзя. Это практически все фотографии, которые следует обрабатывать leanify.

          -rw-r--r-- 1 oz oz 164052 апр 3 01:50 cwebpq100.webp
          -rw-r--r-- 1 oz oz 62436 апр 3 01:50 cwebpq80.webp
          -rw-r--r-- 1 oz oz 88363 апр 3 01:45 ebb257a61229023d8aee7651708966c8.jpg

          WebP можно использовать там, где качество изображения не имеет никакой роли. Например — «Изображение, использованное в одном материале», которое мы и взяли для эксперимента.

          Писал про это же здесь: habr.com/en/post/482820/#comment_21096120
          Я слишком много потратил времени на эти статьи, чтобы всё же убедиться, что золотой пули нет. И что leanify чрезвычайно хороший и достаточный инструмент для оптимизации изображений без потери качества, замены которому на текущий момент нет.
            0

            Вы пробовали флаг -sharp_yuv (cwebp)? Для меня webp был очень мыльным по сравнению с jpg, пока не задействовал этот флаг.

            0
            Теперь маленький вопрос! Кто нибудь сталкивался с переформатированием примерно миллиона изображений из png в webp? какие средства при этом использовались? И сколько времени на то ушло?
              0
              А у вас необходимость именно за раз все сконвертировать?
                0
                Нет нужды за один заход конвертировать всё. Но понимать сколько это может занять времени — важно. Возможно люди здесь знают варианты которые мне потенциально могут быть не известны и могут быть быстрее известных мне, посему решил задать вопрос.
                  0
                  Посмотрите модуль sharp.
                  Его позиционируют как очень быстрый. Есть результаты бенчмарков где сравнивают скорость с другими инструментами. Правда там тестируют только JPEG формат. Не знаю на сколько он быстр по сравнению с другими в плане WebP. Но, на сколько я понял, его архитектура построена так, что он быстрый с любым форматом.
                  Я сам им пользуюсь (именно для работы с WebP) и вижу что он использует сразу все ядра процессора, что само по себе уже хорошо:

                  Конвертирование задействует все ядра процессора

                  Только-что попробовал конвертировать 50 JPG фотографий размером 2880 × 1920 px на макбуке с процессором 2,4 GHz Quad-Core Intel Core i5. У меня это заняло 8.5 сек.
                  В среднем 170 мс на фотографию.
                  Значит конвертирование пол-миллиона таких же фоток на моём ноуте займёт примерно 24 часа.
                    0
                    Можно не конвертить всё вообще, а генерить картинки при обращении. Первый посетитель получате JPG, остальные WEBP.
                  0
                  Pillow-SIMD должен подойти. Время будет зависить от размера изображений, необходимого качества, и количества ядер процессора.
                    0
                    Большое спасибо. Я поинтересуюсь этим чудом =)
                  +1

                  У всей этой истории есть ещё один небольшой неоднозначный момент: у вас не получится подставлять правильные изображения для картинок встроенных в другие теги (как например постер для видео)

                    0
                    В случае с видео экономия нескольких кб на превьюшке не так уже и повлияет на результат
                    0
                    Кажется, что поддержка конкретного формата — вопрос политический: тот, кто продвигает свой вариант, конкурентов старается не замечать. Поэтому стараюсь не использовать встроеный софт — доступных вариантов сейчас достаточно. Проверил поддержку формата: преобразовал png -> webp с помощью IrfanView, открыл в Opera 12 — все на месте.
                      0
                      У элемента picture есть один существенный недостаток. Если например он не загрузил нужный формат или не смог его отобразить, то на этом он останавливается. Это противоречит здравой логике, ведь в списке форматов ещё могут быть более тяжёлые альтернативы, лучшие чем ничего. Поэтому если ваш бэк генерит автоматом набор тегов, а скрипт-конвертер не создал лучшие форматы, юзер может ничего не увидеть вообще.
                      • НЛО прилетело и опубликовало эту надпись здесь

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое