Оптимізація завантаження: стиснення CSS та JS на 1С-Бітрікс

Сайт завантажується 5 секунд, а GTmetrix показує, що CSS та JS займають 80% об'єму. Типова картина для середнього Бітрікс-проекту: вихідні файли важать 500 KB–2 MB, і без стиснення кожен мегабайт передається як є. Налаштування HTTP-стиснення (Gzip або Brotli) зменшує об'єм даних у 3–7 разів для текстових ресурсів — це один із найшвидших способів прискорити завантаження без зміни коду. Ми налаштовуємо такі рішення на десятках проектів, від простих корпоративних до великих каталогів.

Вбудовані інструменти стиснення Бітрікс

Бітрікс включає власний механізм мініфікації та об'єднання CSS/JS, доступний у Налаштування → Продуктивність → Стиснення. Він працює на рівні PHP: збирає підключені через CMain::AddCSSLink() та CMain::AddHeadScript() файли, мініфікує їх та зберігає в /bitrix/cache/css/ і /bitrix/cache/js/. Результуючі файли отримують хеш в імені — браузер кешує їх агресивно.

Важливо: мініфікація Бітрікс працює лише з файлами, підключеними через API Бітрікс. CSS та JS, підключені безпосередньо в шаблоні через <link> та <script>, не обробляються. На legacy-проектах нерідко половина файлів підключена «повз» API. Ми переводимо такі підключення на штатні методи — це обов'язковий етап аудиту.

Чому мініфікації недостатньо для реального прискорення?

Мініфікація зменшує розмір файлів на диску, але при передачі по мережі дані все одно йдуть «як є». Без стиснення на рівні HTTP (gzip/Brotli) ви втрачаєте 70–80% потенційного виграшу. Наприклад, мініфікований файл jQuery UI може важити 150 KB, а з gzip — лише 40 KB. Різниця помітна на кожному запиті.

Як налаштувати gzip на nginx для Бітрікса?

Конфігурація в nginx потребує лише декількох директив:

gzip on;
gzip_types text/css application/javascript application/json text/javascript;
gzip_min_length 1024;
gzip_comp_level 5;
gzip_vary on;

gzip_comp_level 5 — баланс між ступенем стиснення та навантаженням на CPU. Рівні 6–9 дають мінімальний приріст стиснення при значно більшому навантаженні. gzip_vary on додає заголовок Vary: Accept-Encoding, необхідний для коректної роботи кешуючих проксі та CDN. Brotli стискає ще краще — виграш до 20% у порівнянні з gzip. Налаштування аналогічне, але потребує модуля ngx_brotli.

Що дає Brotli у порівнянні з gzip?

Brotli ефективніше gzip у 1.2–1.3 рази за ступенем стиснення. Для сучасних браузерів він кращий, але потребує модуля nginx. Налаштування:

brotli on;
brotli_types text/css application/javascript application/json text/javascript;
brotli_comp_level 6;

Краще залишити gzip як fallback для старих клієнтів. Обидва методи можна комбінувати: gzip_static on для попередньо стиснених файлів.

Що перевірити при налаштуванні

Часта помилка: подвійне стиснення — gzip включений в nginx, але PHP-FPM або сам Бітрікс теж стискають відповідь. Симптом: браузер видає помилку декодування або файл завантажується замість виконання. Перевіряється через curl -I -H "Accept-Encoding: gzip" https://mysite.ru/bitrix/cache/css/file.css — у заголовках має бути Content-Encoding: gzip.

Для мініфікованих файлів з хешем в імені рекомендується налаштувати статичне (pre-compressed) стиснення через gzip_static on — nginx віддає заздалегідь стиснений .gz-файл без навантаження на CPU в реальному часі.

Кейс з нашої практики

Корпоративний сайт на Бітрікс «Стандарт» — 12 CSS і 23 JS файли підключені через API. Після включення мініфікації Бітрікс та gzip на nginx: сумарний розмір CSS+JS знизився з 1,4 MB до 180 KB (мініфікація) → 48 KB (gzip). Кількість HTTP-запитів до CSS скоротилася з 12 до 2, до JS — з 23 до 3. Час до DOMContentLoaded знизився на 0,8 с на мобільних з'єднаннях 3G.

Порівняння алгоритмів:

Що входить у роботу

• Аудит підключення ресурсів: виявляємо «прямі» вставки CSS/JS, які не обробляються Бітрікс.
• Переведення всіх файлів на API: AddCSSLink(), AddHeadScript().
• Включення штатної мініфікації та об'єднання в адміністративній панелі.
• Налаштування gzip/Brotli на сервері (nginx/Apache).
• Перевірка від подвійного стиснення та тестування на всіх сторінках.
• Підготовка звіту з результатами до/після.

