Configuring Bitrix Performance Panel: Diagnostics and Optimization

When a Bitrix site starts to slow down — clients complain, managers get nervous, and every click in the admin panel takes 10 seconds?

The first tool every developer should master is the built-in performance panel. Over 8 years in the market and 50+ Bitrix projects, we've repeatedly confirmed that its data suffices for 80% of diagnostic tasks without external profilers. Recently, an online store with a catalog of 50,000 items came to us — the catalog page loaded in 12 seconds. After panel tuning and SQL optimization, the time dropped to 1.2 seconds — a 10x improvement, . Such results are typical when you know what to look at. Below we break down how to configure the panel, interpret its metrics, and perform actual optimization.

Enabling the Performance Panel

Activate via the admin interface: Settings → Performance → Performance Panel. For quick debugging, you can enable it programmatically:

// Show panel for the current user
$USER->SetShowStatPanel(true);

// Or in dbconn.php for debugging on dev environment
define('BX_STATPANEL', true);

The panel is visible only to authorized users in the "Administrators" group. On production, keep it enabled only during active debugging — it adds a small overhead for data collection. According to official Bitrix documentation, the panel does not affect page speed for regular visitors.

Performance Panel Metrics

• Execution time — total PHP + SQL time in milliseconds, broken down into PHP time and MySQL wait time.
• DB queries — number of SQL queries and their total time. Click on the block to open the list of all queries with individual execution times.
• Cache — number of cache accesses: hits and misses. A low hit rate (<80%) signals inefficient cache configuration or too frequent invalidation.
• Files — number of included PHP files. 500+ files without OPcache means slow initialization.
• Memory — peak PHP script memory consumption. 64 MB+ indicates a need to check for leaks or excessive data loading.

For convenience, here are normal values in a table:

Typical problems and their solutions are compiled below.

Detailed SQL Profiling

Click on the SQL block in the panel to open the list of all queries. Sort by time. Queries >50 ms are candidates for optimization via EXPLAIN. Queries that repeat 10+ times with the same pattern indicate an N+1 problem. Usually these are infoblock element properties fetched one by one. Comparison: a properly built query with a single JOIN runs 10-20 times faster than N individual queries.

Configuring the Performance Monitor

In the menu Settings → Performance → Performance Monitor, set:

• Recording threshold — 1000 ms for production, 500 ms for staging
• Records to store — 1000–5000 entries in the b_perf_hit table
• Record SQL — enable to see the query list for slow pages

View the log: Settings → Performance → View Log. Sort by total SQL time — that's where the most problematic pages appear.

Diagnostic Algorithm for a Specific Problem

1. Open the slow page with the panel enabled.
2. Check the ratio of PHP time vs SQL time. If SQL >70%, optimize queries. If PHP time is large with small SQL — the problem lies in component code.
3. Open the SQL query list, sort by time.
4. Copy a slow query, run EXPLAIN in MySQL Workbench or phpMyAdmin. Often adding an index reduces query time by 5-10x.
5. Add the missing index, refresh the page, and confirm improvement.

A typical case: on one project, the catalog page loaded in 8 seconds. The panel showed 250 SQL queries. EXPLAIN revealed missing indexes on the IBLOCK_SECTION_ID field. After adding the index, the page loaded in 0.8 seconds — a 10x improvement.

Why the Performance Panel Is Not Always Sufficient?

The panel excels at identifying slow SQL queries and caching issues, but it does not show bottlenecks in asynchronous code or external API calls. For deep diagnostics, we additionally use Xdebug profiling and monitoring of REST services (e.g., 1C or payment gateways). The panel is the first line of diagnostics, not the last.

How Often Should Performance Audits Be Conducted?

We recommend keeping the performance monitor running continuously, and conducting a full audit quarterly or after major updates. This catches degradation early. For example, after adding a new catalog section or integrating a new API, check whether the number of SQL queries has increased.

What a Full Performance Audit Includes

If you entrust diagnostics to us, you get:

• A complete audit of current performance using the panel and additional tools.
• SQL query optimization: EXPLAIN analysis, index addition, ORM query refactoring.
• Cache tuning: tagged cache, HTML cache, composite mode.
• Performance monitor configuration for continuous metric collection.
• A final report with recommendations and an action plan.
• A guarantee on results — we will set target load time indicators.

. Order a preliminary free diagnostic using the performance panel. Contact us for a consultation on optimization.

SELECT TABLE_NAME, COLUMN_NAME, INDEX_NAME, NON_UNIQUE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'your_database';

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.