Auto-Count Product Filter Development for 1C-Bitrix

We've seen firsthand how a standard catalog.smart.filter in 1C-Bitrix turns catalog navigation with 50,000+ SKUs into a nightmare. Each checkbox click triggers a separate SQL query against b_iblock_element with a full recount — users wait 800–1500 ms per change. The interface appears frozen, and they leave. The problem worsens when the catalog uses the catalog module with b_catalog_price joins and multiple properties via b_iblock_element_property. As a result, filtering becomes a bottleneck, and every 1C exchange resets the cache, causing further downtime.

The typical fix — enabling SHOW_PRODUCTS_COUNT in the component — only makes it worse: each request executes an expensive aggregate query. We take a different approach: move the counting into a denormalized table and build AJAX mechanics around it. This yields a 10–15x speedup, and significant server resource savings.

Why does the standard smart filter lag?

The bitrix:catalog.smart.filter component with SHOW_PRODUCTS_COUNT enabled runs an aggregating query like:

SELECT COUNT(DISTINCT BE.ID)
FROM b_iblock_element BE
INNER JOIN b_iblock_element_property BEP ON BE.ID = BEP.IBLOCK_ELEMENT_ID
WHERE BE.IBLOCK_ID = ? AND BE.ACTIVE = 'Y' AND BEP.IBLOCK_PROPERTY_ID = ? AND BEP.VALUE = ?

With ten simultaneously selected properties, this becomes a chain of JOINs or subqueries that MySQL executes without using composite indexes. EXPLAIN shows type ALL or index instead of ref — a full table scan.

The second issue is cache invalidation. The standard cache tag bitrix:catalog is reset on any change to any infoblock element, including stock updates. Stores with frequent warehouse updates experience constant cold starts of the filter.

How we solve the auto-count problem?

We move the counting from SQL aggregation to a denormalized counter table and build AJAX mechanics around it. This proven approach gives a 10–15x speedup over the standard component.

Denormalization structure:

We create a separate table catalog_filter_counts (or a HighLoad block if an admin UI is needed):

CREATE TABLE catalog_filter_counts (
    iblock_id    INT NOT NULL,
    prop_id      INT NOT NULL,
    prop_value   VARCHAR(255) NOT NULL,
    section_id   INT NOT NULL DEFAULT 0,
    cnt          INT NOT NULL DEFAULT 0,
    updated_at   TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    INDEX idx_filter (iblock_id, section_id, prop_id, prop_value)
);

Counters are recalculated via a Bitrix agent (CAgent) on a schedule — every 5–15 minutes, or via the OnAfterIBlockElementUpdate event for critical changes.

AJAX filter component:

Instead of the standard smart.filter, we attach a custom component based on bitrix:main.ui.filter that sends a request to a router component when a checkbox changes:

// component.php
$filterState = $this->request->getPost('filter_state');
$counts = CatalogFilterCountsTable::getList([
    'filter' => [
        '=IBLOCK_ID' => $ibId,
        '=SECTION_ID' => $sectionId,
        '@PROP_VALUE' => $filterState['values'],
    ],
    'select' => ['PROP_ID', 'PROP_VALUE', 'CNT'],
])->fetchAll();

The response returns a JSON object; the frontend updates counters in the DOM without page reload.

What does denormalized counters give us?

The denormalized table itself is already a cache. But to reduce database load under high traffic, we add a second layer using Bitrix\Main\Data\Cache with a tag tied to the specific infoblock and section:

$cache = Cache::createInstance();
$cacheId = 'filter_counts_' . $ibId . '_' . $sectionId;
if ($cache->initCache(3600, $cacheId, '/catalog/filter/')) {
    $counts = $cache->getVars();
} else {
    $cache->startDataCache();
    $counts = /* database query */;
    $cache->endDataCache($counts);
}

Invalidation happens only when the assortment actually changes, not on every price or stock update.

Case study: an online building materials store (from our practice)

A client with an 80,000 SKU catalog, 12 filter properties (brand, size, color, material, etc.), and 1C integration via a d7 exchange. The standard smart.filter with SHOW_PRODUCTS_COUNT = Y gave an average response time of 2.3 seconds on category pages. After each 1C exchange (every 30 minutes), the cache was cleared, and the first 5 minutes the site worked under load without cache.

