Какой формат у браузера
Эта статья — расширенный вариант нашего внутреннего документа о том, как подготавливать изображения для сайтов и веб-приложений. В ней мы описали актуальные форматы и собрали рекомендации, как добавить поддержку WebP и AVIF на сайт и какие инструменты можно использовать. В заключительной части обзора расскажем, как мы внедрили эти форматы на нашем сайте и какие результаты получили.
Меня зовут Алексей, я работаю верстальщиком в компании FunBox. Мы разрабатываем продукты для мобильных операторов: геосервисы, мобильную рекламу, платежи, интерактивные сервисы и разное другое. Вы пользуетесь нашими продуктами каждый день или нет — тут у меня NDA.
В FunBox хороший продукт — это результат развитой инженерной культуры, и наш корпоративный сайт это подтверждает. Для нас это история о сапожнике в сапогах, ведь разрабатывать для веба, но не сделать нормальный сайт для себя как минимум не круто. Дальше расскажу, как делать хорошо.
Зачем использовать актуальные форматы изображений
Основное преимущество современных форматов изображений — это уменьшение объёма передаваемого по сети трафика, когда пользователь взаимодействует с сайтом или веб-приложением. Как следствие, страницы открываются быстрее, что положительно влияет как на впечатление пользователя, так и на позиции в поиске: сайты, которые быстро загружаются, получают более высокие позиции в выдаче Яндекса и Google. При этом качество графических материалов остаётся по-прежнему высоким при минимальных трудозатратах на внедрение. В то же время не рекомендуем использовать только самые модные форматы, так как в отдельных случаях это не принесёт большой пользы.
Краткое сравнение основных форматов изображений для веба
Все форматы изображений, которые используются в вебе, можно разделить на две большие группы: векторные и растровые. Из векторных форматов сейчас используется только SVG. Он отлично подходит для изображений с простыми геометрическими формами, например, пиктограмм или логотипов, и они одинаково хорошо выглядят как на обычных экранах, так и на устройствах с HiDPI-дисплеями, что делает SVG идеальным для адаптивной вёрстки под различные устройства. Но он не годится для изображений с большим количеством деталей, например фотографий, из-за размера файла, плюс браузеру потребуются немалые вычислительные ресурсы CPU для отрисовки.
Для фотографий на сайте лучше всего подходят растровые форматы. Самые известные и проверенные временем — JPEG и PNG. Есть ещё GIF для анимированных изображений, но он теряет актуальность, и всё чаще его рекомендуют заменить на HTML5-видео. С развитием веб-технологий JPEG и PNG всё чаще стали использоваться как фолбеки для браузеров, которые не поддерживают современные форматы растровых изображений, такие как WebP и AVIF. Сейчас в вебе JPEG отходит на второй план и уступает своё место новым форматам, так как они во многих аспектах его превосходят.
В 2010 году Google выпустили формат WebP как альтернативу PNG и JPEG. Он использует алгоритм сжатия ключевых кадров из видеокодека VP8, поэтому искажение исходного изображения выглядит иначе относительно других форматов. Сжатие состоит из двух этапов: на первом этапе предсказывается содержимое блоков по уже декодированным, на втором — кодируется ошибка предсказания (Википедия). WebP оставляет чёткие края фотографии, но сжатие с потерями ухудшает детализацию и текстуру. Также надо учитывать, что его настройки сжатия не соответствуют таковым для JPEG, другими словами, качество 50% для WebP и JPEG будет отличаться. В случае с WebP качество снижается достаточно сильно, поэтому рекомендуется начинать с наибольших значений и постепенно их уменьшать (Хабр).
WebP объединяет все достоинства форматов JPEG, PNG и GIF: сжатие с потерями и без потерь, поддержку прозрачности и анимации. Это позволяет использовать его для разных изображений, что упрощает подготовку и обработку графики на сайте. Кроме того, WebP обладает рядом преимуществ:
сжатие изображения без потерь на 26% лучше, чем у PNG;
сжатие изображения с потерями лучше JPEG на 25-34% при одинаковом индексе структурного сходства (SSIM);
поддержка прозрачности без потерь при увеличении размера всего на 22%.
С недавних пор появилась возможность использовать для изображений в вебе ещё один формат — AVIF. Это свободный формат сжатия с потерями качества, основанный на библиотеке для сжатия кадров AV1 (Википедия). Первая версия спецификации была выпущена в начале 2019 года, а первым браузером, который поддерживает изображения в формате AVIF, стал Google Chrome 85, релиз которого состоялся в конце августа 2020 года. Из основных возможностей этого формата отмечают следующие:
значительное уменьшение размера файла при сохранении визуального качества изображения;
поддержка анимированных изображений;
К недостаткам AVIF относят отсутствие поддержки прогрессивного рендеринга: пока изображение не скачается полностью, на его месте ничего не будет отображаться, тогда как JPEG и WebP могут показывать частично загруженное изображение (видео с наглядной демонстрацией).
Чтобы подробнее ознакомиться с WebP и AVIF и сравнить их с другими известными форматами изображений, рекомендую прочитать исследование Джейка Арчибальда и статью одного из авторов-разработчиков формата AVIF в блоге Netflix.
Выбор формата для изображений на сайте
Помимо преимуществ того или иного формата изображений, важно учитывать, поддерживают ли его браузеры. WebP поддерживается практически везде — его доля составляет более 95%:
AVIF в вебе поддерживают почти 70% браузеров:
Есть основания полагать, что все актуальные браузеры начнут полноценно поддерживать AVIF быстрее, чем это получилось с форматом WebP (формат анонсировали в 2010 году, но до браузера Safari его поддержка добралась только в конце 2020 года (!) с выходом Safari 14 и macOS 11 Big Sur). WebKit уже внедрил декодирование AVIF, но ещё не включил его по умолчанию.
Подготовка изображений в форматах WebP и AVIF
Рассмотрим инструменты для подготовки изображений в новых форматах. Одну-две иллюстрации можно обработать с помощью привычных инструментов: онлайн-сервисов, например Squoosh или avif.io, или графических редакторов. Ещё Google выпустили плагин WebPShop для Фотошопа, который добавляет возможность открывать и сохранять изображения в формате WebP, предварительно оценив качество в окне просмотра.
AVIF пока не так широко поддерживается: пока только в GIMP и Pixelmator Pro. Есть надежда, что по мере роста его популярности больше фоторедакторов научатся с ним работать.
Если не знаете, какую степень сжатия выбрать для начала, в качестве опорных значений можно взять цифры из сравнительной таблицы. Она показывает соответствие различных значений качества JPEG, WebP и AVIF. Стоит отметить, что значения, которые вы подберёте опытным путём на своём материале, могут отличаться от приведённых в этой таблице. Это вполне закономерно, так как для разных изображений может требоваться разная степень сжатия.
Если на сайте несколько десятков изображений, будет нерационально конвертировать их вручную в другой формат с помощью графических инструментов. Здесь на помощь приходят консольные утилиты, которые автоматизируют конвертацию и оптимизацию изображений, в том числе путём встраивания в сборку проекта.
Если стоит задача автоматизировать конвертацию изображений только в WebP, можно воспользоваться утилитой Google cwebp. Пример вызова утилиты из документации Google:
cwebp -q 80 image.jpg -o image.webp
Другим вариантом может быть использование утилит, поддерживающих работу сразу с несколькими форматами изображений. Например, мы в FunBox разработали утилиту optimizt. Она работает с наиболее популярными форматам изображений (PNG, JPEG, GIF, SVG) и конвертирует растровые изображения в WebP и AVIF. Пример вызова утилиты для конвертации всех изображений по переданному пути в WebP:
optimizt --webp path/to/directory
Аналогично для AVIF:
optimizt --avif path/to/directory
После автоматической конвертации набора изображений рекомендуем просмотреть их глазами, чтобы в погоне за экономией трафика ненароком не испортить качество графических материалов на сайте.
Как использовать актуальные форматы изображений на сайте
Чтобы использовать графические материалы в новых форматах, потребуется доработать код сайта. Для подключения контентных изображений достаточно использовать в разметке тег picture , в котором на первом месте указан путь до изображения:
Если браузер поддерживает AVIF или WebP, он загрузит и отобразит соответствующее изображение. В противном случае он проигнорирует путь до него и попытается загрузить следующее, указанное в source . Подробнее можно почитать в описании на MDN.
Для декоративных (фоновых) изображений, которые подключаются в CSS, потребуется чуть больше действий. Например, можно использовать специальные классы на корневом элементе html . Имена классов могут быть любыми, главное, чтобы было понятно, за что они отвечают. При помощи JS-кода можно проверять, какой формат поддерживает браузер, и присваивать элементу html соответствующий класс.
Вот пример такого кода, который размещается в блоке head разметки страницы:
Подчеркну, что этот код должен выполняться именно в head , чтобы избежать двойной загрузки одного и того же изображения в разных форматах: сначала в JPEG/PNG, а потом в AVIF/WebP.
Теперь нам нужно немного доработать стили, добавив в них подключение тех или иных изображений в зависимости от класса на элементе html . Вот как это может выглядеть на примере (синтаксис SCSS):
Из кода видно, что если браузер не поддерживает форматы AVIF и WebP, то изображение загружается в формате JPEG.
С помощью этих нехитрых приёмов мы готовы использовать изображения в формате AVIF и WebP на клиенте (в браузере). Также отмечу, что в настройках сервера нужно добавить кеширующие заголовки для форматов .avif/.webp наряду с остальными форматами изображений, если это не сделано по умолчанию.
Благодаря этим доработкам каждый браузер сможет выбрать наилучший из предложенных форматов изображений:
в Google Chrome 85+ и Firefox 93+ загрузится AVIF;
в Safari 14+ на macOS 11+ — WebP;
во всех остальных браузерах — JPEG или PNG.
Что нам дало использование новых форматов изображений
Мы исследовали, как новые форматы изображений влияют на объём трафика и скорость загрузки, на своём корпоративном сайте. Для оптимизации выбирали страницы, на которых есть иллюстрации, и сравнивали показатели до и после.
Начали с главной страницы, так как на неё попадают практически все посетители сайта и скорость её загрузки влияет на общее впечатление о компании. Она содержит два достаточно больших изображения: на первом экране и над футером. После перехода на WebP размер передаваемых данных при загрузке сократился почти на 55% для мобильных устройств и десктопа, а значение Largest Contentful Paint (LCP, время отрисовки самого большого видимого объекта) уменьшилось почти на 25%.
Следующая страница с изображениями — О нас. Она содержит много контентных фотографий, но большинство из них имеют небольшой размер в пикселях. Замена на WebP сэкономила 65-70% трафика в зависимости от устройства. Кстати, эта интересная особенность формата WebP — лучшее сжатие для небольших изображений в сравнении с AVIF — упоминается в статье на Хабре. А вот значение LCP практически не изменилось: стало меньше всего на 5%. Кажется, что такого не может быть, но всё логично: LCP определяется по длительности загрузки самого большого элемента на странице, которым в нашем случае является заглавная фотография, а после конвертации в WebP её размер несильно уменьшился. О причинах этого напишу далее.
И ещё один раздел сайта, в котором есть изображения — Контакты. Здесь находятся схемы проезда к нашим офисам в разных городах, и в качестве иллюстраций для точек на маршрутах мы используем фотографии мест, о которых идёт речь.
Здесь экономия от перехода на WebP уже не так заметна и составляет 17% по сравнению со старым добрым JPEG. И здесь возникает вопрос: почему же в этом случае трафик уменьшился не так значительно, как на других страницах? Всё дело в исходных изображениях, насколько они насыщены мелкими деталями. Для хорошо детализированных изображений, например фотографий на схемах проезда к офисам, пришлось практически вручную подбирать степень сжатия. Нередко она была выше принятых по умолчанию 75%, чтобы изображение после конвертации в WebP сохранило приемлемое качество по сравнению с оригиналом. Из этого можно сделать вывод, что использование WebP для реальных фотографий, насыщенных большим количеством мелких деталей, не всегда приводит к существенной экономии трафика. В отдельных случаях после конвертации изображение может весить даже больше, чем иллюстрация такого же визуального качества в формате JPEG.
Если коротко, внедрение WebP помогло нам сократить размер изображений на сайте:
на главной странице иллюстрации стали весить в 2 раза меньше;
на странице «О нас» удалось достичь почти трёхкратного сокращения общего размера изображений;
в разделе «Контакты» цифры оказались скромнее: всего –17%.
В начале 2021 года мы провели другой эксперимент: решили перевести все изображения в AVIF. Были опасения, что из-за отсутствия поддержки в nginx может ничего не получиться, к тому же AVIF слишком новый формат и при его использовании ещё встречаются некоторые проблемы. Одна из них проявилась спустя несколько месяцев после добавления на сайт AVIF-изображений. Мы заметили, что в одной из dev-версий браузера Firefox перестала отображаться часть иллюстраций. Выяснилось, что эти AVIF-изображения не соответствуют спецификации и содержат технические ошибки (подробное описание можно прочитать на баг-трекерах Chromium и Mozilla). Ошибка закралась в известную библиотеку sharp, которая используется под капотом нашего optimizt. Спустя 4 месяца автор sharp выпустил исправленную версию библиотеки, после чего мы заново переконвертировали изображения.
Тем не менее, результаты внедрения AVIF оказались неоднозначными. Так, на главной странице Retina-изображения показали гораздо лучшую компрессию с сохранением визуального качества (размер файлов уменьшился почти в 2 раза по сравнению с WebP), чем обычные. Надо учитывать, что используемые на странице иллюстрации созданы в графическом редакторе, это не реальные фотографии, а такие изображения, как правило, лучше сжимаются, потому что обычно на них гораздо меньше мелких деталей. А вот на странице «О нас» и на схемах проезда конвертация изображений в AVIF сэкономила всего 5-15% на общем размере файлов по сравнению с WebP. Можно сказать, что в этом случае нет большой разницы между WebP и AVIF. Поэтому если у вас на сайте уже есть WebP-изображения, то вам необязательно их переводить в AVIF — по итогу может оказаться, что результат не оправдает приложенных усилий. Другое дело, если вы ещё не внедрили WebP, в этом случае переход сразу на AVIF может кардинально ускорить загрузку страниц.
В качестве общего вывода отмечу, что всегда нужно делать замеры до и после изменения формата изображений. Это поможет объективно оценить полученные результаты и определить целесообразность перехода на WebP, AVIF или что-то ещё.
Что дальше?
Добавление поддержки WebP и AVIF на нашем сайте сэкономило нам до 50-60% трафика на отдельных страницах. При этом сами форматы привычны и их можно де-факто считать стандартом для изображений в вебе. Да, есть свои минусы (привет, Safari), но в конечном итоге их можно и нужно использовать на сайтах и в веб-приложениях. Посмотрим, что будет дальше. Уже завели таймер на следующий заход, когда появится новый формат изображений для веба, способный потеснить AVIF.
Эдди Османи, в статье «Цена 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 , а также — один тег , который содержит путь к 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-приложениях
Компонент — это прекрасный способ абстрагироваться от некоторых странностей элемента . Я пользуюсь для этого React-компонентами. На мой взгляд, это очень удобно. Вот как это выглядит:
Использование компонента ImgWithFallback очень похоже на работу с обычным тегом img :
Применение современных графических форматов со стилизованными компонентами
Если вы пользуетесь библиотеками styled-components или emotion , то вы, возможно, привыкли к особому оформлению изображений:
Очень хорошо то, что это работает и с нашим компонентом ImgWithFallback . Заключить его в соответствующую обёртку можно так же, как любой другой компонент:
Причина работоспособности этой конструкции заключается в том, как именно работает вспомогательная конструкция styled . Она генерирует класс и внедряет его в таблицу стилей документа. Затем имя сгенерированного класса передаётся компоненту в виде свойства:
Мы делегируем все свойства дочернему тегу , в результате к изображению применяются, как это обычно происходит, правильные стили. Всё работает именно так, как можно ожидать.
Использование пакета gatsby-image
Если вы применяете Gatsby, то знайте, что пакет gatsby-image , при его обычном использовании, уже задействует множество оптимизаций изображений. Сюда входит и преобразование изображений в формат webp (хотя, для этого нужно включить соответствующий параметр).
Пакет gatsby-image не претендует на то, чтобы стать заменой img . Его использование может оказаться не таким уж и простым, его внутренние механизмы могут приводить к появлению неожиданностей, осложняющих разработчику жизнь.
Если этот пакет вам интересен — взгляните на его документацию.
Минусы WebP
Единственным реальным недостатком webp, который мне удалось обнаружить, заключается в том, что с файлами этого формата очень неудобно работать.
Большинство настольных пакетов для работы с изображениями пока его не поддерживают. Например, я не могу открывать webp-файлы в Preview на MacOS. Это значит, скажем, что если я сохраню webp-изображение с веб-страницы, я не смогу просмотреть его на компьютере!
Преобразование webp-файлов в jpeg-файлы — процесс достаточно простой. В интернете можно найти много бесплатных сервисов, выполняющих подобное преобразование. Но, это, опять же, не так удобно, как работа с традиционными графическими форматами. Если ваш сайт предлагает пользователям загружать с него графические файлы — вы, возможно, решите, что переход на webp вам не нужен.
Итоги
Мне очень нравится то, что благодаря использованию webp удалось сократить размер изображений в моём блоге примерно на 50%. Помимо того, что в наше непростое время это улучшает впечатления пользователей от работы с ним, я ещё надеюсь на то, что это позволит мне немного сэкономить на оплате трафика.
Конечно, идея ручного преобразования графических файлов в формат webp выглядит весьма непрактичной. Я уже занимаюсь изучением вопроса о том, как автоматически конвертировать в этот формат jpg- и png-файлы. В идеале этот процесс должен происходить совершенно незаметно для разработчика, во время сборки сайта.
Создатели веб-проектов обычно не особенно интересуются особенностями применения новых графических форматов. Но я полагаю, что разбираться в этом вопросе весьма полезно. Ведь использование WebP — это, вероятно, самый простой способ сократить размеры веб-проекта на сотни килобайт.
Стандарт HTML5 поддерживает всевозможные странные методы. В то же самое время он возрождает (и стандартизует) некоторые старые либеральные правила HTML и вводит передовые возможности, которые работают только в новейших браузерах.
Что касается браузерной совместимости, функциональные возможности HTML5 можно разбить на три категории:
Возможности, которые уже работают . К этой категории принадлежат возможности, которые имеют высокий уровень поддержки, но официально не были частью стандарта HTML в прошлом (например, метод drag and drop). В нее так же входят возможности, которые можно реализовать для старых браузеров, приложив очень небольшие дополнительные усилия, наподобие семантических элементов.
Возможности с поэтапной деградацией . Например, если у старого браузера имеются проблемы с использованием нового элемента , этот элемент позволит вам предоставить браузеру какое-либо другое средство проигрывания например плеер, использующий подключаемый модуль Flash.
Возможности, требующие обходных решений JavaScript . Мотивацией для многих новых возможностей HTML5 послужили разработки, которые веб-программисты уже делали другим, более трудоемким, способом. Поэтому не стоит удивляться, что много из возможностей HTML5 можно дублировать с помощью хорошей библиотеки JavaScript (или, в худшем случае, написав энное количество строк кода собственного специализированного сценария JavaScript).
Создание обходного решения JavaScript может быть очень трудоемкой задачей, поэтому, если вы посчитаете, что определенная возможность является необходимой и требует обходного решения JavaScript, вы можете просто решить использовать это обходное решение для всех страниц и отложить использование методов HTML5 на будущее.
Поддерживает ли браузер вашу разметку?
Последнее слово в вопросе, в каком объеме использовать HTML5, принадлежит разработчикам браузеров. Если браузер не поддерживает какую-либо возможность, нет никакого смысла использовать ее, несмотря на все, что говорится в стандарте. В настоящее время существуют четыре или пять основных браузеров (не считая браузеров для мобильных устройств с возможностью подключения к Интернету, таких как смартфоны и планшеты iPad).
У разработчика-одиночки нет никаких шансов протестировать каждую потенциальную возможность на каждом браузере, не говоря уже о возможности оценить поддержку ее в старых версиях браузеров, которые широко используются до сих пор.
Сначала выберите вкладку Tables, а потом вкладку Compatibility tables и выберите на ней требуемую вам возможность (или группу возможностей), установив соответствующие флажки:
Можно выполнить поиск конкретной возможности, введя ее название в поле Search, расположенное по центру вверху страницы. Или же можно просмотреть целую категорию возможностей, установив соответствующий флажок в разделе Caterogy слева на странице. (В таком случае будет выведена таблица совместимости для каждой вложенной возможности.)
Например, чтобы проверить только возможности, которые считаются частью стандарта HTML5, сбросьте все флажки и установите только флажок HTML5. Чтобы проверить совместимость возможностей на основе JavaScript, которые сначала входили в HTML5, но потом были выделены в отдельную категорию, установите флажок JS API и т.д.
При желании, выберите другие опции, установив соответствующие флажки. Можно уточнить результаты поиска, удалив некоторые подробности. Например возможно, вас не интересует информация о совместимости с браузерами для мобильных устройств или с браузерами, которые находятся в стадии разработки и не были официально выпущены. Но обычно не стоит отказываться от этих подробностей, т.к. таблицы легко понимать даже с ними.
Прокрутите страницу вниз, чтобы просмотреть все результаты:
Для большого количества возможностей одновременно выводится только 20 таблиц результатов. Для просмотра следующих 20 таблиц результатов следует щелкнуть по ссылке Show next 20 внизу страницы.
В таблице для каждой возможности в заголовках столбцов указаны браузеры, в заголовках строк — их характеристики версий. Определенная версия браузера находится на пересечении соответствующего столбца и строки. Если возможность поддерживается данной версией браузера, соответствующая ячейка закрашена светло-зеленым цветом; частичная поддержка обозначается темно-зеленым, а отсутствие поддержки — розовым. Если неизвестно, поддерживается ли данная возможность, в ячейке не указывается номер версии браузера, а сама ячейка окрашена коричневым цветом.
Также приводится примерное количество браузеров, поддерживающих данную возможность, в процентах.
Статистика популярности браузеров
Последним важным пунктом проблемы поддержки возможностей браузерами является статистика популярности конкретных браузеров. Иными словами, информация о том, сколько посетителей Паутины пользуется браузером, поддерживающим возможности, которые вы намереваетесь использовать в своей разметке.
Одним из хороших источников этой информации является популярный сайт GlobalStats. На странице сайта в раскрывающемся списке Statistic выберите вариант Browser. А вариант Browser Version позволит просмотреть популярность не только конкретного браузера, но и каждой из его версий. Результаты можно сузить, выбрав конкретный регион или страну в раскрывающемся списке Country/Region:
Сайт GlobalStats собирает статистические данные ежедневно с помощью кода слежения, который установлен на миллионах веб-сайтов. Однако для вашего сайта цифры могут быть совершенно другими. Например вот статистика для этого сайта, полученная через Google Analytics за тот же период:
Как видите пользователей современных браузеров Google Chrome, Opera и Firefox гораздо больше чем в статистике от GlobalStats. При этом пользователей Internet Explorer всего 6%, что в три раза меньше чем в общемировой статистике. Эта статистика очень сильно зависит от тематики сайта. Данный сайт создан в основном для IT-специалистов, которые редко используют устаревшие браузеры. Если посмотреть статистику какой-нибудь популярной социальной сети, то количество счастливых обладателей браузеров IE
Определение возможностей с помощью Modernizr
В течение нескольких следующих лет абсолютно реальным будет то обстоятельство, что некоторые посетители вашего веб-сайта будут пользоваться браузерами, не поддерживающими HTML5. Но это не должно остановить вас от использования возможностей этого стандарта при условии, что вы согласны вложить немного усилий в разработку обходных решений или возможности поэтапной деградации. В любом случае вам, скорее всего, потребуется некоторая помощь JavaScript. Обычно это делается таким образом: после загрузки вашей страницы браузером запускается специальный сценарий, который проверяет, поддерживает ли браузер определенную возможность.
К сожалению, т.к. в своей основе HTML5 является набором связанных стандартов, одного общего теста на поддержку возможностей не существует. Вместо этого требуется выполнить несколько десятков разных тестов, чтобы проверить наличие поддержки различных возможностей, при этом иногда даже требуется проверять, поддерживается ли определенная часть возможности, что очень быстро делает задачу тестирования весьма неприятной.
При проверке поддержки некоторой функциональности браузером обычно требуется найти возможность в программном объекте или создать объект и использовать его определенным образом. Но подумайте хорошенько, прежде чем приступать к написанию кода тестирования такого типа, т.к. с этой задачей очень легко наломать дров.
Например, код для проверки поддержки возможности браузерами может не работать на некоторых браузерах по той или иной непонятной причине или быстро устареть. Вместо этого подумайте о применении компактного, постоянно обновляемого инструмента Modernizr, который проверяет поддержку браузерами широкого диапазона возможностей HTML5 и связанных возможностей. Он также предоставляет классный метод для реализации поддержки резервных решений при использовании новых возможностей CSS3.
Проверка веб-страниц с помощью Modernizr выполняется так:
Загрузите JavaScript-файл для Modernizr. Для этого в области Download Modernizr в верхней центральной части страницы нажмите кнопку Development.
Обычно, имя этого файла будет похоже на modernizr-2.0.6.js. Точное имя зависит от используемой версии. Некоторые разработчики переименовывают этот файл, убирая номер версии, например modernizr.js. Это позволяет обновить файл Modernizr в будущем, не требуя поиска и корректировки ссылок на него в веб-страницах, в которых он используется.
Код полной версии Modernizr несколько объемистый. Эта версия сценария предназначена для выполнения тестирования на стадии разработки веб-сайта. По окончании разработки, когда сайт можно публиковать для использования, можно создать облегченную версию сценария Modernizr, которая тестирует только требуемые возможности.
Для этого загрузите версию Production, нажав одноименную кнопку в области Download Modernizr. Откроется страница, предлагающая выбрать возможности, поддержку которых вы хотите проверять (установив соответствующие флажки), а потом создать свою специальную версию сценария Modernizr, нажав кнопку Generate слева внизу страницы.
Скопируйте файл сценария в папку, в которой находится веб-страница, требующая тестирования. Либо файл сценария можно поместить в подкаталог и подкорректировать должным образом путь к ней в ссылке JavaScript.
В блоке тестируемой веб-страницы вставьте ссылку на файл сценария Modernizr. В следующем листинге показан пример вставки этой ссылки:
Теперь, всякий раз при загрузке этой страницы будет исполняться сценарий Modernizr. В считанные миллисекунды сценарий тестирует поддержку пары десятков новых возможностей, а потом создает объект JavaScript, называющийся, опять же, Modernizr и содержащий результаты тестирования. Чтобы проверить поддержку браузером определенной возможности, тестируются свойства этого объекта.
Полный список тестируемых с помощью Modernizr возможностей, а также код JavaScript для тестирования каждой из этих возможностей, смотрите в документации Modernizr.
Напишите сценарий, который тестирует требуемую возможность, а потом выполняет соответствующее действие. Пример возможного сценария для проверки поддерживается ли HTML5-возможность drag and drop, и вывода результатов в окне браузера показан в следующем листинге:
Хотя в этом примере показан правильный способ проверки поддержки возможности, применяемый в нем подход к обработке неподдерживаемой возможности не идеален. Вместо того чтобы просто проинформировать (пусть даже и самым вежливым образом) посетителя вашего веб-сайта о том, что его браузер не поддерживает определенную функциональность вашего сайта, намного лучше будет реализовать какое-либо обходное решение, даже если это решение и не будет таким изящным или обладать всеми способностями заменяемой возможности HTML5. Например, если неподдерживаемая возможность — всего лишь какая-то несущественная примочка, которая бесполезна для посетителя сайта, то эту проблему можно вообще игнорировать.
В рассмотренных ранее примерах использовались два популярных стандарта: 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, браузеры могут заупрямиться с воспроизведением вполне качественного мультимедийного файла.
Поддержка браузерами форматов мультимедиа
Все аудио- и видеоформаты в мире будут вам бесполезны, если вы не знаете, как они поддерживаются разными браузерами. Разобраться в этом вопросе вам поможет следующие таблицы, в которых показаны поддержки основными браузерами аудио- и видеоформатов:
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 | - | - |
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.
К счастью, элементы и поддерживают достаточно хорошую систему предоставления резервных решений, которая была хорошо отлажена новаторами веб-технологий. Но, к сожалению, война форматов означает, что содержимое нужно будет кодировать, по крайней мере, дважды, что является затратным процессом по времени, процессорным ресурсам и дисковому пространству.
Но прежде чем приступать к работе, нужно определиться со стратегией поддержки браузеров, которые не признают HTML5. По большому счету, веб-разработчики имеют на выбор два хороших пути:
Использовать Flash в качестве основного решения, а HTML5-решение в качестве резервного
Таким образом, все посетители вашего сайта смогут использовать Flash, за исключением тех, на чьих браузерах этот модуль не установлен. Эта стратегия имеет смысл, если вы уже предоставляете на своем сайте видеосодержимое посредством Flash, но хотите еще привлечь пользователей iPad и iPhone.
Использовать HTML5 в качестве основного решения, а Flash-решение — в качестве резервного
Таким образом, все посетители получают HTML5-видео и/или аудио, за исключением тех, кто использует старые браузеры, которые получают Flash-содержимое. Если вы пойдете этим путем, можно также поддерживать меньшее число форматов HTML5. В таком случае посетители, чьи браузеры хотя и поддерживают HTML5-мультимедиа, но не поддерживают предоставляемые вами форматы, также получат Flash-содержимое. Так как будущее за этим подходом, то он является предпочтительным при условии, что текущие ограничения HTML5 видео и аудио — вам не помеха.
В следующих разделах мы будем воплощать второй подход в жизнь. Таким образом, мы обеспечим для браузеров чисто HTML5-решение во всех случаях, когда это возможно.
ЭлементПервым шагом в обеспечении поддержки нескольких форматов будет удаление атрибута src из элемента или и замена его вложенным списком элементов . Например:
В данном случае элемент содержит два элемента , каждый из которых указывает на отдельный аудиофайл. Из указанных файлов браузер выбирает первый, формат которого он поддерживает. В частности, Opera возьмет файл mysong.ogg, a Firefox, Safari и Chrome - файл mysong.mp3.
Теоретически, браузер может определить, поддерживает он или нет конкретный файл, загрузив и исследовав небольшую его часть. Но лучшим подходом будет использовать атрибут type, чтобы предоставить правильный MIME-тип. Таким образом, браузер попытается загрузить только тот файл, который он, как считает, может воспроизвести.
Этот же метод применяется и для элемента . В следующем листинге показан пример указания видеосодержимого в двух разных форматах — 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 встречается открывающий тег элемента , он с ветерком проносится мимо него, не затрудняясь ознакомиться с атрибутом src и другими параметрами этого элемента. Но при всем этом, браузеры не игнорируют содержимое внутри неизвестного им элемента, что является важной особенностью. Это означает, что в случае следующей разметки:
браузеры, которые не понимают HTML5, ведут себя, как будто бы они видели вот эту разметку:
Эта особенность и лежит в основе бесшовного предоставления резервного решения для старых браузеров.
Правильный подход — это включить в качестве резервного содержимого другое работоспособное видеоокно, иными словами, любое содержимое, которое бы пользовалось на обычной видеостранице, т.е. странице без поддержки HTML5. Можно использовать видеопроигрыватель Flash (или аудиопроигрыватель Flash для аудио). К счастью, в Интернете существует масса видеопроигрывателей Flash, многие из которых бесплатные, по крайней мере, для некоммерческого использования. И большинство из них поддерживает формат H.264, который вы уже, наверное, используете для HTML5-видео.
В следующем листинге приведен пример использования в качестве резервной решения в элементе проигрывателя Flowplayer:
Если же требуется, наоборот, реализовать основное решение в виде Flash, а резервное — в виде HTML, нужно просто переставить строки из предыдущего примера. Начинаем с элемента :
Обычно этот подход следует применять только в том случае, если нужно расширить существующий веб-сайт на основе Flash для поддержки устройств Apple, таких как iPad. Кстати, существует по крайней мере один проигрыватель на JavaScript со встроенной возможностью резервного решения HTML5. Называется он JW Player.
Читайте также: