Корзина грузилась 6.5 секунды: как мы перестали дёргать курьера и банк на каждой странице
Страница корзины крупного интернет-магазина открывалась 6.5–13.5 секунды. SQL был быстрым, а всё время съедал PHP. Разбираем профилирование компонента корзины и одну настройку, которая сократила отрисовку с 6.5 секунды до 189 миллисекунд.
Симптом
Крупный интернет-магазин на 1С-Битрикс (BitrixVM, 24 ГБ RAM). Страница /personal/cart/ открывалась 6.5–13.5 секунды. При этом debug-панель показывала: SQL быстрый — 245 запросов за 0.1 секунды. Тормоз был не в базе, а в PHP: 98% времени уходило внутрь компонента корзины.
Разведка
Расставили временные таймеры по вызовам внутри компонента. Всплыло 18 последовательных операций, и главный виновник — getOrderInfo(): 6.5 секунды из 6.6. Внутри него — getDeliveries() (3.1 с) и getPaySystems() (3.1 с).
Причина
Обработчики служб доставки и платёжных систем на этом проекте при расчёте ходили во внешние API — в систему курьера и в банк — с сетевым таймаутом. И делалось это прямо на странице корзины, хотя реальные варианты доставки и оплаты нужны покупателю только на шаге оформления заказа. То есть на каждый показ корзины сайт синхронно ждал ответа сторонних сервисов.
Что сделали
Отключили расчёт этих данных на самой корзине — параметр компонента CALCULATE_ORDER_DATA переключили с Y на N. Расчёт доставки и платёжек остался там, где он действительно нужен, — на странице оформления заказа.
Результат
Время внутри компонента упало с 6.5 секунды до 189 миллисекунд; полная отрисовка страницы с прогретым кэшем — около 1.2 секунды. Ни строчки в ядре, ни отключённой функциональности — просто перенос тяжёлого расчёта туда, где он к месту. Такие вещи не находятся «на глаз»: нужен профайлер и понимание, что именно делает штатный компонент под капотом.
Имя клиента не раскрываем по NDA. Цифры и подход — реальные.