Website Speed Optimization on 1C-Bitrix: Reducing TTFB to 200 ms
An online store on Bitrix loaded the catalog page in 5 seconds; Google PageSpeed showed TTFB of 1.2 seconds. The client was losing 30% of conversions. After comprehensive optimization, TTFB dropped to 180 ms — conversion increased by 15%. Our team has 8 years of experience with Bitrix and has completed over 120 speed optimization projects. Certified specialists guarantee the result.
TTFB is the time from sending an HTTP request to receiving the first byte of the response. It covers pure server time: DNS, TCP connection, SSL handshake plus page generation time. Google PageSpeed considers a good TTFB under 200 ms. A standard Bitrix site without optimization typically has TTFB of 800 ms to 3 seconds.
Why TTFB Matters for Ranking?
Google incorporates TTFB into Core Web Vitals. According to Wikipedia, TTFB directly influences Largest Contentful Paint. For an online store, each extra millisecond means lost customers. We observed on projects where TTFB dropped from 800 to 200 ms, organic traffic increased by 20-25% over three months. Average ROI for TTFB optimization is 2-3 months due to conversion growth.
What Makes Up TTFB in Bitrix
Typical breakdown on a heavy site:
| Stage | Time | What affects |
|---|---|---|
| DNS + TCP + SSL | 20–100 ms | Hosting, CDN, geolocation |
| PHP + Bitrix initialization | 50–150 ms | OPcache, autoload |
| Core loading, modules, prologue | 30–100 ms | Number of modules, includes in init.php |
| SQL queries to DB | 100–2000 ms | Indexes, cache, query optimization |
| Component execution | 50–500 ms | Component cache, template complexity |
| PHP buffer, obfuscator | 10–50 ms | Output settings |
On most projects, 60–80% of TTFB comes from SQL queries. Start there.
OPcache: Basic PHP Optimization
PHP without OPcache compiles every file on every request. A full Bitrix load includes 200–500 PHP files. OPcache caches compiled bytecode:
[opcache] opcache.enable = 1 opcache.memory_consumption = 256 opcache.interned_strings_buffer = 16 opcache.max_accelerated_files = 20000 opcache.validate_timestamps = 0 ; in production — do not check file changes opcache.revalidate_freq = 0 opcache.fast_shutdown = 1 opcache.enable_cli = 0 validate_timestamps = 0 is critical for speed. OPcache then does not see file changes without a reset. After deployment, clear the cache: opcache_reset() or using CacheTool. Without this setting, OPcache calls stat() for every file on every request — hundreds of system calls. max_accelerated_files = 20000 — a typical Bitrix site with standard modules has 5000–15000 PHP files. If the limit is lower, some files may not be cached. Verify via opcache_get_status()['opcache_statistics']['num_cached_scripts'].
Page and Component Caching
The most effective way to reduce TTFB is to avoid generating the page at all and serve cached HTML. Bitrix supports caching at several levels.
Component caching. The $cache_time parameter in .parameters.php. Standard component bitrix:catalog.section caches for one hour. With proper setup, a repeat request requires 5–20 SQL queries instead of 100–300.
Managed cache / composite. Composite Site technology splits the page into cacheable and dynamic parts. The cacheable part (main column, menu) is served immediately; the dynamic part (basket, notification counter) is loaded via AJAX. Properly configured, TTFB for the main HTML drops to 50–100 ms. Enable it at: Settings → Performance → Composite Site. Components are marked as dynamic via CBitrixComponent::setDynamicMode() or parameter DYNAMIC = Y.
HTML cache via nginx. The fastest option — nginx serves static HTML without running PHP. Implemented via nginx FastCGI cache or Varnish in front of Bitrix. Requires correct invalidation when content updates.
How to Quickly Reduce TTFB Without Risk?
If you need to urgently improve Core Web Vitals, start with three steps:
- Enable OPcache with the settings above. TTFB reduction: 100–300 ms.
- Enable composite cache (Composite Site) — TTFB reduction: 300–800 ms.
- Optimize heavy SQL queries via slow query log. TTFB reduction: 200–1500 ms.
These steps require no changes to business logic and can be done in 1–2 days. We test each stage on a staging environment.
How to Measure TTFB Yourself?
For external measurement, use curl: curl -o /dev/null -s -w "Time to first byte: %{time_starttransfer}s\n" <your-site-url>. Take 3–5 measurements; the first may be with a cold cache. For internal profiling, enable Bitrix's performance panel (/bitrix/admin/perfmon_panel.php). It shows total execution time, SQL query time, component time, and number of file operations.
Database: Connection and Queries
Connection establishment time to MySQL is 1–5 ms for local connections. If the database is on a separate server, it's 5–20 ms for TCP connection. Persistent connections (MYSQL_PCONNECT) reuse connections across requests within a PHP-FPM worker.
In /bitrix/php_interface/dbconn.php, enable:
$DBPersistent = true; Persistent connections reduce overhead but increase open connections on the MySQL server. max_connections in my.cnf should exceed the number of PHP-FPM workers multiplied by the number of virtual hosts.
Optimizing Prologue and init.php
Every request executes /bitrix/php_interface/init.php. If it includes heavy classes, SQL queries, or third-party libraries, that adds to every request. Check for includes of files needed only in specific controllers, initialization of third-party SDKs (1C integration, payment systems) on every request, or SQL queries in OnPageStart event handlers. Use lazy-loading via Loader::includeModule() — include modules only where needed.
Economic Effect of Reducing TTFB
Reducing TTFB by 600 ms helped one client increase revenue by 15% due to conversion growth and improved behavioral factors. Average ROI for TTFB optimization is 2-3 months. Another project with a catalog of 50,000 products reduced TTFB from 1.2 s to 180 ms, resulting in a 12% conversion increase. Order a speed audit for your project — we will assess current performance and propose a work plan. Contact us for a consultation to get started.