Мобильный трафик в казахстанских интернет-магазинах давно перевалил за половину, а в отдельных нишах за три четверти. При этом конверсия с телефонов у сайтов на 1С-Битрикс регулярно оказывается в два-три раза ниже десктопной, и владелец списывает разрыв на «природу мобильного пользователя». Обычно причина проще и лежит в вёрстке. Фильтр каталога не раскрывается на ширине 360 пикселей, кнопка «Купить» уезжает под липкий футер, а в поле телефона на странице заказа не попадает палец. Каждая такая мелочь стоит заказов, и ни одна из них не видна с рабочего монитора разработчика.
Почему потери мобильного трафика не видны в отчётах
Сломанный десктоп замечают за час: звонит клиент, пишет менеджер, кто-то из команды открывает сайт и видит проблему. Сломанный мобильный сценарий живёт месяцами. Сотрудники компании заходят на свой сайт с ноутбуков, руководитель смотрит витрину на большом экране, подрядчик сдаёт работу в браузере шириной 1920. Посетитель с телефона в поддержку не пишет, он просто закрывает вкладку.
В аналитике это выглядит безобидно. Мобильный сегмент даёт трафик, время на сайте вроде бы приличное, отказы чуть выше среднего. Разрыв в конверсии между устройствами кажется нормой, потому что «так у всех». Но если разложить путь пользователя по шагам, от просмотра каталога до оплаты, обнаруживается конкретная ступенька, на которой мобильный трафик обваливается втрое сильнее десктопного. Это и есть место, где вёрстка перестала работать.
Есть и вторая сторона, менее очевидная. Google перевёл сканирование всех сайтов на Googlebot Smartphone: индексируется и ранжируется мобильная версия страницы, а результат применяется к выдаче на всех устройствах. Если на мобильном шаблоне часть контента скрыта, часть блоков подгружается скриптом, а разметка отличается от десктопной, поисковик видит именно этот усечённый вариант. Компания при этом уверена, что продвигает полноценный сайт.
Отсюда практический вывод для 1С-Битрикс. Мобильная вёрстка перестала быть косметикой поверх основного шаблона. Это тот вариант страницы, по которому вас оценивают и посетитель, и поисковая система.
Адаптив, отдельный шаблон или мобильный поддомен
На 1С-Битрикс мобильную версию можно собрать тремя способами, и выбор влияет на бюджет поддержки сильнее, чем на бюджет разработки.
Первый вариант, адаптивная вёрстка одного шаблона: одна разметка, один набор CSS, поведение блоков управляется медиазапросами. Сервер отдаёт всем устройствам одинаковый HTML. Это рабочий выбор по умолчанию для корпоративных сайтов и большинства магазинов, потому что контент не расходится между версиями, SEO не дублируется, а правку достаточно внести один раз. Ограничение честное: тяжёлые десктопные блоки всё равно приезжают на телефон, даже если скрыты стилями, поэтому за весом страницы приходится следить отдельно.
Второй вариант, отдельный мобильный шаблон. В 1С-Битрикс шаблон сайта подключается по условию: раздел «Настройки», далее «Настройки продукта», далее «Сайты». В карточке сайта задаётся список шаблонов с условиями подключения, и один из доступных типов условия, это выражение на PHP. Туда подставляют проверку устройства, и телефон получает собственную разметку. Подход оправдан, когда мобильный сценарий принципиально другой. Например, на десктопе сложный подборщик оборудования, а на телефоне короткая заявка. Плата за это: два шаблона, которые нужно синхронно править, и риск, что через полгода они разъедутся по содержимому.
Третий вариант, мобильный поддомен. Отдельный m-сайт сегодня заводят редко, и без веских причин мы его не рекомендуем: удваивается инфраструктура, усложняется работа с каноническими адресами, а выигрыш по скорости достижим и без раздвоения проекта.
Практика получается простая. Новый проект делаем на адаптиве. На существующем сайте с уже написанным мобильным шаблоном сначала разбираемся, чем именно две версии отличаются по содержимому, и только потом решаем, объединять их или оставить. Если перед решением нужна внешняя оценка текущего состояния, посмотрите наши услуги по разработке сайтов: аудит вёрстки мы делаем и по чужому коду.
Где адаптив на 1С-Битрикс ломается чаще всего
Типовые решения из Маркетплейса поставляются адаптивными. Ломается не поставка, а то, что делают с ней дальше.
Правки в шаблоне компонента вместо копии. Разработчик торопится и меняет вёрстку прямо в системном каталоге компонента, а не в копии внутри /local/templates/. Обновление модуля затирает правку, и адаптив каталога отваливается в один день без видимой причины. Все кастомные шаблоны компонентов должны лежать в собственном шаблоне сайта или в local. Это условие того, что сайт переживёт обновление.
Инлайновые стили из визуального редактора. Контент-менеджер вставил в описание раздела таблицу из Word, редактор сохранил её с жёсткой шириной в пикселях. На десктопе незаметно, на телефоне страница получает горизонтальную прокрутку, и вся карточка едет вбок. Такие вещи находятся только просмотром реальных страниц каталога, а не главной.
Товарные фотографии без ограничения по ширине. Изображение вставлено в описание тегом с фиксированным размером. Лечится правилом в CSS на максимальную ширину картинок внутри контентной области плюс инструктажем менеджеров.
Дороже всего обходится фильтр умного поиска. На десктопе он стоит колонкой слева, на мобильном его нужно превращать в панель, которая открывается кнопкой и закрывается по свайпу или крестику. Если разработчик просто скрыл колонку медиазапросом, пользователь остался без фильтрации вообще, а в магазине с тысячей SKU это равносильно закрытому каталогу.
Рядом стоят липкие элементы, которые накладываются друг на друга. Закреплённая шапка, плавающая кнопка «Заказать звонок», виджет мессенджера и футер с корзиной в сумме съедают половину экрана телефона. Каждый элемент по отдельности выглядел уместно, вместе они превращают просмотр в щель.
Формы ломаются тише, но обиднее всего: поля высотой меньше комфортного касания, чекбокс согласия размером в шесть пикселей, календарь, который открывается за пределами экрана. Это последний шаг сделки, и терять заказ здесь особенно жалко.
Меню каталога с глубокой вложенностью. На десктопе выпадающее меню с тремя уровнями разделов работает наведением мыши. На телефоне наведения нет, и меню либо не раскрывается вовсе, либо раскрывается всё сразу простынёй в двести строк. Мобильная навигация по каталогу требует своей логики: уровень открывается по касанию, есть возврат на шаг назад, текущее положение видно.
Сравнение товаров и таблицы характеристик. Таблица с восемью колонками физически не помещается в 360 пикселей. Варианты решения есть: горизонтальная прокрутка внутри блока с закреплённой первой колонкой, перестроение таблицы в карточки, вывод только различающихся параметров. Не работает единственный подход, когда таблицу оставляют как есть в расчёте на то, что пользователь догадается прокрутить вбок.
Скорость мобильной версии: что именно измеряется
Google оценивает страницы по трём метрикам Core Web Vitals. LCP, это время до отрисовки самого крупного видимого элемента, хороший показатель до 2,5 секунды. INP отвечает за отзывчивость на действия пользователя, хороший показатель до 200 миллисекунд. CLS показывает визуальную стабильность, допустимое смещение до 0,1. Оценка берётся по 75-му перцентилю реальных визитов: три четверти посещений должны укладываться в норму.
Для мобильной версии сайта эти цифры жёстче, чем кажется. Телефон в сети мобильного оператора и на слабом процессоре проигрывает десктопу по всем трём пунктам сразу.
Что даёт результат на 1С-Битрикс:
- Композитный сайт. Штатная технология платформы: страница отдаётся из статического кэша, а динамические блоки догружаются асинхронно. Включается в разделе «Настройки», далее «Настройки продукта», далее «Композитный сайт». Технология доступна начиная с версии 14.5, режим автокомпозита с 16.0.14. На витрине и в каталоге эффект по LCP заметен сразу, но композит требует аккуратной настройки: всё, что зависит от авторизации и корзины, выносится в динамические области.
- Работа с изображениями. Основной вес мобильной страницы магазина приходится на картинки. Нужны современные форматы, отложенная загрузка того, что ниже первого экрана, и обязательные атрибуты ширины и высоты у каждого изображения. Последнее напрямую бьёт по CLS: браузер, знающий размеры, резервирует место и не двигает вёрстку, когда картинка догрузилась.
- Скрипты сторонних сервисов. Виджеты чатов, коллтрекинг, счётчики, пиксели: каждый добавляет к INP, и на телефоне их совокупный эффект в разы заметнее. Инвентаризация подключённых скриптов и отказ от нерабочих остаётся самой дешёвой оптимизацией из существующих.
- Раздача статики через CDN. В административной части это раздел «Настройки», далее «Облако 1С-Битрикс», далее «Ускорение сайта (CDN)». Для проекта с посетителями по всему Казахстану и за его пределами разница в скорости отдачи файлов ощутима.
Порядок работ тут важен не меньше состава. Начинать стоит с инвентаризации того, что грузится на мобильной странице. Список запросов в панели разработчика, отсортированный по весу, обычно даёт две-три позиции, на которые приходится больше половины объёма. Чаще всего это несжатая фотография в баннере первого экрана и библиотека, подключённая ради одного эффекта. Убрать их можно за несколько часов, а эффект на LCP будет больше, чем от недели точечной оптимизации кода.
И только после этого имеет смысл включать композит и подключать CDN. Иначе вы просто начнёте быстрее отдавать тот же лишний вес.
Отдельно про модуль «Монитор производительности». Он показывает нагрузку на сервер, медленные запросы к базе и тяжёлые компоненты, то есть помогает найти узкое место в коде. Реальную скорость загрузки страницы у посетителя он не измеряет, для этого нужны данные по реальным визитам. Путать эти два инструмента дорого: можно вылизать серверные показатели и не сдвинуть Core Web Vitals ни на сотую.
Каталог, карточка и корзина: три экрана, которые решают
Мобильный пользователь магазина проходит короткий путь, и на каждом шаге к вёрстке свои требования.
В списке товаров две плитки в ряд на телефоне читаются лучше одной колонки: пользователь видит больше вариантов за прокрутку. Название товара стоит обрезать на двух-трёх строках, цену давать крупно, а кнопку добавления в корзину выводить прямо в списке. Сортировка и фильтр выносятся двумя кнопками в закреплённую строку над списком.
В карточке товара порядок блоков на телефоне отличается от десктопного. Сначала фотография, название, цена, наличие и кнопка покупки, и всё это должно помещаться в первый экран без прокрутки. Описание, характеристики и отзывы уходят ниже, лучше в аккордеон. Галерею делайте свайпом, а не мелкими превью, по которым тяжело попасть.
Корзина и оформление требуют отдельного внимания: стандартный компонент оформления заказа на телефоне часто разъезжается по ширине из-за таблиц с составом заказа. Убирайте лишние шаги, показывайте итоговую сумму закреплённой строкой, минимизируйте количество обязательных полей. Заказ с телефона делают быстро и в неудобных условиях, в транспорте или между делами.
Две детали дают здесь непропорционально много при копеечной трудоёмкости. Для поля телефона задавайте соответствующий тип ввода, чтобы открывалась цифровая клавиатура вместо буквенной. Для полей имени, адреса и почты включайте автозаполнение: браузер подставит сохранённые данные, и вместо четырёх минут набора пользователь потратит десять секунд. Ссылку на согласие с обработкой данных открывайте в модальном окне, а не переходом на другую страницу, потому что уход со страницы оформления на мобильном почти всегда означает потерянный заказ.
Общий принцип по всем трём экранам: чем меньше на мобильной версии перекрёстных предложений, всплывающих подписок и напоминаний о скидке, тем выше доходимость до кнопки оплаты. Всё, что на десктопе воспринимается как дополнительный блок сбоку, на телефоне становится препятствием поперёк дороги.
Как проверять адаптив перед сдачей
Режим адаптивности в инструментах разработчика годится только как первый фильтр. Он показывает раскладку, но не показывает, как работают касания, как ведёт себя виртуальная клавиатура и сколько страница весит на мобильной сети.
Наш порядок проверки на проектах:
- Три ширины в эмуляторе: 360, 414 и 768 пикселей. Первая отсеивает большинство проблем, потому что узкие Android-телефоны остаются в обиходе и именно на них вылезает горизонтальная прокрутка.
- Проверка на реальных устройствах, минимум на одном iPhone и одном Android. Эмулятор не воспроизводит поведение клавиатуры, инерцию прокрутки и особенности мобильного Safari.
- Обход по типам страниц, а не по одной главной: главная, раздел каталога, карточка товара, корзина, оформление, страница контента, форма обратной связи, результаты поиска. У каждого типа своя вёрстка и свои шансы сломаться.
- Отдельный проход по кнопкам и полям: попадает ли палец, не перекрывает ли что-нибудь клавиатура, работают ли закрытия модальных окон.
- Замер скорости по реальным данным, а не только в лабораторном тесте.
Приведу один пример из работы, чтобы показать, зачем нужен четвёртый пункт. Магазин строительных материалов на 1С-Битрикс жаловался на низкую конверсию с телефонов при нормальном трафике. Обход по шагам показал, что кнопка фильтра в каталоге открывала панель, но на узких экранах панель уходила за границу вьюпорта и не прокручивалась. Кнопка «Применить» оказывалась физически недостижимой: пользователь мог выбрать параметры, но не мог их подтвердить. Правка заняла полдня, а обнаружилась только потому, что проверку делали на конкретном узком устройстве, а не в эмуляторе на широком мониторе.
Аудит кода такие вещи не находит. Их находят, когда кто-то садится и проходит путь покупателя пальцем на настоящем телефоне.
Кто отвечает за мобильную версию после запуска
Адаптивная вёрстка на 1С-Битрикс имеет свойство деградировать. Ломают её обычно не разработчики, а обычная жизнь проекта: маркетолог поставил новый баннер, контент-менеджер добавил акционный блок, подрядчик по рекламе подключил ещё один скрипт аналитики. Каждое изменение делалось из лучших побуждений и на десктопе выглядело нормально.
Поэтому в договорах на сопровождение мы отдельно фиксируем два правила. Первое: любая правка вёрстки принимается после просмотра на телефоне, а не только на мониторе. Второе: в компании есть человек, который раз в месяц проходит основной сценарий покупки со своего смартфона и сообщает о найденном. Роль нетехническая, справится маркетолог или менеджер по продажам.
Второй пункт даёт больше, чем кажется. Именно продажник первым замечает, что форма стала неудобной, потому что слышит по телефону, как клиент пытается оформить заказ и не может. Обратная связь из отдела продаж по мобильной версии почти всегда точнее любых метрик, она приходит с конкретикой: на каком шаге и что именно не нажимается.
Ещё один рабочий приём: фиксировать состояние. Перед крупными изменениями шаблона сохраняйте скриншоты ключевых экранов на телефоне. Когда через два месяца появится ощущение «раньше было удобнее», будет с чем сравнить, а не спор на память.
Частые вопросы
Обязательно ли переделывать вёрстку целиком, если сайт старый?
Не всегда. Если разметка построена на сетке, а проблема в отдельных блоках вроде фильтра, карточки или форм, дешевле точечно исправить эти узлы. Полная переработка нужна, когда шаблон свёрстан таблицами или с жёсткими пиксельными ширинами по всей структуре: латать такое дороже, чем переписать.
Что лучше для SEO, адаптив или отдельный мобильный шаблон?
Адаптив проще и безопаснее, потому что контент и разметка гарантированно совпадают. Отдельный шаблон допустим, но требует дисциплины: любой блок, отсутствующий в мобильной версии, для поисковика на странице отсутствует, поскольку индексируется именно мобильный вариант.
Ускорит ли композитный сайт мобильную версию?
На страницах со статическим содержимым, то есть на витрине, в разделах каталога и на контентных страницах, эффект по времени отрисовки заметный. Но композит не заменяет работу с картинками и сторонними скриптами: если страница весит несколько мегабайт, кэш выдачи проблему не закроет.
Сколько времени занимает приведение существующего сайта в порядок?
Зависит от объёма. Точечные исправления критичных мест занимают от нескольких дней. Переработка мобильной версии магазина среднего размера с каталогом, фильтром и оформлением заказа обычно укладывается в несколько недель, включая тестирование на устройствах.
Можно ли обойтись готовым решением из Маркетплейса?
Готовое решение закрывает базовую адаптивность из коробки. Проблемы начинаются при доработке под конкретный бизнес: кастомные блоки, нестандартные фильтры, интеграции. Именно эти изменения чаще всего и ломают мобильную версию, поэтому их проверяют отдельно после каждого этапа работ.
Регулярный обход ключевых страниц с телефона стоит поставить в календарь наравне с проверкой остатков и цен. Он занимает двадцать минут и находит то, чего не видно ни из аналитики, ни из кода.