Процес роботи

1. Аналітика — вивчаємо структуру шаблонів, спосіб підключення ресурсів, поточний стек сервера.
2. Проектування — обираємо оптимальну схему (мініфікація + gzip або Brotli, статичне стиснення).
3. Реалізація — вносимо зміни в конфігурацію nginx, налаштовуємо Бітрікс, виправляємо шаблони при необхідності.
4. Тестування — перевіряємо заголовки HTTP, швидкість завантаження (Lighthouse, WebPageTest), відсутність помилок.
5. Деплой — застосовуємо на бойовому середовищі, моніторимо протягом тижня.

Налаштування займає від 4 до 8 годин залежно від обсягу legacy-коду. Замовте аудит швидкості — виявимо вузькі місця та налаштуємо стиснення під ключ. Гарантуємо стабільну роботу — всі зміни оборотні. У нас понад 5 років досвіду в оптимізації Бітрікс-проектів.

Корисні посилання:

• gzip на Вікіпедії
• Brotli на Вікіпедії

80% сайтів на Бітрікс гальмують через одну таблицю

b_iblock_element_property — EAV-структура. Кожен рядок зберігає одне значення однієї властивості одного елемента. Каталог у 50 000 товарів з 30 властивостями дає 1,5 млн рядків. Коли розумний фільтр робить JOIN цієї таблиці з b_iblock_element за п'ятьма властивостями, MySQL іде в full table scan на 3–5 секунд.

Наш досвід показує: без втручання в цю таблицю прискорення неможливе. Ми беремося за проекти, де швидкість завантаження впала до 8–10 секунд, і повертаємо TTFB < 200 мс за 1–2 тижні. Оптимізація швидкості сайту починається з аудиту slow-запитів і закінчується комплексною перебудовою інфраструктури під ключ. У нашому портфоліо — понад 200 успішних проєктів. Ми — команда сертифікованих фахівців з 10‑річним досвідом роботи в Бітрікс.

Серверна оптимізація

Nginx. Не просто «увімкнули gzip». Конкретно:

• gzip_comp_level 4-5 — вище безглуздо, CPU з'їдає більше, ніж економить трафік;
• brotli on з brotli_static on — для попередньо стиснутих файлів (Brotli стискає на 20–30% краще за gzip);
• HTTP/2 з http2_max_concurrent_streams 128;
• fastcgi_cache для PHP-відповідей — кешування на рівні Nginx, минаючи PHP-FPM;
• worker_processes auto, worker_connections під кількість одночасних з'єднань.

PHP-FPM. Вибір між pm = dynamic і pm = static — не академічний:

• Static: фіксована кількість воркерів, без overhead на форк — для виділених серверів з передбачуваним навантаженням.
• Dynamic: економить RAM при низькому трафіку. pm.max_children рахуємо як (доступна RAM − RAM для MySQL/Redis) / середня витрата на процес.
• OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшені (перезавантаження PHP-FPM при деплої).

MySQL/MariaDB. Головне вузьке місце майже завжди:

• slow_query_log з порогом 0.5 сек — кожен запит розбираємо через EXPLAIN.
• innodb_buffer_pool_size = 70–80% доступної RAM на виділеному сервері.
• Складені індекси для фасетного пошуку: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
• OPTIMIZE TABLE b_iblock_element_property після масових операцій.

Як налаштувати кешування на три рівні?

Керований кеш компонентів. TTL налаштовуємо для кожного компонента окремо. Каталог — 3600 сек, новинна стрічка — 300 сек, банери — 86400. Однаковий TTL всюди — гарантія або застарілих даних, або марного кешу.

Композитний кеш. Технологія bitrix:composite — Nginx віддає готовий HTML із файлу, PHP не запускається. Динамічні зони (кошик, авторизація) підвантажуються AJAX-запитом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Але не всі компоненти сумісні: $APPLICATION->ShowPanel() і прямий вивід через echo ламають композит. Перевіряємо кожну сторінку через панель «Продуктивність → Композитний сайт».

Порівняння: композитний кеш швидший за керований у 10–20 разів за часом першого байта. Офіційна документація Бітрікс з композитного кешу — Bitrix Composite.

Memcached / Redis. Переносимо кеш із файлової системи:

• Сесії → Redis (session.save_handler = redis) — швидше за файли в 10–50×, плюс робота в кластері.
• Кеш компонентів → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
• Кеш ORM-запитів — однакові GetList() не навантажують MySQL на кожному хіті.

Чому стандартних налаштувань MySQL недостатньо?

Індекси. Складені для фасетного пошуку. Покриваючі — для частих вибірок MySQL відповідає з індексу, не звертаючись до даних. Часткові індекси (MariaDB) для фільтрації за ACTIVE = 'Y'. Аудит невикористовуваних індексів — кожен сповільнює INSERT/UPDATE.

