Какой формат у браузера

Обновлено: 06.07.2024

В рассмотренных ранее примерах использовались два популярных стандарта: MP3 для аудио и H.264 для видео. Этого достаточно для Chrome и Safari, но не для других браузеров.

Небольшие разработчики, такие как Mozilla, создатели браузера Firefox и разработчики Opera, не желают платить непомерно высокую для них цену за лицензию на использование таких популярных стандартов, как MP3 для аудио или H.264 для видео (хотя поддержка этих стандартов включена в версии Firefox 24 и выше, после солидного спонсирования от Google ;). И их трудно винить за это, ведь они предоставляют свои продукты бесплатно.

У компаний покрупнее (таких как Microsoft, Google или Apple) имеются свои оправдания почему надо избегать нелицензированных стандартов. Они жалуются, что качество работы этих стандартов будет ниже (в настоящее время они не поддерживают аппаратное ускорение) и что они не так широко используются, как запатентованные стандарты, такие как, например, H.264, который используется в камкордерах, проигрывателях Blu-Ray и во многих других разных устройствах.

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

Знакомимся с форматами

Официальный стандарт HTML5 не требует, чтобы браузеры поддерживали какой-либо конкретный аудио- или видеоформат. (Ранние версии стандарта содержали такую рекомендацию, но в результате интенсивного лоббирования она была отменена.) Вследствие этого разработчики браузеров могут выбирать форматы, какие они хотят поддерживать, несмотря на то обстоятельство, что разные форматы органически несовместимы друг с другом. Список и краткое описание основных форматов, используемых в настоящее время, приведен в таблице:

Формат	Описание	Расширение файла	MIME тип
MP3	Самый популярный аудиоформат в мире. Но стоимость лицензии делает его непрактичным для небольших разработчиков, наподобие Opera	mp3	audio/mp3
Ogg Vorbis	Открытый, бесплатный стандарт, предоставляющий высококачественное сжатое аудио, сравнимое с MP3	ogg	audio/ogg
WAV	Первоначальный формат для сырого цифрового аудио. Не использует сжатие, поэтому файлы невероятно большого объема и непригодны для большинства интернет-приложений	wav	audio/wav
H.264	Промышленный стандарт для кодирования видео, особенно при работе с видео высокой четкости. Применяется в бытовых устройствах (таких как проигрыватели и камкордеры Blu-Ray), на видеообменных сайтах (таких как YouTube и Vimeo) и в браузерных модулях расширения (таких как Flash и Silverlight)	mp4	video/mp4
Ogg Theora	Открытый, бесплатный стандарт для видео, созданный разработчиками аудиостандарта Vorbis. Качество и производительность ниже стандарта H.264, но достаточно высокие, чтобы удовлетворить потребности большинства пользователей	ogv	video/ogg
WebM	Новейший бесплатный видеоформат, созданный Google на основе приобретенного ими VP8. Критики доказывают, что его качество еще не на уровне видео H.264 и он может содержать скрытые связи с другими патентами, что может вызвать лавину судебных исков в будущем. Тем не менее, WebM является наилучшим выбором для будущего открытого видео	webm	video/webm

В этой таблице также указаны рекомендуемые расширения файлов для мультимедиа. Чтобы осознать, почему это важно, нужно понимать, что для создания видеофайла в действительности применяются три разных стандарта. Первым, наиболее очевидным, стандартом является видеокодек, применяемый для сжатия видео в поток данных. В качестве примера можно назвать такие кодеки, как H.264, Theora и WebM.

Вторым является аудиокодек, который применяется для сжатия одной или нескольких аудиодорожек. Например, для видео в формате H.264 обычно используется звук в формате MP3, а для видео Theora - звук Vorbis. Наконец, формат контейнера применяется для упаковки видео и аудио вместе с описательной информацией и, необязательно, другими безделушками типа изображений и субтитров. Часто расширение файла обозначает формат контейнера, т.е. расширение mp4 означает контейнер типа MPEG-4, расширение ogv — контейнер Ogg и т.п.

Но не все так просто, т.к. формат контейнера поддерживает несколько разных аудио- и видеостандартов. Например, популярный контейнер Matroska (mkv) может содержать видео в формате H.264 или Theora. Чтобы не усложнять этот вопрос излишними подробностями, в приведенной таблице каждый видеоформат соотнесен с наиболее употребляемым для его упаковки контейнером, для которого также обеспечивается наиболее высокий уровень поддержки для Интернета.

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

Поддержка браузерами форматов мультимедиа

