Какое решение для подстраивающихся изображений вы должны использовать?  

👨‍🚀 Мой контент уже сформирован? 

Что в действительности значит: «Мой контент уже сформирован и его совершенно непрактично обновлять?». К примеру, у меня имеются тысячи страниц контента на CSS-Tricks и их черновые варианты:

Я знаю единственный метод, работающий абсолютно без изменений в разметке — это «адаптивные изображения» (Adaptive Images). Он работает посредством маршрутизации запросов с помощью PHP-файла, который разумно отдает (и создает, если необходимо) изображения, соответствующие ширине экрана.

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

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

        <img src="200x100.png" data-1x="400x200.png" data-2x="800x400.png">
        

📢 Заботит ли меня семантика? 

Некоторые техники подстраиваюихся изображений включают в себя не строго семантичную разметку. В конце концов существует лишь один вариант, когда изображение семантично. Если его атрибут src указывает на реальное изображение и если в атрибуте alt указано описание этого изображения. Брэд Фрост (Brad Frost), прекрасно подытожил:

Другими словами, если метод требует, в любом случае, что src может быть пропущен или должна присутствовать ссылка на прозрачный GIF (или что-то подобное), то это отнюдь не семантично.

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

Если семантика для вас важна, вы должны смотреть в сторону методов «адаптивных изображений» (упомянутых выше) или HiSRC, плагина Кристофера Шмидта, которые вы можете использовать с семантичным атрибутом src.

В некоторых методах используются теги <noscript> в которых размещаются <img> для обеспечения фолбэка в случае если JavaScript отключен. Семантично это или нет — позволю решить вам.

✔️ Заботит ли меня валидность? 

Валидация как вопрос «Валидно ли это?», отсылает нас к сервису проверки разметки от Консорциума Всемирной паутины (W3C Markup Validation Service). Валидация — это инструмент, который помогает вам искать ошибки и лучше писать разметку. Если что-то невалидно, это еще не значит, что только лишь поэтому все плохо или неправильно. Если невалидный код замечательно работает во всех браузерах — ни вы ни кто-либо другой не должны беспокоиться о валидности.

Если валидность вас заботит (возможно клиент иррационально требует ее от вас удерживая оплату), есть несколько методов, которые вы не можете использовать. Метод picturefill, к примеру, использует элемент <picture> для того, чтобы делать свою магию. В конечном счете этот синтаксис может быть стандартизирован, но это еще не так, поэтому технически он невалиден. Этот метод также требует, чтобы у <img>-элементов имелся атрибут src, а методы, которые заменяют значения в этом атрибуте для обхода проблемы удваивания загружаемых изображений — невалидны.

Я бы рекомендовал следующие методы, если от вас требуется валидный код: «адаптивные изображения», HiSRC или метод «улучшенного подстраивания» (Responsive Enhance).

🎬 Заботит ли меня кадрирование изображения? 

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

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

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

      <picture alt="description">
        <source src="small.jpg">
        <source src="medium.jpg" media="(min-width: 400px)">
        <source src="large.jpg" media="(min-width: 800px)">
      </picture>
      

Источники подставляются с помощью JavaScript.

☢️ Заботит ли меня JavaScript? 

Большинство из этих методов подстраивающихся изображений для делания своей магии используют JavaScript. Некоторые лишь чуть-чуть для установки кукис, но JavaScript это не все. Некоторые методы обязуют вас вкладывать <img> в тег <noscript>, для того, чтобы обеспечить наличие изображения по-умолчанию, в случае если пользователь отключил у себя JavaScript. Если вам это не нравится и вам нужно быть абсолютно уверенным, что изображения будут работать и при отключенном JavaScript, сервис Sencha.IO будет лучшим выбором. Этот сервис работает по принципу определения устройства по строке его юзер-агента и отдачи изображения надлежащего размера. Таким образом, вы ссылаетесь на самое большое (в разумных пределах) изображение, а Sencha сожмет его и отдаст по мере надобности его меньшие версии (по очевидным причинам этот вервис не работает наоборот, увеличивая изображения).