Партиціонування. Для таблиць з мільйонами рядків: b_stat_session, b_search_content_stem, Highload-блоки з історією. Партиція за датою — запит «замовлення за місяць» не сканує дані за три роки.

Реальний кейс: каталог 200 000 товарів, 50 властивостей. Фільтр за 10 властивостями займав 12 секунд. Після створення складених індексів за (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) та партиціонування b_iblock_element_property за IBLOCK_ID час виконання впав до 0,3 секунди. Навантаження на MySQL знизилося в 40 разів. Це дозволило скоротити витрати на сервер до 40% без втрати продуктивності.

Очищення. У будь-якій базі за рік-два накопичується: застарілий пошуковий індекс, прострочені записи в b_cache_tag, історія b_iblock_element_prop_s*, логи в b_event_log на гігабайти. Налаштовуємо регулярне очищення через агенти.

Партиціонування також вирішує проблему з паралельними запитами при обміні з 1С через CommerceML. Докладніше: MySQL Partitioning Documentation.

Після аудиту вашого проекту ми визначимо вузькі місця за 2 години та запропонуємо конкретний план прискорення. Замовте безкоштовний аудит швидкості — заповніть форму на сайті.

Фронтенд

Зображення — 60–80% ваги сторінки:

• WebP через CFile::ResizeImageGet() з BX_RESIZE_IMAGE_PROPORTIONAL + конвертація;
• srcset + sizes — не завантажуємо 3000px картинку в блок 400px;
• loading="lazy" для всього нижче першого екрану;
• AVIF — ще 20–30% економії порівняно з WebP.

CSS/JS:

• Вбудований модуль Бітрікс: об'єднання та мініфікація через «Налаштування → Оптимізація CSS/JS»;
• PurgeCSS / UnCSS — на типовому Бітрікс-проекті 60–70% CSS не використовуються;
• defer / async для некритичного JS;
• Critical CSS інлайном у <head> для миттєвого FCP.

Шрифти:

• <link rel="preload" as="font" crossorigin> для основного шрифту;
• font-display: swap — текст видно одразу;
• Subsetting через pyftsubset — вирізаємо кирилицю + латиницю, файл зменшується в 3–5 разів.

CDN

Cloudflare, BunnyCDN, AWS CloudFront або локальні (Selectel CDN, VK Cloud CDN).

• Статика (CSS, JS, зображення, шрифти) — через CDN.
• Правила кешування: Cache-Control: public, max-age=31536000, immutable для файлів з хешем.
• Оптимізація зображень на льоту (imgproxy, Cloudflare Polish) без навантаження на origin.

Навіщо потрібне навантажувальне тестування?

Не синтетичні бенчмарки, а реальні сценарії:

• k6 / wrk — імітація маршрутів: каталог → фільтрація → картка → кошик → оформлення.
• Метрики: RPS, час відповіді (p50, p95, p99), відсоток помилок.
• Xdebug (callgrind) або Blackfire — профілювання PHP, пошук вузьких місць.

Результат тестування — об'єктивна картина, де реально гальмує. Після оптимізації проганяємо повторно — фіксуємо покращення.

Результати

Що входить у роботу?

1. Аудит поточної продуктивності — аналіз slow-запитів, профілювання PHP, перевірка кешування, CDN, серверних налаштувань.
2. Налаштування серверної частини — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Оптимізація кешування — керований кеш, композитний сайт, налаштування TTL, теговане кешування.
4. Робота з БД — створення індексів, партиціонування, очищення, реорганізація EAV-таблиць.
5. Фронтенд — зображення (WebP/AVIF), CSS/JS (мініфікація, deferred), шрифти (preload, subsetting).
6. CDN — підключення, налаштування правил кешування.
7. Навантажувальне тестування — сценарії реальних користувачів, звіт за метриками.
8. Документація — опис усіх змін, рекомендації щодо подальшого обслуговування.
9. Гарантія — підтримка протягом 1 місяця після здачі.

Моніторинг

Без моніторингу через півроку все деградує. Новий модуль, неочищені логи, зміна в шаблоні — і швидкість повернулася до початкової.

• web-vitals API — Real User Monitoring від реальних відвідувачів.
• Synthetic monitoring — Pingdom, UptimeRobot, регулярні перевірки з різних локацій.
• Алерти — TTFB > 500 мс або LCP > 3 сек → сповіщення.

Терміни та вартість

Вартість розраховується індивідуально після аудиту. Отримайте консультацію щодо вашого проекту — оцінимо поточний стан і запропонуємо план прискорення з конкретними термінами та бюджетом. Ми — команда з 10+ роками досвіду в Бітрікс, виконали понад 200 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.