Performance Audit for 1C-Bitrix Sites

A catalog page takes 6 seconds to load, the server is powerful, hosting isn't complaining, but clients are leaving. Without diagnostic tools, people start guessing: "maybe the cache isn't working," "maybe the database is slow." Our performance audit provides a precise answer: exactly where time is lost and how much can be gained. With over 10 years and 500+ audits conducted, typical issues repeat: N+1 queries, disabled cache, missing indexes. The audit identifies them in 3-5 days and delivers a concrete action plan.

Imagine an e-commerce store on Bitrix with 10,000 products; a category page opens in 6 seconds. Clients leave, conversion drops. Internal checks reveal nothing—the server isn't overloaded, the database isn't slow. The only systematic step is to conduct a performance audit. It will reveal the root cause of the slowness and provide numbers: how many seconds can be recovered at each stage. Average load time savings: 40%.

How We Diagnose Slow Queries

BX_DEBUG is a built-in Bitrix tool. In dbconn.php or bitrix/php_interface/init.php:

define('BX_DEBUG', true); 

It displays at the bottom of the page: number of SQL queries, PHP execution time, memory usage, cache hits. Norm: < 50 queries, < 500 ms PHP time for a catalog page.

For heavy queries we use EXPLAIN ANALYZE. Slow queries are logged via slow_query_log in MySQL or log_min_duration_statement in PostgreSQL (threshold 200 ms), then the execution plan is analyzed. This is 5 times more effective than guessing without a plan. According to MySQL documentation, using EXPLAIN ANALYZE reduces plan analysis time by half.

Real case: On one project, the catalog was slow due to N+1 queries in a handmade component. After switching to GetList with property selection, the time dropped from 4 s to 1.2 s.

Why Bitrix Slows Down on Large Catalogs

N+1 in components. A product listing makes 1 query for the list and N queries for prices/properties. With 50 products per page, that's 50 extra queries to b_iblock_element_property. Solution: select with required properties or batch fetching.

Disabled cache. A developer turned off caching during development and forgot to re-enable it. Check component settings and global configuration. Enabling the cache can reduce response time by 3-5 times.

Lack of indexes on custom tables. User tables are created without indexes, then queries with WHERE cause full table scans on millions of rows.

Heavy agents in the web thread. CAgent::CheckAgents() is called on every hit if cron is not configured. Agents with heavy logic slow down every page.

How Performance Audit Differs from a Regular Speed Check

A regular check via online services shows only external metrics: TTFB, resource load time. An audit goes inside: profiles PHP code, analyzes SQL queries, checks cache configuration and server settings. The difference in precision is like between a blood pressure monitor and an MRI—the latter sees the problem at the code and data level.

What We Check During the Audit

Here is an example of typical audit results:

According to 1C-Bitrix caching documentation, enabling tagged cache can reduce server load by 5 times.

Work Process

1. Collect metrics — Enable BX_DEBUG, slow_query_log, set up Xdebug. Profile typical pages.
2. Analyze — Examine SQL query plans, look for N+1, check indexes, agents, cache settings.
3. Report — Create a table of bottlenecks with impact assessment (in seconds) and effort to fix.
4. Recommendations — Prioritized plan: what to do first for maximum speedup.
5. Support — If needed, help implement optimizations (cron setup, component fixes, migrations).

Typical Optimization Mistakes

• Cron not configured for agents — every hit triggers CAgent::CheckAgents().
• No indexes on frequently filtered fields (price, status, category).
• Component caching disabled or reset unnecessarily.
• Gzip compression for static files not enabled at the web server level.

Request a consultation to get accurate timelines and cost for your project. Contact us—we are ready to diagnose your site.