💣 Заботят ли меня компоненты на стороне сервера? 

Некоторые из представленных методов зависят не только от JavaScript. Адаптивные изображения делают свою магию главным образом с помощью файла .htaccess и PHP. Что ж, файл .htaccess предполагает наличие сервера Apache. И в то же время, мы конечно же любим и знаем PHP, хотя много веб-сайтов работают на таких технологиях как Ruby и Python.

Метод подстраивающихся изображений (оригинальный метод Filament Group) также использует файл .htaccess. Поэтому если вы используете что-то вроде Nginx в качестве веб-сервера, данный метод либо использовать нельзя, либо вы должны будете портировать компонент работающий с файлом .htaccess в похожий, но другой синтаксис Nginx’а.

🚀 Заботит ли меня тестирование пропускной способности канала связи? 

Тестирование ширины окна браузера и принятие решения относительно того, какое изображение загружать — основополагающая и крутая концепция подстраивающихся изображений. Но в действительности это всего лишь половина того, на чем должно быть основано подобное решение. Вторая половина — пропускная способность канала связи. Если у пользователя очень быстрое интернет-соединение, то с загрузской больших изображений все впорядке. Если же у пользователя скорость интернет-соединения очень медленная, они должны получать изображения поменьше (независимо от размеров экрана). К сожалению, родных медиа-запросов по тестированию пропускной способности канала (bandwidth media queries) не существует.

Два из имеющихся на сегодня метода производят тестирование пропускной способности для принятия решения: Foresight.js и HiSRC (оба основаны на технике из Foresight.js). Это работает путем загрузки тестового файла и измерением времени его загрузки (конфигурируемо). От самого этого теста падение производительности пренебрежительно мало, но теоретически экономия полученная при отсылке изображений, в результате знания о текущей пропускной способности, весьма выгодна.

🏜️ Заботит ли меня зависимость от сторонних сервисов? 

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

Вы возможно думаете: «Ух-ты, сервис Sencha.IO действительно хорош, но беспокоит зависимость от третьих лиц. Хотелось бы запускать его на своем сервере.» Если вы хотите пойти этим путем, то существует база данных WURFL и их сервер-сайд метод подстраивающихся изображений (Server Side Responsive Images technique), который позволяет заставить работать это локально.

Существуют еще такие сторонние сервисы как Device Atlas Cloud, которые позволяют определять различные устройства. Для вашего приложения это также является зависимостью от третьих лиц. Без сомнений их целью является быстрая и бесперебойная работа сервиса, но вы должны подходить с особой осторожностью к тому, от чего может зависеть ваш бизнес.

🐢 Существует ли специализированная СУК с подобными встроенными возможностями? 

Предположим, что ваш проект работает на движке WordPress. У WordPress имеется встроенный загрузчик медиа. Когда вы загружаете с помощью него изображение, он может создать для вас несколько версий этого изображения (путем уменьшения разрешения). Это круто и сильно и вы можете/должны извлекать из этого пользу. Кейр Уитакер (Keir Whitaker) рассказывает об этой возможности в своей статье «Автоматические подстраивающиеся изображения в WordPress» (Automatic Responsive Images in WordPress).

Однако это лишь фишка WordPress. Я уверен, что рассмотренные концепции могут быть внедрены в любую систему управления контентом.

🤖 Могу ли я подождать будущего? 

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

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

Это может быть подстановка значений в src-атрибут изображений, управляемая из CSS, как предположил Николас Галлахер (Nicolas Gallagher). Это может быть <picture>-элемент. Это может быть атрибут srclist и связанный с ним список изображений в HTML или свойство в CSS. Это может быть префикс.

🌐 Дополнительные ссылки по теме 

• У Джейсона Григсби (Jason Grigsby) есть эпическая серия из трех статей о подстраивающихся изображениях начинающаяся с этой.
• Презентация Кристофера Шмидта — большая беседа о подстраиващихся изображениях.
• Мэт Маркуиз (Mat Marquis). Подстраивающиеся изображения: как они работали и что в действительности было нужно нам.