Верстка і шаблони для 1С-Бітрікс
Шаблони компонентів — тут живе 70% проблем
Компонентна система Бітрікс влаштована просто: є компонент (логіка), є шаблон (представлення). Проблема в тому, що в реальних проєктах ця межа розмивається. Відкриваєш template.php від попереднього підрядника — а там SQL-запити, бізнес-логіка й інлайн-стилі в одному файлі. Ми жорстко розділяємо: логіка — в result_modifier.php або component_epilog.php, представлення — в template.php. Жодного CIBlockElement::GetList у шаблоні.
Структура, якої дотримуємось
Кастомний шаблон компонента — це не один файл, а структура:
-
template.php— тільки HTML і виведення$arResult -
result_modifier.php— підготовка даних, додаткові вибірки, форматування -
component_epilog.php— код, що виконується після кешування (лічильники, форми) -
style.cssіscript.js— підключаються автоматично через\Bitrix\Main\Page\Asset -
.parameters.php— параметри для налаштування з візуального редактора
CSS і JS підключаємо через Asset::getInstance()->addCss() та addJs(). Не через <link> у шаблоні — інакше ламається об'єднання файлів і кешування.
Кешування — критично для highload
Компонентне кешування в Бітрікс — потужна штука, але її легко зламати. Типова помилка: вивели ім'я користувача всередині кешованого компонента каталогу — і всі бачать одне ім'я. Рішення: component_epilog.php для динамічних вставок, які не повинні кешуватися.
Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) — обов'язково налаштовуємо. Змінили товар в адмінці — кеш саме цього товару скидається автоматично, без скидання всього.
Типові шаблони
-
Каталог —
catalog.sectionіcatalog.elementз перемиканням виду (плитка/список/таблиця). Lazy load для зображень,srcsetдля ретіни -
Кошик —
sale.basket.basketз AJAX-оновленням без перезавантаження сторінки. Міні-кошик у шапці черезsale.basket.basket.line -
Мегаменю —
menuз кешуванням по розділах і відкладеним завантаженням підменю -
Пошук —
search.titleз автопідказками, дебаунс 300мс, прев'ю товарів у дропдауні -
Хлібні крихти —
breadcrumbз мікророзміткою BreadcrumbList за Schema.org
Кастомізація шаблонів Маркетплейсу
Придбане готове рішення — відправна точка, не фінал. Що зазвичай переробляємо:
- Виносимо інлайн-стилі в окремі файли — у штатних шаблонах люблять засовувати CSS прямо в HTML
- Прибираємо JS, що не використовується — типові рішення тягнуть jQuery-плагіни на 200+ КБ, з яких використовується один слайдер
- Переробляємо
result_modifier.php— часто там надмірні запити до бази, які вже є в$arResult - Адаптуємо дизайн без втрати оновлюваності — кастомізуємо копію шаблону, оригінал не чіпаємо
CSS: BEM, Tailwind або гібрид
BEM — передбачуваність для великих проєктів
На проєктах з десятками шаблонів компонентів BEM — рятівне коло. .product-card, .product-card__price, .product-card--featured. Стилі ізольовані, конфліктів немає, новий розробник читає класи і розуміє структуру без документації.
Специфіка Бітрікса: компоненти генерують обгортки з класами виду bx-component. Не боремося з ними — обгортаємо свій BEM-блок усередині.
Tailwind — швидкість на типових задачах
Для проєктів, де швидкість розробки пріоритетніша за довгострокову підтримку. PurgeCSS (вбудований у Tailwind 3+) вирізає невикористане — підсумковий CSS 10-30 КБ замість сотень. Конфігурація дизайн-токенів через tailwind.config.js: кольори, шрифти, відступи зафіксовані в одному місці.
Гібрид — найчастіше беремо саме його
BEM для структурних компонентів (каталог, картка товару, чекаут), Tailwind для утилітарних речей (відступи, flex-розкладки, кольори тексту). Працює, коли команда домовилася про межу.
Продуктивність фронтенду — Core Web Vitals
Critical CSS — LCP під контролем
Виділяємо стилі першого екрана через critical (npm-пакет), інлайнимо в <head>. Решта завантажується асинхронно через media="print" onload="this.media='all'". Різниця в LCP — секунда-півтори на мобільних.
Зображення — головне джерело гальмувань
- WebP через
<picture>з JPEG-фолбеком. AVIF — якщо аудиторія на свіжих браузерах -
loading="lazy"для всього нижче першого екрана -
widthіheightпрописані явно — CLS = 0, макет не стрибає - Конвертація на льоту: обробник у
urlrewrite.phpдля автоматичної генерації WebP із завантажених зображень
Мініфікація та стиснення
- CSS і JS через Vite або вбудоване об'єднання Бітрікс («Налаштування → Головний модуль → Оптимізація CSS»)
- Brotli на nginx (
brotli_comp_level 6) — на 15-20% ефективніше за gzip - Кешування статики:
expires 1y+ версіонування через query string або хеш в імені файлу
Адаптивна верстка — mobile-first
Базові стилі — для мобільних (320px+). Десктопні додаємо через @media (min-width: 1024px). Не навпаки.
| Breakpoint | Діапазон | Що адаптуємо |
|---|---|---|
| Мобільні | 320-639px | Одноколонкова сітка, збільшені touch-зони (мінімум 44x44px) |
| Планшети | 640-1023px | Двоколонкова сітка, адаптована навігація |
| Десктоп | 1024-1439px | Повна сітка, сайдбари, мегаменю |
| Широкі екрани | 1440px+ | max-width на контейнері, збільшені відступи |
Ретіна: SVG для іконок (проганяємо через SVGO — мінус 30-50% розміру), srcset з 2x для растрових зображень.
Доступність і кросбраузерність
ARIA-атрибути для інтерактивних елементів: role="dialog" на модалках, aria-expanded на акордеонах, aria-label на іконкових кнопках. Навігація табом, контрастність за WCAG 2.1 AA.
Підтримуємо: Chrome, Firefox, Safari, Edge — останні 2 версії. Safari iOS 15+, Chrome Android 10+, Yandex Browser. Для решти — graceful degradation: все працює, але без анімацій і тіней.
Терміни
| Обсяг | Термін |
|---|---|
| Лендінг (5-7 екранів) | 3-5 днів |
| Корпоративний сайт (15-20 унікальних сторінок) | 2-4 тижні |
| Інтернет-магазин (30+ шаблонів компонентів) | 4-8 тижнів |
| Кастомізація готового рішення Маркетплейсу | 1-3 тижні |
| Редизайн наявного проєкту | 3-6 тижнів |
Після аналізу макетів даємо розбивку по компонентах і сторінках — із зазначенням, що перевикористовується, а що верстається з нуля.