Компания
30,72
рейтинг
26 февраля 2013 в 17:27

Разработка → Сравнение методов создания мобильных версий сайтов

Не так уж и давно наличие адаптивного или мобильного сайта стало не трендом, а реальной необходимостью — трафик с устройств продолжает расти, а пользователи уже начинают отказываться от больших компьютеров в пользу смартфонов и планшетов. Для создания таких сайтов сейчас, в основном, используются три метода: адаптивная верстка, разработка отдельной мобильной версии и RESS. Johan Johansson опубликовал сравнение этих методов, перевод которого мы и представляем вашему вниманию. Под катом много текста и картинок.

Кажется, споры насчет технологий создания мобильных сайтов в ближайшее время не утихнут. В этих вопросах Google, например, придерживается разработки адаптивного веб-дизайна, в то время как Якоб Нильсен, известный консультант по юзабилити, выступает за создание отдельных мобильных сайтов.
Третий вариант, который уже становится популярным — когда веб-сервер генерирует соответствующие HTML и CSS в зависимости от устройства по параметрам, получаемым из URL.

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

Для тестирования был использован iPhone 4 с IOS 5,0.

Адаптивный веб-дизайн


Адаптивный веб-дизайн обычно использует CSS3 Media Queries для настройки макета веб-страницы, основываясь на размере области просмотра. Можно использовать один и тот же HTML для отображения различных макетов веб-страницы для настольных компьютеров, планшетов, мобильных устройств, телевизоров и т.д.

Преимущества

  • Сохранность содержимого: Ваш сайт сохраняет контент и HTML разметку, независимо от используемого устройства. Этот подход будет приобретать все большее значение, поскольку все больше людей используют смартфоны в качестве основого средства доступа к Сети.
  • Один URL для веб-страниц: Это облегчает процесс расшаривания контента и избавляет от ненужных редиректов, чтобы получить лучший вид страниц для разных устройств (в отличие от отдельных мобильных сайтов).

Недостатки

  • Материалы не будут полностью оптимизированы для мобильных устройств: Если вы не используете подход, при котором в первую очередь проектируется страница под мобильные, ваш сайт будет содержать ту же информацию, что и его десктопный брат. Сравните это с отдельным мобильным сайтом, где вы могли бы потенциально адаптировать содержание веб-страниц только для мобильных пользователей.
  • Медленная работа: согласно данным за январь’13, средняя веб-страница сегодня весит около 1,3 Мб. Теоретически такого размера можно избежать при использовании адаптивного дизайна, но на практике 86% “резиновых сайтов” весят именно столько, а то и больше.
  • Может быть трудно перемещаться по сайту: Задачи мобильных пользователей как правило отличаются от обычных. Кроме того, они могут быть более привычны к использованию мобильной версии интерфейса и если вы не продумаете структуру навигации для каждого устройства, могут быть проблемы с юзабилити.


Примеры:


Starbucks


image

Сайт Starbucks является отличным примером, демонстрирующим плюсы и минусы адаптивного веб-дизайна. Весь их контент доступен на мобильных устройствах, каждая страница использует один и тот же URL, нет никакого перенаправления.
К сожалению, их сайт является тяжелым для загрузки (около 15 секунд на 3G-смартфоне), и необходимо много прокручивать, чтобы прочесть всю страницу.

Результаты:
Среднее время загрузки: 14,99 секунд
Средний размер страницы: 1,193.88 KB
Количество запросов HTTP: 142

Всемирный фонд дикой природы


image

Сайт Всемирного фонда дикой природы является хорошим примером реализации адаптивного веб-дизайна. Навигация оптимизирована для мобильных задач.
Тем не менее, время загрузки на 3G-смартфоне оставляет желать лучшего (это занимает около 7 секунд). Кроме того, некоторые внутренние страницы (например, их форма подтверждения ) не были оптимизированы для мобильных устройств и остались неудобными для использования на мобильном устройстве.

Результаты:
Среднее время загрузки: 6,91 секунд
Средний размер страницы: 885,97 KB
Количество запросов HTTP: 72

The Boston Globe


image

