Bitrix performance audit: where speed is lost
A slow Bitrix site rarely comes down to one cause. Speed is lost in several places at once: the catalog assembles a product page with a dozen separate database queries, the template pulls the same data again, and the environment remains as it was when the project launched.
The user sees one thing — the page takes a long time to open, and they leave before they manage to choose anything.
The first performance bottleneck is the catalog. Filters, prices, stock, trade offers, and properties are collected by separate queries, although some of them can be resolved in one pass.
The wider the selection and the more properties displayed in the listing, the more noticeable the gap between cold and warmed-up output.
The second is redundant calls. The template accesses the same data several times, external services are queried on every page open, and the cache is cleared more often than the content changes. In total, this is extra work that the server performs in vain.
The third is an unconfigured environment. Caching, compression, static file delivery, database parameters, and task queues are configured for a specific project, not by default. Without this, even clean code runs into server resources rather than its own logic.
Site speed diagnostics shows how these factors add up during peak periods: when ads start or a sale begins, response time grows nonlinearly, and some orders are lost for no apparent reason.
A Bitrix performance audit breaks the picture down into measurable segments and answers the main question — what can be resolved by configuration and what requires code rework.
What optimization delivers: measurable effects for the site
Website performance optimization on 1C-Bitrix is measured not by the word “faster” but by before-and-after numbers. The control points are median and 95th percentile page response time, the share of requests that stayed within budget, and recovery time after failure.
We capture them in production under load, not in a staging environment where traffic does not resemble real traffic.
The first effect is page response time.
Component caching and composite mode, review of heavy database queries, indexes for catalog selections, and moving exports to background tasks speed up response several times over: the share of pages meeting the time budget grows from half to nine out of ten.
The second is resilience to peak load. Cache warming before a promotion, limiting concurrent reports, and a queue for heavy tasks allow the site to hold a peak 3-5 times higher than normal traffic: response grows smoothly, without interruption or the user waiting in a queue.
The third is reduced downtime. Monitoring of key scenarios, a debugged rollback procedure, and pre-taken configuration snapshots turn recovery from hours of searching for the cause into minutes following a clear scenario.
The fourth, and the most valuable in the end: a whole class of failures disappears — database connection timeouts, out-of-memory crashes during import, locks during exchange with the accounting system. Incidents become visible through metrics before they become visible through a client call.
Work formats: one-time diagnostics, implementation, support
The formats differ not in the depth of the report but in what happens after it: whether diagnostics remains a document or turns into changes in the environment.
We select an option for the state of the project — if the site sags during peaks, a one-time audit is usually enough; if releases come out every week, one-time measurements provide almost no benefit.
| Format | When it fits | Limitations |
|---|---|---|
| One-time diagnostics without changes | Need to understand the cause of degradation and estimate the scope of work before starting | Ends with a report: bottlenecks remain in place, we make changes as a separate stage |
| Diagnostics with implementation | The cause is clear, a result is needed within one task | Requires a deployment window, regression, and repeated measurements on the same traffic profile |
| Ongoing performance support | Releases are frequent, load grows unpredictably | Requires access to the server and monitoring, alert thresholds will have to be maintained |
| Review before environment migration | A change of hosting, platform version, or caching scheme is planned | The forecast is accurate only as much as the load profile matches real traffic |
We include load testing selectively — when we need to separate a code problem from insufficient platform resources. The chosen format does not block the others: one-time diagnostics can easily grow into implementation, and implementation into ongoing load monitoring.
Work stages: from taking measurements to handing over procedures
Each stage relies on the numbers from the previous one — blind optimization is excluded. Below are the stages of website optimization on 1C-Bitrix and the work plan: from taking measurements to acceptance of results.
- Collecting access and inventory. We obtain access to the server, admin panel, repository, and backups, and record the environment configuration and module list. Without this, any change is guesswork.
- Taking measurements. Baseline: server response time, page generation speed, number of database queries per typical page, cache hit ratio, and the weight and amount of static files. We repeat the load scenario without changes — otherwise there is nothing to compare.
- Finding bottlenecks. We profile heavy pages: slow queries, selections without indexes, redundant components, agents that run on every request.
- Change plan. We agree on what to change in code, what in server configuration, and what in caching, with risk assessment and rollback order for each item.
- Implementation. We move from the greatest effect at the lowest risk: first cache and queries, then components and environment settings. We verify each block separately.
- Control measurements. We repeat the same scenario and compare with the baseline — this shows the contribution of each change rather than an average number for the project.
- Acceptance of results. We record final metrics and hand over procedures: a bottleneck map, list of changes, caching and monitoring settings, so degradation does not return with the next update.
What you keep: configurations, schemes, procedures
An audit only makes sense when its results can be reused without us. Therefore, every conclusion is recorded in an artifact that your team or another contractor applies directly — without reconstructing context from correspondence. The document package is assembled during the work and handed over in full at acceptance.
- Optimization documentation: what was changed in code and settings, which bottlenecks were closed, which remain and in what order to address them.
- Infrastructure diagram: servers, load balancing, caching, queues, external services — with the critical request path marked.
- Maintenance procedure: backup frequency, order of core and module updates, backup restore verification, monitoring of logs and disk space.
- Bottleneck map with priorities: share of response time at each segment and expected effect of each change.
- Configured monitoring profiles: thresholds for response time, error rate, and load, and rules for notifying responsible staff.
- Rollback plan: which changes are reversible, from what point to restore, and how long it takes.
- Access handover: hosting panel, admin panel, repository, monitoring, and backups — issued to your accounts, not ours.
Acceptance follows the same list: you verify that each item is reproducible on your side, and only then do we close the stage. After that, support can be handled in-house or given to another contractor — the state of the system is described, not kept in people's heads.
How catalog performance improved: before and after
A catalog with tens of thousands of items on 1C-Bitrix stopped responding during seasonal peaks: the section took several seconds to render, filters timed out, and some traffic was lost to failures. We analyze a Bitrix optimization case study with before-and-after metrics.
What was the bottleneck
The main pain was in the section template: product selection ran one query per item, properties and prices were pulled inside the loop, and the cache was cleared on every exchange with 1C and was not split by pagination pages.
Database load grew linearly with the number of products, and any price change reset the entire cached section.
Metrics before and after
The changes were divided into layers: batch queries instead of one-item selection, composite indexes for filters, separate cache keyed to the page and correctly invalidated on the exchange event. Below is the catalog performance growth based on control measurements on the same load profile.
- section page response time: from ~4.5 s to 0.8 s;
- share of database queries per catalog page: reduced by about 7 times;
- failures during peak hours: from 6–8% to the level of statistical noise;
- cache rebuild after exchange with 1C: from minutes to seconds.
A month later, the measurements were repeated on real traffic — the figures held, and import stopped “freezing” the catalog. This is the difference between a “by eye” change and an audit, where every hypothesis is confirmed by before-and-after measurement.
What to do if the bottleneck is not in the code but in the environment?
“Code or server” can only be separated by measurements, not guesses.
We capture a profile in production at the moment of degradation and break execution time into segments: computations in the application, database queries, disk subsystem wait, network calls to external services, and static file delivery.
If the main share is waiting rather than computation, the bottleneck is in the infrastructure — and code optimization will have a cosmetic effect.
Next, we test the hypothesis by comparing environments. We deploy the same release and a copy of production data in a reference environment with a different configuration and run the same scenarios — catalog population, checkout, exports, exchange with the accounting system.
If the same pages render several times faster in another environment with the same code, the question is closed: the cause is in environment configuration, not the application.
Within the environment itself, we look at specific places. Caching of the 1C-Bitrix platform and response cache on the web server side: whether the cache is cleared on every request, whether cache is disabled because of permissions or agents.
Memory limits and the number of concurrent processes that cause requests to queue. The database connection pool and its parameters: worker threads are insufficient, locks interfere, heavy selections go to filesort. Disk state: I/O queue, synchronous writes to logs.
And the schedule: scheduled tasks, backups, indexing crawl, log rotation — if they fall during a peak, the degradation pattern repeats like clockwork.
The order of work matters: first we confirm exactly where the limit is, and only then do we make changes. Otherwise a rewritten section does not change the picture, and the regression has to be rolled back.
We verify every environment change on a copy of production data using the same scenarios and compare before-and-after measurements — then it is clear what exactly delivered the speedup and whether the bottleneck will return at the next load peak.
Concerns about access, timelines, and changes on a live site
A 1C-Bitrix performance audit does not require stopping the site: we take measurements in production during low-load hours, and prepare code and settings changes on a copy. Access is provided through a separate read-only account — settings, event logs, and a database copy.
We do not need write permissions to the production database and site files; access is revoked after the work.
How much access is needed for an audit?
Viewing settings and the event log in the admin panel, reading configuration and logs on the server, and a database copy. We transmit passwords via a secure channel and store them until the end of the work. If external access is prohibited by policy, we review the exports together with your engineer.
Can the site be changed without downtime?
Changes are first verified on a copy and metrics are compared before and after. We transfer to production one block at a time: templates and configurations are under version control, so rollback is switching to the previous state, not manual editing.
How do changes proceed and how long does optimization take?
First diagnostics: we rank bottlenecks by their contribution to total response time. Changes proceed in iterations from the heaviest segment, every step is measurable.
Cache clearing and index rebuilding are controlled operations: we clear cache selectively by component, rebuild indexes in the background, and warm up on a copy.
What happens as load grows?
We look at how the configuration behaves under peak traffic and record the threshold after which server separation is required. This is part of the report, not a surprise on sale day.
Let's discuss your task: what to send for evaluation
To come back with an estimate and work plan, rather than general wishes to “speed up the site,” we need facts about your environment.
Below are the inputs that most often determine exactly where response time is lost; send what you have at hand, and we will gather the rest together in conversation.
- site address and test environment address, if it has a fresh database copy;
- platform core version and list of connected modules, including custom and third-party ones;
- deployment scheme: where the web part runs, where the database is located, and how they are connected;
- monitoring reports and slow query logs for a typical week and for the peak period;
- description of load peaks — sales, mailings, seasonal growth — with dates and nature of activity;
- what you have already tried to change: caching, indexes, template rewriting — and how it ended;
- administrator contact and access to the control panel, backups, and environment settings.
Missing half of the items does not slow the conversation down: our engineers capture part of the picture themselves from the live site, and restore part from indirect signs.
Based on the discussion, you will receive a prioritized list of bottlenecks, a staged work plan with an effort estimate for each, and an understanding of which changes can be safely made without stopping the site.
Describe the optimization task in a convenient format — we will come back with an estimate and plan.
