С началом эры бума мобильных устройств разработчики оказались перед выбором: оставлять ли мобильные версии своих сайтов наряду с «полноценными», или сайты должны стать адаптивными и самостоятельно подстраиваться под разные размеры экранов?

На текущий момент при построении мобильных версий сайтов существуют 3 основных способа их построения:

• Адаптивный дизайн;
• Отдельная мобильная версия сайта;
• RESS (Responsive Design + Server Side).

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

Адаптивный дизайн

Для реализации адаптивного дизайна обычно используются CSS3 Media Queries. В зависимости от размера экрана, пользователь будет видеть разную картинку:

@media screen and (max-width: 1600px) {
    div.for-example {width: 1500px;}
}
@media screen and (max-width: 1280px) {
    div.for-example {width: 1100px;}
}
@media screen and (max-width: 1024px) {
    div.for-example {width: 980px;}
}

Преимущества адаптивного дизайна

• Удобство разработки — при адаптивной верстке вся структура сайта автоматически подстраивается под различную ширину экрана. Для того, что бы получить рабочий продукт не нужно писать все с нуля — достаточно лишь подправить CSS и HTML… С учетом наличия фреймворков, подобных Bootstrapподобная разработка не является очень сложной при стандартной реализации. К тому же, поддержка такого продукта будет относительно простой задачей.
• Один URL — избавляет нас от ненужных редиректов, и надобности пользователю запоминать адрес мобильной версии (пусть даже это просто приставка m. ). Так же наличие единого адреса позитивно скажется на продвижении сайта, поскольку поисковикам будет «удобнее» работать.

Недостатки адаптивного дизайна

• Разные задачи - типовые задачи «мобильных» пользователей крупных сайтов обычно отличаются от задач пользователей ПК. Если вы являетесь клиентом банка, то, скорее всего, в мобильной версии сайта вас будет интересовать очень ограниченный спектр информации — адреса ближайших отделений, банкоматов и т.д.
  В целом, при адаптивной верстке самый распространенный подход — делать копию обычного сайта, реализовать в верстке под телефоны потребности всех групп целевой аудитории. Но тогда о юзабилити можно забыть. Нужные пяти процентам посетителей второстепенные разделы создадут неудобства для основной массы клиентов.
• Медленная загрузка - «вес» сайтов остается серьезным препятствием для пользователей мобильных телефонов. Это означает, что некоторые типичные для десктопных сайтов активные элементы, в том числе embedded-карты, ролики, кредитные калькуляторы и меню с анимацией на мобильных сайтах должны быть заменены на более легкие альтернативы. Может ли адаптивный дизайн дать нам такую возможность? В популярной реализации пользователь с маленьким экраном должен загрузить страницу целиком, чтобы увидеть лишь ее часть. Например, если десктопная версия верстки главной весит 200 Кб, а мобильная — еще 50 Кб, для просмотра придется скачать 250 Кб. Конечно, можно использовать сжатие кода страницы, но лишние запросы к серверу все равно будут идти.
• Безысходность - Одно из неоспоримых преимуществ мобильной версии: если не нравится, ее можно отключить, перейти на обычный домен. Сайты с адаптивным дизайном не дают этого простого, но важного выбора. Если адаптированная верстка неудобна, забагована или если она скрывает важный элемент навигации, пишите пропало: вы ничего не можете сделать, чтобы увидеть его снова. Придется бежать искать десктоп или сайт конкурента. Можно придумать «костыли» для обхода этого ограничения (использовать cookie и подключать разные таблицы стилей). Но такой подход усложняет разработку.

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

Отдельная мобильная версия сайта

Чтобы сделать сайт удобным для мобильных пользователей часто создают так же отдельные версии сайтов — специально ориентированные на пользователя со смартфоном/планшетом. Наиболее распространена практика — перенаправление мобильных пользователей на специальный поддомен (m.example.com, mobile.example.com и т.д.). Наверное, в 99% случаев, мобильная версия представляет собой урезанную основную версию — лишь с тем функционалом, который, по мнению разработчиков, будет необходим и полезен пользователям мобильных устройств и планшетов.

