От автора: Если вы кодируете вебсайты, могу побиться об заклад, что по меньшей мере один из ваших клиентов интересовался или заказывал вебсайт с поддержкой сенсорного ввода. Если вы идете стезей адаптивного дизайна (в соответствии с чем ваш вебсайт достаточно гибок, чтобы визуально подстраиваться под ширину экрана от мобильного устройства до десктопа), то вам также понадобится стратегия создания гибких изображений — решение для адаптивных изображений.
Выучить основы довольно просто, но как только вы их усовершенствуете, то обнаружите, что масштабирование изображений – это только начало, вам также придется решать вопросы производительности и загадки художественной постановки. Вы столкнетесь с огромным выбором решений проблемы адаптивных изображений, каждое со своими сильными и слабыми сторонами — и ни одного идеального! Эта статья введет вас в основы, а затем вооружит информацией, нужной для того, чтобы выбрать самое лучшее решение для адаптивных изображений в вашей ситуации.
Основы
Назначить стили изображениям переднего плана для того, чтобы подогнать ширину их контейнера, очень легко. В таблицу стилей, возможно, в таблицу нормализации или сброса стилей, добавляется следующий код:
|
1 2 3 |
img { max-width: 100%; } |
В большинстве случаев это крошечное правило стилей создает нужный результат! Когда оно стоит на месте, то если контейнер вокруг изображения становится уже его ширины, изображение масштабируется так, чтобы совпасть с шириной своего контейнера. Установка max-width на 100% также гарантирует, что изображение не станет больше своего настоящего размера, что значительно снизило бы его качество. Если вы увязли в попытке обеспечить поддержку для IE 6 или 7, вам понадобится добавить правило стиля width: 100%, которое предназначается только для этих браузеров, потому что они не понимают max-width.
Изображения в высоком разрешении “Retina” могут осложнить эту простую реализацию. Скажем, вам нужно, чтобы логотип размером 150 × 150px отображался в двойной пиксельной концентрации по отношению к его обычной, а изображение достаточно маленькое, так что получение двух отдельных вариантов не станет проблемой. Итак, вы создаете версию логотипа 300 × 300 px, включаете ее — и теперь она огромная! Вашим первым побуждением, возможно, станет попробовать в CSS нечто вроде этого:
|
1 2 3 |
img.sitelogo { max-width: 150px; } |
К сожалению, ничего не работает так, как нужно — изображение-логотип теперь откажется нормально масштабироваться с прочими изображениями на странице.
Чтобы ограничить максимальную ширину адаптивного изображения, вам пришлось бы ограничить максимальную ширину контейнера с изображением, а не самого изображения! Скажем, вы обернули изображение-логотип в модуль с классом branding. Вот стиль, который выдаст нужный результат:
|
1 2 3 |
.branding { max-width: 150px; } |
Итак, теперь в гибкой разметке сайта есть масштабируемые адаптивные изображения. Миссия выполнена. Пора выяснить, что может нам предложить это незнакомое внешнее пространство соскучившемуся по солнышку разработчику, правильно?
Не так быстро! Нам еще нужно преодолеть две главные трудности.
Проблема производительности
При вышеописанном решении адаптивных изображений всем устройствам «скармливаются» одни и те же изображения. Оно неплохо справляется с маленькими иконками и логотипами, но проблема быстро усложняется по мере увеличения и утяжеления изображений. Изображения Retina ее еще больше обостряют — вам не требуется посылать большие изображения Retina на устройство, неспособное отобразить его подробности!
Подумайте об этом. Нужно ли на самом деле посылать изображение в 990 × 300 px и 100 KB, предназначенное для пользователей десктопов, на мобильный телефон? Конечно, посетитель с мобильного устройства может сидеть на Wi-Fi-соединении своего местного кафетерия — однако может оказаться в дороге при неустойчивом беспроводном соединении и пытаться отыскать на вашем вебсайте важную информацию. Каждый мобильный пользователь, сдающийся при слишком долгой загрузке страницы – это потенциально потерянный клиент!
В природе сегодня можно отыскать множество мобильных вебсайтов, которые такие же большие, или даже больше своих десктоповых собратьев. Гай Поджарный (Guy Podjarny) с год назад провел несколько тестов, и не заметил значительного улучшения: в 2011г. 86% вебсайтов были того же размера или даже больше, а в 2012г. это количество уменьшилось до 72%, но увеличился общий размер сайтов. Дэйв Руперт (Dave Rupert) тоже отметил эту проблему в своей статье Больше пикселей – больше проблем (Mo’ Pixels Mo’ Problems).
СЛЕДУЮЩЕЕ ОСЛОЖНЕНИЕ: БРАУЗЕРНАЯ ПРЕДЗАГРУЗКА
Впервые начав борьбу с проблемами производительности адаптивных вебсайтов, я изначально планировал извлекать все варианты изображений на страницу, но установить несколько классов CSS с медиапросами, которые при небольшой ширине скрывали бы большие изображения и показывали маленькие, а при ширине настольного компьютера поступали бы наоборот. Это кажется логичным: не обязан ли браузер скачивать только видимые изображения?
Проблема в том, что для нас браузеры слишком быстрые! Для обеспечения наименьшего возможного времени загрузки браузеры предварительно скачивают все изображения, которые могут определить в исходном коде еще до начала обработки CSS или JavaScript’а. Так что в действительности такой подход поставит мобильных посетителей в невыгодное положение еще сильнее, заставляя их скачивать все варианты изображений!
Из-за предварительного скачивания требуется либо прикладное back-end решение (чтобы предупредить предзагрузку), либо специальная разметка и JavaScript.
ОПРЕДЕЛЕНИЕ ПРОПУСКНОЙ СПОСОБНОСТИ
Последняя деталь головоломки производительности – скорость сети. Ясно, что следует поставлять большие изображения только на те устройства, которые подключены к быстрой сети, но как это определить? Для оценки скорости существует несколько методов, но они еще не полностью надежны.
W3C работает над технологией Network Information API, которая в будущем может очень пригодиться, но в данный момент поддерживается только малым количеством устройств (и, к сожалению, небольших). Сейчас она выполняется в нескольких решениях для адаптивных изображений, но ее широкого применения нельзя ожидать до появления нормальной поддержки. Измерить сеть сложно и, как утверждает Йов Вайсс (Yoav Weiss) в своей статье на сайте Smashing Magazine, надежные «медиазапросы к пропускной способности», похоже, в ближайшем будущем не смогут быть внедрены должным образом.
Foresight.js от Адама Брэдли (Adam Bradley) пользуется JavaScript’ом для тестирования того, сколько времени нужно браузеру для загрузки изображения в 50K, затем хранит эту информацию и применяет ее для принятия решений о пропускной способности. У него имеется несколько мелких недостатков: на вашу страницу добавляется скачивание 50K изображения, и загрузка остальных изображений может блокироваться до момента окончания загрузки тестового. Многие решения адаптивных изображений, применяющих в данный момент определение пропускной способности, пользуются вариацией или адаптацией Foresight.js.
Проблема «художественного руководства»
Скажем, на домашней странице вашего сайта есть отличное широкое изображение. На нем изображена пасторальная сцена с полями и лесом, голубым небом и пушистыми облаками, и счастливым семейством на травке.
Теперь отмасштабируйте ее для мобильного устройства до ширины в 300 px. При таком размере семья на отдыхе смотрится, как муравьи на пикнике!
При масштабировании большого изображения теряются подробности.
Здесь и лежит проблема так называемого «художественного руководства». Некоторые изображения просто невозможно хорошо масштабировать; теряются мелкие детали и снижается яркое воздействие. В случае с нашим изображением оно вышло бы гораздо лучше визуально, если б мобильная версия фотографии была приближена, обрезана, а счастливая семья оказалась бы в фокусе. Для этой проблемы нам понадобится такое решение адаптивного изображения, которое даст возможность либо определить разные версии изображения для разных ситуаций, либо подстраивать изображение «на ходу».
Иногда при маленькой ширине экрана желательна обрезка или приближение изображения.
Выбор своего решения
К счастью, у сообщества веб-разработков и дизайнеров нет недостатка в умных, творческих личностях, работающих над решением этих проблем. Конечно, обратной стороной монеты является то, что можно легко оказаться сбитым с толку количеством существующих адаптивных решений. Как вы думаете, какое подойдет вам лучше всего?
Выбор может оказаться крайне сложным, потому что в игру вступает так много факторов. В данный момент не существует идеального решения в любой ситуации; каждое из них было создано для решения определенного набора проблем. Чтобы выбрать, вам придется взвесить их в свете конкретных запросов вашего проекта. Крис Койер (Chris Coyier) проделал огромную работу, резюмируя факторы принятия решения (включая таблицу для их отслеживания, хотя некоторые из новейших методов не упомянуты). Вот некоторые из факторов, которые нужно обдумать:
Придется ли вам решать проблему художественного руководства (т.е. различных соотношений изображения, обрезки и размеров для разной ширины)?
У вас большой вебсайт или CMS, где нереально вернуться и добавить специальную разметку к каждому изображению?
Все ли изображения имеются налицо при загрузке страницы, или некоторые динамически загружаются через JavaScript?
Хотите ли вы проверять пропускную способность пользователя, чтобы определить, достаточно ли быстрое у него соединение для загрузки изображений в высоком разрешении?
Требуется ли для выбранного решения недоступная вам платформа (такая как jQuery или PHP)?
Применимо ли для вас стороннее решение, или оно вам нужно на внутреннем хостинге?
С этой целью давайте рассмотрим некоторые адаптивные решения изображений, уже некоторое время существующие и широко применяемые в сообществе разработчиков.
Заметьте, пожалуйста: список нижеприведенных решений ни в коем случае не окончателен. Либо я лично нашел их наиболее полезными, либо они уже находятся в послужном списке из-за своей надежности. У вас есть любимое решение, отсутствующее здесь? Расскажите нам о нем в комментариях!
Опробованные и надежные адаптивные решения
PICTUREFILL
Сеть на самом деле всемирная, и нам приходится противостоять тому факту, что не у всех есть доступ к соединениям по оптоволоконному кабелю и 4G-сетям. Скотт Джел (Scott Jehl) лично столкнулся с этим цифровым неравенством во время путешествия и работы в Юго-Восточной Азии, и он – ярый сторонник mobile-first и адаптивных вебсайтов, которые не отягчают мобильных пользователей. Его скрипт Picturefill – это полифил для предложенного элемента
Picturefill’у не требуется jQuery, но, естественно, ему нужно, чтобы куда-либо на страницу был включен скрипт picturefill.js. Picturefill’у также нужна специальная разметка, с div’ами для представления вариантов изображения, различаемых атрибутами data-media, которые действуют как медиазапросы в CSS. Также можно по выбору внести изображение в условные комментарии для тех браузеров, которые на поддерживают медиазапросов (это об IE 8), и альтернативный вариант в тэг noscript для тех браузеров, где отключен JavaScript (это о BlackBerry). Вот пример типичных настроек Picturefill:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
<span data-picture data-alt="Descriptive alt tag"> <span data-src="images/myimage_sm.jpg"></span> <span data-src="images/myimage_lg.jpg" data-media="(min-width: 600px)"></span> <!--[if (lt IE 10) & (!IEMobile)]> <span data-src="images/myimage_sm.jpg"></span> <![endif]--> <!—Альтернативный контент для браузеров без JS. --> <noscript> <img src="images/myimage_sm.jpg" alt="Descriptive alt tag" /> </noscript> </span> |
Вот и все, что нужно для отображения адаптивных изображений во время загрузки страницы с помощью Picturefill. Внесите скрипт, сконфигурируйте разметку и все легко заработает. Также можно вызывать Picturefill программным путем, если требуется «на ходу» добавлять изображения на страницу.
Picturefill’у нужно большое количество пользовательской разметки, поэтому он может оказаться не лучшим выбором для тех, кому никак нельзя менять исходный код вебсайта. Кроме того, он не делает определения пропускной способности. Если она очень важна для вашего проекта, то рассмотрите следующее решение.
HISRC
HiSRC от Марка Грабански (Marc Grabanski) и Кристофера Шмитта (Christopher Schmitt) – это плагин jQuery, который позволяет создавать версии изображения в низком, среднем и высоком разрешении, а скрипт показывает самое подходящее из них на базе готовности к Retina и скорости сетевого подключения.
Чтобы установить его, сначала убедитесь, что где-то на страницу добавлен jQuery и скрипт HiSRC.
В коде HTML сначала добавьте на страницу обычный тэг изображения и установите исходник на версию изображения с самым низким разрешением (или на самое маленькое). Добавьте к изображению или его упаковщику класс (вроде .hisrc), чтобы определить, какие изображения должен обрабатывать HiSRC. Затем добавьте специальную разметку к тэгу изображения: атрибуты data-1x и data-2x для версий со средним и высоким разрешением соответственно. Например:
|
1 |
<img src="//placekitten.com/200/100" data-1x="//placekitten.com/400/200" data-2x="//placekitten.com/800/400" class="hisrc" /> |
Затем после загрузки DOM просто вызовите функцию на используемый вами класс изображения, как тут:
|
1 2 3 |
$(document).ready(function(){ $(".hisrc").hisrc(); }); |
На деле браузер сначала загрузит источник изображения — т.е. мобильную версию изображения. Затем скрипт проверит, использует ли пользователь мобильную пропускную полосу (такую, как 3G). Если это так, то он оставит изображение mobile-first. Если соединение скоростное, а браузер поддерживает изображения Retina, то будет доставлена версия @2x. Если соединение скоростное, но Retina не поддерживается, то будет доставлена версия @1x.
Вы могли обратить внимание, что изображение с низким разрешением загружается всегда, даже если скрипт позднее решит, что устройство пользователя – подходящий кандидат для высокого разрешения. Даже если технически это двойная загрузка, неудобства она доставляет только тем, у кого скоростное соединение. Я с удовольствием принимаю такой компромисс!
HiSRC может управлять изображениями, динамически добавляемыми на страницу. Он также позволяет множественные изображения, поэтому можно определить разные обрезки и размеры для того, чтобы побороться с проблемой художественного руководства.
Что касается его слабых сторон, то HiSRC требуется jQuery, поэтому он не принесет пользы, если вы не пользуетесь это библиотекой. Ему также нужна пользовательская разметка в HTML, так что он может оказаться не лучшим выбором, если у вас большой вебсайт со множеством унаследованных изображений или CMS, где нельзя изменить выпуск тэга изображения. Если это ваша ситуация, то читайте дальше!
АДАПТИВНЫЕ ИЗОБРАЖЕНИЯ
В отличие от двух первых скриптов, Adaptive Images Мэтта Уилкокса (Matt Wilcox) – это по большей части решение на серверной стороне. Ему требуется чуть-чуть JavaScript’а, но настоящая работа проделывается посредством веб-сервера Apache 2, PHP 5.x и библиотеки GD.
Для его установки на ваш веб-сервер понадобится переделать или добавить файл .htaccess, выгрузить несколько файлов PHP в корневую директорию вашего вебсайта, добавить немного JavaScript’а на страницы (который добавит куки-файл для записи разрешения экрана пользователя) и сконфигурировать несколько переменных контрольных точек в файлах PHP, соответствующих медиазапросам вашего вебсайта.
Инструкции по инсталляции весьма многословны — немного длинноваты для этой статьи. Для получения информации посетите официальный вебсайт и щелкните вверху ссылку “Details”.
Самое лучшее свойство Adaptive Images в том, что ему не требуется пользовательской разметки к изображениям. Если вам удалось его правильно установить и сконфигурировать, то это все! Скрипт PHP перехватит любой запрос изображения, на ходу изменит его размер так, как требуется для отдельных контрольных точек и автоматически установит на ваши страницы.
У PHP множество опций конфигурирования, таких как качество изображения, контрольные точки, кэширование и даже фильтр увеличения четкости, которые можно применить для генерирования масштабированных изображений.
У него есть несколько ограничений:
Из-за того, что ему требуется сочетание Apache и PHP, Adaptive Images может не подойти для платформы вашего вебсайта или оказаться недоступным с сервера вашего веб-хоста.
Он полагается на способность веб-сервера перехватывать все запросы на изображения (посредством файла .htaccess). поэтому если ваши изображения лежат где-то еще, например, в сети доставки контента, то работать он не станет.
Он не определяет пропускную способность.
Он не предназначен для решения проблемы художественного руководства, потому что только изменяет масштаб первоначальных изображений. Он не может обрезать исходное изображение или создать из него разные соотношения размеров.
Вы, возможно, заметили, что всем решениям так или иначе требуется JavaScript, и зачастую некоторая детализированная конфигурация. Если вы ищете такое, которому не нужен JavaScript, и которое можно сравнительно легко применить, то подумайте о следующем.
SENCHA.IO SRC
Известное до этого как TinySrc, Sencha.io Src – это стороннее решение, действующее как посредник, поэтому вам не нужно ничего конфигурировать на сервере. Просто направьте свое изображение на серверы Sencha (определив или не определив какие-нибудь опции), и Sencha обработает его и пошлет обратно нужную версию требуемых размеров.
Скажем, у вас есть большое изображение:
|
1 |
<img src="//www.your-domain.com/path/to/image.jpg" alt="My large image" /> |
В самом упрощенном варианте можно дописать префикс атрибуту src с //src.sencha.io/, как здесь:
|
1 |
<img src="//src.sencha.io///www.your-domain.com/path/to/image.jpg" alt="My large image" /> |
Sencha.io по умолчанию изменит размер вашего изображения так, чтобы то соответствовало ширине экрана устройства, применив для детекции строку агента пользователя. На телефоны будет отправлено изображение шириной 320 px, на «таблетки» — шириной 768 px и так далее.
Также можно сконфигурировать строку-префикс Sencha.io так, чтобы та возвращала определенные размеры, ориентацию, размеры в процентах и любое количество сложных вычислений.
Sencha.io – бесплатный сервис для индивидуальных пользователей и может оказаться очень удобным решением проблемы адаптивных изображений. Однако вы добавляете зависимость от третьей стороны, при этом возможны простои и неконтролируемые вами проблемы. Тщательно взвесьте эти риски.
Решения проблемы адаптивных изображений, которые стоит рассмотреть
Описанные решения сейчас уже применимы, но не являются единственными в своем роде. Некоторые самые новые из них очень компромиссны, и я тщательно за ними присматриваю, чтобы видеть их развитие в современных веб-технологиях. В частности, ниже описаны два из них, на которые вы могли бы обратить внимание.
CAPTURING/MOBIFY.JS 2.0
Захват (Capturing) – новая возможность находящегося в разработке Mobify.js 2.0, которая предлагает доступ (или «захват») к исходной разметке HTML до начала ее анализа или отображения в браузере. Доступ к исходному коду на этом этапе дает возможность поменять атрибут изображения src до того, как браузер его скачает. Можно даже сделать альтернативный вариант к одному из других решений, такому как Picturefill, на случай неудачи.
Так как эта техника напрямую обходит «родную» предварительную загрузку браузера, это немного спорный момент в кругах веб-производительности. Будучи неправильно употребленной, она может создать настоящие проблемы с производительностью сайта вместо их устранения!
Еще одно, что удерживает меня от принятия этого решения с распростертыми объятиями – его кроссбраузерная поддержка. Capturing не будет работать во всех версиях IE ниже 10, поэтому пользователи IE 8 и 9 останутся ни с чем. Однако, я буду наблюдать — в будущем, когда IE 8 и 9 наконец канут в Лету, это решение станет более жизнеспособным!
Если вы заинтересованы в получении дополнительной информации о Capturing, команда Mozilla вдается в подробности в посте своего блога Capturing: улучшение производительности адаптивного веба (Capturing: Improving Performance of the Adaptive Web).
RESRC.IT
ReSRC.it – еще одно стороннее решение (недавно вышедшее из стадии beta), которое доставляет адаптивные изображения из облака. Оно, кажется, очень схоже по осуществлению с Sencha.io Src, но добавляет фильтры изображений и опредение пропускной способности, и не полагается на детекцию агента пользователя или куки.
Чтобы начать работу, во-первых, нужно создать пробный аккаунт на ReSrc.it. Во-вторых, вам понадобится вставить на свою страницу их файл Javascript (это простой код JS; а также для улучшения производительности они предлагают метод асинхронной вставки):
|
1 |
<script src="//use.resrc.it"></script> |
Затем, предположим, у вас есть такое изображение:
|
1 |
<img src="//path/to/image.jpg" alt="My large image" /> |
Вы добавите префикс к URL’у исходника изображения с указанием пути к серверам ReSRC.it и добавите изображению класс CSS “resrc”. Сейчас у них два сервера, один для платных аккаунтов, второй для пробных — в своем примере мы применим пробный:
|
1 |
<img src="//trial.resrc.it///www.your-domain.com/path/to/image.jpg" alt="My large image" class="resrc" /> |
ReSRC.it позволяет добавлять параметры к запрошенному requested URL’у для проведения над изображением таких операций, как вращение, обрезка и переворот. Так появляется гибкость и потенциальная направленность на проблему художественного руководства. Параметры обрабатываются по порядку слева направо и могут быть связаны вместе.
Вот пример изображения, перевернутого по горизонтали, размер изменен до ширины в 300px, в результате чего изображение получилось оптимизированным до 80%-качественного JPEG:
|
1 |
<img src="//trial.resrc.it/r=h/s=w300/o=80///www.your-site.co/image.jpg" alt="My large image" class="resrc" /> |
ReSRC.it только вышел из стадии beta, так что если у тех, кто им пользуется, есть подсказки или советы (за или против), мы с удовольствием узнали бы о нем больше в комментариях.
Тестируйте, тестируйте, тестируйте!
После того, как выберете и внедрите какое-либо решение для адаптивных изображений, абсолютно необходимо протестировать производительность вашего вебсайта, чтобы убедиться в нормальной работе избранного решения. Ниже приведены несколько полезных онлайн-инструментов тестирования.
YSLOW
Созданный Yahoo, YSlow – инструмент клиентской стороны, анализирующий ваш вебсайт по 23 контролепригодным правилам, определенным Yahoo как способным неблагоприятно влиять на производительность веб-страницы. За каждое правило YSlow присуждает вашему вебсайту степень, объясняя каждое из них и предлагая варианты улучшения производительности вебсайта. YSlow доступен для Firefox, Chrome, Safari и Opera (а также для некоторых прочих средств, вроде командной строки).
WEBPAGETEST
Онлайн-инструмент WebPageTest – проект с открытым исходным кодом, поддерживаемый Google. Вы вводите URL своего вебсайта, выполняете тестирование скорости из выбранного местонахождения, и уточняете, какой браузер использовать. Расширенные установки дают возможность выполнять многоступенчатые транзакции, подбирать скорость сети (кабельной, DSL, FiOS и так далее), отключать JavaScript, блокировать рекламу и делать прочие запросы, и кое-что помимо этого. Результаты выдаются в виде таблиц, диаграмм, скриншотов, обзора производительности и множества отличных данных для анализирования!
В блоге Yottaa есть статья, подробно описывающая применение WebPageTest для тестирования их вебсайта как с загрузкой адаптивных изображений, так и без нее — прочтите!
Заключение
Если вы читаете Smashing Magazine, то, скорее всего, уже занимаетесь созданием для вашей аудитории наилучшего из возможных впечатления от вебсайта. Поэтому в следующий раз при создании великолепного, пригодного к употреблению сайта для своих мобильных посетителей, испробуйте одно из решений проблемы адаптивных изображений и продвиньте свой вебсайт еще на милю вперед. Ваши мобильные пользователи будут вам благодарны!
Автор: Sherri Alexander
Источник: //mobile.smashingmagazine.com/
Редакция: Команда webformyself.
Комментарии (1)