Optimizing the loading speed of a 1C-Bitrix website

Website Speed Optimisation for 1C-Bitrix

The typical picture after several years of Bitrix project development: TTFB 800–1,200 ms, Largest Contentful Paint over 4 seconds, PageSpeed Insights in the red zone. The causes are usually not the hosting — they lie within the application itself: uncached components, unoptimised infoblock queries, 200+ HTTP requests per page due to unmerged JS/CSS, and images without compression served at their original resolution.

Optimising 1C-Bitrix is not a single action but a systematic elimination of several classes of problems. Each class delivers its own improvement, and it is important to work in the right order: server side first, then frontend.

Server Side: Cache, Queries, Agents

Component caching — the first thing to check in any audit. In Bitrix, each component manages its own cache via the CACHE_TYPE and CACHE_TIME parameters. A common situation: developers set CACHE_TYPE = N (no cache) during debugging and forgot to revert it. Just one such component on the home page and TTFB grows several times over.

Checking via \Bitrix\Main\Diag\Debug::dumpToFile() or the bitrix.performance module shows a list of uncached components and their execution times. The standard tool is the performance panel (.../bitrix/admin/perfmon_panel.php).

DB query optimisation. Bitrix infoblocks, when used carelessly, generate queries with SELECT * against b_iblock_element, b_iblock_element_property, and b_iblock_section with no field restrictions. Switching to the D7 API (Iblock\ElementTable) with an explicit select reduces the volume of transferred data and the MySQL load. A separate issue is the N+1 problem: a component makes a query for each element inside a loop. Identified via $DB->ShowSqlStat() or MySQL slow query log with long_query_time = 0.1.

Agents and background tasks. Bitrix agents run in the context of a web request by default 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.

Composite Site: What Actually Speeds Things Up and When It Does Not Help

Bitrix composite mode (bitrix.composite) caches page HTML to the filesystem and serves it without executing PHP, replacing dynamic blocks (cart, authorisation) via AJAX. For content and catalogue pages this is the most powerful tool — TTFB drops to 20–50 ms.

But composite does not work automatically. It requires marking dynamic zones with the bitrix:nocache tag, migrating authorisation and cart to AJAX components, and configuring exclusions for personalised pages. Incorrect configuration results in logged-in user data being captured in cache — a critical error on projects with personal accounts.

Frontend: HTTP Requests and Resource Size

After server optimisation, examine the client side via Chrome DevTools → Network. Typical problems on Bitrix projects:

• Unmerged CSS/JS: each module loads its own files separately. On a loaded project this means 30–80 files. Bitrix can combine them via compression settings (Settings → Performance → Compression), but requires correct path configuration and HTTP/2.
• Images without optimisation: original files from the media library are served without WebP conversion, without srcset for retina displays. The resize_image module can resize images on the fly, but without resize cache configuration this creates load.
• No lazy loading: images below the fold load together with the first screen. In Bitrix this is addressed via the loading="lazy" attribute in component templates or JavaScript IntersectionObserver.

Case Study: Corporate Online Store, 15,000 SKUs

Project on Bitrix "Business", PostgreSQL, VPS 4 CPU / 8 GB RAM. Before optimisation: PageSpeed Mobile — 22/100, TTFB — 1.4 s, LCP — 5.8 s. Customer complaints about slow catalogue loading.

Audit revealed:

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

Sequence of work:

1. Fix component caching → TTFB 1.4 s → 380 ms
2. Optimise N+1, migrate to D7 API → queries per product page: 48 → 6
3. Move agents to cron → removed 80–200 ms latency
4. Merge 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 catalogue and home page

Result: PageSpeed Mobile 71/100, TTFB 180 ms, LCP 2.1 s. Mobile traffic conversion improved — users stopped leaving slow catalogue pages.

Self-Diagnosis Tools

Before contacting a specialist you can check independently:

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

Phases and Timeline

Work is divided into an audit and resolution of issues by priority:

Timelines depend on the volume of custom code and the number of issues identified.