Gzip Compression for Bitrix: Performance & Bandwidth Savings

Gzip is the first thing a PageSpeed auditor checks after a Bitrix installation. We often see it either completely disabled or incorrectly configured. HTML is compressed, but JS and CSS are not, or the compression level is set to maximum, eating CPU without noticeable benefit. A typical catalog HTML page is 80–200 KB; after gzip level 6, it drops to 15–35 KB. That's a 75–80% traffic savings on every non-cached HTML request. For a store with 10,000 daily visitors, this significantly reduces server load and improves LCP. We have helped over 500 projects configure compression — with more than 10 years of experience.

Want to configure gzip correctly? Order an audit and setup — a typical project takes 2–4 hours, cost is calculated individually.

How Gzip Affects Load Speed

Compression reduces the amount of data transferred. For HTML — 4–6 times smaller, for CSS/JS — 3–5 times. For example, a catalog page without compression weighs 180 KB, with compression — 25 KB. On mobile internet, this saves 3–5 seconds of load time. Gzip is supported by all modern browsers, and search engines consider speed as a ranking factor.

Comparison: gzip_static vs Dynamic Compression

Static pre-gzip (gzip_static) is 3 times less CPU-intensive than dynamic compression because files are compressed once at deploy time. Dynamic compression processes every request; at level 6, it offers excellent compression but loads CPU. For static resources (CSS, JS), gzip_static is preferable. Here is a comparison table:

Compression Efficiency by Content Type

Why gzip_static is Better for High-Load Projects

On projects with millions of static file requests, the CPU load from dynamic compression can be 10–15% of total resources. gzip_static removes it entirely. In one of our projects (a catalog with 1 million products), switching to gzip_static reduced CPU from 60% to 35%, and static response time dropped by 200 ms. Get a consultation if you want to implement gzip_static on your project.

How to Configure Gzip in nginx: Step-by-Step Guide

The standard Bitrix installation via setup.sh sets up basic gzip, but often misses important MIME types and does not enable gzip_vary.

Step 1: Basic Configuration

Complete configuration in the http or server block:

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 — critical when using a CDN or proxy. Adds the Vary: Accept-Encoding header so that caches don't serve compressed content to browsers without gzip support.

gzip_min_length 1024 — do not compress files smaller than 1 KB. The overhead of gzip headers and CPU is not justified for small responses.

gzip_comp_level 6 — levels 7–9 give less than 2% additional compression at 2–3x CPU cost. Level 1–2 is fast but compresses 15–20% worse. According to tests, level 6 offers the best ratio of compression to performance.

Step 2: Enabling gzip_static

gzip_static on; — when requesting app.js, nginx looks for app.js.gz. If found, it serves it without CPU cost for compression.

Generation of .gz files in deploy script:

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

Step 3: Check for Double Compression

Bitrix can compress responses via PHP (ob_gzhandler). If both PHP and nginx compression are enabled, the browser receives doubly compressed content. Check php.ini or bitrix/php_interface/dbconn.php — zlib.output_compression should be Off. In Bitrix settings: "Settings → Product Settings → Page Compression" should be disabled if nginx handles compression.

What to Choose: gzip_static or Dynamic Compression on Apache?

On servers with nginx (Bitrix recommendation), configuration is simpler and more efficient — one-time compression, static pre-gzip. Apache requires the mod_deflate module, which uses more CPU. On shared hosting, the choice is usually limited. In any case, gzip should be enabled at the web server level, not through PHP.

Apache Configuration

