Веб дизайн: мобильная версия - какие особенности учесть при разработке.

Разработку дизайна можно начинать с десктопной версии, а затем адаптировать её для планшета и смартфона. Можно двигаться и в обратном направлении: сначала спроектировать мобильную версию сайта, затем расширять макет для большого экрана. Такой подход называют mobile-first. Выбирать отправную точку лучше по задачам посетителей и аналитике своего сайта: доля мобильной аудитории у разных проектов различается.

У Google есть ещё и mobile-first индексирование: для индексирования и ранжирования используется мобильная версия содержимого страницы. Это не требование создать второй сайт. Один адаптивный шаблон может отдавать одинаковый HTML по одному URL и менять расположение элементов под экран. Подробности — в руководстве Google Search Central.

Рассмотрим мобильную версию детальнее: что нужно предусмотреть, чтобы просматривать сайт с экрана смартфона и взаимодействовать с ним было максимально удобно.

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

Простота, лаконичность и структурирование

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

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

Экономить место за счёт полезного содержания не стоит. Условия доставки, характеристики товара, описание услуги и другие важные сведения должны оставаться доступными с телефона. Их можно перенести в раскрываемые блоки. Но текст должен быть доступен поисковому роботу: Google отдельно предостерегает от загрузки основного контента только после нажатия, свайпа или ввода пользователя.

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

Удобство использования на сенсорных экранах

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

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

Критерий 2.5.8 WCAG 2.2 уровня AA задаёт минимум 24 × 24 CSS-пикселя с исключениями, в том числе для ссылок внутри текста. Маленькие цели могут проходить по исключению о расстоянии: окружности диаметром 24 CSS-пикселя вокруг их центров не должны пересекать другую цель или такую окружность вокруг другой маленькой цели.

Для основных кнопок удобнее ориентироваться на более просторную область. Размер 44 × 44 CSS-пикселя указан в критерии 2.5.5 уровня AAA, также с исключениями. Не путайте этот ориентир с минимумом AA и с физическими пикселями матрицы телефона.

Также полезно, чтобы взаимодействие было возможно не только через точечное касание определённой зоны — кнопки, стрелки или точки, — но и с помощью жеста смахивания. Особенно это касается блоков, которые можно листать. При этом свайп должен дополнять кнопки переключения: в WCAG предусмотрена альтернатива жестам, зависящим от траектории.

Адаптивность и резиновость

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

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

В разработке для этого используют гибкую сетку и media queries — правила CSS, срабатывающие при определённых условиях. Точки перестройки выбирайте там, где содержимому становится тесно: меню перестаёт помещаться, карточки сжимаются, подписи начинают мешать кнопкам. Принцип описан в руководстве MDN по адаптивному дизайну.

Ещё одна техническая основа — viewport. В служебной части страницы обычно нужна запись <meta name="viewport" content="width=device-width, initial-scale=1">. Она задаёт ширину области отображения по устройству и начальный масштаб. Попросите разработчика проверить эту настройку в шаблоне сайта. Не запрещайте увеличение через user-scalable=no: это мешает людям со слабым зрением, о чём предупреждает MDN.

Крупные элементы

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

То же касается и самих текстовых блоков — текст должен быть хорошо видимым и читаемым без дополнительного увеличения.

В рамках одного экрана не нужно пытаться уместить как можно больше пунктов, товаров или услуг в формате «заголовок + фото или иконка + текст описания + кнопка заказа или перехода». Число карточек зависит от содержания и ширины экрана. Если ради второго товара приходится уменьшать текст и область нажатия, лучше оставить одну карточку в ряду и дать странице нормально прокручиваться.

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

Одна колонка контента

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

Боковые, дополнительные и вспомогательные блоки при этом не обязательно удалять. Их можно вывести перед основным содержимым, после него или в раскрываемой панели. Например, фильтр каталога открывать по заметной кнопке, а связанные статьи перенести под текст. На десктопе несколько колонок по-прежнему допустимы; одинаковое содержание не требует одинакового расположения на всех экранах.

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

Минимизация виджетов и всплывающих окон

Так как на экране смартфона мало места, всплывающее окно может загородить почти всё содержимое. Кроме того, сторонние онлайн-чаты для поддержки и виджеты, которые в готовом виде встраиваются в сайт, требуют проверки: не уползают ли они за край экрана, не перекрывают ли кнопки, не задерживают ли работу страницы. Отказываться от любого готового решения заранее не нужно — оценивайте конкретное поведение.

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

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

Связь в один клик

На десктопных версиях контактный телефон иногда размещают внутри сайта в разделе «Контакты». Это может подходить B2B-проектам, дорогостоящим услугам и бизнесам без быстрой покупки онлайн. Однако на маленьком экране дополнительные переходы затрудняют поиск контактов. Если цель посетителя — связаться с компанией, путь к телефону или сообщению лучше сделать заметным.

Поэтому в мобильном дизайне можно выводить иконку телефона в верхнее закреплённое меню рядом с «бургером» и поиском. Подпись «Позвонить» поможет объяснить действие. Номер оформляют ссылкой tel:, но звонок не обязательно начнётся сразу: поведение зависит от устройства и обработчика телефонных ссылок. Это уточнение есть в справке MDN.

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