Преимущества мобильной версии

• Легкость в изменениях — поскольку сайт существует, де-факто, отдельно от основной версии, вносить в него правки, связанные только с мобильной версией значительно проще, поскольку мобильная версия чаще всего не предоставляет избыточного, ненужного функционала.
• Удобство для пользователя — мобильная версия обычно сильно упрощена по сравнению с десктопной версией, поэтому пользователю не нужно будет далеко ходить за нужной ему информацией.
• Быстрота — из-за того же упрощения сайта, мобильная версия грузится быстрее. Это существенно для пользователей, которые все ещё ходят через GPRS или слабый 3G.
• Выбор- чаще всего, в мобильной версии есть возможность перейти на основную версию сайта.

Недостатки мобильной версии

• Несколько адресов — для десктопной и мобильной версии разные адреса. Для одних это может оказаться плюсов, для других же — крайне раздражительным фактором, когда для того, что бы удобно посмотреть сайт, нужно запоминать ещё один адрес. Так же есть проблемы и с поисковиками: во избежание дублированного контента SEO-специалистам нужно использовать мета-теги rel=«alternative» и rel=«canonical». Кроме того, когда пользователь мобильного поиска Google кликнет по ссылке в результатах, он попадет на десктопную версию или перенаправлен на мобильную. Но если мобильная версия этой страницы не существует, он получит сообщение об ошибке.
• Неудобство для пользователя — для десктопной и мобильной версии разные адреса. Для одних это может оказаться плюсов, для других же — крайне раздражительным фактором, когда для того, что бы удобно посмотреть сайт, нужно запоминать ещё один адрес. Так же есть проблемы и с поисковиками: во избежание дублированного контента SEO-специалистам нужно использовать мета-теги rel=«alternative» и rel=«canonical». Кроме того, когда пользователь мобильного поиска Google кликнет по ссылке в результатах, он попадет на десктопную версию или перенаправлен на мобильную. Но если мобильная версия этой страницы не существует, он получит сообщение об ошибке.
• Ограниченность — создание отдельного мобильного сайта означает избавление от части содержания и функциональности. Кроме того, у вас может быть два различных набора контента, который может негативно сказаться на общей информационной картине.

В целом, создание мобильных версий сайтов оправдывает себя достаточно хорошо, в частности, для крупных проектов. Как пример — Amazon использует у себя специальную, мобильную версию сайта.

RESS

Сам Google, хоть и поддерживает использование веб-мастерами адаптивного дизайна, однако в своих продуктах использует иную систему. Если зайти, к примеру, на главную страницу под разными User-Agent-ами, то можно увидеть различный HTML для различных устройств. RESS — Responsive Design + Server Side. Пример реализации, набросанный «на коленке»:

$DS = DIRECTORY_SEPARATOR;
require_once( dirname(__FILE__) . $DS . 'libraries' . $DS . 'browser.php');
$device = BBrowser::detectDevice();
if($device == DEVICE_TYPE_MPHONE){
    $tmpl = 'template.m.php';
}
else if($device == DEVICE_TYPE_TABLET){
    $tmpl = 'template.t.php';}
else{
    $tmpl = 'template.php';
}
include( dirname(__FILE__) . $DS . 'templates' . $DS . $tmpl);

Плюсы RESS

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

• Минимизация трафика — Ненужные JavaScript могут быть удалены из HTML, который освобождает CPU, память и кэш на мобильном устройстве. Так же может быть специально оптимизирована html и css.
• Возможно использовать таргетирование — например, для Android-устройств предлагать скачать приложение с GooglePlay, а для Apple – с iTunes. Для каждого устройства можно сделать свою вёрстку.

Минусы RESS

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

В целом же, RESS — самый лучший из трех предложенных вариантов, однако требует намного больших трудозатрат при разработке.

Резюме

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