For Bitrix servers on Apache (bitrix-env uses nginx as frontend, but on shared hosting often pure 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

    # Don't compress already compressed formats
    SetEnvIfNoCase Request_URI \.(?:gif|jpg|jpeg|png|zip|gz|br)$ no-gzip dont-vary

    Header append Vary Accept-Encoding
</IfModule>

Common Bitrix Configuration Mistakes

Double compression via PHP and nginx. We already mentioned it — disable zlib.output_compression.

Missing gzip_proxied any — if the site is behind a load balancer or CDN, nginx without this directive does not compress responses for proxied requests (the Via header is present).

application/json not in the list. Bitrix API responses (components working in AJAX mode) return JSON. Without compression, JSON responses for a catalog with 50 items weigh 40–80 KB; with compression, 8–15 KB.

Checking Compression

# Check response compression
curl -sI -H "Accept-Encoding: gzip" https://site.ru/ | grep -i content-encoding
# Content-Encoding: gzip

# Compare sizes
curl -s --compressed https://site.ru/ | wc -c
curl -s -H "Accept-Encoding: identity" https://site.ru/ | wc -c

The Check GZIP compression tool at GiftOfSpeed shows compression for any URL along with byte savings.

What's Included in Our Gzip Setup Service

• Audit of current server and Bitrix configuration.
• Gzip setup on nginx or Apache with verification of all MIME types.
• Optimization of compression level and caching.
• Setting up gzip_static for static resources.
• Checking for double compression, adjusting PHP and Bitrix.
• Testing via PageSpeed, GTmetrix, and curl.
• Documentation of changes made.
• Consultation and support for one week after setup.

We guarantee results: load time improvement in tests by 30-400% (depending on current state). If you're unsure about your configuration, contact us for a free project assessment. Get a consultation on gzip setup for your Bitrix project.

80% of Bitrix sites slow down due to one table

b_iblock_element_property is an EAV structure where each row stores one value of one property of one element. A catalog of 50,000 products with 30 properties yields 1.5 million rows. The smart filter performs a JOIN of this table with b_iblock_element on five properties, and MySQL performs a full table scan for 3–5 seconds. Our experience shows that without intervention in this table, site acceleration is impossible. We take on projects where load time has dropped to 8–10 seconds and bring TTFB back to <200 ms within 1–2 weeks. Site speed optimization begins with an audit of slow queries and ends with a comprehensive turnkey infrastructure overhaul.

Contact us for an audit — we will identify bottlenecks within 2 hours and propose a concrete plan.

How to achieve TTFB below 200 ms?

Server optimization is the first step. Nginx configuration goes beyond simple gzip. Specifically:

• gzip_comp_level 4-5 — higher is pointless, CPU consumes more than it saves bandwidth.
• brotli on with brotli_static on for precompressed files.
• HTTP/2 with http2_max_concurrent_streams 128.
• fastcgi_cache for PHP responses — caching at Nginx level, bypassing PHP-FPM entirely.
• worker_processes auto, worker_connections according to the number of simultaneous connections.

PHP-FPM tuning: choose between pm = dynamic and pm = static. Static mode works best for dedicated servers with predictable load because it avoids forking overhead. Dynamic saves RAM under low traffic. Calculate pm.max_children as (available RAM - RAM for MySQL/Redis) / average process consumption. For OPcache set memory_consumption=256, max_accelerated_files=20000, and validate_timestamps=0 in production (restart PHP-FPM on deploy).

MySQL/MariaDB: the main bottleneck is almost always the database. Enable slow_query_log with a threshold of 0.5 sec and analyze every query via EXPLAIN. Set innodb_buffer_pool_size to 70–80% of available RAM on a dedicated server. Create composite indexes for faceted search: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) on b_iblock_element_property. Run OPTIMIZE TABLE b_iblock_element_property after mass operations.

How to configure three-level caching?

Managed component cache. Set TTL individually for each component. Catalog — 3600 sec, news feed — 300 sec, banners — 86400. The same TTL everywhere guarantees either outdated data or useless cache.

Composite cache. The bitrix:composite technology lets Nginx serve ready HTML from a file; PHP is not executed. Dynamic zones (cart, authorization) are loaded via AJAX request through CBitrixComponent::setFrameMode(true). TTFB drops below 50 ms. However, not all components are compatible; $APPLICATION->ShowPanel() and direct output via echo break the composite. We check every page through the panel 'Performance → Composite Site'. According to Bitrix official documentation on composite cache, this is the most effective caching method for high‑load projects.

Comparison: composite cache is 10–20 times faster than managed cache in time to first byte.

Memcached / Redis. Transfer cache from the file system: sessions go to Redis (session.save_handler = redis) — 10–50 times faster than files, plus cluster support. Component cache goes to Memcached via .settings.php: 'cache' => ['type' => 'memcache']. Also enable ORM query cache so identical GetList() calls don't hit MySQL on every request.

