Brotli Compression for 1C-Bitrix: Step-by-Step Setup on nginx and Apache

A 1C-Bitrix site with a catalog of 50,000 products is a typical case where Gzip is already enabled but pages still load in 4–5 seconds on 3G. Enabling Brotli for 1C-Bitrix reduces response size by up to 20% without changing a single line of code. The Brotli setup for 1C-Bitrix is straightforward with our guide. For CSS and JS the difference is even more noticeable: a 400 KB bundle after Gzip is 110 KB, after Brotli — 90–95 KB. On slow connections this saves seconds, cuts traffic costs by up to 30%, and improves e‑commerce conversion rates. Traffic savings can reach 30%, which with high traffic gives significant cost reduction. For a typical Bitrix site with 100 GB monthly traffic, Brotli can save approximately $50/month on CDN costs, totaling $600 annually. We implement Brotli on projects from landing pages to complex catalogs and always get a measurable speed boost.

According to Google documentation, Brotli provides 20% better compression than Gzip for text content. CDN traffic savings reach 20%.

Why Brotli is more effective than Gzip

The Brotli algorithm uses LZ77 and Huffman coding with a 120 KB static dictionary, unlike Gzip's 32 KB, giving an advantage on repetitive data. A typical Bitrix HTML template with repeating classes and comments compresses 18% tighter. The cost is slightly higher compression time at high levels. We recommend brotli_comp_level 6 for dynamic content: a balance between compression and CPU load. Level 11 (+5–8% compression) is justified only for pre-compressed static files. Brotli at level 6 compresses HTML 1.1 times better than Gzip level 6, and at level 11 it is 1.2 times better.

Comparison table:

How to set up Brotli for 1C-Bitrix

Step-by-step guide

1. Install the ngx_brotli module
2. Configure nginx
3. Prepare pre-compressed static files
4. Verify it works

Installing the Brotli module for nginx

Nginx does not support Brotli out of the box — you need the ngx_brotli module. Two options:

# Compile from source or use a ready package
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/

# Alternative for Debian/Ubuntu:
# add-apt-repository ppa:ondrej/nginx
# apt update
# apt install libnginx-mod-http-brotli

nginx configuration for Bitrix

# /etc/nginx/nginx.conf — in the http block
load_module modules/ngx_http_brotli_filter_module.so;
load_module modules/ngx_http_brotli_static_module.so;

http {
    # Brotli dynamic compression
    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;

    # Static pre-compressed files
    brotli_static on;

    # Gzip as fallback for browsers without Brotli
    gzip on;
    gzip_comp_level 6;
    gzip_types text/html text/css application/javascript;
    gzip_vary on;
}

brotli_static on — nginx looks for assets/app.js.br next to assets/app.js. If found, it serves the pre-compressed archive without CPU cost. This is especially useful for Bitrix static — JS bundles and CSS builds that rarely change.

Pre-compressed files for Bitrix static

Prepare .br files for CSS/JS bundles in advance:

# Install brotli CLI and compress all JS/CSS
apt install brotli
find /var/www/bitrix/public -name "*.js" -o -name "*.css" | while read f; do
    brotli --best --keep "$f"
done

Add to your deploy script: after frontend build, automatically generate .br files.

Verification

curl -sI -H "Accept-Encoding: br" https://site.ru/bitrix/js/main/core/core.js | grep -i content-encoding
# Expected response: 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

If Bitrix runs on Apache without an nginx frontend:

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 is included in Apache 2.4.26+. On older Bitrix environment servers (Apache 2.2) Brotli is not available — an upgrade or migration to nginx is needed.

What's included in the setup

Our specialists, with over 5 years of experience and 40+ Bitrix projects, deliver:

1. Audit – Check web server configuration, software versions, permissions. Result: list of required changes.
2. Module installation – Compile or install ngx_brotli package. Result: module added to nginx.
3. Compression setup – Configure brotli, gzip fallback, pre-compressed static. Result: working compression on all content types.
4. Testing – Check with curl, PageSpeed, VPN emulation of slow networks. Result: before/after metrics report.
5. Documentation – Deploy instructions, compression level recommendations. Result: delivered artifacts.
6. Support – Monitoring for 2 weeks. Result: stable operation.

Deliverables include configuration files, documentation, and 2 weeks of support. Timeline: 1 to 3 days depending on infrastructure complexity. Cost is calculated individually after a preliminary assessment. For a basic nginx configuration, setup cost starts from $200. Contact us for a free consultation — we will discuss your server and select the optimal configuration. Order Brotli setup and get a guaranteed result.

Common mistakes when setting up Brotli

• Missing brotli_static module. If brotli_static on is not set, nginx will not look for pre-compressed files and will compress dynamically, loading the CPU.
• Wrong MIME types. image/svg+xml or font/woff2 not included — they remain uncompressed. Check the full list in the configuration.
• Missing Gzip fallback. Browsers without Brotli support (older ones) will not get compressed content. Always enable gzip on with gzip_vary on.
• High compression level for dynamic content. Level 11 increases compression latency. For dynamic pages level 6 is sufficient.

On Bitrix projects we typically combine Brotli for modern browsers and Gzip for fallback. This gives maximum coverage without performance loss. For Brotli setup on 1C-Bitrix, our team follows a step-by-step approach: first we install the module, then configure nginx, and finally test.

Why trust us with the setup

We implement Brotli with a guarantee of measurable speed improvement: you will get before/after comparison graphs. The team has dozens of successful acceleration cases for 1C-Bitrix sites. We only use official repositories (see Wikipedia and GitHub). No third-party scripts — only proven tools. Submit a request for an infrastructure audit and get a personalized configuration.

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.