Совсем недавно, всего лишь год назад, мы все пели торжественные дифирамбы новой технологии адаптивного дизайна, которая должна была наконец-то решить эволюционную проблему «мобилизации» доступа к Интернету. Однако, несмотря на все очевидные достоинства responsive web design, очень скоро вскрылись существенные сложности при его проектировании.
Да, мы пришли к новому «стандарту качества» при проектировании сайтов и теперь можем забыть про такое понятие, как мобильная версия сайта. Адаптивный дизайн позволил сделать универсальное решение как для мобильных устройств, так и для стационарных компьютеров. Отпала проблема правильного отображения контента, мы далеко продвинулись в вопросах мобильного юзабилити - в условиях сокращения площади экрана мы научились определять приоритетность информации и способы ее оптимального представления. Новые, нетривиальные макеты сайтов в буквальном смысле разрывали шаблоны восприятия традиционного веба. Вроде бы, эпоха future friendly наступила, но…
То, что безусловно хорошо для пользователей, не всегда легко выполнить разработчикам. К числу «тонких моментов» при проектировании адаптивного дизайна можно отнести следующие:
- Некорректное изменение размера изображений
- Обработка стороннего контента, используемого на сайте
- Совместимость с более ранними технологическими решениями (старые браузеры и т.д.)
- Баги устройств
- Сложный менеджмент такого рода проектов.
Разрешение всех этих проблем естественным образом увеличивает сроки сдачи проекта и удорожает его стоимость. Но давайте посмотрим на результат.
Как звучит один из постулатов адаптивного дизайна, сайт самостоятельно определяет тип воспроизводящего его устройства и подстраивается под размер его экрана или, в случае с десктоп-версиями, под ширину окна браузера.
В качестве эффектного трюка демонстрации технологии часто показывают следующее: открытое окно браузера начинают сужать, и вслед за этим верстка сайта начинает без перезагрузки страницы подстраиваться под изменения. Изображения становятся меньше, исчезают или замещаются текстом, некоторые блоки скрываются, горизонтальное меню становится вертикальным – так далее. Выглядит действительно эффектно, а теперь перейдем к практической стороне этого действа.
Адаптивный дизайн представляет собой не что иное, как совокупность нескольких шаблонов страниц, каждый из которых «заточен» под определенное разрешение экрана. Как правило, разработчики предлагают 3 основных шаблона:
- для полноразмерной версии сайта (например, от 1280 пикселей по ширине),
- для планшетов (1024)
- для смартфонов (640).
При первоначальной загрузке страницы вы будете загружать ВСЕ три шаблона, со всеми соответствующими им скриптами, но на экран будет выводиться только тот, который максимально удовлетворяет текущему разрешению экрана или ширине окна браузера.
Даже если вы заходите на сайт с адаптивной версткой с мобильного устройства и видите «усеченную» версию основного сайта, велика вероятность того, что вы загружаете его полностью, со всеми компонентами. Даже если часть элементов сайта скрыта, вы все равно их загружаете. Это, во-первых, не рационально с точки зрения логики, а, во-вторых, серьезно подвергает сомнению сам принцип удобства мобильного пользователя, на которого перекладываются лишние расходы на неэффективный трафик.
Неудачный пример использования адаптивного диайна, сайт The Boston Globe;
обилие элементов существенно утяжеляет загружаемые «по умолчанию» шаблоны
На сегодняшний день адаптивного дизайна уже мало. На повестку дня выходит оптимизация работы с ним, и, в частности, технология, получившая название RESS (аббревиатура, соединившая в себе Responsive Web Design и Server Side Components).
Если коротко, эта технология позволяет выполнять часть задач при работе с адаптивным сайтом за счет ресурсов серверной части. При первоначальной загрузке сайта загружается только один шаблон, соответствующий устройству доступа. Соответственно и количество загружаемых обслуживающих его скриптов сокращается в разы.
На практике это означает, что трюк, о котором шла речь выше, уже не удастся исполнить без перезагрузки страницы – при изменении размеров окна сайт будет воспроизводить именно тот шаблон, который был вызван при обращении к серверу.
Использование подхода RESS позволяет запускать версии сайта последовательно: основная, под планшеты, под смартфоны, - в то время как полностью адаптивный макет требует верстки сразу всего сайта. Последний вариант может быть гораздо дольше, дороже и сложнее в поддержке и обслуживании.
Рассмотрим технологию RESS на примере 2-х проектов: оба представляют собой сайты, использующие в той или иной форме технологию адаптивной верстки.
Адаптивный сайт компании «Пластика Окон» (plastika.pirogov.ru)
Сайт компании Saiwala (saiwala.ru)
Сайт «Пластики Окон» автоматически загружает все разработанные шаблоны и ситуативно использует тот из них, который соответствует экрану просмотрщика.
Сайт «Saiwala» демонстрирует нам пример использования компонентов Server Side – загружается только тот шаблон страницы, который актуален для устройства доступа. При изменении размеров окна на стороне клиента изменений не происходит, для загрузки нового шаблона при изменении размеров окна браузера требуется перезагрузка. Этот сайт более «легкий» для мобильного доступа, но – формально – он может даже не считаться адаптивным, поскольку технически адаптация происходит не на сайте, а на стороне сервера, который в ответ на запрос пользователя передает ему нужный шаблон. Тем не менее, визуально это выглядит также как адаптивный дизайн.
Шаблон для мобильного устройства, растянутый до полноформатного размера
Шаблон для планшетов сочетает в себе элементы адаптивной верстки
Принцип Server Side позволяет осуществлять на серверной части как хранение данных, так и частичное исполнение процессов, что экономит ресурсы клиентской части. В том, что касается мобильного доступа, это может существенно экономить пользовательский трафик и ускорить обработку запросов. На стороне сервера может происходить декодирование мультимедийной информации, контроль верстки, стилей CSS и JS, - и, как итог, пользователь получит только тот контент, который ему нужен, и именно в том виде, который оптимален для его устройства.
По сути дела, RESS – это адаптация адаптивного дизайна к техническим особенностям взаимодействия устройства доступа и сервера, к которому осуществляется доступ. В этом подходе нет ничего принципиально нового, однако он расширяет наше понимание возможностей адаптивного дизайна и способов его практического использования.
Орфография и пунктуация в данном тексте сохранены в том виде, в котором они были предложены автором.
Главное время загрузки. Что толку от всяких вариантов контента сжатого по технологии Compact HTML или использовании разных шаблонов, тогда как обычная загрузка картинок размером в 2 Мбайта (обычные размер сделанного фото на мобильнике) перечеркивает все усилия. Необходим такой фреймворк, который, при внешней схожести подготавливал «правильный» контент, для большого разнообразия мобильников.
Посмотрим результаты теста мобильного фреймворка: MobiCot - PHP Mobile Content Management Framework http://mobitest.akamai.com/m/results.cgi?testid=130508_PE_18 и вы увидите, что даже, уже заранее, подготовленные фреймворком в размер экрана мобильника картинки дают основной вклад. А что будет если перекачивать большие картинки и полагаться на приемы адаптивного дизайна картинок,это будет неприемлемое время.
Эволюция должна идти на серверной части. Например с использованием и обработки адаптивных ББкодов, таких как фото, меню...
Интересно то, что счетчик яндекса существенный тормоз.