Адаптивная верстка шаблона сайта 1С-Битрикс под ключ

Недавно к нам обратился клиент с типичной проблемой: верстальщик сдал шаблон — на десктопе всё отлично. Открываешь на iPhone 13, и шапка с логотипом перекрывает меню, фильтр каталога вылезает за пределы экрана, а кнопка «Купить» прячется под sticky-баннером. Это не баг верстки в вакууме — это следствие того, что адаптив делался без учёта специфики шаблонной системы Битрикс: вложенных компонентов, подключаемых через $APPLICATION->IncludeComponent(), и того, что часть HTML генерируется PHP, а часть — JavaScript.

По данным StatCounter, мобильный трафик уже превышает десктопный, и поисковые системы учитывают адаптивность при ранжировании. Мы, как разработчики Битрикс с 10-летним опытом, знаем, как правильно адаптировать шаблон без потери функциональности. За 5 лет мы адаптировали более 30 шаблонов для разных отраслей — от интернет-магазинов до корпоративных порталов.

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

Шаблон сайта в Битрикс — это папка в /bitrix/templates/<имя_шаблона>/ или /local/templates/<имя_шаблона>/. Точки входа: header.php, footer.php, styles.css, script.js. Компоненты переопределяются в /bitrix/templates/<шаблон>/components/ или /local/templates/<шаблон>/components/.

Адаптив требует работы на двух уровнях:

• Шаблон сайта (header.php, footer.php, общие блоки): навигация, шапка, подвал, сайдбар
• Шаблоны компонентов: у bitrix:catalog.section, bitrix:news.list, bitrix:sale.basket.basket своя разметка в template.php — её тоже нужно адаптировать

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

Какие компоненты требуют адаптации в первую очередь?

Мы выделяем четыре зоны, которые ломаются чаще всего:

Мобильное меню — компонент bitrix:menu генерирует <ul> с классами. Для мобильного бургер-меню нужно либо переопределить шаблон компонента, либо управлять видимостью через CSS/JS. Важно сохранить доступность: меню должно работать без JavaScript при SSR-кэшировании.

Каталог и фильтр — bitrix:catalog.section с bitrix:catalog.smart.filter на мобильном требует отдельного подхода: фильтр выносится в оверлей или аккордеон, сетка товаров переключается с 3 колонок на 2 и 1.

Формы — bitrix:form.result.new и формы оформления заказа (bitrix:sale.order.ajax) часто имеют многоколоночный layout, который нужно перестроить в одну колонку.

Таблицы с данными — прайс-листы, характеристики товаров: на мобильном заменяются стекированным layout или горизонтальным скроллом с фиксированной первой колонкой.

Mobile-first или Desktop-first: что выбрать?

Для новых проектов мы рекомендуем Mobile-first — писать стили для мобильных и расширять через min-width медиазапросы. Это даёт более чистый код и лучшую производительность на мобильных. Desktop-first актуален, когда адаптируем существующий шаблон, написанный под десктоп: добавляем медиазапросы через max-width, меньше риска сломать текущий вид. На практике второй подход встречается чаще, но требует более тщательного тестирования. В основе лежит концепция Responsive web design.

Брейкпоинты согласуются с дизайном, но типичный набор для Битрикс-проектов: 1280px, 1024px, 768px, 480px, 375px.

Кейс из нашей практики: адаптация корпоративного сайта

Сайт строительной компании, шаблон написан несколько лет назад, без адаптива. Доля мобильного трафика по данным Метрики — 58%. Задача: полная адаптация без редизайна и без переписывания логики PHP.

Мы прошли по всем страницам и составили список компонентов и блоков с проблемами. Основная работа сосредоточилась на: главной странице (баннер + блоки услуг), каталоге (фильтр + сетка), странице контактов (карта Яндекс + форма). Параллельно переопределили шаблоны трёх компонентов в /local/templates/. Работа заняла от 5 до 8 рабочих дней. Результат: мобильный трафик стал приносить на 30% больше заявок, а показатель отказов снизился на 15%.

Что входит в работу

• Аудит текущего шаблона и выявление проблемных компонентов
• Адаптация шаблона сайта (header, footer, общие блоки)
• Переопределение шаблонов компонентов (до 5–10)
• Настройка брейкпоинтов и медиазапросов
• Тестирование на реальных устройствах и в BrowserStack
• Проверка кэширования Битрикс — адаптивные скрипты не должны попадать в кэш некорректно
• Передача правок и документация по адаптиву

Гарантируем, что после нашей работы ваш сайт будет корректно отображаться на всех устройствах — от iPhone SE до 27-дюймовых мониторов.

Тестирование адаптива

Проверяем в Chrome DevTools (device toolbar) — это минимум. Дополнительно: реальные устройства или BrowserStack, проверка touch-событий, проверка кэшированных страниц Битрикс (важно: Битрикс кэширует HTML, убедитесь что адаптивные скрипты не попали в кэш некорректно).

Сроки

Оценим ваш проект бесплатно — свяжитесь с нами для консультации. Закажите адаптивную верстку шаблона под ключ, и мы приступим в течение недели.

Почему вёрстка сайтов на 1С-Битрикс требует профессионализма?