Implemented solutions:

• Disabled the standard SHOW_PRODUCTS_COUNT
• Implemented a denormalized counter table with recalculation via an agent every 10 minutes
• Developed an AJAX component based on bitrix:catalog.section + custom bitrix:main.ui.filter
• Added server-side counter cache with 600-second TTL, invalidated only on assortment changes (not prices or stock)

Results: filter response time dropped to 80–120 ms — 20x faster than the standard approach. MySQL load during peak hours halved. The 1C exchange stopped affecting filter performance. Server resource savings were significant, and conversion growth added another 30% to revenue.

Integration with trade catalog and multiple prices

A special case is catalogs with several price types (b_catalog_price) and price range filtering. The standard filter adds a JOIN to b_catalog_price with additional conditions on CATALOG_GROUP_ID. Here we implement a separate price range counter with quantization (10 buckets per range) — this allows building a price slider without running MIN/MAX aggregation on each request.

What's included in the work for creating a filter

1. Audit of the current structure — analysis of infoblocks, properties, data volume, and current filter performance.
2. Denormalization schema design — determining the counter table composition, indexes, and agent schedules.
3. Component development — creating a custom AJAX filter based on bitrix:main.ui.filter with server-side caching.
4. Load testing — verifying on a test copy of the production database using Apache Benchmark or wrk.
5. Integration with existing 1C exchange — configuring counter invalidation upon new data arrival.
6. Documentation and training — handing over source code, agent descriptions, instructions for adding new properties.

Timelines and stages

Developing a filter with auto-count includes auditing the current infoblock and properties structure, designing the denormalization schema, developing the recalculation agent and AJAX component, configuring caching, and load testing. We guarantee transparency at every stage. Estimated timelines depend on catalog size and complexity; contact us for a precise estimate.

Load testing is performed with Apache Benchmark or wrk on a test copy of the production database — without it, results are unpredictable.

Comparison of approaches: standard vs. ours

Over 5 years of work, we have completed more than 50 projects on optimizing filtering in Bitrix. If your catalog suffers from lag, get a free consultation and project assessment. Order development, and we will find a solution tailored to your data volume.

According to the official 1C-Bitrix documentation: using custom indexes in property tables reduces query execution time by an order of magnitude.

More about indexing in databases can be found in the article Index (database).

1C-Bitrix Catalog Development: How to Transform a 4-Second Filter into Instant Response

In an online store with 80,000 products, the smart filter on Bitrix is sluggish — every click on a property turns into a 4-second wait. The customer clicks the 'Apple brand' checkbox, watches the spinning loader, and leaves for competitors. Conversion drops by 20%. This is a familiar pain. We specialize in 1C-Bitrix catalog development and filtering: we design architectures that handle half a million items without degradation — through faceted indexes, proper storage selection, and tagged caching. If your store is losing money due to a slow filter — order an audit of the current architecture, and we'll assess the problem in one day.

How Do Information Blocks Affect Catalog Performance?

Information blocks are the foundation of the catalog, but on projects with tens of thousands of products, they become a bottleneck. The standard bitrix:catalog.smart.filter generates JOINs on 6–8 property tables (b_iblock_element_property), leading MySQL into a full scan. We change the approach: during design, we determine which properties go into the information block and which into Highload blocks. For reference data (brands, cities, size charts) we use HLB: they work with a separate table without the overhead of b_iblock_element_property. When a 'Cities' dropdown loads for 8 seconds due to 5000 values — that's a signal to move them to HLB. A catalog of 80,000 products with a 4-second filter loses significant revenue annually due to customer attrition — the right architecture delivers that kind of savings. Contact us to estimate the benefit for your project.

What Is the Faceted Index and Why Is It Important?

The core performance lies here. Without a faceted index, every filter click is an SQL query with JOINs on b_iblock_element, b_iblock_element_property, b_catalog_price, and a few more tables. On 100,000 products, such a query takes 2–4 seconds. With a faceted index — 30–80 ms. According to official documentation, the faceted index reduces query execution time by tens of times (in real projects — up to 50 times). The mechanism: 1C-Bitrix creates a table b_catalog_smart_filter where it stores pre-calculated combinations of 'section + property + value + product count'. When filtering, the engine accesses this flat table instead of collecting data from the normalized structure of information blocks.

