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

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

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

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

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

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

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

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

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

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

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

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

On September 15, 2026, the BitrixFramework documentation was updated with materials on pagination. Among the described techniques is avoiding the exact count of all records where it is unnecessary. This is not a new magic speed button, but an opportunity to review the logic of a large catalog.

To display '48,327 items found', the system must retrieve the total count of matching records. With complex filters, such a query can cost more than fetching the first batch of results. This is especially true if the catalog has grown while the original 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 determined by measurements, not by superficial similarity of symptoms.

In an action history or a long list of service 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 more content. This approach is also described in the documentation.

The situation in the product catalog is more complex. The number of results helps shoppers assess how much their selection has narrowed. I would not remove it everywhere without checking user behavior. Sometimes it is better to speed up the count, adjust the filter, or reconsider caching.

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

After making changes, verify returning from the product card, sorting persistence, and filter functionality. A shopper who views multiple pages should not be sent back to the start of the list each time. It is also important to consider what happens when a product disappears or stock levels change between page transitions.

Receiving is best performed on a copy with a realistic data volume. A small demonstration catalog hides exactly the problems that prompted the optimization. A good result is predictable response times for the buyer's relevant scenarios, not just a pretty number in the main page test.