Третья страница «обувь» крутится девять секунд. Большое фото ещё даже не начинало ехать: пауза до того, как страница вообще начала приходить, уже восемь секунд. В журнале визитов этот адрес в топе. Хостер пишет про восемь ядер. На копии видно другое: список товаров раздела (catalog.section) для каждой пары отдельно спрашивает свойства, цену и склад. Тридцать пар — сотня походов в базу. Покупатель смотрит на крутилку и считает магазин пустым.
Человек не отличит «база думает» от «сайт умер». Он закроет вкладку и купит там, где сетка обуви уже на экране. Ядра эту сетку не нарисуют, пока шаблон ходит в базу по кругу.
Проблема
На копии включают журнал медленных обращений к базе и открывают тот же адрес три раза. В админке «Производительность» смотрят, сколько работы пришлось на сборку страницы. В настройках списка — какие свойства вообще просят: часто тащат всё «на всякий случай», хотя на экране размер, цена и бейдж. Сортировка «по свойству из учёта, которое меняют раз в год» на первом экране стоит секунд и почти никому не нужна.
- Убрать из выборки то, чего нет на карточке в сетке.
- Не ходить в базу внутри цикла «для каждой пары». Один запрос на все сразу.
- На странице двадцать пар — не выбирать шестьдесят «про запас».
- Сохранённая копия списка должна срабатывать на втором заходе.
Причина
Решение
Индекс помогает, когда запрос один и тот же. Если шаблон делает триста мелких вопросов, индекс только ускорит каждый из трёхсот. Сортировка по множественному свойству часто не умеет работать так быстро, как ждёт владелец. Служебные поля выгрузки из учёта в фильтре добавляют ещё один круг — человек их не видит, а ждёт.
Пик в минуты обмена с учётом — другая история: диск и база заняты загрузкой. Если журнал красный всю неделю на одном адресе раздела — виноват шаблон, не «1С по утрам». Лечить одним тикетом нельзя. Человек на третьей странице уже выбрал размер в голове: ещё три секунды крутилки — и он возвращается в поиск, не в вашу сетку.
Число обращений к базе на том же адресе гостя, время в «Производительность», повторный заход без той же пачки вопросов. Фильтр по одному размеру не должен превращаться в полный перебор каталога. В 2026-м у актуальной базы нет старого «ускорителя запросов как в восьмёрке MySQL» — его не включают «как раньше».
Он уже выбрал фасон. Листает. Крутилка на девять секунд выглядит как пустой склад. Реклама привела его на первую страницу, а размер часто на третьей. Пока база отвечает на сотню мелких вопросов, сосед в выдаче уже показывает сетку. Это не «пользователь нетерпеливый». Это вы заставили его ждать учётную работу шаблона.
- Индекс помогает, когда запрос один и тот же.
- Если шаблон делает триста мелких вопросов, индекс только ускорит каждый из трёхсот.
- Сортировка по множественному свойству часто не умеет работать так быстро, как ждёт владелец.
- Служебные поля выгрузки из учёта в фильтре добавляют ещё один круг — человек их не видит, а ждёт.
Проверка
Пока не сняли журнал медленных вопросов на копии, тариф не покупают. Пока список ходит по кругу, не ускоряют подвал и не спорят про частоту процессора. Боевые настройки базы не крутят вслепую: сначала копия и архив. Если после выноса лишнего второй заход раздела стал коротким, покупатель наконец видит сетку, а не крутилку — это и есть результат, не письмо «мы добавили ядра».
Чек-лист
- Индекс помогает, когда запрос один и тот же.
- Если шаблон делает триста мелких вопросов, индекс только ускорит каждый из трёхсот.
- Сортировка по множественному свойству часто не умеет работать так быстро, как ждёт владелец.
- Служебные поля выгрузки из учёта в фильтре добавляют ещё один круг — человек их не видит, а ждёт.
Назад в раздел
