«Сегодня мы проектируем объекты, которые будут восприниматься и использоваться в разнообразных условиях, о которых раньше мы не могли и подумать. Адаптивный дизайн позволяет нам двигаться вперёд, даёт реальную возможность „создавать продукты, способные устоять в бурном потоке перемен“».

Этими двумя предложениями Итан Маркотт заключил статью, представившую миру адаптивный дизайн. С тех пор подход захватил веб, словно эпидемия. Кажется, не проходит и дня, чтобы мы не услышали о новом адаптивном сайте какой-нибудь компании. Крупные бренды, такие как Microsoft, Time и Disney, пустили адаптивный дизайн в ход, чем сразу обезоружили критиков, настаивавших на его пригодности только для небольших блогов.

Это, безусловно, отличная новость. Как верно заметил Итан, а незадолго до него и Джон Оллсопп (John Allsopp), присущая веб-среде гибкость — это в первую очередь новая возможность, а не ограничение. Уникальная способность веб-ресурсов взаимодействовать с неограниченным числом устройств, с неограниченным числом способов ввода — это то, к чему нам ещё предстоит привыкнуть.

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

Несколько месяцев назад Стефани Ригер (Stephanie Rieger) написала в своём Twitter’е:

«Пристрелите меня... кажется, адаптивный дизайн воспринимают как возможность сокращения производительности, а не как возможность её увеличения».

Я бы рад не согласиться, но, к сожалению, происходящее вокруг подтверждает слова Стефани. Посмотрите на размер и количество запросов для четырёх известных адаптивных сайтов, запущенных в 2012 году:

• 74 запроса, 1,511кб
• 114 запросов, 1,200кб
• 99 запросов, 1,298кб
• 105 запросов, 5,942кб

И это показатели страниц для маленьких экранов!

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

Одно дело, если бы эти сайты были исключением, но, к сожалению, их ошибки типичны. Гай Поджарный (Guy Podjarny), серьёзно изучивший производительность адаптивных сайтов, обнаружил, что у 86% страницы для мобильных устройств имеют тот же или больший размер, чем дектопный вариант.

В сущности, высокая производительность сайта — важное требование для любого веб-проекта, и подумать о ней надо заранее. С низкой производительностью связано снижение прибыли, объёмов траффика, конверсии и общей удовлетворённости пользователей от ресурса. Кейс за кейсом мы видим, как оптимизация производительности, даже небольшая, приводит к общему росту показателей. Ситуация с мобильными сайтами почти такая же: 71% пользователей ожидают, что смогут открыть сайт с мобильного быстрее или хотя бы так же быстро, как на компьютере.

Вывод: производительность — важная характеристика опыта взаимодействия

Итак, если она так важна для любого веб-проекта, почему мы видим столько тяжёлых адаптивных сайтов?

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

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

Формирование культуры производительности

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

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

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

1. Оптимизировать функцию или инструмент, уже существующий на странице
2. Удалить со страницы существующую функцию или инструмент
3. Не добавлять новую функцию или инструмент

Идея здесь следующая: решения, касающиеся производительности сайта, должны приниматься в процессе разработки, а не в конце.

Испытайте неудобства на себе

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

Когда я тестировал упомянутый выше 5,942-килобитный сайт в 3G-сети, его загрузка заняла 93 секунды. Полторы минуты я смотрел на белый экран. Если бы кто-то из разработчиков проделал то же самое, уверен, они бы не запустили сайт в таком состоянии.

Не думайте о цифрах, точнее, подумайте не только о них. Откройте сайт в более медленной сети и испытайте на себе всю прелесть ожидания. Если у вас нет к ней доступа, симулируйте её с помощью таких инструментов, как Slowy,Throttle или Network Conditioner, установленного на Mac OS X 10.7.

Начните с простого

Существует несколько общих приёмов по улучшению работы сайта, как адаптивного, так и традиционного, которыми почему-то часто пренебрегают. Отличным началом может послужить знакомство с правилами Yahoo!

Некоторые правила могут показаться слишком сложными или даже пугающими, но это не так. Можно взять файл .htaccess из шаблона HTML 5 Boilerplate или использовать файл .htaccess Сергея Чернышева (Sergey Chernyshev). Для упрощения создания спрайтов можно использовать такие инструменты, как SpriteMe, для оптимизации изображений — ImageOptim.

Благодаря этим простым способам оптимизации можно сделать страницу намного легче, а загрузку — быстрее.

