Задача и границы решения
Страница каталога может отдельно запрашивать свойства каждого товара. При росте числа карточек это превращается в повторяющуюся нагрузку, незаметную на маленьком тестовом каталоге.
Как подойти к задаче
Сгруппируйте одинаковые запросы и проверьте, как их количество меняется с размером страницы. Определите нужные поля вместо загрузки всего объекта. Объединение выборок и индексы оценивайте по плану выполнения и объёму данных.
Что проверить на практике
Сравните раздел на десять и на сто товаров, холодный и прогретый кеш. Следите за памятью: уменьшение числа запросов не должно превращаться в загрузку всего каталога ради одной страницы.
Какой ошибки избежать
Не добавляйте индекс на каждое поле наугад. Индексы занимают место и влияют на запись. Изменение должно соответствовать реальному условию выборки, а результат — подтверждаться замером.
Пример для проверки на вашем проекте
На странице из двадцати товаров выполняется двадцать похожих запросов к одному справочнику. Если увеличить выдачу в пять раз, нагрузка растёт вместе с ней. Возможное решение — получить необходимые значения одной выборкой и сопоставить их в памяти. Но в тесте также измеряют объём загруженных данных: нельзя ради сокращения запросов каждый раз читать весь многомиллионный справочник.
Диагностика вместо предположений
Для измерений выбираем типовые страницы и фиксируем устройство, сеть и состояние кеша. Смотрим серверный ответ, обращения к БД, размер ресурсов и работу браузера. Результат диагностики — список узких мест с ожидаемым влиянием, а не предложение заменить всё окружение. Приоритет получает изменение, которое улучшает важный пользовательский сценарий.
Как подтверждается улучшение
Каждое изменение сравнивается с исходным замером в тех же условиях. Проверяем функциональную корректность: персональные цены, корзина и авторизация не должны пострадать ради скорости. Отдельно описываем ограничения внешних сервисов. Заказчик получает результаты измерений и рекомендации по наблюдению за проектом после запуска.