Налаштування gzip-стиснення для 1С-Бітрікс: прискорення та економія

Gzip — перше, що перевіряє аудитор PageSpeed після встановлення Бітрікс. Ми часто бачимо: він не налаштований зовсім або налаштований неправильно. Стискається HTML, але не JS і CSS, або compression level виставлено на максимум і жере CPU без відчутної користі. Типовий HTML сторінки каталогу — 80–200 КБ, після Gzip 6 — 15–35 КБ. Економія 75–80% трафіку на кожен некешований HTML-запит. Для магазину з 10 000 відвідувачів на день це суттєво знижує навантаження на сервер і покращує LCP. Ми вже допомогли більш ніж 500 проєктам налаштувати стиснення — досвід понад 10 років.

Хочете налаштувати gzip правильно? Замовте аудит і налаштування — типовий проєкт займає від 2 до 4 годин, вартість розраховується індивідуально.

Як gzip впливає на швидкість завантаження?

Стиснення зменшує об'єм переданих даних. Для HTML — у 4-6 разів, для CSS/JS — у 3-5 разів. Наприклад, сторінка каталогу без стиснення важить 180 КБ, зі стисненням — 25 КБ. На мобільному інтернеті це дає економію 3-5 секунд завантаження. Gzip підтримується всіма сучасними браузерами, і пошуковики враховують швидкість як фактор ранжування.

Порівняння: gzip_static vs динамічне стиснення

Статичне pre-gzip (gzip_static) у 3 рази менш затратне по CPU, ніж динамічне стиснення, оскільки файли стискаються один раз при деплої. Динамічне стиснення обробляє кожен запит, що при рівні 6 дає відмінне стиснення, але навантажує CPU. Для статичних ресурсів (CSS, JS) gzip_static є кращим. Ось таблиця порівняння:

Ефективність стиснення за типами контенту

Чому gzip static кращий для високонавантажених проєктів?

На проєктах з мільйонами запитів до статики навантаження CPU від динамічного стиснення може становити 10–15% всіх ресурсів. gzip_static повністю знімає його. В одному з наших проєктів (каталог 1 млн товарів) перехід на gzip_static знизив CPU з 60% до 35%, а швидкість відповіді статики скоротилася на 200 мс. Отримайте консультацію, якщо хочете впровадити gzip_static на своєму проєкті.

Як налаштувати gzip в nginx: покрокова інструкція

Стандартна установка Бітрікс через setup.sh налаштовує базовий Gzip, але часто пропускає важливі MIME-типи і не включає gzip_vary.

Крок 1: Базова конфігурація

Повна конфігурація в блоці http або server:

gzip on;
gzip_disable "msie6";

gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 1024;

gzip_types
    text/plain
    text/css
    text/xml
    text/javascript
    application/javascript
    application/x-javascript
    application/json
    application/xml
    application/xml+rss
    application/rss+xml
    application/atom+xml
    image/svg+xml
    font/ttf
    font/otf
    application/vnd.ms-fontobject;

gzip_vary on — критично важливий при наявності CDN або проксі. Додає заголовок Vary: Accept-Encoding, щоб кеші не віддавали стислий контент браузерам без підтримки Gzip.

gzip_min_length 1024 — не стискаємо файли менше 1 КБ. Overhead Gzip-заголовків і CPU-витрати не виправдані для маленьких відповідей.

gzip_comp_level 6 — рівні 7–9 дають менше 2% додаткового стиснення при 2–3x рості CPU. Рівень 1–2 швидкий, але стискає на 15–20% гірше. Згідно з тестами, рівень 6 дає найкраще співвідношення стиснення та продуктивності.

Крок 2: Включення gzip_static

gzip_static on; — при запиті app.js nginx шукає app.js.gz. Якщо знайдено — віддає без витрат CPU на компресію.

Генерація .gz-файлів у деплой-скрипті:

find /var/www/site/public/build -name "*.js" -o -name "*.css" | xargs -P4 -I{} gzip -k -6 {}

Крок 3: Перевірка подвійного стиснення

Бітрікс вміє стискати відповідь через PHP (ob_gzhandler). Якщо увімкнено і в PHP, і в nginx — браузер отримує двічі стислий контент. Перевіряємо в php.ini або bitrix/php_interface/dbconn.php — zlib.output_compression має бути Off. В налаштуваннях Бітрікс: «Налаштування → Налаштування продукту → Стиснення сторінок» вимкнути, якщо стиснення робить nginx.

Що обрати: gzip_static чи динамічне стиснення на Apache?

На серверах з nginx (рекомендація Бітрікс) конфігурація простіша і продуктивніша — одноразове стиснення, статичне pre-gzip. Apache вимагає модуль mod_deflate, який завантажує більше CPU. На shared-хостингах вибір зазвичай обмежений. У будь-якому випадку, gzip має бути увімкнено на стороні веб-сервера, а не через PHP.

Конфігурація Apache

Для серверів Бітрікс на Apache (bitrix-env використовує nginx як фронтенд, але на shared-хостингах часто чистий Apache):

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml
    AddOutputFilterByType DEFLATE text/css application/javascript
    AddOutputFilterByType DEFLATE application/json application/xml
    AddOutputFilterByType DEFLATE image/svg+xml font/ttf

    DeflateCompressionLevel 6

    # Не стискати вже стислі формати
    SetEnvIfNoCase Request_URI \.(?:gif|jpg|jpeg|png|zip|gz|br)$ no-gzip dont-vary

    Header append Vary Accept-Encoding
</IfModule>

Типові помилки конфігурації Бітрікс

Подвійне стиснення через PHP і nginx. Ми вже згадували — вимикаємо zlib.output_compression.

Відсутність gzip_proxied any — якщо сайт за балансувальником або CDN, nginx без цієї директиви не стискає відповіді для проксованих запитів (заголовок Via присутній).

application/json не в списку. Відповіді API Бітрікс (компоненти, що працюють в режимі AJAX) повертають JSON. Без стиснення JSON-відповіді каталогу з 50 товарами важать 40–80 КБ, зі стисненням — 8–15 КБ.

Перевірка стиснення

# Перевіряємо стиснення відповіді
curl -sI -H "Accept-Encoding: gzip" https://site.ru/ | grep -i content-encoding
# Content-Encoding: gzip

# Порівнюємо розміри
curl -s --compressed https://site.ru/ | wc -c
curl -s -H "Accept-Encoding: identity" https://site.ru/ | wc -c

Інструмент Check GZIP compression на GiftOfSpeed показує стиснення для будь-якого URL разом з економією в байтах.

Що входить у нашу послугу з налаштування gzip

• Аудит поточної конфігурації сервера та Бітрікс.
• Налаштування gzip на nginx або Apache з перевіркою всіх MIME-типів.
• Оптимізація рівня стиснення та кешування.
• Налаштування gzip_static для статичних ресурсів.
• Перевірка подвійного стиснення, коригування PHP та Бітрікс.
• Тестування через PageSpeed, GTmetrix та curl.
• Документація щодо внесених змін.
• Консультація та підтримка протягом тижня після налаштування.

Ми гарантуємо результат: прискорення завантаження в тестах на 30-400% (залежно від поточного стану). Якщо ви сумніваєтеся в налаштуваннях — зв'яжіться з нами, оцінимо проєкт безкоштовно. Отримайте консультацію з налаштування gzip для вашого Бітрікс-проєкту.

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