Сайт Boston Globe — возможно, один из лучших масштабных проектов с адаптивным дизайном. Сайт использует “резиновые” изображения и оптимизирует JavaScript, чтобы он не отразился на производительности на мобильных устройствах.

Результаты:
Среднее время загрузки: 5,55 секунд
Средний размер страницы: 605,27 KB
Количество запросов HTTP: 87

Отдельный мобильный сайт


Чтобы сделать сайт удобным для мобильных пользователей, некоторые веб-мастера создают отдельные сайты. Наиболее распространена история с перенаправлением мобильных пользователей на специальный поддомен (например, mobile.examplesite.com для examplesite.com ).

Преимущества:

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

Недостатки:

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


Примеры выделенных мобильных сайтов


Walmart

(mobile.walmart.com)
image
Отдельный мобильный сайт Walmart показывает невероятно быстрое время загрузки — всего 1.35 секунды

Результаты:
Среднее время загрузки: 1,35 секунд
Средний размер страницы: 272,29 KB
Количество запросов HTTP: 45

Amazon

(www.amazon.com / GP / AW / h.html)
image
Как и у Walmart, страницы мобильного сайта Amazon загружаются быстрее, чем при адаптивном дзайне ( 2,25 секунды).
Странно, однако, что не все страницы на сайте имеют мобильные версии. Например, если вы ищете в Google с помощью смартфона, многие результаты будут относиться к “большой” версии сайта без редиректа на мобильную версию. Кроме того, если вы обратитесь к мобильной странице с десктопного компьютера, вас не перенаправят на полную версию.

Результаты:
Среднее время загрузки: 2.25 секунд
Средний размер страницы: 103,66 KB
Количество запросов HTTP: 16

BBC

(www.bbc.co.uk / мобильный)
image
Страницы сайта BBC для мобильных устройств грузятся быстрее по сравнению с адаптивными (3,40 секунд), но почти половина этого времени занимает перенаправление пользователей (1,65 секунды).
В отличие от сайта Amazon, если вы пытаетесь получить доступ к странице для мобильных устройств с десктопного компьютера, вы будете автоматически перенаправлены обратно на “большую” версию сайта.

Результаты:
Среднее время загрузки: 3,40 секунд
Средний размер страницы: 56,04 KB
Количество запросов HTTP: 22

RESS: Вывод разных HTML и CSS на одном URL


Этот метод создания мобильных сайтов использует программирования на стороне сервера, чтобы создать CSS и HTML для различных устройств. То есть мобильные пользователи получают один набор кода, в то время как пользователям десктопных компьютеров выводится другой набор кода.

Это сделано с целью повысить эффективность сайта и лучше всего работает в связке с адаптивной версткой.
Такой метод был назван адаптивный веб-дизайн + ПО на стороне сервера (RESS).
При использовании этого метода, важно, чтобы был включен тип заголовков Vary HTTP (подробно об этом написано в справке Google, руководство по созданию оптимизированных веб-сайтов ), так что поисковые роботы будут посещать как настольные и мобильные версии.

Преимущества:

  • Легче ориентироваться: структура навигации может быть настроена для различных задач, выполняемых с мобильных и настольных компьютеров.
  • Меньше элементов на странице: Вместо того, чтобы создавать скрытые для мобильных устройств элементы страницы, они могут быть удалены из HTML или CSS. Это позволит уменьшить объем загружаемых данных и ускорить время загрузки.
  • Быстрое время загрузки: Ненужные JavaScript могут быть удалены из HTML, который освобождает CPU, память и кэш на мобильном устройстве.

Недостатки:

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


Примеры RESS


CNN


image

В мобильной версии используется сочетание HTML и CSS, оптимизированное для мобильных ПК, в то время как настольная версия использует значительно больше HTTP запросов и JavaScript.
Навигация также специально продуманна конкретно для мобильных задач.

Результаты:
Среднее время загрузки: 3,46 секунд
Средний размер страницы: 163,12 KB
Количество запросов HTTP: 28

eHow


image
Как и в CNN, для мобильной версии eHow настроены HTML и CSS. Навигация верхнего уровня одинаковая для обоих сайтов, делается акцент на поиск и семь основных рубрик.

