Содержание
«Сегодня мы проектируем объекты, которые будут восприниматься и использоваться в разнообразных условиях, о которых раньше мы не могли и подумать. Адаптивный дизайн позволяет нам двигаться вперёд, даёт реальную возможность „создавать продукты, способные устоять в бурном потоке перемен“».
Этими двумя предложениями Итан Маркотт заключил статью, представившую миру адаптивный дизайн. С тех пор подход захватил веб, словно эпидемия. Кажется, не проходит и дня, чтобы мы не услышали о новом адаптивном сайте какой-нибудь компании. Крупные бренды, такие как 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) недавно обсуждал в своём подкасте, заключается в создании основанного на этих показателях бюджета. Первым делом устанавливается минимум, после чего любой желающий добавить что-либо на страницу сначала должен убедиться, что нововведение остаётся в рамках бюджета. Если оно его превышает, выбирается один из трёх вариантов дальнейших действий:
- Оптимизировать функцию или инструмент, уже существующий на странице
- Удалить со страницы существующую функцию или инструмент
- Не добавлять новую функцию или инструмент
Идея здесь следующая: решения, касающиеся производительности сайта, должны приниматься в процессе разработки, а не в конце.
Испытайте неудобства на себе
Тревожный тренд утяжеления сайтов набирает силу, и отчасти это связано с тем, что низкая производительность не кажется нам проблемой. Большинство из нас работает с быстрыми сетями с малым временем ожидания. У нас нет никаких проблем с загрузкой 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. (Это именно тот случай, когда может пригодиться метод бюджета производительности).
Не ограничивайтесь работой над визуальным оформлением сайта
Говоря об адаптивном дизайне, мы любим ссылаться на универсальность веб-среды. Но эта универсальность не ограничивается размерами экранов. Нельзя забывать и о параметрах сетей, аппаратных возможностях устройств.
Веб-среда — невероятно быстрое и интерактивное пространство, и проектирование для него подразумевает, что мы берём в расчёт не только визуальное оформление, но и другие важные аспекты работы любого сайта.
Автор: Тим Кедлек (Tim Kadlec), перевод: Proactivity
Оригинал: http://24ways.org/2012/responsive-responsive-design/