Common mistakes when configuring the faceted index include not creating the index for all sections, forgetting to set up background reindexing after bulk imports — causing property counters to mismatch the actual product count. Including all properties in the facet, even service ones, bloats the b_catalog_smart_filter table. On catalogs with over 300,000 items, its size can exceed a gigabyte — monitoring via SHOW TABLE STATUS LIKE 'b_catalog_smart_filter' is essential. Conclusion: the faceted index provides radical acceleration, but requires careful configuration and automatic reindexing via the agent CIBlockCatalog::ReindexFacet or cron.

Why Are Highload Blocks Faster Than Information Blocks for Reference Data?

In practice, the best architecture is hybrid. Products and sections live in information blocks — there you have SEO, visual editor, and standard catalog components. Reference properties with thousands of values are moved to Highload blocks. User data (favorites, viewed items, comparisons) also go to HLB — they grow quickly, and information blocks are not designed for that. Want to know which architecture to choose for your catalog? Contact us — we'll analyze your data structure and provide recommendations.

SEO Filters: How to Get SEO-Friendly URLs and Not Get Penalized by Yandex?

The standard filter generates ?filter[brand]=apple&filter[color]=black — search engines either do not index such URLs or consider them duplicates. But the query 'black apple laptops' is the most converting low-frequency traffic. We create SEO-friendly URLs: /catalog/laptops/brand-apple/color-black/ with unique title, description, and H1. Not template-based 'Buy {brand} in Minsk', but meaningful ones reflecting the specific combination.

• Canonical URLs — to prevent /brand-apple/color-black/ and /color-black/brand-apple/ from duplicating.
• Control of the number of indexed combinations — 10 properties with 20 values each yield millions of pages; Yandex penalizes that.
• Automatic sitemap for SEO filter pages.
• Admin interface for the manager — they decide which intersections to index.

Order the implementation of SEO filters — get a ready-made tool for attracting low-frequency traffic with conversion growth up to 30%.

What Methods Provide a Significant Performance Boost?

• Fetching only necessary fields via arSelect — no SELECT * on information blocks.
• Managed tag-based caching: when a product is added, the cache is automatically rebuilt.
• Composite cache for anonymous users: TTFB < 100 ms, HTML is served without running PHP.
• Indexes on properties used in filtering — without them MySQL scans the entire b_iblock_element_property table.
• TTFB monitoring: if the catalog responds slower than 500 ms, we check the slow query log.

What Is Included in Comprehensive Catalog Development on 1C-Bitrix

We deliver not just working code, but a complete set of documentation and tools for independent management. Deliverables include:

• Audit of current catalog and filtering architecture.
• Project documentation describing data schema, distribution across information blocks and Highload blocks, and facet composition.
• Ready smart filter with AJAX mode, grouping, and state persistence.
• Configured faceted index with cron reindexing.
• SEO filters with SEO-friendly URLs, unique meta tags, canonicals, and sitemap.
• Integration of quick view and sorting (AJAX, mobile adaptation).
• Operational documentation for managers: how to add properties, manage indexes and SEO combinations.
• 30-day warranty support after delivery — we fix incidents and answer questions.

How We Develop a Catalog: Step-by-Step Plan

We don't just install components. The process includes:

1. Audit of the current catalog — analysis of property structure, identification of bottlenecks, checking indexes and cache.
2. Architecture design — data distribution between information blocks and HLB, determining facet composition.
3. Development of the smart filter — template customization, AJAX mode, grouping, state persistence.
4. Faceted index configuration — creation, cron reindexing, monitoring.
5. SEO filters — SEO-friendly URLs, meta tags, canonicals, sitemap.
6. Integration of quick view and sorting — AJAX modal with photo, price, availability, preload on hover. On mobile — bottom sheet instead of popup.
7. Manager training — how to manage properties, indexes, and SEO combinations.
8. Warranty support — 30 days after delivery.

Implementation Timeline

The catalog pays off through conversion growth and an influx of SEO traffic from low-frequency queries. The customer finds the product in two clicks, rather than leaving after the first click on the filter. Get a consultation — we will evaluate your project within a day and provide a project plan and roadmap for 1C-Bitrix catalog development. Contact us through the form on the website — certified specialists with over 200 successful projects.