Один размер подходит некоторым: руководство по адаптивным решениям для изображений в веб-дизайне

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

Хотя разместить текстовую информацию может быть почти тривиально, сложная часть возникает, когда мы принимаем во внимание такой контент, как адаптивные изображения, инфографика, видео и т. д., которые когда-то разрабатывались только для настольных компьютеров. Это не только поднимает вопрос о правильном отображении контента, но и о том, как сам контент потребляется на разных устройствах. Пользователи смартфонов отличаются от пользователей настольных компьютеров. Также необходимо учитывать такие вещи, как планы данных и скорость обработки. Google начал выделять сайты, удобные для мобильных устройств, в результатах поиска, и некоторые предполагают, что это приведет к значительному повышению рейтинга страниц таких сайтов. В более ранних решениях это решалось путем развертывания поддоменов только для мобильных устройств (и перенаправлений), но это увеличивало сложность и быстро вышло из моды. (Не каждый сайт может позволить себе этот маршрут.)

В поисках адаптивных веб-изображений

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

Тег <img> имеет только исходный атрибут, напрямую связанный с самим изображением. Он не может определить правильный тип изображения без каких-либо надстроек.

Разве мы не можем просто включить все размеры изображений в HTML и использовать правила CSS для display:none для всех, кроме правильного изображения? Это самое логичное решение в идеальном логическом мире. Таким образом, браузер может игнорировать все не отображаемые изображения и теоретически не загружать их. Однако браузеры оптимизированы за пределами обычной логики. Чтобы страница отображалась достаточно быстро, браузер предварительно загружает связанный контент еще до того, как будут полностью загружены необходимые таблицы стилей и файлы JavaScript. Вместо того, чтобы игнорировать большие изображения, предназначенные для настольных компьютеров, мы загружаем все изображения, что приводит к еще большей загрузке страницы. Техника только с CSS работает только с изображениями, предназначенными для фоновых изображений, потому что они могут быть установлены в таблице стилей (с помощью медиа-запросов).

Итак, что делать с сайтом?

Решения для масштабирования внутренних адаптивных изображений

За исключением сайтов/поддоменов, предназначенных только для мобильных устройств, нам остается перехватывать пользовательский агент (UA) и использовать его для предоставления пользователю изображений правильного размера. Однако любой разработчик может подтвердить, насколько ненадежным может быть это решение. Новые строки UA постоянно появляются, что усложняет поддержание и обновление полного списка. И, конечно же, это даже не принимает во внимание ненадежность строк UA, которые легко подделать.

Адаптивные изображения

Однако некоторые серверные решения заслуживают внимания. Адаптивные изображения — отличное решение для тех, кто предпочитает внутреннее исправление адаптивных изображений. Он не требует какой-либо специальной разметки, вместо этого использует небольшой файл JavaScript и выполняет большую часть тяжелой работы в своем внутреннем файле. Он использует настроенный сервер PHP и nginx. Он также не полагается на какой-либо анализ UA, а вместо этого проверяет ширину экрана. Адаптивные изображения отлично подходят для уменьшения изображения, но также удобны, когда большие изображения нуждаются в художественном оформлении, т. е. уменьшении изображения с помощью таких методов, как обрезка и поворот, а не просто масштабирование.

Сенча Тач

Sencha Touch — еще одно решение для обработки изображений с адаптивным дизайном, хотя лучше называть его сторонним решением. Sencha Touch соответствующим образом изменит размер изображения, обнюхивая UA. Ниже приведен базовый пример работы сервиса:

 <img src="http://src.sencha.io/http://example.com/images/kitty_cat.jpg" alt="My Kitty Cat">

Существует также возможность указать размеры изображения на случай, если мы не хотим, чтобы Sencha автоматически изменяла размер изображения.

В конце концов, серверным (и сторонним) решениям требуются ресурсы для обработки запроса перед отправкой правильного изображения обратно. Это отнимает драгоценное время и, в свою очередь, замедляет процесс запроса-ответа. Лучшим решением могло бы быть, если бы устройство само определяло, какие ресурсы запрашивать напрямую, и сервер отвечал бы соответствующим образом.

Интерфейсные решения

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

Элемент <picture> был введен и одобрен W3C в спецификации HTML5. В настоящее время он широко доступен не во всех браузерах, но вскоре он станет доступным и по умолчанию. До тех пор мы полагаемся на полифиллы JavaScript для элемента. Полифиллы также являются отличным решением для устаревших браузеров, в которых отсутствует этот элемент.

