Optimizing 1C-Bitrix Page Rendering: Diagnosis & Solutions

We've encountered cases where PageSpeed Insights scores 38 with an LCP of 4.2 seconds. TTFB is 1.8 s, and the full content is already in the HTML. The issue isn't the network or client-side JS—the page is slow to generate on the server. Bitrix's diagnostic tools exist but are rarely used correctly.

Our competencies:

Frequently Asked Questions

We've encountered cases where PageSpeed Insights scores 38 with an LCP of 4.2 seconds. TTFB is 1.8 s, and the full content is already in the HTML. The issue isn't the network or client-side JS—the page is slow to generate on the server. Bitrix's diagnostic tools exist but are rarely used correctly. TrueTech has 10+ years of Bitrix experience and has completed 50+ optimization projects. Our experience shows that in 80% of cases, the bottleneck is suboptimal caching or N+1 queries in templates. Catalog pages with hundreds of products are especially vulnerable—SQL queries can exceed 400. Without a systematic approach, fixing one bottleneck may have no effect if caching isn't enabled at all levels. Optimizing 1C-Bitrix page rendering requires a comprehensive audit and sequential actions. One client saved $500/month in server costs after optimization.

Why Is 1C-Bitrix Page Rendering Slow?

Main causes:

  • Components working with inconsistent caching mode (CACHE_TYPE=N).
  • Loops in templates generating N+1 SQL queries.
  • Tagged caching disabled.
  • Composite mode not configured.
  • Bitrix agents not optimized.

How to Diagnose Slow Bitrix Page Rendering?

A four-step diagnostic algorithm:

  1. Enable the debug panel: constants SHOW_PAGE_EXEC_TIME and SHOW_SQL_STAT in dbconn.php.
  2. Analyze SQL query count and execution time—normal is up to 100 queries in 0.5 s.
  3. Identify components without cache or with CACHE_TYPE=N.
  4. Check for N+1 queries in templates (e.g., GetByID calls inside loops).

Diagnosis via standard Bitrix tools

Enable the debug panel:

$_GET["show_page_exec_time"] or constant: define('SHOW_PAGE_EXEC_TIME', true); define('SHOW_SQL_STAT', true); 

The panel in the page footer shows:

  • total execution time
  • SQL query count and total time
  • memory consumption

Typical problematic page: 400+ SQL queries, 1.5–2.5 s on SQL vs 0.3 s on PHP. Components run with inconsistent caching modes. 1C-Bitrix documentation recommends tagged caching to speed up pages.

What are N+1 queries and how to eliminate them?

The most common cause of 400+ queries is a loop over results with an inner query. This is known as the N+1 query problem.

// Bad: query per item foreach ($arResult['ITEMS'] as &$item) { $item['SECTION'] = \CIBlockSection::GetByID($item['IBLOCK_SECTION_ID'])->GetNext(); } 

Fix with an aggregated query before the loop:

$sectionIds = array_unique(array_column($arResult['ITEMS'], 'IBLOCK_SECTION_ID')); $sections = []; $res = \CIBlockSection::GetList([], ['ID' => $sectionIds], false, ['ID', 'NAME', 'CODE']); while ($s = $res->GetNext()) { $sections[$s['ID']] = $s; } foreach ($arResult['ITEMS'] as &$item) { $item['SECTION'] = $sections[$item['IBLOCK_SECTION_ID']] ?? null; } 

Which profiling tools to use?

Bitrix lacks a built-in component-level profiler. The simplest way is to install the Bitrix Performance Monitor module from Marketplace. Alternatively, use xhprof/Tideways with a custom wrapper. For a quick estimate, you can add a handler in init.php that outputs the 10 slowest components, but this requires caution. For advanced profiling, consider using APCu or Redis for caching to improve Bitrix SQL optimization.

How to configure composite mode?

Composite mode is a built-in Bitrix mechanism that caches entire pages and replaces dynamic blocks (cart, auth) via AJAX. It gives TTFB of 50–100 ms for authorized users. However, composite requires template adaptation—it cannot be enabled with a button without component adjustments. We recommend it for projects with high speed requirements.

Composite setup step-by-step:

  1. Enable composite in the admin panel: "Settings" → "Product Settings" → "Composite Site".
  2. Ensure all dynamic blocks (cart, login form) are moved to deferred functions or AJAX widgets.
  3. Configure exceptions for pages that should not be cached (e.g., checkout page).
  4. Test with composite enabled for administrators.

Optimizing Bitrix LCP acceleration involves focusing on server-side rendering. Bitrix agents can also cause delays if not configured properly.

Caching type comparison

Caching Type Speed Setup Complexity
Standard file caching Medium (TTFB 200–500 ms) Low
Tagged (Bitrix Cache Engine) High (TTFB 100–200 ms) Medium
Composite mode Maximum (TTFB 50–100 ms) High (requires template adaptation)

Reasons for slow component performance

Component with no cache or with NONE cache

$APPLICATION->IncludeComponent('bitrix:catalog', '.default', [ 'CACHE_TYPE' => 'N', // <- performance killer ]); 

Change to:

'CACHE_TYPE' => 'A', // auto according to site settings 'CACHE_TIME' => 3600, // seconds 

For user-dependent components (cart, personal area), component-level caching doesn't work—use an AJAX approach: serve the template from cache, load personal data separately.

Disabled caching in composite component

A composite component (e.g., bitrix:catalog) manages caching of its children. If the section settings have "Do not cache", caching is disabled for the entire tree, including product listing sections. Check in site settings: Settings → Product Settings → Caching. Tagged caching (Bitrix Cache Engine) is 3 times faster than standard file caching—use it.

Template optimization

Minification of PHP templates. Bitrix assembles pages from dozens of includes. Each include is a filesystem call. On HDD servers, this takes 5–15 ms per file. Solution: OPcache with opcache.validate_timestamps=0 in production (manual cache invalidation after deployment).

Move heavy blocks to AJAX. Widgets like "similar products", "recently viewed", "popular in category" are candidates for AJAX. The main page renders quickly, widgets load in parallel.

Example result

An online store of building materials with 180,000 SKUs. Before optimization: TTFB 2.1 s, 380 SQL per category page. After: disabled CACHE_TYPE=N in three components, eliminated two N+1 queries, enabled OPcache with validate_timestamps=0. Result: TTFB 420 ms, 38 SQL queries, LCP 1.9 s. Server load reduction allowed significant savings on VPS rental ($500/month).

Optimization stages

Stage Content Duration
Audit Profile top 5 pages, identify bottlenecks, report with recommendations 1–2 days
Cache optimization Configure component caching, enable tagged cache, test composite 1–2 days
Eliminate N+1 Refactor templates with aggregated queries, optimize API calls 2–5 days
Composite Configure and adapt template for composite mode, test 2–4 days
Delivery Hand over documentation, accesses, train developer, 30-day warranty 1 day

Deliverables include: documentation of changes, access to profiling tools, developer training, and 30-day performance warranty.

Request a performance audit of your site—we find bottlenecks in one day. Or get a consultation on rendering optimization. Contact us for diagnosis.