Навигация на мобильных устройствах

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

Главное меню

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

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

• Назовите разделы словами посетителя: «Доставка», «Оплата», «Каталог», а не внутренними названиями подразделений компании.
• Покажите, в каком разделе находится человек и как вернуться на предыдущий уровень.
• Проверьте открытие и закрытие меню касанием и клавиатурой, видимость текущего фокуса и возможность прокрутить длинный список.
• Не делайте важные переходы доступными только при наведении курсора: пройдите весь путь на сенсорном устройстве.

Форма поиска

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

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

Кнопки действий

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

Подписывайте действие конкретно: «Добавить в корзину», «Отправить заявку», «Показать результаты». Проверьте не только исходный вид кнопки, но и состояние после нажатия. Человеку должно быть понятно, выполняется ли запрос и получен ли результат. Рядом с основным действием не стоит размещать столь же заметную кнопку с противоположным смыслом без достаточного расстояния.

Формы обратной связи

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

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

Разработчику стоит задать подходящий тип поля: type="tel" для телефона, type="email" для почты. Атрибут inputmode помогает подсказать удобную виртуальную клавиатуру, но сам не проверяет правильность данных — это отдельно оговорено в документации MDN. Проверьте форму с открытой клавиатурой и вставкой значения из буфера, а не только в макете.

Если форма собирает персональные данные, обеспечьте доступ к политике обработки: ч. 2 ст. 18.1 152-ФЗ требует публикации документа в том числе на страницах сбора данных, а также сведений о реализуемых требованиях их защиты. Для удобства ссылку на политику стоит разместить рядом с формой, чтобы её можно было открыть с телефона.

Когда основанием обработки служит согласие, оформляйте его отдельно от иных подтверждаемых сведений и документов — это требование ч. 1 ст. 9 152-ФЗ. Не объединяйте всё в одну фразу «согласен со всеми условиями». Это часть проверки формы; состав документов и основание обработки определяют для конкретного сценария.

Завершите проверку намеренной ошибкой: оставьте обязательное поле пустым, исправьте его и отправьте форму повторно. Хороший результат — понятная подсказка рядом с полем и сохранённые остальные значения. После успешной отправки нужен ясный ответ, что заявка получена: посетителю не должно приходиться гадать, сработала ли кнопка.

Оптимизация изображений

Помимо оптимизации структуры самой страницы мобильной версии необходимо также оптимизировать все используемые изображения. Чем больше объём файла, тем дольше может идти его загрузка при прочих равных. Это влияет на восприятие скорости страницы. Но большой файл сам по себе не означает автоматического понижения в поисковой выдаче: Google оценивает множество сигналов, а хорошие Core Web Vitals не гарантируют верхних позиций.

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

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

Практический вариант — оставить одно содержание изображения, но предоставить несколько файлов разной ширины. Атрибут srcset перечисляет варианты, а sizes описывает ширину места для картинки в макете. Браузер выбирает файл с учётом условий отображения, включая плотность пикселей. Если размеры карточки меняются в CSS, подсказки sizes тоже должны соответствовать макету. Принцип разобран в MDN об адаптивных изображениях.

Если на телефоне нужен другой кадр — например, крупнее показать сам предмет вместо широкого окружения, — используйте picture. Это уже изменение композиции, а не просто уменьшение файла. Проверьте, сохранился ли смысл: важная часть товара или схемы не должна исчезнуть при обрезке.

Для растровых изображений стоит сравнить WebP и AVIF с исходным форматом при приемлемом качестве. Через picture можно предложить подходящие варианты и базовый JPEG в src. Для простых иконок и логотипов часто уместен SVG. Возможности форматов описаны в справочнике MDN; выбирайте по конкретному изображению, а не по обещанию одинаковой экономии для всех файлов.

Изображения ниже первого экрана можно загружать отложенно через loading="lazy". Для этого не обязательно подключать отдельную JavaScript-библиотеку. Но главную картинку, видимую сразу после открытия страницы, особенно если она определяет LCP, задерживать таким способом не следует. Эти различия объясняет web.dev.

Задавайте изображениям width и height с правильными пропорциями, чтобы браузер мог зарезервировать место до загрузки. Адаптивная ширина при этом должна сохранять пропорции картинки. Так текст и кнопки не будут неожиданно уезжать вниз после появления фотографии. После настройки посмотрите в сетевой панели браузера, какой файл действительно загрузился на узком экране.

Как проверить скорость и отзывчивость

В актуальный набор Core Web Vitals входят LCP, INP и CLS. INP заменил FID 12 марта 2024 года — переход подтверждён в объявлении команды Chrome. Если в старом техническом задании для оценки отзывчивости указан только FID, обновите критерии приёмки.

• LCP — загрузка основного содержимого. Хороший ориентир: не более 2,5 секунды. Метрика отслеживает отрисовку крупнейшего видимого изображения, текстового блока или видео с начала перехода на страницу.
• INP — отзывчивость на взаимодействия. Хороший ориентир: не более 200 миллисекунд. Важен видимый отклик на действия, например нажатие кнопки, а не только первоначальная загрузка страницы.
• CLS — стабильность макета. Хороший ориентир: не более 0,1. Это безразмерная оценка неожиданных сдвигов, а не время в секундах.

По методике web.dev пороги оценивают на 75-м перцентиле загрузок отдельно для мобильных и настольных устройств. Один быстрый запуск на рабочем компьютере этого не подтверждает. В PageSpeed Insights смотрите доступные полевые данные, а лабораторный тест используйте для поиска причин. Отсутствие полевых данных не означает ни хороший, ни плохой результат.

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

Интеграция с соц.сетями

При просмотре сайта с помощью смартфона посетителю может понадобиться поделиться интересной информацией в мессенджере или социальной сети. Или отправить ссылку на страницу самому себе в «Избранное», чтобы вернуться к ней позже. Например, Telegram прямо предусматривает передачу материала в сохранённые сообщения.

Не стоит лишать посетителя такой возможности. Предусмотрите удобную отправку ссылки во ВКонтакте, Telegram и Одноклассники, а также её копирование. Однако нажатие «поделиться» не означает автоматического роста позиции в поиске. Делайте эти действия для удобства читателя; Google объясняет роль качества страницы без обещания топа даже за хорошие показатели скорости.

Кнопки «поделиться» можно сделать без тяжёлых внешних скриптов. Для Telegram официальная документация предлагает собственную кнопку со ссылкой передачи; для Одноклассников также описано использование без установки виджета. Значения параметров ссылки нужно корректно кодировать, а результат — проверить на телефоне.

Другой вариант — системное меню «Поделиться» через navigator.share(). Оно работает по действию пользователя в защищённом контексте HTTPS и поддерживается не везде. Список направлений зависит от устройства и установленных приложений. Поэтому оставьте запасной путь: копирование ссылки или обычные ссылки передачи. Ограничения описаны в MDN.

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

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

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

Нужно ли делать отдельный сайт для смартфонов?

Не обязательно. Адаптивный сайт может использовать один URL и один HTML для разных устройств, перестраивая макет под ширину окна. Google рекомендует этот вариант как удобный в реализации и сопровождении. При отдельной мобильной версии особенно внимательно сверяйте основное содержание: условия, характеристики и полезные тексты не должны исчезать.

Можно ли спрятать длинное описание в раскрываемый блок?

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

Какого размера должна быть кнопка на телефоне?

Проверяйте область нажатия, а не только значок. В WCAG 2.2 критерий AA задаёт минимум 24 × 24 CSS-пикселя с исключениями; у более строгого критерия AAA ориентир — 44 × 44. Для основных действий стоит предусмотреть просторную область и проверить соседние цели, чтобы человек не нажимал на них случайно.

Можно ли поставить lazy loading на все фотографии?

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

Достаточно ли проверить сайт в режиме телефона на компьютере?

Это хороший первый проход, но дополните его проверкой на реальном устройстве. Пройдите путь посетителя: найти раздел, воспользоваться поиском, открыть товар, заполнить форму, отправить или сохранить ссылку. Посмотрите страницу с экранной клавиатурой, увеличенным текстом и в другой ориентации. Отдельно оцените доступные полевые данные Core Web Vitals.

Источники

• Мобильное содержимое и индексирование — Google Search Central, Mobile site and mobile-first indexing best practices.
• Адаптивная сетка и viewport — MDN, Responsive web design; meta name="viewport".
• Область нажатия и жесты — W3C WAI, WCAG 2.2: SC 2.5.8 Target Size (Minimum), AA; SC 2.5.5 Target Size (Enhanced), AAA; SC 2.5.1 Pointer Gestures.
• Окна поверх содержимого — Google Search Central, Avoid intrusive interstitials and dialogs, обновление 10.12.2025.
• Подписи полей — W3C WAI, Forms Tutorial, Labeling Controls. Клавиатура и телефонные ссылки — MDN, inputmode; HTML anchor element.
• Обработка персональных данных — Федеральный закон от 27.07.2006 № 152-ФЗ, ред. от 26.07.2026: ст. 9; ст. 18.1. КонсультантПлюс.
• Изображения разных размеров и форматов — MDN, Using responsive images in HTML; Image file type and format guide.
• Отложенная загрузка изображений — Osmani A., Djirdeh H., Bynens M., Pollard B., web.dev, Browser-level image lazy loading for the web.
• Метрики качества страницы — Walton P., web.dev, Web Vitals, обновление 31.10.2024; определение Largest Contentful Paint. Замена FID на INP — Wagner J., Viscomi R., Interaction to Next Paint becomes a Core Web Vital on March 12, переход 12.03.2024.
• Качество страницы и ранжирование — Google Search Central, Understanding page experience in Google Search results.
• Передача ссылки — Telegram, Sharing Button; ОК для сайтов, Кнопка «Класс» / «Поделиться»; MDN, Navigator: share() method.