What is the fastest way to optimize Bitrix database?

Default MySQL settings are insufficient. Indexes — composite for faceted search, covering for frequent queries. MySQL responds from the index without accessing the data. Partial indexes (MariaDB) for filtering by ACTIVE = 'Y'. Audit unused indexes — each slows down INSERT/UPDATE.

Partitioning. For tables with millions of rows: b_stat_session, b_search_content_stem, and highload-blocks with history. Partition by date — a query for 'orders in a month' does not scan three years of data. Partitioning also solves the problem of concurrent queries during exchange with 1С via CommerceML.

Real case: a catalog of 200,000 products, 50 properties. Filtering by 10 properties took 12 seconds. After creating composite indexes on (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) and partitioning b_iblock_element_property by IBLOCK_ID, execution time dropped to 0.3 seconds. MySQL load decreased by 40 times.

Cleanup. Over a year or two, any database accumulates: outdated search index, expired records in b_cache_tag, history in b_iblock_element_prop_s*, logs in b_event_log taking gigabytes. We set up regular cleanup via agents.

Frontend and CDN

Images account for 60–80% of page weight. Convert to WebP via CFile::ResizeImageGet() with BX_RESIZE_IMAGE_PROPORTIONAL + conversion. Use srcset + sizes — never load a 3000px image into a 400px block. Add loading="lazy" for everything below the fold. AVIF offers another 20–30% savings vs WebP.

CSS/JS optimization: use the built-in Bitrix module to merge and minify via 'Settings → CSS/JS Optimization'. Apply PurgeCSS / UnCSS — in a typical Bitrix project, 60–70% of CSS is unused. Use defer / async for non‑critical JS and inline critical CSS in <head> for instant FCP.

Fonts: add <link rel="preload" as="font" crossorigin> for the main font. Set font-display: swap — text visible immediately. Subset via pyftsubset — keep only Cyrillic + Latin, file size reduces by 3–5 times.

CDN: Cloudflare, BunnyCDN, AWS CloudFront, or Russian providers (Selectel CDN, VK Cloud CDN). Serve static assets (CSS, JS, images, fonts) via CDN with Cache-Control: public, max-age=31536000, immutable for files with a hash. Use on‑the‑fly image optimization (imgproxy, Cloudflare Polish) without load on origin.

Why is load testing necessary?

Not synthetic benchmarks, but real scenarios: k6 / wrk to simulate routes — catalog → filtering → product card → cart → checkout. Measure RPS, response time (p50, p95, p99), error rate. Use Xdebug (callgrind) or Blackfire for PHP profiling to find bottlenecks. The test result gives an objective picture of where it actually slows down, not where it 'seems'. After optimization, run again to record improvements.

Results

What is included in the work?

1. Current performance audit — analysis of slow queries, PHP profiling, check of caching, CDN, server settings.
2. Server configuration — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Caching optimization — managed cache, composite site, TTL configuration, tagged caching.
4. Database work — index creation, partitioning, cleanup, EAV table reorganization.
5. Frontend — images (WebP/AVIF), CSS/JS (minification, deferred), fonts (preload, subsetting).
6. CDN — connection, caching rule setup.
7. Load testing — real user scenarios, metric report.
8. Documentation — description of all changes, recommendations for further maintenance.
9. Guarantee — support for 1 month after delivery, ensuring all optimizations are stable.

Monitoring

Without monitoring, everything degrades in six months. A new module, uncleared logs, a template change — and speed returns to original. Use web-vitals API for Real User Monitoring from actual visitors. Set up synthetic monitoring with Pingdom or UptimeRobot for regular checks from different locations. Configure alerts — TTFB > 500 ms or LCP > 3 sec triggers notification.

Timelines and cost

Cost is calculated individually after the audit. Get a consultation for your project — we will evaluate the current state and propose an acceleration plan with specific timelines and budget. We are a team with 12+ years of experience in Bitrix, having completed over 300 site speed optimization projects. Contact us to start the performance audit today.