Why a Large 1C-Bitrix Catalog Lags Even When Displaying Only Twenty Products

На странице всего двадцать товаров, а открывается она несколько секунд. Фотографии уже уменьшили, тариф хостинга повысили, но покупатель всё ещё ждёт. Иногда причина находится не в этих двадцати карточках, а в работе, которую сервер выполняет перед их показом.

15 сентября 2026 года в документации BitrixFramework обновили материалы о постраничной навигации. Среди описанных приёмов есть отказ от точного подсчёта всех записей там, где он не нужен. Это не новая волшебная кнопка ускорения, а повод проверить логику большого каталога.

Чтобы написать «найдено 48 327 товаров», система должна получить общее количество подходящих записей. При сложных фильтрах такой запрос может оказаться дороже самой выдачи первой порции. Особенно если каталог вырос, а прежнюю схему запросов никто не пересматривал.

Попросите разработчика раздельно измерить получение товаров и вычисление общего числа. Затем повторите замер с популярными сочетаниями фильтров. Проверка только пустого фильтра не показывает, что происходит при выборе бренда, наличия, размеров и нескольких характеристик сразу.

Если задержку создаёт совсем другой запрос, удаление счётчика не поможет. Решение нужно принимать по измерениям, а не по внешнему сходству симптомов.

В истории действий или длинном списке служебных записей человеку часто достаточно кнопки перехода дальше. Можно запросить чуть больше элементов, чем помещается на страницу, и понять, существует ли продолжение. Такой подход описан и в документации.

В товарном каталоге ситуация сложнее. Количество результатов помогает покупателю оценить, насколько сузился выбор. Убирать его везде без проверки поведения пользователей я бы не стала. Иногда правильнее ускорить подсчёт, изменить фильтр или пересмотреть кеширование.

Кнопка «Показать всё» заслуживает отдельного внимания. Для раздела из тридцати позиций она безобидна, а для десятков тысяч может создать тяжёлый запрос и огромную страницу. Ограничение должно соответствовать реальному размеру каталога.

После изменений проверьте возвращение из карточки, сохранение сортировки и работу фильтров. Покупатель, просмотревший несколько страниц, не должен каждый раз попадать в начало списка. Важно и то, что происходит при исчезновении товара или изменении остатков между переходами.

Приёмочные испытания лучше проводить на копии с реалистичным объёмом данных. Маленький демонстрационный каталог скрывает именно те проблемы, ради которых затевалась оптимизация. Хороший результат — предсказуемое время ответа на нужных покупателю сценариях, а не просто красивая цифра в тесте главной страницы.

The page displays only twenty products, yet it takes several seconds to load. Images have already been resized, and the hosting plan has been upgraded, but the buyer is still waiting. Sometimes the cause lies not in those twenty product cards, but in the work the server performs before displaying them.

On September 15, 2026, the BitrixFramework documentation updated its materials on pagination. Among the described techniques is abandoning exact counting of all records where it is unnecessary. This is not a new magic button for acceleration, but a reason to review the logic behind large catalogs.

To display "48,327 products found," the system must retrieve the total count of matching records. With complex filters, such a query can be more expensive than fetching the first batch of results. This is especially true if the catalog has grown while the previous query scheme has gone unreviewed.

Ask the developer to measure product retrieval and total count calculation separately. Then repeat the measurement with popular filter combinations. Checking only an empty filter does not reveal what happens when a brand, availability, sizes, and multiple attributes are selected simultaneously.

If the delay is caused by a completely different query, removing the counter will not help. The solution must be decided based on measurements, not on superficial symptom similarity.

In an action history or a long list of records, a user often only needs a 'Next' button. You can request slightly more items than fit on a page to determine if there is a continuation. This approach is also described in the documentation.

The situation is more complex in a product catalog. The result count helps shoppers assess how much their selection has narrowed. I would not recommend removing it everywhere without checking user behavior. Sometimes it is better to speed up the count, adjust the filter, or review caching.

The 'Show All' button deserves separate attention. For a section with thirty items, it is harmless, but for tens of thousands, it can create a heavy query and an enormous page. The limit must correspond to the actual catalog size.

After the changes, verify the return from the product card, sorting persistence, and filter functionality. A shopper who views multiple pages must not be redirected to the beginning of the list each time. It is also critical to account for what happens when a product disappears or stock levels change between page transitions.

Acceptance testing should be performed on a copy with a realistic data volume. A small demonstration catalog hides the very issues that prompted the optimization. A good result is predictable response times for shopper-relevant scenarios, not just a high score on the homepage test.