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 to result_modifier.php or a module service class.
- Direct SQL queries (
$DB->Query()) instead of D7 ORM. Loses caching, type safety, injection protection.
- One giant
init.php with 2000 lines. Move to a module with autoloading.
- Cache without tags. Use
SetResultCacheKeys() and CIBlock::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.
How to properly design infoblocks?
When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.
Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.
Why 1C-Bitrix outperforms most CMS for business
The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.
What highload blocks are and how they speed up the catalog
Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.
From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.
What integrations are critical for 1C-Bitrix stores
Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.
What's included in 1C-Bitrix website development
Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.
- Technical specification – user stories, infoblock diagrams, integration schemas.
- Source code in Git – with commit history, release tags, branching rules.
- Administrative documentation – description of custom components, deployment instructions, list of agents and events.
- Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
- Access to staging during development – test before production deployment.
- Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).
Our process and technologies
| Project type |
Timeline |
Complexity |
Key features |
| Corporate website |
from 1 month |
Medium |
Catalog, news, forms, CRM integration |
| Online store |
from 2 months |
High |
54-FZ, marketplaces, 1C exchange, SKU |
| B2B portal |
from 3 months |
Very high |
Personal prices, document flow, Bizproc |
| Landing page |
from 2 weeks |
Low |
LCP < 2s, composite cache, static |
| Multisite structure |
from 1.5 months |
High |
Separate content, shared catalog, hreflang |
Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.
Process:
-
Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
-
Design – UI/UX with design system. Components are reusable.
-
Development – write components with custom templates in
local/templates/. Business logic in local/modules/.
-
Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
-
Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.
Multilingual support and redesign
Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.
Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.
Guarantee and support
We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.
