Bitrix doesn't slow down. The way teams use it does.
Every third conversation about Bitrix starts with "it's slow." I stopped arguing. I ask to see the profiler instead.
Bitrix usually isn't there.
What I find: an unindexed query, a cache that isn't invalidating, an ORM doing N+1 in a loop. The platform is rarely the culprit. It just takes all the blame.
The short answer for anyone who needs it: 1C-Bitrix performance issues almost always come from three sources — missing data-level caching, a misconfigured PHP-FPM pool, and no slow-query monitoring. Fix those and most "slow Bitrix" sites improve significantly without any platform change. The rest of this article is the longer version, with profiler screenshots and real numbers from a project I optimized.
Where the myth comes from
Bitrix is an old platform. Built when PHP 5.3 was normal and Redis wasn't a given. Parts of its internals carry that age — events, agents, tables with b_ prefixes tightly coupled to each other.
That's real. But it's not what makes a site take 8 seconds to load.
What does it: developers treating Bitrix like a generic framework. They skip the caching documentation. Write raw SQL inside components. Don't tune PHP-FPM for load. Put the site on shared hosting and wonder why 200 concurrent requests bring it down.
What a profiler actually shows
Open Xdebug or the built-in Bitrix Debug Panel on a "slow" site. The pattern I see most often:
N+1 in iblock queries
A developer fetches products with CIBlockElement::GetList() inside a loop. Each product gets a separate query for its properties. 50 products on a page = 51 database hits. That's not Bitrix. That's how someone is using Bitrix.
Fix: FETCH_DATA_PAGE_SIZE + GetList with SELECT EXTENDED. One query instead of 51. On a 28k SKU catalog, the difference is 4 seconds versus 0.3 seconds.
Cache that isn't actually on
Bitrix's component cache works well. It's also easy to accidentally disable. CACHE_TYPE=N in a component, a misplaced $APPLICATION->ResetAllStaticCache() call, or a developer who turned caching off "for debugging" and never turned it back on.
In the profiler: repeated database hits on every request for data that changes once a day. A static product listing firing 120 SQL queries per page.
Enable the cache: 12 queries. The rest served from Redis.
Static files going through PHP
Nginx is there but the static file location isn't configured correctly. The server is burning PHP-FPM workers serving 40kb JPEGs.
At 100 concurrent users, that exhausts the worker pool immediately. New requests queue. TTFB climbs to 3-4 seconds — not because the business logic is slow, but because the server is busy with images.
Three causes I see on almost every slow Bitrix site
The first is missing data-level caching. Not component caching — actual data. If your filters rebuild a category tree on every request, that's a SQL query every time. Redis plus a wrapper around CIBlockSection::GetList(), and the tree builds once, lives for 10 minutes, rebuilds on an event.
The second is an unconfigured PHP-FPM. pm = dynamic with default values doesn't hold up under load. pm.max_children = 5 with 50 concurrent users means guaranteed queuing. I usually set pm = static and calculate pm.max_children from available memory: (RAM - OS overhead) / avg_worker_size. On a 4GB server that's 20-25 workers, not 5.
The third is no slow-query monitoring. MySQL slow query log is off. OPcache is wrong: opcache.revalidate_freq=0 in production means constant filesystem checks. These problems are invisible without tooling, but they accumulate.
What does two days of 1C-Bitrix optimization actually look like?
A real case from 2022: an ecommerce store on Bitrix, 3,000 products, users complaining about slowness during peak hours.
Day 1: turned on the Bitrix Debug Panel, found 3 components with caching disabled and one GetList running in a loop. Enabled caching, rewrote the query.
Day 2: fixed the Nginx static location, moved assets to CDN, recalculated PHP-FPM workers.
Results:
- TTFB: 2.1s → 0.4s
- DB queries per catalog page: 87 → 9
- Peak CPU load: 94% → 31%
No rewrite. No platform change. Two working days.
When Bitrix actually is the problem
Honestly: sometimes it is. If you have 500k+ products and need real-time faceted search on SQL, Bitrix's ORM won't help. You need Elasticsearch and a separate index. If you're at 10,000 simultaneous users, a PHP monolith will hit a ceiling, and you need to think about queues or a caching layer on top.
But that's not "Bitrix is slow." That's "we've outgrown the use case."
Most sites never get there. Their problem is misconfiguration and antipatterns, not some inherent ceiling in the platform.
The check before you sign anything
Before writing "we need to rewrite" — open the profiler. Count the database queries on a single page. Check whether caching is actually on. Look at the PHP-FPM config.
Odds are you're looking at hours of work, not months of migration.