Мобильная версия сайта: чем отличается от адаптивной и когда она нужна

Что такое мобильная версия сайта?

Представьте, что вы открываете знакомый интернет-магазин с телефона и попадаете на соседний адрес, не тот, что с ноутбука. Вместо site.com в строке стоит m.site.com. Это и есть мобильная версия: самостоятельный сайт, который показывают тем, кто пришёл со смартфона или планшета.

Такому сайту можно придумать собственную судьбу. Разработчики вправе убрать страницы, добавить другие, переписать меню и даже заменить контент, потому что у мобильного ресурса своя логика: короткие сценарии, крупные кнопки, минимум лишнего. Отсюда и главный вопрос, который стоит перед владельцем сайта: нужен ли вам второй сайт или хватит одного, который умеет подстраиваться.

Вопрос не праздный, потому что телефоны давно обогнали компьютеры по числу визитов. По данным Яндекс Радара, в России около 70% визитов приходится на мобильные устройства, и доля продолжает расти. Для интернет-магазина или сервиса услуг это означает, что с телефона к вам приходит большинство клиентов.

Часто путают мобильную версию с мобильным приложением, но это разные вещи. Версия открывается в браузере по ссылке и ничего не требует установить. Приложение живёт в магазине приложений и, как отмечает Яндекс Реклама, требует отдельных усилий, чтобы человек его скачал.

Чем мобильная версия отличается от адаптивной?

Адаптивный сайт один, и адрес у него один. По описанию Яндекс Рекламы, его дизайн автоматически подстраивается под размер, разрешение и ориентацию экрана. Блоки перестраиваются, второстепенное прячется, но архитектура остаётся прежней. Мобильная версия идёт дальше и допускает другую структуру.

Наглядный пример привёл Яндекс Практикум: на десктопной главной странице Кинопоиска есть анимация, реклама и большой баннер фильма, а в мобильной версии этих элементов нет. Тяжёлое оформление, которое на ноутбуке выглядит эффектно, на телефоне с медленным интернетом только задерживает загрузку, поэтому команда его убрала.

У Google есть собственная классификация. В руководстве для мобильных сайтов описаны три конфигурации. Адаптивный дизайн отдаёт один HTML всем устройствам. Динамический показ использует один URL, но выдаёт разный HTML на основе заголовка Vary: user-agent. Разные URL, то есть поддомен m., перенаправляют пользователя на подходящий адрес. Google прямо говорит, что вам не обязательно создавать мобильную версию, чтобы попасть в поиск, но советует её сделать.

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

Когда отдельная версия оправдана, а когда нет?

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

Против говорит цена. Второй сайт нужно создавать, настраивать и вести: даже у магазина на 50-100 товаров позиции приходится сверять в двух местах. Есть и ловушка упрощения. Если мобильную версию лишили функции, ради которой человек пришёл, например 3D-примерки, он уйдёт разочарованным. Об этом предупреждает Практикум.

Как это выглядит в цифрах, показали аналитики Adlook на демо-данных Яндекс Метрики. В отчёте 51,42% заходов пришло с мобильных, 43,8% с компьютеров и 0,18% со смарт-ТВ. Для такого проекта телевизорами можно пренебречь, а мобильная часть почти равна десктопной, поэтому мобильные сценарии надо проектировать наравне с остальными, а не доделывать в последнюю очередь.

Две истории из практики показывают границы подхода. На сайт ресторана гости заходят с домашнего компьютера или с телефона уже за столиком, чтобы открыть меню по QR-коду, и им нужен короткий сценарий без лишнего. Для онлайн-кинотеатра картина обратная: его часто открывают на телевизоре, и мобильная упрощёнка там бесполезна. Оба примера разобраны в материале Практикума и объясняют, почему сначала смотрят на устройства аудитории, а потом выбирают подход.

• Отдельная версия подходит сложным проектам с тяжёлым десктопным интерфейсом и бюджетом на второй сайт.
• Адаптивная вёрстка подходит, когда устройств у аудитории много, а команда небольшая.
• Конструктор и CMS закрывают задачу малого проекта, если нужен быстрый запуск.
• PWA стоит рассматривать, когда сайт должен вести себя как приложение.

Что мобильная версия меняет для поиска?

Поисковики смотрят на мобильную версию в первую очередь. Google пишет, что при индексировании и ранжировании использует версию сайта, которую просканировал Googlebot для смартфонов. Подробности есть в его руководстве. Поэтому всё, что есть на десктопе, но исчезло на телефоне, для поиска фактически не существует.

Для отдельных адресов Google перечисляет конкретные проверки, и каждая из них описывает реальный провал. Если десктопная страница отдаёт контент, а мобильная ошибку, страница пропадает из индекса. Фрагменты URL с решёткой на мобильном поддомене обычно не индексируются, и такие страницы тоже выпадают. Канонической должна быть полная версия, а мобильную помечают как альтернативную: в документации приведены оба тега link.

Минус отдельных адресов в том, что вы продвигаете два ресурса, а контент на них дублируется. Практикум отмечает, что это плохо влияет на ранжирование. Поэтому тем, кто создаёт мобильную версию, важно держать разметку и тексты синхронными, а канонические ссылки расставлять аккуратно.

Яндекс предлагает инструмент проверки: по его материалу страницу можно проверить в Вебмастере после добавления сайта. Там же советуют не делать мобильное содержание кардинально отличным от основного, а часть контента свернуть под ссылку «Читать ещё».

Скорость на телефоне решает больше, чем дизайн

Скорость в мобильных страницах значит больше красоты. Яндекс Реклама называет критичной загрузку дольше 3 секунд, а авторы Calltouch пишут, что даже 2 секунды заставляют многих посетителей отказаться от страницы.

Цену этой скорости измерили в Vodafone. Телеком-компания провела A/B-тест целевой страницы: половина трафика из платных каналов видела версию, оптимизированную по Web Vitals, вторая половина обычную. Версия A показала LCP лучше на 31%, и продажи выросли на 8%, а переходы от визита к лиду на 15%. Подробности опубликованы на web.dev. Единственным различием между версиями была скорость.

Похожий путь прошёл индонезийский маркетплейс Tokopedia. Команда выборочно загружала сторонние скрипты, заменяла тяжёлые библиотеки, подгружала картинки лениво и грузила качественные изображения только тем, у кого быстрая сеть. Результат из отчёта на web.dev: CTR вырос на 35%, конверсия на 8%, а время до интерактивности сократилось на 4 секунды.

Проверить свою страницу можно бесплатно в сервисе PageSpeed Insights: сервис принимает адрес страницы и показывает, что тормозит загрузку на телефоне.

Как проходит работа над мобильным сайтом

Работа начинается не с рисования. По описанию Практикума, в классическом процессе пять стадий, и от каждой зависит следующая. Сначала дизайнер выясняет у заказчика, какие метрики должен улучшить продукт, и вместе с командой формулирует гипотезы. Затем исследует аудиторию: опросы, интервью, данные Метрики.

1. Погружение: заказчик ставит задачу и называет метрики.
2. Описание: исследование, анализ и презентация гипотез.
3. Макеты: концепция, прототип и юзабилити-тест.
4. Коридорное тестирование готового сайта.
5. Доработка после запуска.

Дальше идёт прототип. Макеты собирают в Figma, а потом проверяют на людях. Участникам дают задание и просят комментировать каждое действие вслух. Возьмём прототип мобильного магазина уходовой косметики. Участнику говорят: найдите и закажите шампунь для кудрявых волос. Один не находит фильтр по типу волос, другой застревает на оформлении заказа, и каждая заминка записывается. По итогам макет переделывают до того, как программисты написали хоть строчку кода.

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

Какими должны быть мобильные страницы?

Дизайнеры из Яндекс Практикума, которые вели курсы по интерфейсам, собрали набор правил. Основной текст на телефоне должен быть размером от 16 до 18 пикселей, заголовок около 28 пикселей и не длиннее трёх строк, как следует из их разбора. Расстояние между заголовком и текстом внутри блока делают в 2-3 раза меньше, чем между блоками, и тогда блоки читаются отдельно без линий.

Контраст проверяют в реальных условиях, и тут помогает история с сайтом такси из материала Практикума. Люди открывают такой сайт на улице, а тёмная тема в солнечный день превращается на экране в одно пятно, где не разглядеть кнопки. Поэтому для основного текста там советуют контраст не ниже 7 к 1, для заголовков 3 к 1, и палитру выбирают до рисования макетов.

В мобильной вёрстке надо подумать и о том, чтобы страница вообще масштабировалась. В Яндекс Рекламе для этого приводят метатег viewport с параметром width=device-width. Без него телефон показывает уменьшенную копию десктопной страницы с мелкими буквами.

Анна Грязева, наставник Практикума, предупреждает о типичной ошибке новичков: увлечении декоративными шрифтами. В её совете главная мысль звучит так:

любой IT-продукт в первую очередь должен быть удобным для пользователя

Анна Грязева, наставник факультета дизайна интерфейсов Яндекс Практикума

Витиеватые шрифты она советует оставить для баннеров и акцентов, а для основного текста взять классику вроде Roboto или Open Sans.

• Основной текст: 16-18 пикселей.
• Заголовок: около 28 пикселей и до трёх строк.
• Контраст основного текста: не ниже 7 к 1.
• Всплывающие окна: легко закрываются и не перекрывают ключевое.

Часть решений специфична для телефона. По рекомендациям Яндекса, меню в шапке стоит свернуть в «гамбургер», кликабельные элементы сделать крупнее, таблицам добавить горизонтальную прокрутку. Всплывающие окна нужно проверить отдельно: если они перекрывают текст или кнопки, конверсия падает.

Чем делать мобильную версию в России?

Выбор инструмента следует из размера проекта. Для лендинга или небольшого каталога хватит конструктора вроде Tilda, где блоки автоматически подстраиваются под экран телефона, а детали правят вручную. Для корпоративного сайта или магазина на 1С-Битрикс можно настроить отдельные мобильные шаблоны, не пересобирая проект с нуля.

Для макетов и прототипов есть несколько вариантов, и выбор зависит от команды:

• Figma: на прототипе можно нажимать кнопки и открывать экраны, поэтому путь клиента виден до разработки.
• Lunacy: бесплатный редактор для Windows, Linux и macOS с готовыми иконками и наборами интерфейсов.
• Sketch: редактор только для macOS, у которого нет совместной работы над проектом.

Статистику по устройствам берите из Метрики. Сравните время на странице и достижение целей отдельно для мобильных: короткие визиты и низкая доля дошедших до кнопки заявки указывают, где ломается сценарий. Повторите проверку после каждого крупного обновления.

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

Частые вопросы