Внимательно работайте с изображениями

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

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

Ситуация с картинками на странице несколько сложнее. Ни за что не отправляйте большую картинку для большого монитора на устройство с маленьким экраном. Это наносит сайту вред, не только утяжеляя страницу, но и нагружая память устройства. Вместо этого воспользуйтесь инструментом, например, Adaptive Images или src.sencha.io, и убедитесь, что пользователь загружает только подходящие по размеру изображения.

Новый бурно обсуждаемый элемент <picture> — ещё одно отличное решение для тех, кто думает о будущем своего проекта. Уже сейчас его можно спокойно использовать, не беспокоясь по поводу поддержки, — благодаря picture polifill’у.

Выборочная загрузка

Не загружайте ресурсы, которые не будут использоваться. Если для некоторых размеров потребность в скрипте отпадает, используйте matchMedia polyfill для обеспечения его выборочной загрузки — только в тех случаях, когда он необходим. Аналогично, используйте eCSSential для выборочной работы с файлами CSS.

В позапрошлом году на сайте 24 ways опубликовали статью Джереми Кейта (Jeremy Keith) о выборочной загрузке контента в адаптивном дизайне, основанной на ширине экрана. Впоследствии техника было усовершенствована Filament Group и выпущена как Ajax-Include Pattern. Это простой и эффективный способ сделать легче страницы, загружаемые на устройства с маленькими экранами, а также избавиться от лишних элементов.

Будьте проще

Если вы заглянете в HTTP Archive, то увидите, что другим «тяжёлым» ресурсом, наряду с изображениями, является JavaScript — его размер на странице в среднем составляет 215 кб. Он также может похвастаться пятым местом в рейтинге медленно загружающихся и вторым — в рейтинге долго не отображающихся ресурсов.

Большие размеры можно объяснить и тем, что разработчики стали больше полагаться на фреймворки. Для мобильных устройств это серьёзная проблема. Питер Пол Кох (@PPK) недавно заявил, что существующие JavaScript-библиотеки «слишком тяжелы для мобильных». Исследование времени на разбор запроса, проведённое Стояном Стефановым (Stoyan Stefanov), это подтверждает. На некоторых устройствах под Android и iOS разбор jQuery-запроса может занять 200-300 мс.

В использовании фреймворка нет ничего плохого, но проблема заключается в том, что оно становится стандартом. Перед подключением очередного фреймворка или плагина надо остановится и подумать о том, какую реальную ценность он принесёт и можно ли достичь того же результата с помощью простых JavaScript и CSS. (Это именно тот случай, когда может пригодиться метод бюджета производительности).

Не ограничивайтесь работой над визуальным оформлением сайта

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

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

Оригинал: http://24ways.org/2012/responsive-responsive-design/

Дмитрий Демидовский
Веб-технолог в AGIMA

Оптимизации сайтов вообще часто уделяют недостаточно внимания — это касается не только адаптивного дизайна. Но именно на мобильных устройствах огрехи производительности становятся особенно заметны. Низкая скорость соединения (при использовании 3G или EDGE), слабые (по сравнению с десктопом) процессоры — эти факторы предъявляют повышенные требования к быстродействию сайтов.

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

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

Кстати, когда пользователь открывает мобильный сайт, например, проезжая в метро — поверьте, ему не важно оформление, ему важен контент, за которым он пришел: номер телефона, адрес, время работы и.т.д. Если скорость соединения позволяет загрузить только простой текст — значит, надо загрузить простой текст. И лишь потом пытаться загрузить CSS и JS.

В конце концов, существует же так называемый академический стиль веб-дизайна, целиком полагающийся на семантику и соответствующее оформление по умолчанию (которое, по сути, не требует ресурсов вообще). Главное — это контент, всё остальное — по мере возможности; таким я вижу практическое применение концепции прогрессивного улучшения. И на производительность это повлияет самым положительным образом.

Алексей Ёжиков

Я предлагаю посмотреть на ситуацию с глобальной стороны. Старожилы помнят приписываемую Биллу Гейтсу фразу «640 килобайт должно быть достаточно для каждого». Каждый из нас носит в кармане или сумочке всю вычислительную мощь мира 60-х годов, чтобы шарить фотки в Инстаграме.

Тем временем неумолимо действует закон Мура о росте производительности процессоров, и неумолимо растёт проникновение и скорость широкополосного доступа в Интернет, в том числе мобильного (помните GPRS на телефонах типа Siemens SL45 и WAP-сайты?).

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