Результаты:
Среднее время загрузки: 6,15 секунд
Средний размер страницы: 188,95 KB
Количество запросов HTTP: 31

SlideShare


image
Мобильная и настольная версии SlideShare совершенно разные. Мобильная версия использует адаптивный веб-дизайн, в то время как настольная — нет.Каждый сайт использует разный HTML и CSS. Например, в мобильной версии значительно меньше присутствует JavaScript. Каждый сайт также использует различные структуры навигации.

Результаты:
Среднее время загрузки: 6,15 секунд
Средний размер страницы: 188,95 KB
Количество запросов HTTP: 31

Резюме


Теоретически, адаптивный веб-дизайн является лучшим решением. Но на практике большинство таких сайтов реализованы неправильно и приводят к увеличению времени загрузки.
Мои тесты показывают, что лучшее время загрузки — у мобильных сайтов, но есть значительные недостатки в такой реализации задачи.
По моему мнению, лучше всего использовать комбинацию из адаптивного веб-дизайна и RESS. В этом случае мы получаем все плюсы “резиновой верстки” и решаем две больших проблемы: использования множества файлов и медленную загрузку.



Дмитрий Васильев, NetCat: “Для специалистов — дизайнеров, проектировщиков, верстальщиков — адаптивный сайт это куда более интересная задача, чем традиционная связка сайтов «широкоформатный-мобильный». Но недостатки адаптивных сайтов в статье описаны довольно подробно. Я бы еще добавил сложность подготовки контента после запуска сайта. Представьте: секретарю ставится задача в раздел «О компании» поставить большую фотку директора и таблицу с важными вехами в истории развития. Разумеется, она не сможет подготовить адаптивный контент, даже если захочет. Правильный подход — передать задачу профессионалу, но тем самым мы повышаем стоимость владения сайтом для пользователя.

Но есть сайты, которые объективно лучше изначально делать адаптивными. Например, это корпоративные визитки или другие сайты без сложной функциональности. И мы считаем, что разработчик должен иметь выбор. Поэтому сайт под управлением NetCat может работать в одном из трех режимов: обычный сайт, мобильная версия обычного сайта и адаптивный сайт (и все модули системы также поддерживают эти режимы).

Что касается RESS, то это интересный подход, но он не снимает всех проблем, связанных с адаптивной версткой. К тому же, часто пользователю смартфона лучше предложить выбор, смотреть ему обычный сайт или мобильный, потому что сценарии использования веба на телефонах могут быть разные. Например, я с телефона часто захожу на Афишу. Если я хочу выбрать фильм или кафе, я захожу на обычную версию сайта, если посмотреть, где идет нужный мне фильм или узнать какой-то адрес — на мобильную. И я доволен тем, что сайт не решает за меня, в каком виде смотреть контент, а дает выбор.

Резюмируя: я считаю, что для большинства задач подход «обычный сайт плюс мобильная версия» является путем наименьшего сопротивления, благо современные CMS позволяют резко минимизировать расходы на создание второго сайта. Но однозначной победы какого-то из конкурирующих подходов в ближайшее время не будет.”

Какие методы вы используете для создания мобильных сайтов? Поделитесь своими мыслями на эту тему в комментариях или отметьте вариант опроса.
Какого метода придерживаетесь вы?