Открываете template.php у предыдущего подрядчика — а там SQL-запросы, бизнес-логика и inline-стили в одном файле. На каждом втором проекте, который берём на поддержку, код шаблонов выглядит как свалка: кэш не работает, добавить новую фичу — переписывай всё. Средняя стоимость исправления такой вёрстки сайтов — 15 000–30 000 рублей только на отладку, а потерянная выручка из-за сломанной корзины в пик сезона может уходить в миллионы. Наша команда с 10-летним опытом строго разделяет: логика — в result_modifier.php или component_epilog.php, представление — в template.php. Никакого CIBlockElement::GetList в шаблоне. Это сокращает время правок на 30–40% и исключает типовые ошибки, которые ломают кэш. Аналогичную проблему исправляли клиенту, который месяц не мог обновить блок «Акции» — после настройки тегированного кэша правки вставали за минуту, а не за день.

Как правильно организовать шаблоны компонентов?

Кастомный шаблон — это не один файл, а структура из пяти-шести файлов:

• template.php — только HTML и вывод $arResult
• result_modifier.php — подготовка данных, дополнительные выборки
• component_epilog.php — код после кэширования (счётчики, динамика)
• style.css и script.js — подключаются через Asset::getInstance()->addCss() и addJs() (не через <link> — иначе ломается объединение)
• .parameters.php — параметры визуального редактора

Пример структуры для каталога:

local/templates/your_template/components/bitrix/catalog.section/.default/
├── template.php
├── result_modifier.php
├── component_epilog.php
├── style.css
├── script.js
└── .parameters.php

Типовые шаблоны, которые верстаем под ключ:

Кэширование: почему оно ломается и как чиним?

Компонентное кэширование в Битрикс ломается одной ошибкой: вывели имя пользователя внутри кэшированного каталога — все видят одно имя. Решение — component_epilog.php для динамических вставок.

Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) настраиваем обязательно. Изменили товар — очищается кэш только этого товара, а не всего раздела. На проекте с 50 000 товаров это даёт прирост скорости на 40% по сравнению с полным сбросом.

Реальный кейс. Клиент жаловался — на странице каталога у всех одна корзина. Оказалось, предыдущий разработчик вывел $_SESSION['BASKET'] внутри template.php компонента catalog.section. Компонент кэшировался на час — корзина застыла. Перенесли вывод в component_epilog.php, настроили тегированный кэш на sale.basket.basket.line. Страница не потеряла в скорости, корзина стала актуальной. Ущерб от неработающей корзины в пик сезона мог составлять миллионы, а цена исправления — в пределах 15 000 рублей. Другой клиент потерял 200 000 рублей за неделю из-за некорректного кэша формы заказа — мы вернули работоспособность за два дня.

Официальная документация Битрикс рекомендует использовать component_epilog.php для динамических вставок — подробнее в руководстве.

CSS-подходы: BEM, Tailwind или гибрид?

Для больших проектов (30+ шаблонов) используем BEM — .product-card__price, .product-card--featured. Стили изолированы, конфликтов нет. Подробнее о BEM. В Битрикс обёртки с классами bx-component не трогаем — оборачиваем свой BEM-блок внутри.

Для типовых задач (лендинги, админки) берём Tailwind 3+ с PurgeCSS — итоговый CSS 10–30 КБ вместо сотен. Дизайн-токены в tailwind.config.js фиксируют цвета, шрифты, отступы в одном месте.

На большинстве проектов применяем гибрид: BEM для структурных компонентов (каталог, карточка, чекаут), Tailwind для утилитарных вещей (отступы, flex-раскладки). Границу оговариваем с командой заранее.

Как мы достигаем Core Web Vitals?

Critical CSS — выделяем стили первого экрана через пакет critical, инлайним в <head>. Остальное грузится асинхронно через media="print" onload="this.media='all'". LCP на мобильных сокращается на 1–1.5 секунды.

Изображения — главный тормоз. Используем <picture> с WebP и JPEG-фолбэком. loading="lazy" для всего ниже первого экрана. width и height явно прописаны — CLS = 0. Обработчик в urlrewrite.php генерирует WebP на лету.

Минификация и сжатие. CSS и JS через Vite или встроенное объединение Битрикс. Brotli на nginx (brotli_comp_level 6) — на 15–20% эффективнее gzip. Кэширование статики: expires 1y + версионирование через query string.

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

Что входит в услугу вёрстки сайтов на 1С-Битрикс?

После заказа вёрстки шаблона или адаптации готового решения передаём:

• Исходники шаблонов компонентов с разделением на template.php, result_modifier.php, epilog
• CSS и JS, подключённые через Asset — без инлайн-стилей
• Настроенное кэширование с тегами
• Документацию по структуре и параметрам
• Доступ к Git-репозиторию с историей изменений
• Обучение вашего разработчика: как править шаблон без потери обновляемости

Гарантируем соответствие Core Web Vitals и кроссбраузерность. Закрепляем инженера с опытом 10+ лет — получите консультацию по вашему проекту до начала работ.

Процесс работы:

1. Анализ макетов и текущего проекта — выявляем компоненты для переработки
2. Проектирование структуры — разбиваем страницу на BEM-блоки
3. Реализация — верстаем шаблоны по схеме: template, result_modifier, epilog, CSS, JS
4. Тестирование — проверяем кэш, адаптивность, Core Web Vitals, кроссбраузерность
5. Деплой — стейджинг, приёмка, продакшен

На каждом этапе вы получаете промежуточный результат и можете внести правки. Свяжитесь с нами — оценим проект за 1–2 дня после получения макетов.

Сроки

После анализа даём разбивку по компонентам — что переиспользуется, что верстается с нуля. Закажите предварительную консультацию — посчитаем сроки и бюджет индивидуально.