Mobile First в 2026: что проверить в макете, формах и ТЗ сайта

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

≈ 59 %

трафика в мире приходит с мобильных

сентябрь 2026

≈ 32 %

трафика в Украине приходит с мобильных

остальное в основном десктоп

24 × 24 px

минимальный размер цели по WCAG 2.2 (AA)

web.dev советует около 48 px

Источники: Statcounter Global Stats (сентябрь 2026), W3C WCAG 2.2, web.dev

Сколько у вас мобильных посетителей на самом деле

По данным Statcounter, в сентябре 2026 года на мобильные устройства приходилось около 59 % трафика в мире. Для Украины тот же сервис показывает около 32 %, остальное в основном десктоп. Почему так, мы утверждать не беремся: выборка Statcounter может отличаться от аудитории конкретного бизнеса. Вывод для владельца проще: не гадайте, смотрите в собственную аналитику.

На практике мы советуем сделать три вещи:

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

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

Mobile First и адаптивный сайт: не синонимы

Адаптивная вёрстка подстраивается под ширину окна: гибкая сетка, медиазапросы, масштабируемая типографика. Сайт может быть адаптивным, но сделанным desktop-first: сначала полный десктопный макет, потом его «ужимают» под телефон.

Mobile First — это порядок стилей и мышления: базовые стили для узкого экрана, а дальше @media (min-width: …) для широких. Плюсы: меньше лишнего CSS на телефоне, чётче приоритет контента и меньше шансов, что мелкие экраны «доделают» в последний день.

Подход	С чего стартуют	Типичный риск
Desktop First	Большой макет	Перегруженная мобильная версия, мелкий текст, «обрезанные» блоки
Mobile First	Узкий экран	Нужна дисциплина: не тащить на десктоп лишнее без необходимости

Техническая основа — тег viewport. Без <meta name="viewport" content="width=device-width"> часть мобильных браузеров рисует страницу в виртуальном окне шире экрана (MDN приводит пример в 980 px), а затем уменьшает результат. Медиазапросы под узкие экраны при этом просто не срабатывают.

Противоположная ошибка — отключить масштабирование через user-scalable=no. По MDN, это мешает людям со слабым зрением, а WCAG требует, чтобы страницу можно было увеличить минимум вдвое. К тому же браузеры нередко игнорируют такое ограничение: iOS, начиная с десятой версии, делает это по умолчанию.

Что именно Google требует от мобильной версии

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

основной контент мобильной версии должен быть эквивалентен десктопному; если его меньше, Google прямо предупреждает о возможной потере трафика;
одинаковые структурированные данные, title, description, мета-теги robots и alt-тексты изображений;
не подгружайте основной контент только после действия пользователя (свайп, клик, ввод): такой контент Google не загрузит;
аккордеоны и вкладки на мобильном допустимы, если содержимое эквивалентно десктопному.

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

Скорость и Core Web Vitals — отдельная тема. Напомним лишь, что телефон среднего класса слабее ноутбука по процессору, поэтому каждый сторонний скрипт там обходится дороже.

Тач-цели: размер, в который не «промахиваются»

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

Источник	Размер цели	Примечание
WCAG 2.2, критерий 2.5.8 (уровень AA)	не менее 24 × 24 CSS-пикселей	исключения: достаточный отступ, ссылка внутри текста, равнозначный элемент
web.dev, рекомендация	около 48 × 48 px (примерно 9 мм)	отступ между целями около 8 px

Увеличивать саму иконку необязательно. Web.dev советует добавить padding, чтобы зона касания выросла до 48 px, а иконка осталась, скажем, 24 px. Увеличенную зону можно включать только для сенсорных устройств через @media (any-pointer: coarse).

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

Формы: где мобильный сайт чаще всего теряет заявки

Форма на телефоне — место, где разбиваются усилия, вложенные в рекламу. Рекомендации web.dev по формам сводятся к нескольким правилам:

у каждого поля есть label, а не только подсказка внутри поля;
правильные type и autocomplete, чтобы браузер мог подставить данные; для чисел, которые не увеличивают и не уменьшают (например, номер карты), не используйте type="number", берите текстовое поле с inputmode="numeric";
блокируйте кнопку отправки после нажатия, чтобы не было двойных заявок;
проверяйте данные во время ввода, а не только после отправки;
не спрашивайте лишнего и принимайте имя одним полем.

От себя для украинского малого бизнеса добавим: поле телефона с type="tel", маска, которая не ломается при вставке номера из буфера, и рядом понятные альтернативы для тех, кто не любит формы, — звонок одним касанием и кнопка в мессенджер.

Современный CSS: меньше breakpoints, больше гибкости

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

контейнерные запросы (@container) меняют компонент в зависимости от ширины его контейнера, а не окна, поэтому карточка одинаково работает и в узком сайдбаре, и на всю ширину;
единицы svh и dvh учитывают панель браузера, которая прячется при прокрутке: полноэкранный блок не «съедается» адресной строкой;
viewport-fit=cover вместе с переменными env() нужен для устройств с вырезом: MDN советует отступать через них от краёв, чтобы важное не обрезалось;
плавная типографика через clamp() заменяет пачку медиазапросов для размеров шрифта.

Типичные ошибки

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

Как проверить мобильную версию до запуска

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

1

Контент и приоритеты

что человек должен увидеть первым на узком экране
2

Базовые стили

макет для узкого экрана без медиазапросов
3

Расширение

планшет и десктоп через min-width
4

Тест в DevTools

режим устройства с ограничением сети и процессора
5

Реальные телефоны

Android, iPhone и хотя бы одно устройство постарше

Схема авторская; шаги тестирования — по документации Chrome for Developers

Режим устройства в Chrome DevTools показывает размер экрана и умеет «душить» сеть и процессор. Есть пресет Mid-tier mobile (быстрая 3G, процессор в 4 раза медленнее) и Low-end mobile (медленная 3G, в 6 раз медленнее). Документация честно называет это приближением первого порядка: код не запускается на настоящем телефоне, поэтому финальную проверку делайте на живых устройствах.

Короткий чек-лист для приёмки:

На узком экране нет горизонтальной прокрутки (ориентируйтесь примерно на 320–360 px).
Все кнопки и ссылки легко нажимаются большим пальцем, без промахов.
Форма заполняется с экранной клавиатурой, а поле не прячется под ней.
Звонок и мессенджер доступны одним касанием.
Масштабирование страницы не отключено, текст читается без увеличения.
На мобильной версии тот же основной контент, что и на десктопной.

Что зафиксировать в ТЗ

Целевые ширины и список устройств, на которых принимается вёрстка.
Минимальные размеры тач-целей и отступов, хотя бы по уровню WCAG AA.
Поведение форм, фильтров и таблиц на узком экране: как именно они перестраиваются.
Требования к скорости в мобильном режиме и к тестированию на реальных устройствах.
Отдельным решением: нужен ли PWA, а не «по умолчанию».

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

Что делать дальше

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

Хотите, чтобы мы посмотрели ваш сайт на телефоне и назвали, что исправлять в первую очередь? Напишите нам.

Автор: Сергей Филатьев — основатель авторской студии Veb-Dev.