Все аудио- и видеоформаты в мире будут вам бесполезны, если вы не знаете, как они поддерживаются разными браузерами. Разобраться в этом вопросе вам поможет следующие таблицы, в которых показаны поддержки основными браузерами аудио- и видеоформатов:

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

IE	Firefox	Chrome	Safari	Opera	Safari iOS	Android
MP3	9	24	5	3.1	-	3	-
Ogg Vorbis	-	3.6	5	-	10.5	-	-
WAV	-	3.6	8	3.1	10.5	-	-

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

IE	Firefox	Chrome	Safari	Opera	Safari iOS	Android
H.264	9	24	5	3.1	-	4	2.3
Ogg Theora	-	3.5	5	-	10.5	-	-
WebM	9 (при установке кодеков)	4	6	-	10.6	-	2.3

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

Если вы хотите, чтобы видео проигрывалось на мобильных устройствах, примите за правило кодировать его в формате H.264 Baseline Profile (а не в формате High Profile). Для телефонов iPhone и под управлением операционной системы Android следует использовать размер 640x480, а для BlackBerry — 480x360. Многие программы кодирования имеют предварительные настройки, с помощью которых можно создать видео, оптимизированное для мобильных устройств.

Множество форматов: как понравиться всем браузерам

Что делать бедному веб-разработчику со всеми этими форматами? Горькая правда состоит в том, что ни один аудио- или видеоформат не будет работать на всех браузерах. Если вы хотите поддерживать все браузеры, а поддерживать их все вы должны, вам нужно запастись мультимедийными файлами в нескольких форматах. Кроме этого, вам, скорее всего, нужно будет организовать резервное решение Flash для посетителей, которые пользуются браузерами, не признающими HTML5, такими как, например, IE8.

К счастью, элементы <audio> и <video> поддерживают достаточно хорошую систему предоставления резервных решений, которая была хорошо отлажена новаторами веб-технологий. Но, к сожалению, война форматов означает, что содержимое нужно будет кодировать, по крайней мере, дважды, что является затратным процессом по времени, процессорным ресурсам и дисковому пространству.

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

Использовать Flash в качестве основного решения, а HTML5-решение в качестве резервного

Таким образом, все посетители вашего сайта смогут использовать Flash, за исключением тех, на чьих браузерах этот модуль не установлен. Эта стратегия имеет смысл, если вы уже предоставляете на своем сайте видеосодержимое посредством Flash, но хотите еще привлечь пользователей iPad и iPhone.

Использовать HTML5 в качестве основного решения, а Flash-решение — в качестве резервного

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

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

Элемент <source>

Первым шагом в обеспечении поддержки нескольких форматов будет удаление атрибута src из элемента <video> или <audio> и замена его вложенным списком элементов <source>. Например:

В данном случае элемент <audio> содержит два элемента <source>, каждый из которых указывает на отдельный аудиофайл. Из указанных файлов браузер выбирает первый, формат которого он поддерживает. В частности, Opera возьмет файл mysong.ogg, a Firefox, Safari и Chrome - файл mysong.mp3.

Теоретически, браузер может определить, поддерживает он или нет конкретный файл, загрузив и исследовав небольшую его часть. Но лучшим подходом будет использовать атрибут type, чтобы предоставить правильный MIME-тип. Таким образом, браузер попытается загрузить только тот файл, который он, как считает, может воспроизвести.

Этот же метод применяется и для элемента <video>. В следующем листинге показан пример указания видеосодержимого в двух разных форматах — H.264 и Theora:

В этом примере следует отметить одну новую особенность. При использовании разных видеоформатов файл в формате H.264 всегда должен быть в списке первым. В противном случае он не будет проигрываться на старых устройствах iPad под управлением iOS 3x. (Эта проблема была решена в операционной системе iOS 4, но размещение файла H.264 вверху списка ничем ничему не вредит.)

Так сколько же видеоформатов следует использовать? Чтобы прикрыть все тылы необходимо использовать форматы H.264 и Theora для основного решения HTML5 и Flash для резервного. Для лучшего качества видео формат Theora можно заменить форматом WebM. Или же можно совсем разойтись и включить все версии своего видео — H.264, Theora и WebM в указанном порядке. Версия WebM идет перед версией Theora для того, чтобы браузеры, которые поддерживают эти формата, выбрали видео лучшего качества.

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

Резервное решение Flash

Испокон веков все браузеры обрабатывают нераспознаваемые теги одинаково - игнорируют их. Например, если Internet Explorer 8 встречается открывающий тег элемента <video>, он с ветерком проносится мимо него, не затрудняясь ознакомиться с атрибутом src и другими параметрами этого элемента. Но при всем этом, браузеры не игнорируют содержимое внутри неизвестного им элемента, что является важной особенностью. Это означает, что в случае следующей разметки:

браузеры, которые не понимают HTML5, ведут себя, как будто бы они видели вот эту разметку:

Эта особенность и лежит в основе бесшовного предоставления резервного решения для старых браузеров.

Правильный подход — это включить в качестве резервного содержимого другое работоспособное видеоокно, иными словами, любое содержимое, которое бы пользовалось на обычной видеостранице, т.е. странице без поддержки HTML5. Можно использовать видеопроигрыватель Flash (или аудиопроигрыватель Flash для аудио). К счастью, в Интернете существует масса видеопроигрывателей Flash, многие из которых бесплатные, по крайней мере, для некоммерческого использования. И большинство из них поддерживает формат H.264, который вы уже, наверное, используете для HTML5-видео.

В следующем листинге приведен пример использования в качестве резервной решения в элементе <video> проигрывателя Flowplayer:

Если же требуется, наоборот, реализовать основное решение в виде Flash, а резервное — в виде HTML, нужно просто переставить строки из предыдущего примера. Начинаем с элемента <object>, в который вставляем элемент <video> непосредственно перед закрытием тега </object>:

Обычно этот подход следует применять только в том случае, если нужно расширить существующий веб-сайт на основе Flash для поддержки устройств Apple, таких как iPad. Кстати, существует по крайней мере один проигрыватель на JavaScript со встроенной возможностью резервного решения HTML5. Называется он JW Player.

Свершилось то, чего многие ожидали — крупнейшие видеосервисы (YouTube, Vimeo) предоставили в режиме бета-тестирования возможность воспроизводить ролики средствами HTML5. Казалось бы, всё прекрасно, и Flash-у пора уйти на заслуженный покой. Ан нет — оказалось всё не так гладко.

А разгадка одна — кодеки. Разработчики браузеров и поставщики контента не сошлись во мнении, какой кодек для видео использовать. На самом деле, эта проблема обсуждалась и ранее, и консенсуса по ней так и нет. В итоге из черновой спецификации HTML5 были удалены упоминания о конкретном кодеке.

Кодеки

На звание кодека для HTML5 video в данный момент претендуют два кодека — Ogg Theora и H.264.

Ogg Theora

Использовать Ogg Theora можно везде, всегда, без лицензионных или патентных отчислений.

H.264 — это лицензируемый стандарт сжатия видео. Его использование требует платы в странах, где действует патенты на него (в первую очередь, это США). Однако, на сегодняшний день, это один из самых лучших способов сжимать видео. Именно H.264 является стандартом де-факто сжатия HD-видео, к примеру. H.264 заметно эффективнее Ogg Theora по соотношению качество/битрейт.

Если кратко, H.264 — лучше, но даже его open-source реализации не могут быть использованы свободно в странах, где действуют патенты на него.

Реализации в современных браузерах

Здесь я упоминаю только те браузеры, в которых HTML5 video работает уже сейчас.

Mozilla Firefox

Реализация использует библиотеку liboggplay, а это означает, что могут использоваться только Ogg Theora для видео и Ogg Vorbis для аудио. Т.е. кодек фиксирован, и чтобы сделать поддержку чего-то ещё, нужно по сути переписать реализацию.

Google Chrome

Реализация использует статически привязанный ffmpeg. ffmpeg поддерживает кучу разных кодеков, включая и Ogg Theora, и H.264, и вообще практически всё, что сейчас реально используется.

К слову, ffmpeg в данный момент используется почти повсеместно — например, в CCCP и K-Lite Codec Pack, а также в mplayer и VLC используется именно ffmpeg.

Казалось бы, всё замечательно. Но! ffmpeg, хоть и open source, не может быть свободным в США. Для распространения программы, использующей ffmpeg, нужно платить отчисления. Google себе это может позволить, и имеет право выпускать билды со встроенным ffmpeg. Но совсем не такая ситуация с дистрибутивами Linux. Те из них, что выпускаются в США, не смогут включить в свои репозитории Chrome с поддержкой ffmpeg, так как это потребует платы отчислений. В первую очередь это касается такого небезызвестного дистрибутива, как Fedora.

Safari

Использует фреймворк QuickTime, что позволяет воспроизводить что угодно, если установлен соответствующий QuickTime-кодек.

Наверное, из современных реализаций эта наиболее правильная, т.к. имеет модульную архитектуру изначально. Но это всё сильно завязано на Mac OS, поэтому к остальным системам и браузерам неприменимо.

Суровая реальность

