Boost Your 1C-Bitrix Site: Slash TTFB from 1.2s to 200ms

We see a typical picture after several years of Bitrix project development: TTFB 800-1200 ms, Largest Contentful Paint over 4 seconds, PageSpeed Insights in the red zone. The causes are usually not in the hosting — they are inside the application itself: uncached components, unoptimized infoblock queries, 200+ HTTP requests per page due to unbundled JS/CSS, and uncompressed images uploaded at original resolution. According to Google, increasing LCP from 2.5 to 5 seconds raises bounce probability by 90%. For a Bitrix store with a monthly turnover of 1 million rubles, each second of delay can cost 200-300 thousand rubles in lost sales. Practice shows that comprehensive 1C-Bitrix optimization is not a single action but a sequential elimination of several problem classes. Order matters: server side first, then frontend. With a proper approach, we can reduce TTFB by 3-5 times in the first week, and PageSpeed moves from red to green. Recently on a project with 15,000 SKUs, we lowered TTFB from 1.4s to 180ms in one week — details in the case study. Our optimization services are priced on request and pay off quickly through increased conversion. Our company has been working with Bitrix for over 10 years and has completed more than 200 optimization projects. Assess your project — contact us.

Price of a Slow Site: Impact on Conversion and SEO

Loading speed directly affects conversion and search rankings. 53% of users leave if a page takes longer than 3 seconds. For Bitrix online stores, each second of catalog loading can cost thousands of rubles. After optimization, our clients record a 20-30% increase in mobile traffic conversion.

Server Side: Cache, Queries, Agents

Component caching is the first step in any audit. In Bitrix, each component manages its cache via the CACHE_TYPE and CACHE_TIME parameters. Often developers set CACHE_TYPE = N (no cache) during debugging and forget to revert. One such component on the homepage multiplies TTFB.

Check via \Bitrix\Main\Diag\Debug::dumpToFile() or the bitrix.performance module to list uncached components and their execution time. The standard tool is the performance panel (/bitrix/admin/perfmon_panel.php).

Database query optimization. Infoblocks in Bitrix, when used carelessly, generate queries like SELECT * on b_iblock_element, b_iblock_element_property, b_iblock_section without field limits. Switching to D7 API (Iblock\ElementTable) with explicit select reduces data transfer and MySQL load. A separate issue is the N+1 problem: a component in a loop makes a query for each element. Detected via $DB->ShowSqlStat() or MySQL slow query log with long_query_time = 0.1. Query caching improves TTFB 2-4 times faster than uncontrolled execution.

Agents and background tasks. Bitrix agents by default run in the context of a web request if cron mode is not configured. This adds 50-300 ms to random requests. Moving agents to cron (/bitrix/modules/main/tools/cron_events.php) eliminates this delay entirely.

How Composite Mode Accelerates a Site and When It Doesn't Help

Composite mode caches HTML pages in the file system and serves them without executing PHP, replacing dynamic blocks (cart, authorization) via AJAX. For content and catalog pages, it's the most powerful tool — TTFB drops to 20-50 ms. Composite speeds up server response up to 10 times compared to regular PHP.

But composite doesn't work automatically. It requires marking dynamic zones with the bitrix:nocache tag, converting authorization and cart to AJAX components, and setting exclusions for personalized pages. Incorrect configuration leads to cached data for logged-in users — a critical error on projects with personal accounts.

Frontend: HTTP Requests and Resource Weight

After server optimization, we examine the client side via Chrome DevTools → Network. Typical problems of Bitrix projects:

• Unbundled CSS/JS: each module loads its own files separately. On a heavy project, this means 30-80 files. Bitrix can combine them via compression settings (Settings → Performance → Compression), but requires correct path configuration and HTTP/2.
• Unoptimized images: original files from the media library are served without conversion to WebP, without srcset for retina. The resize_image module can crop images on the fly, but without caching the cropped versions, it creates load.
• Missing lazy load: images below the fold load with the initial screen. In Bitrix, this is solved via the loading="lazy" attribute in component templates or JavaScript IntersectionObserver.

Case Study: From TTFB 1.4s to 180ms in One Week

One of our clients — a corporate online store with 15,000 SKUs on Bitrix "Business", VPS 4 CPU / 8 GB RAM. Before optimization: PageSpeed Mobile — 22/100, TTFB — 1.4s, LCP — 5.8s. Customer complaints about slow catalog loading.

Audit findings:

• 4 components with CACHE_TYPE = N on the homepage (left by developer during debugging)
• N+1 in the "similar products" component — 48 queries per product page
• Agents in web mode, 11 agents running synchronously
• 94 HTTP requests on the homepage (CSS/JS not bundled)
• Images in JPEG without WebP, average size 340 KB

Work sequence:

1. Fix component caching → TTFB: 1.4s → 380ms
2. Optimize N+1, migrate to D7 API → queries per product page: 48 → 6
3. Move agents to cron → eliminated 80-200ms latency
4. Bundle CSS/JS → HTTP requests: 94 → 18
5. WebP via CFile::ResizeImageGet() + lazy load → average page weight: 2.8 MB → 680 KB
6. Configure composite mode for catalog and homepage

Result: PageSpeed Mobile 71/100, TTFB 180ms, LCP 2.1s. Mobile traffic conversion increased — users stopped leaving slow catalog pages. Composite sped up TTFB by 10x compared to initial state.

DIY Diagnostics Tools

Before contacting specialists, you can check:

• /bitrix/admin/perfmon_panel.php — built-in Bitrix performance panel
• MySQL slow query log (long_query_time = 1) — slow queries
• Chrome DevTools → Lighthouse — frontend overview
• For Bitrix: php bitrix/modules/main/tools/cron_events.php to check agents

For more on web application performance, see Wikipedia.

Comparison of Optimization Methods

What's Included

• Full performance audit with report on each bottleneck
• Fix component caching and configure tagged cache
• Optimize database queries (migrate to D7, eliminate N+1)
• Set up composite mode with dynamic zone markup
• Frontend optimization: CSS/JS bundling, WebP, lazy load, minification
• Move agents to cron and monitor their execution
• Load testing and metric recording
• Maintenance documentation for achieved speed

Stages and Timeframes

Timeframes are approximate and depend on custom code volume. We recommend regular audits. We guarantee an objective assessment and transparent work plan. Get a consultation — tell us about your project, and we will choose the optimal solution. Contact us to order an audit. Закажите услуги по оптимизации Bitrix: ускорение сайта, настройка кеширования, композитного режима, оптимизация изображений и HTTP-запросов.