В прошлом году пришел клиент с вопросом, который я слышал много раз: почему Яндекс Директ дает заявки с ноутбуков, а с телефона - почти тишина. Формально все было «нормально»: сайт грузился, меню открывалось, форма существовала. Открыли страницу на обычном Android и увидели баннер на весь экран, потом пустой кусок, потом поля в странном порядке, а кнопка отправки жила где-то после восьмого скролла. Компания уже платила за клики, которые сама же не доводила до заявки.
Проблема в том, что бизнес часто проверяет только сам факт открытия страницы. Деньги теряются раньше - в момент, когда человеку неудобно сделать нужное действие.
Открывается - не значит помогает купить
Адаптивная верстка - это не просто html-верстка, которая не развалилась на маленьком экране. Для бизнеса критерий другой: человек должен быстро понять, что ему делать, и без лишнего сопротивления дойти до кнопки, формы или оплаты.
Я видел это десятки раз. На desktop форма в две колонки выглядит аккуратно, а на смартфоне превращается в простыню на 8 полей. CTA уезжает вниз, клавиатура перекрывает подсказки, селект города открывается криво, маска телефона мешает ввести номер с первого раза.
У сервисной B2B-компании мы сократили форму до 4 полей, подняли кнопку выше и убрали лишний блок с преимуществами между заголовком и формой. Мобильная конверсия выросла с 0,8% до 2,1% за 2 недели.
Мобильная версия и адаптив - это одно и то же?
Нет. Отдельная мобильная версия живет своей жизнью и быстро расходится с основным сайтом. Адаптив - это один интерфейс, который подстраивается под экран и сохраняет логику сценария.
Потери видны в цене лида, а не в макете
Когда вы уже платите за SEO, контекст или таргет, плохой mobile делает каждый визит дороже. В промышленном оборудовании у клиента desktop CR был 3,2%, mobile - 0,9%. Маркетолог думал, что проблема в трафике, но в GA4 и Метрике было видно другое: люди доходили до карточки, а терялись на фильтрах и форме запроса цены.
После переделки фильтров и упрощения карточки стоимость заявки с мобильного трафика упала на 34%. Бюджет не меняли, канал тоже.
Если mobile конвертит в 2-3 раза хуже desktop, я сначала проверяю сценарий на экране, а потом рекламу.
Есть и вопрос скорости. Тяжелые баннеры, картинки без srcset, прыгающие блоки при загрузке бьют по Core Web Vitals так же больно, как плохая верстка сайта. Если LCP уходит далеко за 2,5 с, а CLS выше 0,1, часть людей исчезает еще до первого полезного действия.
<picture>
<source srcset="image-480.webp" media="(max-width: 480px)">
<source srcset="image-800.webp" media="(max-width: 800px)">
<img src="image-1200.webp" alt="Описание" loading="lazy" width="1200" height="600">
</picture>
Сам код простой. Смысл в другом: сначала грузим то, что помогает действию, а не то, что красиво выглядит в презентации.
Хороший адаптив решается еще до фронтенда
Когда создание веб-приложения идет по схеме «сначала рисуем desktop, потом frontend-разработка как-нибудь ужмет», обычно выходит дорого. Команда начинает лечить симптомы: здесь спрятали колонку, там уменьшили шрифт, тут сжали таблицу до нечитаемого состояния.
Мы у себя сейчас фиксируем мобильные сценарии еще до дизайна. Для каких действий нужен телефон, где нужен планшет, где без desktop человек просто не сможет работать. Это влияет уже не только на CSS, но и на backend-разработку, API, пагинацию, состав ответов и даже на создание базы данных веб-приложения.
На одном B2B-сервисе на Node.js 20 + NestJS мы для mobile отдавали укороченные карточки, а детали подгружали по запросу. Размер ответа сократился примерно на 68%, первый полезный экран стал быстрее, и пользователи перестали теряться в длинных таблицах.
Один раз мы сами это провалили. Кабинет для дистрибутора спроектировали под офисную работу с ноутбука, а после запуска выяснилось, что половина согласований идет с телефона - в дороге и на складе. Поздняя переделка меню, карточек и API заняла 7 недель и стоила около 1,2 млн ₽. Я бы не стал оставлять мобильный сценарий «на потом» нигде, где есть роли, статусы и согласования.
Что проверить бизнесу до релиза
Приемка должна идти по сценариям, а не по фразе «у меня на телефоне открывается». Смотрите: берете 4 типа устройств - iPhone, Android, планшет, desktop - и проходите ключевые действия руками.
Проверьте хотя бы это:
- видно ли главную кнопку без долгого поиска
- можно ли заполнить форму одной рукой
- нет ли горизонтального скролла на важных страницах
- читаются ли таблицы, фильтры, статусы и селекты
- не прыгают ли элементы при загрузке
Я бы добавил еще три метрики, которые бизнес почти никогда не смотрит, хотя зря: время до действия, число касаний до заявки и долю ошибок на форме. По ним быстро видно, где адаптив ломает воронку, даже если в макете все выглядит аккуратно.
Где чаще всего ломаются веб-сервисы
На лендинге адаптив обычно бьет по заявкам. В создании веб-сервисов цена ошибки выше: там ломаются навигация, таблицы, роли, статусы, поиск, документы. Если в интерфейсе много данных, простой перенос desktop-макета на телефон почти всегда дает слабый результат.
Я придерживаюсь простого правила. Если действие на телефоне повторяется каждый день, его надо проектировать отдельно. Если с телефона это разовая история, можно оставить упрощенный сценарий и не усложнять продукт.
Если сайт уже работает, не начинайте с редизайна. Откройте аналитику по устройствам и найдите шаг, где mobile резко сыпется. Самый дорогой баг для бизнеса часто выглядит буднично - страница ведь и правда открывается.