Проголосовало 1098 человек. Воздержалось 275 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Автор: @loginovskaya
NetCat
рейтинг 30,72
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Комментарии (37)

  • +3
    >> Этот метод создания мобильных сайтов использует программирования на стороне сервера, чтобы создать CSS и HTML для различных устройств
    А остальные методы как? Готовые .html страницы сразу складывают в папке?
    • +1
      Остальные могут адаптироваться посредствам вёрстки, при одинаково отдаваемом контенте. Отдельный мобильный сайт сам по себе отдаёт готовое решение для мобильных устройств.
      • +3
        Речь о том, что перед тем, как отдать мобильный сайт, все равно происходит формирование страниц на сервере, (где самое прожорливаое — запросы к БД), а влияние этого RESS на скорость отдачи страниц будет на уровне погрешности вычислений
        • +1
          Это понятно и без того, вопрос всё же про методы. Когда устройству отдаётся именно под него оптимизированная структура — система устройства не грузит процессор и прочие ресурсы на оптимизацию отображения.
  • +1
    CSS сейчас полностью позволяет адаптировать содержание к экрану. Остается только загрузка лишнего JS-кода (что можно на уровне JS определять), лишней HTML-разметки (но эти 3-5 Кб мало кого волнуют) и неоптимизированные изображения (вот их на уровне сервера, видимо, только вставлять). Хотя если через JS подгружать изображения, то с сервера и эту нагрузку снять можно.
    • 0
      Если я ничего не путаю, то сейчас nginx умеет на лету оптимизировать изображения (ресайзить точно умеет).
      • –1
        php тоже умеет ресайзить на лету изображения. Уже лет 10 точно :) А через cgi-bin и Apache уже лет 15 такое возможно.
        • +9
          Извините, забыл приписать «не роняя сервер».
      • 0
        Может молодой и зеленый, но совсем не понимаю зачем это нужно делать?
        Почему нельзя при заливку создавать несколько копий разного разрешения? Дисковое пространство — самое дешевое из остальных параметров сервера
        • 0
          Это у кого как) вообще это просто как вариант, всё зависит от случая. Например если у вас крупный, совсем картиночный сайт или вроде того, то дисковое пространство вам будет нужно, а заодно вам нужно будет разработать систему, которая будет конвертировать, отдавать для разных параметров разные картинки, и т.д. Иногда проще один раз настроить веб-вервер, который будет ресайзить и кэшировать. Я не говорю, что так нужно делать всегда)
  • 0
    Я считаю что лучше всего писать универсальный API на бэкенде, а на фронтенде адаптивная верстка с каким-нить js mvc фреймворком(Backbone, Ember, Spine, Angular итд) который и работает с этим API и по сути является HTML5 приложением. Ну и js-шаблоны можно делать разные для десктопного и мобильного и использовать HTML5 app cache. Ну например с помощью AMD можно какие-то скрипты грузить или нет итд. Не так уж критично что первая загрузка сайта будет долгой, ведь потом все скрипты и стили будут лежать в app cache и с сервера будут поступать только json данные которые не много весят.
    А уже потом, при необходимости, создать нативные приложения для мобильных платформ которые с этим-же API и будут взаимодействовать.
    • +3
      Как бы оно так да не так…
      Увы много у этого подхода недостатков. Индексация поисковиками — никакая (делать hashbang копии страниц — дополнительные затраты времени и далеко не все поисковики поддерживают). Шаринг в социальных сети мягко говоря непрост — одни сети вообще убирают location hash, другие ищут open graph, который закономерно един для SPA. Но куда хуже проблема с кэшированием — размер кэша у большинства браузеров (особенно мобильных) ограничен, и складывая туда мегабайты яваскрипта мы ускоряем лишь загрузку последующих страниц. А завтра пользователь будет качать javascript по новой.
      Кроме этого AMD порождает очень много http запросов. (решается через rjs для requirejs, но использует его нечасто). Если целится на нативные приложения — о сессиях необходимо забыть сразу, а это ещё пачка проблем. SPA на MVC-фреймворке с REST-API на сервере — это классная штука, но окружение пока ещё не очень к ним дружелюбно.
      • +3
        HTML5 History API убирает проблему hashbang. GitHub один из самых показательных примеров. Есть множество плагинов которые решают проблемы с кросс-браузерностью.
        • 0
          Ээээ а можно подробнее? Как мне пошарить страницу вконтактик через html5 history?
          • 0
            Изначально у SPA (single page application) возникала проблема, что контент меняется, а URL остается. Чтобы это исправить, использовались хеш-теги, например myapp.com/#!/about или myapp.com/#!/news/17. Тут возникает куча проблем, которые описал xel — то что после # не отсылается на сервер.

            С появлением History pushState можно менять URL, который показывается в адресной строке, не перегружая при этом страницу. Таким образом пользователь, перейдя с главной страницы на новость будет видеть myapp.com/news/17 и этот же URL будет шарить в контактик.
            • 0
              … и как быть с тем, что порядка 40% или сколько там пользователей сидят на ИЕ? Какие такие чудо-плагины порешают проблему с кросс-браузерностью в случае соц. сетей, отрезающих хэш?
              • 0
                Ну значит 60% смогут копировать URL из адресной и шарить его в соц. сетях. Остальные пусть нажимают кнопку Like/Share, в которой адрес будет указан явно. Плагины просто делают fall-back в URL с хешами.

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

                • 0
                  В том-то и дело, что плагины делают fall-back в хэши. И получается у нас уже три урла у одной страницы (нормальный, с хэшбэнгом и жуть после раскрытия хэшбэнга). А это уже совсем печалька.
  • +1
    Может быть, ссылки на сайты-примеры добавите? Чтобы народу не гуглить.
    • 0
      Сейчас поправлю)
  • +5
    Меня всегда полностью устраивает обычная немобильная версия, что на смартфоне, что на планшете. Если открывается урезанная мобильная, то насильно переключаюсь в полную версию. Неудобства никакого нет. Неудобство скорее от пользования «специальными» мобильными версиями с урезанным функционалом, отключенными комментариями и т.д.
    • +2
      На планшете согласен, часто даже странно выглядит мобильная версия на большом экране, почти как у ноута. А вот на мобильнике лучше всё-таки по умолчанию открывать мобильную версию, и давать кнопку перехода на полную, если чего-то не хватает (лучше, конечно, чтобы все функции были и в мобильной).
  • 0
    Я за адаптивный дизайн (в целом) (сам недавно пробовал верстать).

    Время загрузки отличается полагаю из-за насыщенности страницы графикой. И если фоновое изображение можно легко переназначить на более «легкое» или вообще не использовать картинку, то с тегом img могут быть проблемы. И опять же, с помощью того-же css можно скрывать то, что по мнению разработчиков не должно быть видимым в мобильной версии сайта, впрочем, насколько я понимаю, это перечит концепции адаптивного дизайна.
  • +3
    Для начала хочу бросить камень в огород любителей отдельных мобильных версий сайтов: когда я поочередно посещаю один и тот же сайт, пользуясь десктопом / мобилой / планшетом, я меньше всего на свете хочу лицезреть координально разную логику взаимодействия с интерфейсом. Я хочу, чтобы все возможные версии были максимально приближены друг к другу и пускай на телефоне громоздкое меню будет спрятано под заметной кнопкой «меню». И вообще, на телефоне с горизонтальным разрешением >1000px я не желаю лицезреть убогую мобильную версию, хочу оригинал.

    Потом, «Мобильные пользователи должны быть как-то вычислены, а технология определения устройств пока недостаточно надежна». Неужели?

    Замеры скорости загрузки сайтов-примеров меня умиляют. Starbucks, например, грузился добрые несколько секунд на десктопе с 50 мегабинтым интернетом. И вообще, хватит уже считать килобайты. Смотрите за производительностью сервака, за тем, сколько статики он отдает и сколько динамического содержимого при загрузке страницы. Пусть мгновенно загружаются тексты, и скелет страницы (базовый шаблон), а потом плавно подгружается все остальное.

    Лично я обоими руками голосую за адаптивный дизайн. Более того, сегодня считаю это направление веб-разработки одним из самых интересных.
  • 0
    del
    • 0
      Немного подумав, я также пришел к выводу, что автор путает цель и средства.

      Мобильную версию можно сделать легкой как и отдельной страницей, так и использовав @media правила, просто скрыв «лишние» блоки, порезав графику.

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

      Весь вопрос в концепции и предполагаемых сценариях использования.

      С моей точки зрения с технической стороны использование @media правил намного элегантнее и правильнее.
  • 0
    время загрузки на 3G-смартфоне оставляет желать лучшего (это занимает около 7 секунд)

    Мне бы такие проблемы со скоростью загрузки) Это при том количестве не адаптивных сайтов, которые грузятся от минуты до пока не надоест ждать.
    • 0
      Opera mini, при всех её других недостатках, часто грузит десктопные сайты быстрее чем другие браузеры грузят мобильные их версии.
  • +1
    как-то писал свои мысли про тот момент когда еще можно использовать media queries, а когда уже нужен отдельный мобильный сайт и как все это реализуется, не буду пересказывать, может будет интересно:
    nazz.me/few-words-about-responsive-design/
  • 0
    Переключение в режим просмотра полной версии сайта с мобильного устройства должно осуществлять нативно само это устройство. В качестве примера могу привести Internet Explorer на Windows Phone, там в настройках указывается, какой версией надо представляться: обычной или мобильной. К сожалению, пока не дошли руки протестировать, как это будет работать с адаптивной вёрсткой, отталкивающейся от ширины экрана.
    • 0
      В родном браузере Андроида (4 и выше) тоже есть возможность переключаться между мобильной и обычной версиями, но это задается для конкретной открытой страницы. Если галочка на отображение большой версии стоит по умолчанию для всех сайтов, которые будут открываться на устройстве, это тоже не есть хорошо, потому что многие из них все равно еще сложно просматривать с маленьких экранов
      • 0
        Мой комментарий был к этому:
        Например, я с телефона часто захожу на Афишу. Если я хочу выбрать фильм или кафе, я захожу на обычную версию сайта, если посмотреть, где идет нужный мне фильм или узнать какой-то адрес — на мобильную. И я доволен тем, что сайт не решает за меня, в каком виде смотреть контент, а дает выбор.

        Я считаю, что сайт должен «решать за пользователя», в каком виде показывать контент на уровне определения по заголовкам и пр. Пользователь же, если хочет видеть не мобильную, а обычную версию сайта должен иметь возможность указать это нативными способами на самом устройстве. В таком случае и волки сыты и овцы целы: большинство пользователей, просматривая сайт с мобильных устройств будут видеть мобильную версию и всё ок; те же, кому надо полную версию на смартфоне поставят соответствующий чек-бокс в настройке и тоже будут рады.
  • +1
    Сколько не сталкивался, мобильные версии сайтов вызывают обычно раздражение и воспринимаются обрезанными. То, что красиво смотрится на сайтах дизайнеров или на каталогах шаблонов, в жизни часто неудобно для использования. Меню становятся на всю ширину телефона, красоты пропадают, появляются какие-то автоматические перенаправления на мобильную (либо нет) версию сайта — сплошные условности, за которыми страницу воспринимать только сложнее…

    По мне, так проще ориентироваться на дексктопный режим браузера, при возможности. Мобильник — это не платформа для серфига, это инструмент быстро что-то посмотреть. Чем быстрее будет выдан контент, и чем меньше придется разбираться, где в мобильной версии те же кнопки/ссылки, что в десктопной версии, тем быстрее я найду нужную информацию.

    С планшетом, конечно, более спорно. Главное же — не скрывать информацию, чем бы пользователь не зашел на сайт, это будет самое честное.
    • 0
      На пример webasyst, лучше не делать мобильной версии, чем делать такую
  • 0
    Перед разработкой решения для мобильных устройств главное определить, для чего пользователи заходят с мобильных телефонов. Не столько важна подгонка под ширину экрана (тексты, естественно, должны быть масштабируемы при приближении, а то бывает...), сколько возможность быстро получить от сайта желаемое (телефон, карту проезда, свежие цитаты с башорга, ближайший сеанс электричек и т. д.). Да и по диагонали можно быстрее промотать до нужного места страницы, чем только вертикальной прокруткой, если знаком с сайтом и знаешь куда мотать.
  • 0
    У новомодоного RESS имеются определенные проблемы угадайте с каким браузером: в версиях меньше 9 внутреннее кэширование при использовании Vary просто отключается. По-хорошему этот самый Vary должен быть у всего — HTML, CSS, JS, картинок — поэтому у типичных бухгалтерш сайт будет еле-еле ползать. А у большинства коммерческих сайтов именно бухгалтерши являются целевой аудиторией, а отнюдь не хипстеры с гаджетами.
  • +1
    Отличная статья! :)

    Хочется верить, что адаптивный дизайн вскоре избавится от своих недостатков!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка