Мобильная версия интернет-магазина на 1С-Битрикс: UX и скорость

Откройте статистику любого российского интернет-магазина — и вы почти наверняка увидите, что бо́льшая часть визитов приходит с телефонов. Человек ищет товар в дороге, в очереди, лёжа на диване, и решение о покупке принимает на экране шириной в ладонь. Если на этом экране мелкая кнопка «В корзину», фильтр открывается криво, страница грузится пять секунд, а форма заказа не помещается — покупатель уходит, и никакая красивая десктопная версия его уже не вернёт. Мобильная версия магазина на 1С-Битрикс — это не «уменьшенный сайт», а основной канал продаж, который проектируют отдельно и придирчиво.

В этой статье разберём по-инженерному, из чего складывается удобный и быстрый мобильный магазин: адаптивный дизайн против отдельной мобильной версии и почему побеждает подход mobile-first, что именно важно на маленьком экране (тап-зоны, крупные кнопки, sticky-панель «В корзину», меню-бургер, фильтр в шторке, мобильный поиск и checkout), как добиваться скорости на смартфонах (LCP главного изображения, lazyload, вес страницы, шрифты, композит) и как всё это верстается в шаблоне Битрикс через viewport и медиазапросы. Материал основан на нашей практике оптимизации конверсии (CRO), ускорения сайтов на 1С-Битрикс и разработки интернет-магазинов — без выдуманных «процентов роста», зато с рабочими принципами.

Почему мобильный экран стал главным местом покупки

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

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

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

Доля мобильного трафика в e-commerce

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

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

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

Адаптив против отдельной мобильной версии

Исторически было два способа сделать магазин пригодным для телефона. Первый — адаптивный дизайн (responsive): одна вёрстка и один код, которые через медиазапросы CSS перестраиваются под ширину экрана. Второй — отдельная мобильная версия: обычно на поддомене вроде m.site.ru, со своим шаблоном, а иногда и своим кодом, куда пользователей перекидывают по типу устройства. Сегодня выбор почти всегда в пользу адаптива, и вот почему.

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

Mobile-first: проектируем от смартфона

Адаптивный сайт можно проектировать двумя путями. «Desktop-first» — сначала рисуют широкий десктоп, а потом «ужимают» его под телефон. «Mobile-first» — наоборот: сначала собирают узкий мобильный макет, а затем расширяют его до планшета и десктопа. Разница кажется технической, но на деле она меняет весь результат.

Почему mobile-first работает лучше:

• Заставляет отобрать главное. На узком экране физически мало места, поэтому вы вынуждены оставить только важное: цену, наличие, кнопку покупки, ключевой контент. Всё второстепенное отсеивается само собой.
• Даёт чистую базу. Когда основа собрана под мобильный, на десктопе вы добавляете элементы (боковые колонки, больше товаров в ряд), а не пытаетесь впихнуть богатый десктоп в узкую колонку.
• Ведёт к лёгкости. Mobile-first подталкивает грузить сначала минимум, а тяжёлое подключать по мере роста экрана и надобности. Это напрямую помогает скорости на телефонах.
• Соответствует индексации. Раз поисковик оценивает мобильную версию первой, логично и проектировать её первой, а не «по остаточному принципу».

На уровне вёрстки mobile-first выражается в том, что базовые стили пишут без медиазапросов (они и есть «мобильные»), а расширения добавляют через min-width: «начиная с планшета — две колонки», «начиная с десктопа — боковой фильтр». Такой код проще и предсказуемее, чем набор «отключений» десктопных стилей на узких экранах. В Битриксе это ложится на шаблон компонентов: сетку каталога, карточку, корзину верстают от одной колонки, а многоколоночность включают на широких брейкпоинтах.

Тап-зоны, крупные кнопки и зона большого пальца

Главное отличие мобильного интерфейса от десктопного — способ ввода. На десктопе точный курсор и наведение (hover), на телефоне — крупный неточный палец и касание. Всё, что проектируется под курсор, на телефоне ломается: мелкие ссылки, тесно стоящие кнопки, элементы, которые «показываются при наведении».

Размер и расстояние между целями

Общепринятый ориентир мобильной доступности — интерактивный элемент около 44–48 CSS-пикселей по стороне, с достаточным отступом от соседних целей. Кнопка «В корзину», плюс-минус количества, чекбоксы фильтра, пункты меню, ссылки пагинации — всё это должно быть крупным и «с воздухом». Мелкая или зажатая между другими кнопка означает промахи, а промах — это раздражение и потерянное действие.

Зона большого пальца

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

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

Меню-бургер и упрощённая навигация

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

Что важно в мобильном меню:

• Понятная точка входа. Иконка бургера — привычная и крупная, а рядом с ней обычно живут логотип, поиск и корзина. Это стандартная мобильная «шапка», которую пользователь узнаёт без объяснений.
• Вложенность без потери контекста. Разделы каталога раскрываются шаг за шагом (аккордеоном или переходами «вглубь» с кнопкой «назад»), чтобы не вываливать всё дерево сразу и не заставлять бесконечно скроллить.
• Главное — выше. Наверх меню выносят то, что нужно чаще: каталог, акции, доставку и оплату, контакты, вход в личный кабинет. Второстепенные страницы — ниже.
• Быстрый доступ к ключевым действиям. Поиск и корзина обычно вынесены из бургера в постоянно видимую панель, чтобы к ним не приходилось открывать меню.

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

Фильтр в шторке (bottom sheet)

Умный фильтр каталога на десктопе обычно живёт слева, в боковой колонке, и всегда на виду. На телефоне такой колонки нет — экран узкий, и постоянный фильтр съел бы всё место под товары. Поэтому на мобильном фильтр прячут за кнопкой «Фильтр» и открывают шторкой — панелью, которая выезжает снизу (bottom sheet) или сбоку поверх каталога.

Как сделать мобильный фильтр удобным:

• Заметная кнопка вызова. Кнопка «Фильтр» (часто со счётчиком выбранных условий) — крупная и на виду, нередко закреплена внизу вместе с сортировкой.
• Шторка, а не новая страница. Фильтр открывается поверх текущего каталога, не теряя контекста. Пользователь видит, что он всё ещё в той же категории.
• Применение по кнопке. На мобильном обычно дают выбрать несколько условий и нажать «Показать N товаров», а не перезагружать выдачу на каждый чекбокс. Так покупатель не ждёт по разу на каждое касание.
• Виден результат. Кнопка применения показывает, сколько товаров найдётся, — это снимает страх «выберу и ничего не останется».
• Лёгкий сброс. Понятные «Сбросить» и закрытие шторки, крупные чекбоксы и переключатели — всё под палец.

Технически на 1С-Битрикс это чаще всего штатный компонент умного фильтра (catalog.smart.filter) с мобильным поведением шаблона: на узких экранах он сворачивается в кнопку и шторку, на широких — раскрывается в боковую колонку. Важно, чтобы это переключение управлялось медиазапросами и не ломало фасетную логику: фильтр по свойствам и остаткам должен работать одинаково на всех экранах, меняется только способ его показа. Как устроен сам умный фильтр и фасетный индекс — тема отдельная, но на мобильном к ней добавляется вопрос удобной подачи в шторке.

Мобильный поиск

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

• Иконка поиска на виду. Лупа в шапке или строка поиска над каталогом — то, к чему тянется рука в первую очередь. Прятать поиск глубоко в меню — ошибка.
• Подсказки и автодополнение. По мере ввода показывать подсказки, популярные запросы и найденные товары с картинками. Это экономит набор на мелкой клавиатуре, где печатать неудобно.
• Правильная клавиатура и фокус. При открытии поиска сразу ставить фокус в поле и поднимать клавиатуру, чтобы не было лишнего касания.
• Поиск по артикулу. Для технических и B2B-ниш покупатель приходит с точным кодом — поиск должен находить товар по артикулу и синонимам, а не только по названию.
• Понятная выдача. Результаты — крупными карточками с фото, ценой и наличием, удобными для касания.

В 1С-Битрикс за поиск отвечает модуль поиска и компоненты вроде search.title (быстрые подсказки) и страницы результатов. На мобильном к ним добавляют требование скорости отклика: подсказки не должны «тормозить» при вводе, а выдача — грузиться быстро и не прыгать. Медленный или неудобный поиск на телефоне превращается в тупик, из которого покупатель уходит к конкуренту.

Sticky «В корзину» и панель действий

Sticky-элементы (закреплённые, «липкие») — один из главных инструментов мобильного UX. На узком экране контента много, а важные действия быстро уходят из вида при прокрутке. Липкие панели решают эту проблему: они остаются на месте, пока пользователь листает страницу.

Где sticky-панели особенно полезны:

• Кнопка «В корзину» на карточке. Пока покупатель листает фото, характеристики и отзывы, внизу экрана держится панель с ценой и главной кнопкой. Действие доступно в любой момент одним касанием.
• Панель оформления в корзине. Итоговая сумма и кнопка «Оформить заказ» закреплены внизу, чтобы к ним не приходилось скроллить через весь список товаров.
• Кнопка «Фильтр/Сортировка» в каталоге. Закреплённая внизу панель управления выдачей всегда под рукой при длинной прокрутке товаров.
• Мини-шапка с поиском и корзиной. Компактная закреплённая шапка даёт быстрый доступ к поиску и корзине без возврата наверх.

Главное правило sticky-панелей — умеренность. Если закрепить и шапку, и панель фильтров, и панель «в корзину», и баннер с промокодом, то на маленьком экране под сам контент почти ничего не останется. Липкими делают одно-два по-настоящему важных действия, а не всё подряд. И следят, чтобы закреплённые панели не перекрывали контент и последний товар в списке: под sticky-панель добавляют нижний отступ, иначе она наезжает на кнопку или текст.

Мобильная карточка товара

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

Что важно в мобильной карточке:

• Правильный порядок сверху вниз. Фото, заголовок, цена, наличие, выбор вариации, кнопка — и ничего лишнего над ними. Каждый пиксель над ценой на телефоне стоит покупателей.
• Галерея свайпом. Листание фото пальцем с точками-индикаторами удобнее, чем мелкие стрелки. Зум по тапу или разведению пальцами — для рассматривания деталей.
• Sticky-панель покупки. Цена и кнопка «В корзину» закреплены внизу, пока покупатель читает характеристики и отзывы.
• Крупный выбор вариаций. Размеры и цвета — большими плитками и свотчами, а не в тесном выпадающем списке. Недоступные комбинации помечены заранее.
• Характеристики и описание в аккордеонах. Длинные блоки сворачивают, чтобы страница не растягивалась на километр, но заголовки секций остаются видны для навигации.

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

Мобильная корзина и шторка

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

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

Что важно в мобильной корзине:

• Понятное подтверждение добавления. После касания «В корзину» — явная реакция: шторка, обновлённый счётчик, сумма. Молчание рождает повторные касания и сомнение «добавилось ли».
• Крупное управление количеством. Кнопки «плюс» и «минус» — большие, с достаточным расстоянием, чтобы не менять количество случайно.
• Виден итог. Сумма заказа и, если есть, порог бесплатной доставки — на виду, чтобы покупатель понимал, сколько платить и что добавить до бесплатной доставки.
• Sticky-кнопка «Оформить». Главная кнопка перехода к заказу закреплена внизу и не теряется при прокрутке списка товаров.
• Лёгкое удаление и правка. Убрать товар или изменить вариацию — понятными крупными элементами, без мелких «крестиков» в углу.

В 1С-Битрикс за корзину отвечают компоненты малой корзины (sale.basket.basket.line) и страницы корзины (sale.basket.basket). Шторку обычно реализуют на базе малой корзины с мобильным поведением: на узком экране она выезжает панелью, на широком может оставаться выпадающей мини-корзиной. Ключевая техническая задача — чтобы обновление корзины (добавление, изменение количества) шло без перезагрузки страницы и быстро, иначе на медленной мобильной сети каждое действие превращается в ожидание.

Мобильное оформление заказа (checkout)

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

1. Убирайте лишние поля. На шаге заказа спрашивайте только то, без чего нельзя отгрузить: имя, телефон, адрес или пункт выдачи, способ оплаты. Всё необязательное — прочь.
2. Правильные типы полей и клавиатуры. Для телефона — числовая клавиатура, для e-mail — соответствующая раскладка, автозаполнение (autocomplete) включено. Это резко ускоряет ввод.
3. Подсказки адреса и ПВЗ на карте. Автоподсказка адреса и выбор пункта выдачи на карте экономят ручной ввод и снижают ошибки.
4. Гость без обязательной регистрации. Не заставляйте создавать аккаунт до покупки. Регистрацию можно предложить после оформления, одним касанием на основе уже введённых данных.
5. Понятная валидация. Ошибку показывайте сразу у поля и понятным текстом, а не общим «проверьте форму» после отправки. Не сбрасывайте уже введённые данные.
6. Видимый итог и sticky-кнопка. Сумма к оплате и кнопка подтверждения — на виду и под пальцем. Никаких сюрпризов по цене на последнем шаге.
7. Быстрые способы оплаты. СБП, оплата картой в один шаг, кошельки — чем короче путь до оплаты, тем меньше отказов на финише.

В 1С-Битрикс оформление строится на компоненте sale.order.ajax, который поддерживает пошаговый и одностраничный сценарии без перезагрузки. Для мобильного важно настроить его так, чтобы шагов было минимум, поля не дублировались, а расчёт доставки и оплаты подтягивался быстро. «Быстрый заказ» (купить в один клик с одним полем — телефоном) на телефоне особенно ценен: он ловит тех, кому лень проходить полный чекаут на мелкой клавиатуре. Держите оба сценария — полное оформление и быстрый заказ — рядом, разделяя их по приоритету.

Что проверить в мобильном UX

Сведём ключевые элементы мобильного удобства в единую таблицу — по ней удобно принимать готовность магазина к «мобильному» покупателю и находить слабые места.

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

Скорость на мобильных: почему это критично

Удобная, но медленная мобильная версия всё равно теряет покупателей. На телефоне скорость критичнее, чем на десктопе, сразу по нескольким причинам: слабее процессор, нестабильнее сеть (мобильный интернет, метро, слабый Wi-Fi), меньше памяти. То, что на мощном ноутбуке грузится незаметно, на бюджетном Android может «думать» несколько секунд — и покупатель уходит, не дождавшись.

Скорость бьёт по магазину дважды. Во-первых, по поведению людей: чем дольше грузится страница, тем больше отказов и меньше заказов, особенно на первом экране, где решается судьба визита. Во-вторых, по SEO: поисковики учитывают скорость и стабильность страницы (Core Web Vitals) как сигнал ранжирования и собирают эти данные в первую очередь по мобильным. Медленный мобильный сайт проигрывает и в конверсии, и в позициях.

Дальше разберём главные факторы скорости по очереди: изображения и LCP, вес страницы и шрифты, JavaScript и композит. Это не абстрактная «оптимизация ради цифр», а прямая работа над тем, чтобы мобильный покупатель увидел товар и кнопку быстро и без раздражения.

LCP главного изображения и первый экран

На большинстве страниц магазина самый крупный видимый элемент — большое изображение: главное фото товара на карточке, баннер на главной, первая плитка в каталоге. Именно оно чаще всего становится LCP (Largest Contentful Paint — отрисовка крупнейшего контента), одной из ключевых метрик Core Web Vitals. Чем позже отрисовывается этот элемент, тем «медленнее» страница в глазах и пользователя, и поисковика.

Что делать с главным изображением:

• Современный формат и правильный размер. Отдавайте фото в WebP или AVIF и в размере под мобильный контейнер, а не оригинал на несколько тысяч пикселей, ужатый стилями. Через srcset/sizes телефон получит свою, лёгкую версию.
• Не «ленивое» главное фото. Атрибут loading="lazy" уместен для галереи и блоков ниже, но не для LCP-изображения — иначе вы сами откладываете отрисовку главного элемента первого экрана.
• width и height заданы. Явные размеры резервируют место и убирают скачки вёрстки (CLS), когда картинка «допрыгивает» на место после загрузки. На мобильном скачки особенно бесят: пользователь уже целится в кнопку, а всё уезжает.
• Preload критичного ресурса. Предзагрузка главного изображения помогает браузеру начать грузить его раньше, до разбора всей страницы.

Первый экран в целом должен быть максимально лёгким: минимум тяжёлых скриптов и сторонних виджетов над «сгибом», критический CSS — inline или в приоритете, остальное — отложенно. Цель простая: чтобы на телефоне при среднем интернете покупатель за секунду-две увидел товар, цену и кнопку, а не белый экран или прыгающую вёрстку. Тема Core Web Vitals и LCP шире одной страницы — мы разбираем её подробно в материале про Core Web Vitals для интернет-магазина, и мобильную скорость стоит проектировать с оглядкой на эти метрики.

Lazyload, вес страницы и шрифты

Если главное изображение грузим в приоритете, то всё остальное — наоборот, откладываем. Это и есть lazyload (ленивая загрузка): картинки и тяжёлые блоки, которые сейчас не видны, подгружаются по мере прокрутки, а не все сразу при открытии страницы.

Ленивая загрузка изображений

В каталоге и на длинных страницах десятки, а то и сотни картинок. Грузить их все при первом открытии — значит забить канал и память телефона. Атрибут loading="lazy" на изображениях ниже первого экрана решает задачу штатно, без сложного JS. Важное исключение — уже упомянутое LCP-изображение первого экрана: его ленивым делать нельзя. В типовых шаблонах Битрикса ленивую загрузку картинок каталога включают в настройках компонентов или на уровне шаблона.

Общий вес страницы

Вес — это суммарный объём того, что скачивает телефон: HTML, CSS, JS, картинки, шрифты, данные виджетов. Чем он меньше, тем быстрее страница на слабой сети. Здесь помогают: сжатие (gzip/brotli) на сервере, объединение и минификация статики, отказ от лишних сторонних скриптов (чаты, счётчики, баннеры множатся незаметно), оптимизация картинок. Каждый килобайт и каждый лишний сетевой запрос на мобильном ощутимее, чем на десктопе.

Шрифты

Веб-шрифты — частый скрытый тормоз. Если браузер ждёт загрузки шрифта, чтобы отрисовать текст, покупатель видит пустоту (эффект «невидимого текста»). Лечится это так: font-display: swap, чтобы текст сразу показывался системным шрифтом и заменялся на фирменный после загрузки; ограниченный набор начертаний (не грузить десяток толщин, если нужны две-три); современные форматы (woff2); подключение только используемых наборов символов (кириллица + латиница, без лишнего). Шрифты — из тех вещей, где легко «незаметно» утяжелить каждую страницу на сотни килобайт.

JavaScript, INP и композитный кэш

JavaScript — самый коварный фактор мобильной скорости. Картинку телефон просто скачивает, а скрипт ещё и исполняет, нагружая слабый процессор. Чем больше JS грузится и работает, тем хуже INP (Interaction to Next Paint — отзывчивость на действия пользователя): касания «залипают», меню открывается с задержкой, кнопка реагирует не сразу.

Как держать JS под контролем:

• Грузить по необходимости. Скрипты галереи, зума, карт, отзывов подключают там, где они реально нужны, а не на каждой странице «про запас».
• Откладывать некритичное. Аналитика, чаты, виджеты подключают отложенно (defer/async, после загрузки основного), чтобы они не блокировали первый экран и первые касания.
• Ревизия сторонних скриптов. Чаты, пиксели, баннерные системы, коллбэк-виджеты накапливаются и суммарно замедляют сайт. Периодически стоит проверять, что из этого действительно работает и нужно.
• Не блокировать главный поток. Тяжёлые вычисления и обработчики не должны надолго занимать главный поток, иначе интерфейс «замирает» в ответ на касания.

Композитный кэш Битрикса

У 1С-Битрикс есть мощный штатный инструмент ускорения — композитный сайт. Идея в том, что статическая часть страницы (шапка, каркас, «неизменяемое» содержимое) отдаётся мгновенно из кэша, а динамика (корзина, персональные данные, актуальные остатки) догружается отдельно. Для мобильного это особенно ценно: покупатель почти сразу видит готовую страницу, а «живые» блоки подтягиваются следом, что резко улучшает воспринимаемую скорость и метрики. Композит настраивают аккуратно, исключая из кэша по-настоящему динамические блоки, но при правильной настройке он даёт один из самых больших приростов скорости малой кровью. Вместе с серверным кэшированием, сжатием и оптимизацией изображений это и есть база быстрой мобильной витрины.

Вёрстка в шаблоне Битрикс: viewport и медиазапросы

Всё описанное выше живёт в вёрстке шаблона. Разберём, на чём технически держится адаптивность магазина на 1С-Битрикс.

Мета-тег viewport

Фундамент адаптива — правильный мета-тег в <head>: <meta name="viewport" content="width=device-width, initial-scale=1">. Он говорит браузеру телефона отрисовывать страницу по реальной ширине устройства, а не «как десктоп с уменьшением». Без него мобильный браузер покажет крошечную десктопную версию, которую придётся растягивать пальцами. Этот тег есть во всех современных шаблонах Битрикса, но при кастомной вёрстке его иногда теряют — и вся адаптивность рассыпается.

Медиазапросы

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

Адаптивные компоненты

Типовые компоненты 1С-Битрикс — каталог (catalog.section), карточка (catalog.element), фильтр (catalog.smart.filter), корзина, оформление (sale.order.ajax) — поставляются с адаптивными шаблонами. Задача разработчика — не сломать эту адаптивность при кастомизации и довести мобильное поведение до нужного уровня: сетка от одной колонки, фильтр в шторку, sticky-панели, крупные тап-зоны. Всё это делается на уровне шаблона компонента и стилей, без переписывания логики ядра. Правильный подход — переопределять шаблон и CSS, а не лезть в сам компонент: так проще обновлять платформу и не ломать корзину с оформлением. Если же нужна глубокая переработка витрины под мобильный сценарий, это уже задача уровня разработки интернет-магазина на 1С-Битрикс, а не косметики.

Тестирование на реальных устройствах

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

Как тестировать по-настоящему:

• Реальные устройства разных классов. Недорогой Android средней мощности (на нём проблемы скорости видны лучше всего), iPhone, разные диагонали и версии браузеров. «Заодно» проверяют планшет.
• Сквозной сценарий большим пальцем. Пройдите весь путь «каталог → фильтр → карточка → добавление в корзину → оформление заказа» одной рукой, как реальный покупатель. Так вылезают промахи, неудобные зоны и застревания.
• Медленная сеть. Проверьте загрузку на замедленном соединении (throttling), чтобы увидеть сайт глазами покупателя из метро или из региона со слабым интернетом.
• Формы и клавиатура. Проверьте, что поля вызывают правильную клавиатуру, работает автозаполнение, а валидация понятна и не сбрасывает введённое.
• Инструменты измерения. PageSpeed Insights и данные Core Web Vitals по мобильному профилю, а также реальная полевая статистика (RUM) дают объективную картину поверх субъективных ощущений.

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

PWA обзорно и мобильная воронка

Когда база — быстрый адаптивный сайт — готова, поверх неё можно добавить PWA (Progressive Web App). Это технология, которая делает сайт «почти приложением»: его можно добавить на домашний экран, показать сплэш-экран при запуске, кэшировать часть контента через service worker для работы при слабой сети и, при желании, слать push-уведомления.

Что PWA может дать магазину:

• Быстрые повторные заходы. Кэширование каркаса и статики ускоряет второй и последующие визиты.
• Иконка на экране. Магазин запускается «как приложение», без установки из сторов, — удобно для лояльной аудитории.
• Работа при плохой сети. Ранее просмотренные разделы доступны даже при обрывах связи.
• Push-уведомления. Канал возврата покупателей (со всеми оговорками про согласие и умеренность).

Но важно трезво оценивать роль PWA. Это усиление для магазина с уже хорошим мобильным UX и лояльной аудиторией частых визитов, а не замена базовой оптимизации и не «кнопка конверсии». Начинать проект с PWA вместо того, чтобы сначала сделать быструю и удобную адаптивную версию, почти всегда преждевременно. Сперва — UX и скорость, потом — PWA как надстройка.

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

Частые ошибки

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

• Десктоп, «ужатый» в телефон. Версию проектировали от десктопа, и на мобильном всё мелко, тесно и перегружено, вместо чистого mobile-first.
• Мелкие тап-зоны. Кнопки и ссылки крошечные и стоят вплотную — палец промахивается, покупатель раздражается.
• Опора на hover. Меню и действия карточки работают только «при наведении», которого на телефоне нет, — и превращаются в ловушку.
• Всё спрятано в бургер. Даже поиск и корзина убраны в меню, до нужного действия — лишние касания.
• Фильтр перезагружает выдачу на каждый чекбокс. Вместо шторки с применением по кнопке — ожидание на каждое касание.
• Нет sticky-кнопки «В корзину». Дочитав до отзывов, покупатель вынужден скроллить обратно к блоку покупки.
• Тяжёлое LCP-изображение. Главное фото грузится лениво и в оригинальном весе — первый экран «висит».
• Скачки вёрстки (CLS). Не заданы размеры картинок и блоков, контент прыгает, покупатель промахивается мимо кнопки.
• Гора сторонних скриптов. Чаты, пиксели, баннеры и виджеты подключены на всех страницах и душат отзывчивость (INP).
• Забыли viewport. При кастомной вёрстке потеряли мета-тег — и мобильный браузер показывает крошечный десктоп.
• Длинный checkout на мелкой клавиатуре. Десяток полей, обязательная регистрация, неправильные клавиатуры — заказы бросают на финише.
• Тестировали только в эмуляторе. На реальном бюджетном телефоне всё тормозит и не влезает, но этого никто не проверил.

Чек-лист мобильного магазина

Сведём всё в практический список, по которому удобно принимать готовность мобильной версии перед запуском или после доработки.

1. Адаптив, а не отдельная версия. Один код и один URL под все экраны; отдельная мобильная версия — только при веских причинах.
2. Mobile-first в вёрстке. Базовые стили — под узкий экран, расширения — через min-width; viewport на месте.
3. Крупные тап-зоны. Кнопки ≈44–48px с отступами; главные действия — в зоне большого пальца; нет опоры на hover.
4. Понятная навигация. Бургер для разделов, поиск и корзина на виду, вложенность без потери контекста.
5. Фильтр в шторке. Заметная кнопка вызова, применение по кнопке с числом товаров, крупные чекбоксы.
6. Удобный поиск. Лупа на виду, автоподсказки, поиск по артикулу, правильная клавиатура и фокус.
7. Мобильная карточка. Первый экран отвечает на 4 вопроса, свайп-галерея, sticky-панель покупки, крупный выбор вариаций.
8. Корзина-шторка. Подтверждение добавления, крупные ±, видимый итог, sticky «Оформить».
9. Короткий checkout. Минимум полей, правильные клавиатуры и autocomplete, гость без обязательной регистрации, СБП/карта в шаг.
10. LCP под контролем. Главное фото в WebP/AVIF, нужного размера, не lazy, с width/height и по возможности preload.
11. Lazyload и лёгкий вес. Картинки ниже сгиба — ленивые, сжатие и минификация включены, лишние сторонние скрипты убраны.
12. Аккуратные шрифты. font-display: swap, ограниченный набор начертаний, woff2, только нужные наборы символов.
13. JS и INP. Скрипты по необходимости и отложенно, ревизия виджетов, главный поток не блокируется.
14. Композит и кэш. Композитный сайт включён и настроен, серверное кэширование и сжатие работают.
15. Проверено на устройствах. Сквозной сценарий большим пальцем на реальных телефонах и медленной сети; замеры Core Web Vitals по мобильному профилю.

Вывод

Мобильная версия интернет-магазина на 1С-Битрикс — это не «уменьшенная копия» десктопа, а основной интерфейс, через который большинство покупателей знакомится с товаром и оформляет заказ. Побеждает связка «адаптивный сайт + mobile-first»: один код и один URL, спроектированные сначала под смартфон. На маленьком экране решают удобство касания (крупные тап-зоны, sticky-кнопка «В корзину», меню-бургер, фильтр в шторке, короткий checkout) и скорость (лёгкое LCP-изображение, lazyload, аккуратные шрифты, минимум JS и композитный кэш).

В 1С-Битрикс инструменты для быстрого и удобного мобильного магазина есть штатно: адаптивные компоненты каталога, карточки, фильтра, корзины и оформления, композитный сайт, кэширование, поддержка современных форматов изображений. Задача — грамотно довести их до ума в шаблоне, оптимизировать скорость по мобильному профилю Core Web Vitals и проверить всё на реальных устройствах, пройдя воронку «каталог → карточка → корзина → заказ» большим пальцем одной рукой. Сделайте это — и мобильный трафик перестанет утекать сквозь мелкие кнопки и медленные страницы, а начнёт стабильно превращаться в заказы.