Существует также случай с атрибутом srcset , который доступен для нескольких браузеров на основе webKit для элемента <img> . Это можно использовать без какого-либо JavaScript, и это отличное решение, если нужно игнорировать браузеры, отличные от WebKit. Это полезная временная мера для странного случая, когда другие решения не работают, но не следует считать комплексным решением.

Картинка

Picturefill — это библиотека полифиллов для элемента <picture> . Это одна из самых популярных библиотек среди интерфейсных решений для адаптивного изменения размера и масштабирования изображений. Есть две версии; Picturefill v1 имитирует элемент <picture> с помощью span , в то время как Picturefill v2 использует элемент <picture> среди браузеров, которые уже предлагают его, и предоставляет полифилл для устаревших (например, для IE >= IE9). Он имеет некоторые ограничения и обходные пути, в первую очередь для Android 2.3, что, кстати, является примером того, где на помощь приходит атрибут img srcset . Ниже приведен пример разметки для использования Picturefill v2:

 <picture> <source media="(min-width: 768px)"> <source media="(max-width: 767px)"> <img alt="My Kitty Cat"> </picture>

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

Imager.js

Imager.js — это библиотека, созданная командой BBC News для создания адаптивных изображений с использованием подхода, отличного от того, который используется в Picturefill. В то время как Picturefill пытается добавить элемент <picture> в неподдерживаемые браузеры, Imager.js фокусируется на загрузке только подходящих изображений, а также следит за скоростью сети. Он также включает ленивую загрузку без использования сторонних библиотек. Он работает, используя элементы-заполнители и заменяя их элементами <img> . Пример кода ниже демонстрирует это поведение:

 <div> <div class="image-load" data-src="http://example.com/images/kitty_{width}.jpg" data-alt="My Kitty Cat"></div> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

Визуализированный HTML будет выглядеть так:

 <div> <img src="http://example.com/images/kitty_480.jpg" data-src="http://example.com/images/kitty_{width}.jpg" alt="My Kitty Cat" class="image-replace"> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

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

Перетасовка источников

Source Shuffling подходит к проблеме отзывчивого изображения с несколько иной точки зрения, чем остальные интерфейсные библиотеки. Это напоминает что-то из школы мысли «сначала мобильные», благодаря чему по умолчанию используется наименьшее возможное разрешение. Обнаружив, что устройство имеет больший экран, оно меняет источник изображения на изображение большего размера. Это больше похоже на взлом, а не на полноценную библиотеку. Это отличное решение в основном для мобильных сайтов, но означает, что двойная загрузка ресурсов для настольных компьютеров и/или планшетов неизбежна.

Некоторые другие известные библиотеки JavaScript:

• HiSRC — плагин jQuery для адаптивных изображений. Зависимость от jQuery может быть проблемой.
• Mobify.js — более общая библиотека для адаптивного контента, включая изображения, таблицы стилей и даже JavaScript. Он «захватывает» DOM перед загрузкой ресурсов. Mobify — это мощная всеобъемлющая библиотека, но она может быть излишней, если целью являются только адаптивные изображения.

Резюме

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

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

• Являются ли устаревшие браузеры проблемой? Если нет, рассмотрите возможность использования более современного подхода (например, srcset ).
• Критично ли время отклика? Если нет, выберите стороннее или серверное решение.
• Должны ли решения быть внутренними? Сторонние решения, очевидно, будут исключены.
• Есть ли уже много изображений на сайте, который пытается перейти на адаптивные изображения? Есть ли опасения по поводу проверки или семантических тегов (или, скорее, не семантических тегов)? Для этого потребуется внутреннее решение для маршрутизации запросов изображений к чему-то вроде Adaptive Images.
• Является ли художественное руководство проблемой (особенно для больших изображений с большим количеством информации)? Библиотека наподобие Picturefill будет лучшим решением для такого сценария. Кроме того, любое из внутренних решений также будет работать.
• Есть ли опасения по поводу отсутствия JavaScript? Ни о каких внешних решениях не может быть и речи, что оставляет внутренние или сторонние варианты, которые полагаются на анализ UA.
• Имеет ли время отклика мобильных устройств приоритет над временем отклика настольных компьютеров? Библиотека, такая как Source Shuffling, может быть более подходящей.
• Нужно ли обеспечивать отзывчивое поведение для каждого аспекта сайта, а не только для изображений? Mobify.js может работать лучше.
• Достигнут ли совершенный мир? Используйте только CSS-подход display:none !