Теперь поговорим о поставщиках контента. Свобода~~, равенство, братство~~ — это всё хорошо в теории, но на практике вопрос решается небольшими зеленоватыми бумажками с портретами американских президентов. Google-у как-то проще заплатить за лицензию на более эффективный кодек, чем платить больше за трафик, и место на серверах. Мало того, учитывая то, что у них и так всё видео хранится в H.264, было бы особенно глупо (с точки зрения бизнеса, естественно), перекодировать это всё в Ogg Theora. Так что решение использовать H.264 — это абсолютная, экономически оправданная, жизненная необходимость. YouTube не станет использовать Ogg Theora. Не выгодно. Точка.

А мало того, использование H.264 выгоднее и нам, конечным пользователям. Мы же не платим лицензионные отчисления, а, тем не менее, получаем лучшее качество видео при меньшем количестве загруженных данных (привет жителям не-столиц с хилыми каналами в интернеты).

Всё плохо?

Сейчас — да. Но! Есть выход. Для декодирования видео в браузере нужно использовать модульный подход, не привязываясь к определённому кодеку. Мало того, в каждой операционной системе уже и так есть модульная инфраструктура кодеков. В Windows — это DirectShow, в Mac OS X — это QuickTime, в Linux — это gstreamer. А gstreamer ещё и кроссплатформенный, между прочим, и уже используется в кроссплатформенных программах, к примеру, Songbird для воспроизведения музыки использует именно gstreamer на всех платформах.

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

А мало того, в gstreamer предусмотрена возможность использовать кодеки, установленные в родном для данной системы фреймворке (для Windows — DirectShow, для Mac OS — QuickTime).

Светлое будущее, наступит ли оно?

Mozilla Firefox

Собственно, вот. Но, судя по комментариям там, сейчас такая интеграция планируется только для Fennec. Честно говоря, я искренее недоумеваю по этому поводу. Поддержка H.264 для Firefox нужна, и быстро, иначе есть большой риск остаться за бортом.

Google Chrome

Беда. Я пытался вникнуть в причину отказа, но она мне показалось не слишком веской. В принципе, тут нечего добавить. Можно почитать обсуждение, оно довольно жаркое. Ещё можно проголосовать за этот баг (отметить звёздочкой). Мало ли…

Opera

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

Другие браузеры

Неповоротливые гиганты легко могут оказаться позади маленьких, почти не используемых в широких массах браузеров, таких как Epiphany, Midori, Aurora. Все они используют WebKit. Epiphany и Midori используют GtkWebKit, в нём планируется (или уже сделана) поддержка HTML5 video через gstreamer. Aurora использует QtWebKit, в нём для HTML5 планируется (или уже частично сделано) использование Phonon, который, с свою очередь, может использовать разные бэкэнды, в том числе и gstreamer.

Однако, на текущий момент, ни в одном из них работающей поддержки HTML5 нет. Остаётся верить в их скорое светлое будущее, ведь оно вполне реально.

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

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

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

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

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

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

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

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

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

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

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

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

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

Результаты оказались прямо-таки невероятными.

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

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

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

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

Формат 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 и один элемент img . Браузер последовательно парсит эти элементы, подбирая, на основе атрибута type (и media ), тот из них, которым сможет воспользоваться. Когда такой элемент будет найден, браузер выясняет адрес изображения, пользуясь атрибутом srcset , после чего выводит это изображение с помощью элемента img .

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

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

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

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

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

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

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

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

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

Я отдаю компактное 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:

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

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

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

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

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

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

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

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

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

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

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

Мы делегируем все свойства дочернему тегу <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 — это, вероятно, самый простой способ сократить размеры веб-проекта на сотни килобайт.

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

Растровые форматы

Для начала рассмотрим форматы, которые относятся к растровой графике: GIF, JPEG, PNG и WebP. Подробнее о растровой графике можно прочитать в статье «Растровая и векторная графика».

Основные характеристики, которые нас будут интересовать при выборе формата — это качество изображения, вес и количество цветов. В вебе тяжёлые изображения непрактичны, поскольку они долго загружаются. Чтобы уменьшить вес файла, используются алгоритмы сжатия. Сжатие может быть с потерями и без потерь. При выборе подходящего формата изображения, нам нужно найти баланс между весом файла и качеством картинки, так как некоторые алгоритмы сжимают изображения с потерей качества. Теперь рассмотрим каждый из форматов подробнее.

GIF (Graphics Interchange Format)

Формат был разработан компанией CompuServe в далёком 1987 для передачи растровых изображений по интернету. GIF имеет цветовую палитру, состоящую из 256 цветов. Алгоритм GIF выбирает 256 наиболее используемых в исходном изображении цветов, а все остальные оттенки создаются путём подмешивания — подбора соседних пикселей таким образом, чтобы человеческий глаз воспринимал их как нужный цвет. По этой причине GIF не подходит для хранения полноцветных изображений и фотографий.

Формат поддерживает прозрачность — каждый пиксель изображения может быть в двух состояниях: прозрачный или непрозрачный, полупрозрачность не поддерживается.

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

Таким образом, формат GIF подходит если:

изображение не многоцветное;
нужна простейшая прозрачность;
нужна анимация.

JPEG (Joint Photographic Experts Group)

Формат JPEG получил своё название от объединённого комитета экспертов по фотографии, который и создал этот стандарт в конце 80-х — начале 90-х годов. Он был разработан для сжатия и хранения полноцветных фотографий. Поддерживает более 16 миллионов цветов.

Формат JPEG сжимает изображения с потерей качества. Алгоритм сжатия основан на разбиении исходного изображения на квадраты 8×8 пикселей, и последующей их группировке. Можно получать JPEG изображения очень маленького веса, но только за счёт ухудшения качества картинки, можно получить и очень качественные JPEG, но тогда картинка будет слишком тяжёлой. Поэтому главная задача при работе с JPEG — подобрать такой уровень качества, чтобы вес был небольшой и качество картинки было приемлемым (обычно, это диапазон от 60 до 70, но нужно тестировать на каждой картинке).

Пример изображения в формате JPEG с неоптимальной степенью сжатия. Качество: 10. Вес: 20 килобайт.

Первая картинка весит 20 килобайт. Это круто, очень мало, но для этого мы задали уровень качества 10 и картинка выглядит плохо.

Пример изображения в формате JPEG с оптимальной степенью сжатия. Качество: 60. Вес: 65 килобайт.

Вторая картинка с уровнем качества 60 весит чуть больше первой — 65 килобайт, но выглядит уже хорошо.

Пример изображения в формате JPEG с минимальной степенью сжатия. Качество: 95. Вес: 169 килобайт.

Для третьей картинки мы задали уровень качества 95, из-за чего её вес стал 169 килобайт. Вторая и третья картинка внешне почти неразличимы, однако вторая картинка весит на 104 килобайта легче.

Таким образом, формат JPEG лучше подходит для:

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

PNG (Portable Network Graphics)

PNG является относительно недавним форматом, который был введён как альтернатива для GIF-файлов.

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

Формат имеет две вариации: PNG8 и PNG24. PNG8 может хранить лишь 256 цветов, а PNG24 использует уже более 16 миллионов цветов.

Главная особенность формата PNG — поддержка альфа-прозрачности, то есть каждому пикселю в отдельности можно задать свою степень прозрачности.

Пример изображения в формате PNG (источник изображения: Wikimedia Commons)

Итак, формат PNG подходит для:

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

WebP — новый формат, созданный и развиваемый с 2010 года компанией Google.

Главная цель этого проекта — ещё больше уменьшить вес при сохранении такого же качества.

Формат использует новый алгоритм сжатия, в котором искажения отличаются от искажений других форматов. Ухудшается детализация и структура, в то время как края остаются чёткими.

сжимает изображения без потерь лучше, чем PNG (на 26% по данным Google);
сжимает изображения с потерями лучше, чем JPEG (на 25–34% по данным Google);
поддерживает прозрачность (альфа-канал).

Иногда WebP сжимает изображение даже лучше, чем заявляет Google.

JPEG: 44 килобайт WebP: 26 килобайт. Если изображение не видно, значит ваш браузер не поддерживает формат WebP.

Ввиду относительной новизны формата, не все браузеры умеют с ним работать. На сегодняшний день WebP поддерживается только Chrome, Opera и Firefox.

Векторные форматы

GIF, JPEG, PNG, и WebP — растровые форматы, основанные на дискретном (пиксельном, точечном) представлении изображения, в то время как векторные форматы основаны на математических формулах (геометрическом представлении фигур). Подробнее о векторной графике можно прочитать в статье «Растровая и векторная графика».

SVG (Scalable Vector Graphics)

SVG переводится как — масштабируемая векторная графика. Формат существует с 1999 года.

Размер объектов SVG намного меньше размера растровых изображений, а сами изображения не теряют в качестве при масштабировании. В отличие от растровых форматов мы можем взаимодействовать с изображениями в формате SVG — при помощи CSS можно изменять параметры графики: цвет, прозрачность или границы, а при помощи JavaScript — анимировать изображение.

SVG поддерживается почти всеми браузерами за исключением Internet Explorer 8 и ниже, но и это можно решить подключением JavaScript-библиотек, например, SVGeezy.

Читайте также: