В марте 2012 года Гай Подъярны (Guy Podjarny) провел тест, в ходе которого сравнивалась продуктивность работы сотен новых адаптивных сайтов на устройствах с четырьмя различными разрешениями экранов. Получившиеся результаты были весьма разочаровывающими.
После двух лет подъема адаптивного дизайна, когда любой дизайнер и разработчик, которых только можно представить, запрыгнули в этот поезд, тест производительности на различных разрешениях потряс сами основы адаптивной теории.
Гай доказал, что практически все адаптивные сайты имеют избыточный вес.
«Мы сделали интернет по своему подобию … Тяжелым», – Джейсон Григсби.
Но, что еще важнее, мобильные пользователи точно так же, как и пользователи настольных ПК, подвергались килобайтной перегрузке.
Представители веб-сообщества по-разному отреагировали на эти данные. Некоторые заявляли, что адаптивный дизайн не является решением на все случаи жизни и, возможно, на данный момент недостаточно развит, чтобы справляться со всеми вызовами, с которыми сегодня сталкиваются дизайнеры.
К счастью, в веб-сообществе всегда найдутся люди, которые схватят быка за рога и перевернут ситуацию с ног на голову.
Современные веб-гуру вроде Брэда Фроста (Brad Frost), Люка Вроблевски (Luke Wroblewski) и Кристиана Хейльманна (Christian Heilmann) увидели возможности там, где другие ужасались кризису, и смогли обернуть проблему на пользу сообществу.
«Если ваш сайт весит 15MB, то это не HTML5. Это глупость», – Кристиан Хейльманн.
Без обид, но производительность в вебе традиционно достигалась за счет вещей, которые лучше всего описываются жаргонизмами разработчиков. Термины вроде GZIP-инг, уродование (uglifying), минификация, DNS Lookup, файл-конкатенация… Все эти непонятные слова выносят дизайнеров за скобки.
Умные люди в сообществе, однако, все же поняли, что корни проблемы лежат глубже. На самом деле абсолютно не важно, оптимизируете вы или сжимаете изображение в ультра высоком разрешении, если при этом вы просто скрываете его от мобильного пользователя, который все равно должен скачать это изображение, чтобы его посмотреть.
«Хорошая производительность – это хороший дизайн», – Брэд Фрост.
Чтобы создавать по-настоящему легкие сайты, не стоит заморачиваться на производительности, вместо этого, производительность должна рассматриваться как один из элементов дизайна.
Производительность так же важна, как и любая другая вещь. Сайты, которые добиваются хороших результатов производительности, с самого начала придерживаются такого подхода. А те, кто упускает это из виду, в конечном итоге страдают от низкой скорости загрузки.
«Производительность – это уважение. Уважайте своих пользователей и они вернутся снова», – Брэд Фрост.
Почему так происходит
Показатель отказов
Существует исследование, согласно которому, 57% пользователей уйдут с вашего сайта, если он загружается дольше трех секунд.
Google, Page Speed & SEO
Весной 2010 года Google начал учитывать скорость при ранжировании сайтов. Она не оказывает большое влияние на позицию сайтов со средней скоростью загрузки, но если страница не загружается за определенное время, то поисковый алгоритм применяет к такому сайту штрафные санкции.
Это еще раз доказывает, что когда речь идет о пользовательском опыте, необходимо уделять внимание скорости.
Соображения скорости
Люди часто говорят о довольно абстрактной концепции «Мобильного контекста». Согласно знаменитой теории Google мобильные пользователи делятся на три типа:
- Повторяющие (Repetitive Now): люди, которые используют свои телефоны, чтобы быть в курсе непрерывных, повторяющихся изменений (спортивные результаты, обновления ленты в Facebook, динамика акций на фондовом рынке).
- Скучающие (Bored Now): Пользователи, которые обращаются к телефону во время ожидания какого-то события.
- Срочные (Urgent Now)
Похоже на правду, не так ли?
На самом деле это не имеет ничего общего с действительностью. Нет никакого «мобильного контекста». Люди будут использовать свои телефоны во время прогулки по улице, домашнего отдыха или в путешествии на поезде. Они делают все одновременно!
Телефоны следуют за людьми, куда бы те ни отправились. Поэтому люди их используют абсолютно везде.
«Мобильный контекст – важная штука, но сначала нужно понять, что же это вообще, черт возьми, такое», – Тим Кадлец.
Люк Вроблевски приводит действительно интересную статистику:
Где люди используют мобильные устройства?
- 84% дома
- 80% в свободное время в течение дня
- 76% в очередях и в процессе ожидания
- 69% в процессе шоппинга
- 64% на работе
- 62% во время просмотра ТВ-программ (альтернативные исследования дают цифру в 84%)
- 47% во время подготовки к работе
С возникновением новых возможных ситуаций, развитием новых рынков и появлением новых привычек у людей, мобильный контекст неизбежно изменится. Можно с уверенностью предположить, что концепция мобильного контекста сохранит свою актуальность до тех пор, пока люди будут пользоваться мобильными устройствами.
И это заставляет нас внимательнее взглянуть на скорость интернета. Есть только одна возможность давать пользователям тяжелый сайт и не получить при этом проблем: если пользователь будет открывать его на Macbook Pro находясь дома с быстрым интернетом.
Однако же необходимо предусмотреть и прочие ситуации, которых существует великое множество. Люди используют для просмотра сайтов бесконечное количество устройств, появляющихся на рынке каждый день.
«Вы не можете знать, с каких устройств будут просматривать ваш сайт. Это решают пользователи», – Карен МакГрейн.
Даже в тех странах, где пару лет назад было не так много смартфонов, сейчас их число растет бешеными темпами.
«Если ваши материалы, контент, информация, продукты, услуги недоступны в мобильной среде, то для этих людей они не существуют вовсе», – Карен МакГрейн.
Еще более важный момент – места, из которых люди будут приходить на ваш сайт. Так что вы должны будете учитывать любую скорость интернета. Дело даже не в том, что некоторые пользователи живут в удаленных регионах, где качество покрытия оставляет желать лучшего. Люди будут заходить на сайт с работы, где есть канал на 100 мб/с, из дома, где доступна скорость от 2 до 30 мб/с, через 3G и 4G и так далее.
Говоря напрямую, адаптивный дизайн больше не история про размеры экранов, но различные сценарии, решения для которых должны быть гибкими и продуманными «от и до».
И как?
Хорошо, что вы спросили.
Выше мы говорили, что производительность не стоит рассматривать, как набор автоматизированных заданий, запускаемых на стороне сервера для спасения обреченного сайта. Существуют способы преодолеть подобные проблемы и даже обратить их в конкурентные преимущества.
Чего стоит избегать
Гай Подъярны выделяет три главные причины существования большого количества тяжелых адаптивных сайтов:
- Загрузка и сокрытие: большое количество элементов загружается, но не показывается пользователю
- Загрузка и урезание: изображения в высоком разрешении загружаются, а затем урезаются для соответствия пользовательскому экрану
- Избыточный DOM: не существует способа избежать парсинга и обработки браузером всех зон DOM, включая скрытые
Упреждающий подход
Существует большое количество информации на тему того, почему сайтам не всегда удается соответствовать ожиданиям в плане производительности. Большинство специалистов говорят что-то вроде «нужно быть адаптивным с самого начала».
Все техники, которые мы обсудим далее, не являются чем-то новым. Интересный момент здесь в том, как они совмещаются и переплетаются, сглаживая недостатки и подчеркивая достоинства друг друга.
Прогрессивное улучшение
Смысл этой техники заключается в обеспечении опыта использования сайта в вебе, который ограничен только самым главным.
Пару лет назад эта теория воспринималась главным образом с «браузерной» точки зрения. С развитием таких технологий как HTML5, CSS3, jQuery и т.п. разработчики, кажется, забыли о своих пользователях. Многие из них создавали несовершенные сайты, слишком полагаясь на эти новые технологии.
Теперь, когда браузеры на основе Webkit, Firefox и другие отвоевали большую долю рынка, появилась другая проблема – огромное количество мобильных устройств с браузерами, которые не обладают возможностями iPhone или Samsung. Прогрессивное улучшение – это единственный подход, который предполагает, прежде всего, учет способностей всех этих забытых игроков, а уже затем движение в сторону более навороченных устройств.
Разработка Mobile First
В 2009 году Люк Вроблевски предложил подход к разработке, получивший название Mobile First, по трем причинам:
- Мобильный рынок продолжает развиваться бешеными темпами.
- Мобильная среда заставляет вас фокусироваться (позволяя избавиться от беспорядка, причиной которому является слишком большее количество места на экране).
- Мобильная среда расширяет ваши возможности (благодаря технологиям вроде GPS, геолокации, мультитач-жестам, акселерометру, камерам).
С тех пор веб-дизайн постоянно смещается в сторону этого подхода. Многие дизайнеры и разработчики отмечают, что построение сначала мобильной версии сайта, дает преимущественно над десктопной разработкой (что очень неплохо иллюстрирует второй пункт выше). Прогрессивное улучшение и подход Mobile First также неплохо сочетаются друг с другом. Разработчики начинают создавать сайт для мобильных устройств, постепенно улучшая его, добавляя большие разрешения к первоначально небольшому размеру экрана.
Джордан Мур (Jordan Moore) собрал отличный список причин использования Mobile First. Он утверждает, что из-за того, что полностью положиться на скорость соединения нельзя, «адаптивный веб-дизайнер» должен начинать работы с самой низкой входной точки – мобильной версии сайта, предполагая низкую скорость соединения, и двигаясь в разработке поэтапно, к более крупным точкам прерывания для более быстрого соединения. В будущем мы сможем полагаться на высокую скорость соединения, но пока стоит принять как должное низкое качество связи и не предпринимать опрометчивых шагов.
Вывод
Разрабатывайте сайт с расчетом на небольшие разрешения и возможности. Используйте технику прогрессивного улучшения с самого начала. Добавляйте дополнительную функциональность, улучшенные визуальные эффекты и способы взаимодействия там, где это имеет смысл.
RESS: Responsive Web design + Server Side components
По мнению многих людей у адаптивного дизайна есть один большой недостаток – он целиком и полностью зависит от определения ширины экрана.
С появлением все большего количества типов устройств, включая гибриды вроде ноутбуков с тачскринами, определение разрешения экрана стало крайне важной вещью в адаптивном дизайне. Библиотеки, которые обеспечивают эту функциональность (главным образом, Modernizr), буквально расцвели и сейчас используются в большинстве проектов. Они помогают разработчикам понимать, поддерживает ли браузер пользователя ту или иную функциональность и, соответственно, предоставлять ее. Но во многих случаях полагаться на браузеры – не лучшая идея, поскольку, зачастую, они могут поддерживать те или иные функции лишь частично, при этом «заявляя» о полной поддержке.
Для решения этой проблемы и был создан RESS. Как и Mobile First термин RESS был образован Люком Вроблевски в 2011 году. Он основывается на определении типа устройства, его оценке и обеспечении связанного пользовательского опыта. Для выполнения этой задачи существуют тяжелые средства вроде WURFL, DeviceAtlas и более легкие, такие как Browser Gem, которые считывают строку User Agent и действуют на основе этой информации.
Оценка типа устройства имеет и другие преимущества. Она позволяет разработчикам использовать различные шаблоны сайта в зависимости от устройства пользователя. Скажем, вы создаете очень большой сайт и хотите упростить мобильную навигацию. Вы можете «поиграть с контентом», показывая или скрывая что-либо, подвигать дивы по JavaScript коду или использовать разные шаблоны для мобильной и десктопной версии сайта, необходимость показа которых определяется сервером.
Представители BBC говорят о том, как RESS и прогрессивное улучшение могли бы работать отдельно. Подход называется Cut the Mustard! Он состоит в создании основной версии сайта, которая будет работать на любом устройстве. Затем устройство оценивается сервером для того, чтобы определить, «срезает ли оно горчицу». Если ответ да, то используется улучшенная версия сайта. Если же устройство не обладает нужными параметрами, пользователь все равно видит основной контент.
Условная загрузка
«Мобильные пользователи хотят видеть наше меню, часы работы и телефон доставки. Пользователи десктопа само собой хотят видеть картинку в 1 мб, на которой кто-то смеется в салат», – Мэт «Wilto» Маркиз.
Рассмотрим пару точек зрения:
1) Мобильные пользователи хотят получить контент, также сильно, как пользователи десктопов.
«Если ваш контент доступен по URL, то его обязательно будут просматривать с мобильных устройств», – Брэд Фрост.
2)Мобильная среда заставляет фокусироваться. Существуют определенные ограничения (вроде скорости соединения или размера экрана), которые дизайнерам необходимо принять, чтобы одинаково хорошо предоставить тот же самый контент.
Эта техника, также называемая «Агрессивным улучшением», позволяет дизайнерам фокусироваться на ключевом контенте и прогрессивно улучшать его для бОльших экранов. Она подразумевает базовый доступ к определенному контенту, который затем может быть дополнен на странице, при появлении места.
«Возможно, более точным определением условной загрузки будет назвать ее подходом content-first. В этом случае сайдбары или многочисленные столбцы с красивым, но нефункциональным контентом – роскошь, вам недоступная», – Джереми Кейт.
Вы можете использовать отличное средство MatchMedia, которое подражает поведению CSS и оценивает размер экрана в JavaScript.
Ленивая загрузка
Сайты, тяжелые на вид и в использовании (Facebook, Twitter, Pinterest), когда им необходима оптимизация для мобильной среды, прибегают к использованию техники ленивой загрузки (lazy loading) для обеспечения лучшего пользовательского опыта. Когда вы загружаете страницу впервые, загружается определенное число постов. Когда вы прокручиваете страницу вниз, дизайнер предполагает, что вы хотите увидеть больше контента, поэтому тот вставляется на страницу с помощью Ajax. Это позволяет значительно ускорить загрузку страницы и избежать избыточности DOM.
Установка бюджета производительности
Тим Кадлец утверждает, что установка максимального веса страницы и контроль этого показателя, является главным способом сокращения времени загрузки страницы. «Задавайте цели и стремитесь к ним». Стив Соудерс (Steve Souders) предлагает на выбор три опции, если вы уже превысили свой бюджет:
- Оптимизация существующей функции или элемента
- Удаление существующей функции или элемента
- Избегание добавления новой функции или элемента
Звучит довольно радикально, но такой подход позволяет сфокусироваться на том, как на общую производительность сайта влияет каждая новая функция.
Кроме того, существует определенное количество методов, работающих на более техническом и менее концептуальном уровне.
Техники работы с изображениями
Веб-сайты примерно на 60% состоят из изображений. И если вы показываете мобильным пользователям с неизвестной скоростью соединения картинки десктопного размера, то обрекаете свой сайт на проблемы со скоростью загрузки.
Способ решения этой проблемы заключается в показе различных версий изображений в зависимости от размера экрана или типа устройства. Таким образом, вы будете показывать маленькое изображение при заходе на сайт с мобильного телефона, картинку в высоком разрешении пользователю десктопа и еще в два раза большее изображение в случае HiDPI устройства.
Адаптивные изображения
Дизайнеры и разработчики во всем мире вели борьбу за включение адаптивных изображений в спецификацию HTML. Мэт ‘Wilto’ Маркиз один из наиболее ярких сторонников этой идеи. Битва еще не выиграна, но появились решения на базе JavaScript, которые помогают добиться желаемого результата.
Скот Йель (Scott Jehl), из Filament Group написал плагин, который имитирует разметку, предложенную сообществом, и прекрасно работает: это PictureFill.
Сжатие изображений
Голландский дизайнер Даан Джобсис (Daan Jobsis) обнаружил очень странный феномен при сжатии изображений в Photoshop. Ему удалось осуществить следующую последовательность действий: он взял изображение, удвоил его размер (200%), сжал его до 25% или менее от его первоначального качества, затем восстановил размер изображения в браузере до изначальной величины (100%). В результате изображение не только стало легче, но и изначально было оптимизировано для HiDPI экранов, благодаря дублированию плотности пикселей.
Единственная обнаруженная проблема здесь заключается в том, что браузеру может быть тяжело отрисовывать увеличенное вдвое изображение в его изначальном размере (особенно если это необходимо делать сотни раз, в случае сайтов с большим числом медиа контента). Чтобы убедиться в оптимальности данного решения необходимо уделить время тестированию.
Векторные vs растровые изображения
Отличным выбором можно назвать SVG изображения. Они полностью масштабируемы, благодаря чему хорошо работают на любом экране. Реализовать fallback в этом случае будет очень просто с помощью Modernizr.
Иконочные шрифты
Технически они на самом деле являются векторными изображениями, только представленными в виде шрифта. Как говорит Крис Койер (Chris Coyier), «иконочные шрифты изумительны» потому что:
- Легко изменять их размер
- Легко менять их цвет
- Легко оттенять форму шрифта
- Они работают в IE6, в отличие от прозрачных PNG.
- С ними можно делать все то же, что и с изображениями
- Они предоставляют неограниченный простор для типографики
Изображения HiDPI
Дэйв Бушелл (Dave Bushell) не так давно написал очень интересную статью с размышлениями о HiDPI-изображениях. Он утверждает, что, даже несмотря на то, что сегодня мы можем показывать пользователям iPhone, iPad или других современных устройств изображения, которые соответствуют возможностям этих девайсов, все еще слишком рано предполагать, что это не навредит сайту.
«Означает ли высокая скорость и высокая плотность пикселей, что пользователи хотят видеть изображения лучшего качества? В случае пакетного тарифа с ограничением по количеству гигабайт, вряд ли», – Дэйв Бушелл.
Что дальше?
Недавно Google разработал новый формат изображений – WebP. Он предоставляет возможность сжатия изображений без потерь, что позволяет получать в три раза меньшие файлы, в сравнении с PNG.
Сегодня существуют простые и легкие JavaScript-библиотеки, с помощью которых можно конвертировать изображения в и из WebP формата. Учитывая влияние последних новинок Google, вполне возможно, что начать эксперименты с WebP для улучшения работы сайтов с большим числом изображений уже сейчас может быть хорошей идеей.
Загрузка элементов
Загружайте элементы аккуратно и по порядку. Контроль этого аспекта несет в себе большие преимущества, позволяя странице сначала отображать базовый контент, а затем улучшать его.
CSS, изображения
Контролируйте загрузку с помощью media query, условной или ленивой загрузки и применяйте техники адаптивных/сжатых изображений.
JavaScript
Используйте такие функции HTML5, как async или defer. Кроме того существуют такие «помощники при загрузке», как RequireJS, который может контролировать загрузку и зависимости.
Реклама, социальные виджеты и сторонние элементы
Просто вставляйте их на страницу после загрузки.
Олдскульные техники улучшения производительности
Они известны довольно давно, но все еще неплохо работают.
Снижайте число HTTP-запросов
Чтобы это добиться, разработчикам необходимо приложить усилия, однако есть ряд способов, позволяющих достичь этого:
- Применяйте конкатенацию для всех CSS-файлов или используйте CSS Preprocessors, чтобы скомпилировать их в один файл.
- Объединяйте JS плагины в том же файле и всегда загружайте их в футере, за исключением случаев, когда им действительно необходимо блокировать рендеринг страницы (если вы загружаете шрифты Typekit в футере, вы получите знаменитый эффект FOUT или «Взрыв нестилизованного текста»).
- При необходимости работы с PNG-изображениями, используйте спрайты. Они объединяют все изображения в одно и используют CSS для «нарезки» его на нужные кусочки.
- По возможности используйте схему данных URL (рус, англ), которая позволит включать изображения в качестве строчных данных и еще сократить число HTTP-заголовков.
Снижайте число байтов
Минифицируйте каждый скрипт или CSS-файл, который вызывается со страницы. Настройте на сервере GZIP-компрессию/расширение и применяйте их для всех элементов.
Заключение
Со времен рождения адаптивного дизайна важность производительности в вебе была сильно преувеличена.
Дизайнеры и разработчики фокусируются на сборке адаптивного паззла, в качестве элементов которого стали выступать различные скорости доступа в сеть, множество различных устройств, разные места нахождения пользователей.
Чтобы подготовиться к проблемам завтрашнего дня нам необходимо обращать большое внимание на производительность, ведь декстоп-ориентированный веб исчезает прямо на наших глазах. Мобильный пользователь быстр, легок и не будет преодолевать препятствия для доступа к контенту, и, учитывая, что сайтов с каждым днем становится все больше, быть быстрым означает быть впереди.
Вам также может понравиться [en]…
- 20 плагинов jQuery для изображений и мультимедиа.
- 20 уроков по замене плагинов, подсказки, сниппеты и решения для WordPress.
- 50 бесплатных инструментов и приложений для веб-дизайнеров и разработчиков.
- 30 фантастических новых плагинов jQuery.
- Какую лицензию вы выбираете для своего кода?
- 20 уроков по CSS3 и техникам создания кнопок.
P. S. Замечания по переводу принимаются в личку.
P. P. S. Еще мы начали размещать дайджесты интересных публикаций мира юзабилити и UX в своем блоге. Вдруг кому интересно.
Автор: XvonabuR
