Налаштування стиснення Brotli для 1С-Бітрікс: nginx та Apache

Сайт на 1С-Бітрікс з каталогом на 50 000 товарів — типовий випадок, коли Gzip уже встановлений, а сторінки все одно завантажуються 4–5 секунд на 3G. Налаштування Brotli для 1С-Бітрікс знімає до 20% розміру відповіді без жодної зміни в коді. Для CSS і JS різниця ще помітніша: бандл 400 КБ після Gzip — 110 КБ, після Brotli — 90–95 КБ. На повільних з'єднаннях це дає секунди економії, знижує витрати на трафік до 30% і покращує конверсію інтернет-магазину. Економія на трафіку може становити до 30%, що при високій відвідуваності дає суттєве скорочення витрат. Ми впроваджуємо Brotli на проектах від лендінгів до складних каталогів і завжди отримуємо вимірюваний приріст швидкості.

Відповідно до документації Google, Brotli забезпечує на 20% краще стиснення, ніж Gzip для текстового контенту. Економія на CDN-трафіку досягає 20%.

Чому Brotli ефективніший за Gzip?

Алгоритм Brotli використовує складніший словник і контекстне моделювання, що дає перевагу на повторюваних даних. Типовий HTML-шаблон Бітрікса з повторюваними класами та коментарями стискається на 18% щільніше. Ціна — трохи більший час компресії на високих рівнях. Рекомендуємо brotli_comp_level 6 для динаміки: баланс між стисненням і навантаженням на CPU. Рівень 11 (+5–8% стиснення) виправданий лише для pre-compressed статики.

Таблиця порівняння:

Як налаштувати Brotli для 1С-Бітрікс?

Покрокова інструкція

1. Встановлення модуля ngx_brotli
2. Конфігурація nginx
3. Pre-compressed статика
4. Перевірка

Встановлення модуля Brotli для nginx

Nginx не підтримує Brotli з коробки — потрібен модуль ngx_brotli. Два шляхи:

# Компіляція з вихідних кодів або готовий пакет
cd /usr/local/src
git clone --recurse-submodules https://github.com/google/ngx_brotli.git
nginx -v
wget http://nginx.org/download/nginx-1.24.0.tar.gz
tar -xzf nginx-1.24.0.tar.gz
cd nginx-1.24.0
./configure --with-compat --add-dynamic-module=/usr/local/src/ngx_brotli
make modules
cp objs/ngx_http_brotli_filter_module.so /etc/nginx/modules/
cp objs/ngx_http_brotli_static_module.so /etc/nginx/modules/

# Альтернатива для Debian/Ubuntu:
# add-apt-repository ppa:ondrej/nginx
# apt update
# apt install libnginx-mod-http-brotli

Конфігурація nginx для Бітрікс

# /etc/nginx/nginx.conf — в блоці http
load_module modules/ngx_http_brotli_filter_module.so;
load_module modules/ngx_http_brotli_static_module.so;

http {
    # Brotli динамічне стиснення
    brotli on;
    brotli_comp_level 6;
    brotli_types
        text/html
        text/css
        text/javascript
        application/javascript
        application/json
        application/xml
        text/xml
        image/svg+xml
        font/woff2;

    # Статичні pre-compressed файли
    brotli_static on;

    # Gzip як fallback для браузерів без Brotli
    gzip on;
    gzip_comp_level 6;
    gzip_types text/html text/css application/javascript;
    gzip_vary on;
}

brotli_static on — nginx шукає файл assets/app.js.br поруч з assets/app.js. Якщо знайдено, віддає готовий архів без витрат CPU. Це особливо корисно для статики Бітрікс — JS-бандлів та CSS-збірок, які рідко змінюються.

Pre-compressed файли для статики Бітрікс

Для CSS/JS бандлів готуємо .br-файли заздалегідь:

# Встановлюємо brotli CLI та стискаємо всі JS/CSS
apt install brotli
find /var/www/bitrix/public -name "*.js" -o -name "*.css" | while read f; do
    brotli --best --keep "$f"
done

Додаємо в деплой-скрипт: після збірки фронтенду автоматично генеруємо .br-файли.

Перевірка роботи

curl -sI -H "Accept-Encoding: br" https://site.ru/bitrix/js/main/core/core.js | grep -i content-encoding
# Очікувана відповідь: Content-Encoding: br

curl -s -H "Accept-Encoding: identity" https://site.ru/css/app.css | wc -c
curl -s -H "Accept-Encoding: br" https://site.ru/css/app.css | wc -c

Apache mod_brotli

Якщо Бітрікс працює на Apache без nginx-фронтенду:

LoadModule brotli_module modules/mod_brotli.so

<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript
    BrotliCompressionLevel 6
</IfModule>

mod_brotli входить в Apache 2.4.26+. На старих серверах Бітрікс-оточення (Apache 2.2) Brotli недоступний — потрібен апгрейд або перехід на nginx.

Що входить в роботу з налаштування?

Наші спеціалісти з досвідом понад 5 років та 40+ проектами на Бітрікс виконують:

Терміни — від 1 до 3 днів залежно від складності інфраструктури. Вартість розраховується індивідуально після попередньої оцінки. Зв'яжіться з нами для безкоштовної консультації — обговоримо ваш сервер і підберемо оптимальну конфігурацію. Замовте налаштування Brotli та отримайте гарантований результат.

Які типові помилки виникають при налаштуванні Brotli?

• Пропущений модуль brotli_static. Якщо не включена опція brotli_static on, nginx не буде шукати pre-compressed файли, і статика стискатиметься динамічно, навантажуючи CPU.
• Неправильні MIME-типи. Не вказані image/svg+xml або font/woff2 — вони залишаться без стиснення. Перевірте повний список у конфігурації.
• Забутий fallback Gzip. Браузери без підтримки Brotli (застарілі) не отримають стиснений контент. Завжди вмикайте gzip on з gzip_vary on.
• Високий рівень стиснення для динаміки. Рівень 11 збільшує затримку компресії. Для динамічних сторінок достатньо 6.

На Бітрікс-проектах зазвичай комбінують Brotli для сучасних браузерів і Gzip для fallback. Це дає максимальне покриття без втрати продуктивності.

Чому варто довірити налаштування нам?

Ми впроваджуємо Brotli з гарантією вимірюваного приросту швидкості: ви отримаєте графіки порівняння до та після. На рахунку команди — десятки успішних кейсів прискорення сайтів на 1С-Бітрікс. У роботі використовуємо лише офіційні репозиторії (див. Wikipedia та GitHub). Жодних сторонніх скриптів — лише перевірені інструменти. Залиште заявку на аудит інфраструктури та отримайте індивідуальну конфігурацію.

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 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.