When we take on a Bitrix project, the first question is not "which template" but "how to design the data structure so that filters don't need rewriting in a year"?
One misconfigured infoblock with 30 properties — and b_iblock_element_property grows to millions of rows. CIBlockElement::GetList takes 4 seconds, and the faceted index doesn't help because link properties aren't in b_catalog_sm_*. To rebuild on production means rewriting templates, filters, SEO rules. It's cheaper to design it right once. Our experience shows that proper architecture saves up to 40% of maintenance budget. Common consequences of wrong architecture: increased page load times, drop in conversion, and cost overruns on refinements.
Why the choice of storage type determines performance
This isn't an abstract question. It decides which components work out-of-box and which have to be written from scratch. A design mistake can cost months of code rewriting.
Infoblocks store properties in the EAV table b_iblock_element_property. For 5,000 products with 10 properties — 50,000 rows, MySQL handles it. For 80,000 products with 25 properties — 2,000,000 rows, JOINs during filtering take seconds. But infoblocks provide SEO wrapper, visual editor, catalog components.
Highload-blocks — flat table, one column per property. Indexes are efficient, filtering 200,000 records takes 30-80 ms. No section property inheritance, no built-in SEO module. Ideal for reference data (cities, brands).
D7 ORM (Bitrix\Main\ORM\Data\DataManager) — for entities that don't fit into infoblocks or HL-blocks: orders with relations, custom logs, aggregations. Full control, but admin panel is built manually.
| Criterion | Infoblocks | Highload-blocks | D7 ORM |
|---|---|---|---|
| Filter speed for 100K+ items | 1-3 s (with faceted index 50-200 ms) | 30-80 ms | Depends on query |
| Built-in catalog components | Yes | No | No |
| SEO module | Yes | No | No |
| Arbitrary relations | Limited | By field | Full-fledged |
How Bitrix compares with WordPress and Laravel
WordPress also uses EAV via wp_postmeta, but lacks built-in e-commerce level. WooCommerce is a plugin. Bitrix provides the catalog module with trade offers, price types, warehouse accounting, 1C exchange via CommerceML. For companies living in 1C:Enterprise, this is a decisive factor.
Laravel is a framework, not a CMS. Freedom of architecture, but catalog, cart, access rights, 1C exchange are written from scratch. On a project with a 4-6 month budget and a team of 3, Laravel is justified. For a corporate site needed in 2 months, Bitrix is faster. Not better — faster for typical tasks.
The key difference is the component approach. bitrix:catalog.section is a ready-made bundle of controller + model + caching. It's included in a template, configured via $arParams, customized in template.php. Business logic goes into result_modifier.php or a custom module in local/modules/. Template in local/templates/. Not in the core, never in the core.
How we ensure performance before the first commit
Optimizing after launch is expensive. Here's what we build into the architecture:
Caching — three levels: managed component cache, common cache (memcached/Redis), composite site. Composite delivers HTML without kernel initialization — response time drops from 200 ms to 15-30 ms.
Static files — CDN for /upload/, /bitrix/js/, /bitrix/css/. WebP via CFile::ResizeImageGet(). Lazy loading. Moving static to CDN reduces server load by 40-60%.
Database — composite indexes on frequently filtered properties. EXPLAIN on every heavy query. For catalogs over 50,000 products — faceted indexes (Bitrix\Catalog\Model\SmartFilter), filter time goes from 3 seconds to 50 ms.
PHP — OPcache with JIT on PHP 8.1+, realpath_cache_size=4096K. Check via "Performance" → "PHP" panel.
Case: 6x catalog speedup
For a client with a catalog of 120,000 products and 40 properties, we migrated filtering from infoblocks to Highload-blocks with faceted indexes. Catalog page load time dropped from 4.2 s to 0.7 s. Additionally, we enabled composite cache for unauthorized users — time to first byte became 25 ms. Maintenance savings reached 30% of annual budget.
Learn more about composite mode in the official documentation.
What is included in the work
- Requirements analysis and data architecture design
- Design and responsive layout
- Custom components and modules
- Integration with 1C (CommerceML), payment systems, delivery services
- Caching, CDN, composite mode setup
- Testing (functional, load, security)
- Documentation and admin training
- 12-month warranty support
Stages and timelines
- Analysis and design (1-2 weeks) — infoblock specification, integrations, prototypes
- Design (1-3 weeks) — UI/UX, design system
- Development (3-8 weeks) — 2-week sprints, demo on staging
- Testing (1-2 weeks) — PageSpeed, Lighthouse, WebPageTest
- Launch (3-5 days) — deployment, monitoring, stabilization
| Project scope | Timeline |
|---|---|
| Corporate site, 10-20 pages | 6-10 weeks |
| Catalog with filtering, up to 10,000 products | 8-14 weeks |
| Online store with 1C | 12-20 weeks |
| B2B portal with personal account | 14-24 weeks |
Timelines are adjusted after requirements analysis. Cost is calculated individually — too many variables for template numbers.
Typical mistakes in Bitrix projects
- Business logic in
template.php. Discounts, permissions — move toresult_modifier.phpor a module service class. - Direct SQL queries (
$DB->Query()) instead of D7 ORM. Loses caching, type safety, injection protection. - One giant
init.phpwith 2000 lines. Move to a module with autoloading. - Cache without tags. Use
SetResultCacheKeys()andCIBlock::clearIblockTagCache(). - Updating the core without staging. Always staging, then production.
Our engineers have 1C-Bitrix certification and 10+ years of commercial experience. We guarantee quality and timeline.
Order a Bitrix site — get a consultation and project estimate in 2 days. Contact us to discuss details.