New arrivals block in 1C-Bitrix: a bottleneck in catalog output
The new arrivals block is the storefront of an online store's catalog, by which a customer judges whether the assortment is alive.
As long as it is built by a standard selection by creation date and active status, everything rests on one assumption: that sorting by this field is cheap.
On a catalog with tens of thousands of items, the assumption stops working — the selection runs over element tables without a suitable composite index, and each display of the block pulls extra joins with properties and prices.
This hits the speed of assortment updates the hardest. While a manager edits and uploads products, the cache of the block and sections is reset entirely, and the next request rebuilds it across the entire database.
The more frequent the deliveries, the more often pages serve an empty or outdated block: formally the product is created, but in fact the customer does not see it.
The second bottleneck of the catalog is duplicates in the catalog output. A product ends up both in the block and in the main selection of the section, and when linked to several categories, it is duplicated in the list.
Dates from the accounting system are overwritten on each exchange, so a "new arrival" either moves down or disappears altogether. The storefront diverges from the accounting, managers stop trusting it and announce new arrivals manually.
The reason is not in the template or the design, but in the data layer: the block has no own novelty criterion separate from the card creation date. We analyze how this is closed.
New arrivals block: what changes in output speed and load
A typical new arrivals block on 1C-Bitrix is built by a heavy query: selection by activity date, sorting, pulling properties and trade offers, then rights check.
As long as the storefront is rebuilt on each render, any catalog upload doubles the load — the product card and the home page start competing for the same tables, and response time grows precisely at the moment of publication.
We separate two processes: data update and rendering. New arrivals go into a separate view, which is updated by product change events, rather than by a full recalculation on a schedule.
The managed cache receives tags of the infoblock and specific elements, so the reset is targeted — by the changed item, not by the whole section.
The effect is visible in three metrics. The storefront update time is reduced from minutes to seconds after publication: the visitor sees the new arrival immediately, not after a nightly recalculation.
The number of queries for rendering the list drops to one or two instead of dozens — properties and stock are taken from the prepared view, not assembled piece by piece.
Third, the class of partial upload failures goes away, when the block shows a mix of old and new nomenclature or hangs on incomplete data.
The update frequency of new arrivals becomes manageable: it is set by a date threshold, a manual reset of the output cache, or an event from the supplier, rather than by a rigid schedule.
Options for displaying new arrivals: comparison
In 1C-Bitrix, a "new arrival" is not a separate field, but a way of selection.
The same catalog can be displayed by addition date, by a flag property, through a separate section, or manually as an enumerated list — and each option behaves differently as the catalog grows, stock updates, and cache resets.
Below are the options for displaying new arrivals that are actually chosen between.
We separately take into account template limitations: the ready-made catalog markup does not always support the required sorting, and displaying the block outside the main template requires editing the template of the composite component.
| Option | When suitable | Limitations |
|---|---|---|
| Automatic selection of products by addition date | Catalog is replenished regularly, no one to curate the list | Everything gets to the top: service items, re-uploaded cards, products without stock |
| Selection by the "New arrival" property | Manual selection of new arrivals by a content manager is needed | Requires a regulation: the flag is forgotten to be removed, and the block shows the same thing for months |
| Separate section or infoblock for new arrivals | A curated list with a given order is needed | Duplication of products, desynchronization of prices and stock with the main catalog |
| Manual list of items in the component settings | Display on the home page, strict order control | Does not scale: edits only through a developer, breaks when the assortment changes |
In practice, we more often take a hybrid: automatic selection of products by activity date with a filter by availability and a flag property. The algorithm fills the block itself, and the manager intervenes only to remove the mark from an outdated item.
Work stages: from catalog audit to handover
The new arrivals block is not a static storefront, but a selection from the 1C-Bitrix catalog by conditions: arrival date, new arrival mark, availability, section activity.
If the order of work is violated, the block is assembled "by eye" and falls apart on the very first supplier upload. Therefore, we follow a fixed chain.
- Catalog audit. We analyze infoblocks and trade offers, completeness of properties, duplicates, and empty cards. The output is a list of fields missing for selection and a decision: fix the data or the logic.
- Output design. We fix the novelty period, section priority, number of items, and rotation rule so that the block does not get stuck on old products.
- Selection setup. We assemble the selection taking into account warehouses, prices, and element activity, set up the cache and its reset when the catalog is updated. We separately check the empty result — a placeholder instead of a hole in the layout.
- Load testing. We run the page with a cold and warmed-up cache, measure the response time and the number of database queries. We compare the output with the manual list: a discrepancy in at least one item means going back to design.
- Acceptance of the revision. We agree on test scenarios, show the work on real data, and fix the rollback procedure to the previous block.
- Documentation handover. We provide the selection scheme, instructions for editing conditions, and a memo for the content manager: how to add a property without breaking the sorting.
What we hand over to the project: files, schemes, regulations
After the block is delivered, the project retains not only working pages, but also a set of artifacts by which the catalog can be developed without us. We hand them over to the repository and in a form suitable for a developer who opens the project for the first time.
- Working configuration of the new arrivals block — component, output templates, selection and cache settings, binding to the catalog infoblock.
- Data flow scheme — from 1C upload to the card on the site: which properties are mapped, where items without stock are filtered out, and how the arrival date is determined.
- New arrivals update scheme — exchange schedule, "new arrival" flag, rules for removing the mark after expiration, and block behavior if the exchange fails.
- Publication regulation — procedure: who adds the product, which fields are mandatory before output to the block, how removal from publication is processed.
- Access rights to sections — role matrix: content manager, catalog manager, administrator. It is clear what each can change without risk of breaking the selection.
- Catalog documentation — description of infoblock properties, links with trade offers, and extension points for future tasks.
- Acceptance and maintenance checklist — how to check the block after a catalog update, where to look at exchange logs, and what to do in case of desynchronization with 1C.
We write each document for a specific action, not "for a checkmark": according to the publication regulation, a new employee outputs a product without contacting the developer; according to the update scheme, the duty engineer understands at which step the exchange stopped.
Case study: storefront update without delays
The project is an online store on 1C-Bitrix with a catalog of several thousand items and its own logic for selecting new arrivals.
Managers assembled the "New Arrivals" storefront manually: once a week they went through the arrivals, marked items manually, and arranged the order.
While the catalog was small, this worked — at large volumes, the list became outdated faster than it could be updated, and some items did not reach the storefront at all.
What it was like before the revision
The upload of arrivals went as a single package and had no division into batches.
On a catalog with active discounts and price recalculation, it did not complete: the process stopped in the middle, some items remained with old new arrival flags, and the store showed a product that was no longer in stock. They sorted it out manually — the manager compared the report with what was actually on the site.
What was changed
The selection of new arrivals was moved to rules: date of first arrival, activity mark, binding to a section, lifetime on the storefront. The upload was divided into batches with a checkpoint saved — if interrupted, it continues from the last processed item, not from scratch.
The manual order was replaced with sorting by arrival date with priority for items with stock in the warehouse.
What became
The time for selecting new arrivals was reduced from several hours of manual work to an automatic recalculation on a schedule. Upload failures, which previously occurred on almost every run, are gone: no incomplete runs were recorded during the observation period.
The share of items reaching the storefront in the first 24 hours after arrival grew from about two thirds to full coverage — and the block stopped holding sold-out products.
What to do if the catalog is already built with standard tools?
In most cases, a catalog on standard tools is not a dead end, but a working starting point.
The standard output is built on components, template, and selection parameters, so there is no need to break it entirely: it is enough to override a specific area — sorting, set of fields, selection conditions, card appearance.
Technically, this is done with a custom component template in the site template or a child component. The core remains untouched, which means updates are installed in a standard way, without conflicts and manual file comparison after each release.
We also do not touch the data. The structure of sections, properties, binding of trade offers, prices and stock remain as they are — only the output layer changes. The source of truth remains single, no catalog duplicates or desynchronization between sections appears.
Replacing the output without rewriting the catalog is a separate template section that is connected instead of or alongside the standard one. We keep the old output working: if the new block behaves differently under real load, the rollback is performed by switching one template.
Stopping the site for such a revision is not required. Edits go to a copy, publication is by replacing the template at a moment of low activity, rollback is by the same action in one step.
Partial revision is almost always faster and safer than a complete catalog rebuild, and the laid extension points cover subsequent output edits without repeated intervention.
Frequent technical questions about output revision
The new arrivals section is almost always assembled from already existing catalog entities — properties, sections, trade offers.
Therefore, before starting work, we fix where the selection is calculated, what goes into the cache, and how data comes from the accounting system: both the page response speed and the server load at peak traffic depend on these decisions.
Will the block break caching and indexing?
The new arrivals selection is designed as a separate component with its own cache key tied to the sales start date and the product activity flag. When these fields change, the cache is reset in a targeted way, not for the entire catalog.
For search engines, the section is served with regular links with pagination and correct meta tags, without loading only via script — otherwise new arrival pages fall out of crawling.
How do new arrivals come from the accounting system?
We do not create a second source of truth: the "new product" and "appearance date" attributes come to the catalog along with other fields during exchange.
If the accounting system does not provide such attributes, we add them to the upload rules or calculate them on the site side by the date of first arrival. The update goes in batches so that the exchange does not take all resources for itself.
What happens when the number of products grows?
The layout and queries are designed for growth with a margin: the number of items on a page is limited, the rest goes to paginated output, and the selection runs with indexes on dates and activity. Adding products does not require re-layout — only the number of section pages grows.
Is it necessary to stop the site during work?
No. Edits go to a separate copy, are tested on test data, then transferred to the production environment. Switching takes seconds and does not interrupt order placement; if necessary, we work in a night window.
Let's discuss the task: what is needed to evaluate your output
The evaluation of catalog revision relies on facts, not assumptions, so we start with the inputs. Gather the items listed below — using this data, we will calculate the labor intensity and come back with a work plan for the catalog.
- Access to a test environment or a copy of the production site with a real catalog — the new arrivals selection is not reproduced on a demo installation.
- Assortment structure: number of products and trade offers, properties for selection, regional prices and warehouses.
- Source of the "new arrival" attribute: date of appearance in the catalog, card property, or upload from the accounting system — one source of truth is needed.
- Requirements for update frequency: once a day on a schedule, on an event when a card changes, or during synchronization with the accounting system.
- Display locations and volume: home page, category pages, mobile version, number of items, and block behavior when there are no new arrivals.
- Acceptance criteria: testable scenarios, who confirms the result, and what we consider readiness.
- Already made revisions: custom template, edits in components, extensions — the evaluation will take into account conflicts during updates.
- Accesses and roles: site administrator, repository, upload from the accounting system, who accepts the work.
Using this data, we calculate the scope of edits, the order of rollout to production, and the set of acceptance checks — and come back with an estimate and work plan.