WooCommerce на 50 тысячах товаров: что сломается первым

Каталог WooCommerce с 50 тысячами товаров не обязательно медленный: решает не только размер базы, но и то, как магазин ищет товары, строит фильтры и выполняет фоновые задачи. Под нагрузкой первым обычно страдает не «лимит товаров», а конкретный узкий участок — запрос к каталогу, база данных или очередь задач. Без замеров называть универсальный порог нельзя: одна и та же установка выдерживает разную нагрузку в зависимости от оборудования, темы, плагинов, кэша и структуры каталога.

Почему число товаров не предсказывает поломку

WooCommerce хранит данные товаров в WordPress и собственных таблицах. Запросы каталога могут учитывать категорию, цену, наличие, атрибуты и сортировку. Когда посетитель включает несколько фильтров, магазин должен найти подходящие товары и посчитать результат. Цена запроса зависит от данных и способа их чтения, а не только от общего количества карточек.

В WooCommerce есть таблица поиска по товарам wc_product_meta_lookup, которая хранит часть значений, важных для каталога, например цену и наличие. Она помогает выполнять некоторые операции, но не превращает любой фильтр или поиск в дешёвый запрос. Плагины фильтрации могут добавлять собственные таблицы, запросы и правила индексации. Поэтому важный вопрос — не «есть ли lookup-таблица», а «какой SQL выполняется на конкретном медленном URL».

Термин: индекс базы данных — структура, которая помогает находить строки по заданным полям без полного перебора таблицы. Индексы ускоряют одни запросы, но занимают место и требуют обновления при изменении данных.

50 тысяч товаров — не диагноз. Диагноз начинается с конкретного медленного запроса и того, как часто он повторяется.

Что обычно ломается первым

Категории и фильтры

Страница категории с сортировкой по цене и несколькими атрибутами может быть тяжелее главной, даже если на ней выводится всего несколько десятков товаров. Особенно рискованны фильтры, которые строят отдельные запросы на каждый параметр или пересчитывают количество результатов при каждом изменении. Если посетители часто используют комбинации фильтров, база получает повторяющуюся нагрузку, а время ответа растёт.

Проверяйте не только обычную категорию, но и реальные URL с параметрами фильтрации. Запишите время ответа, число запросов к базе и медленные SQL-запросы. Сравните страницу без фильтров с той же страницей после выбора атрибута и диапазона цены. Если разница появляется только на комбинациях, менять сервер «на всякий случай» может оказаться дороже, чем исправить запрос фильтра.

Поиск по каталогу

Стандартный поиск WordPress не равен полноценному поисковому движку. Большой каталог, поиск по SKU, синонимам и нескольким полям часто требует дополнительных плагинов или внешнего сервиса. Под нагрузкой поиск может конкурировать с категориями за ресурсы базы, особенно когда каждый запрос посетителя запускает широкий поиск по данным товаров.

Смотрите, что именно ищет покупатель: название, артикул, атрибуты или содержимое описания. От этого зависит и решение, и цена внедрения. Внешний поиск добавляет инфраструктуру и синхронизацию индекса; специализированный плагин — зависимость от его реализации и совместимости с темой.

Кэш и персональные страницы

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

Отдельно проверьте объектный кэш. Он может сокращать повторные обращения WordPress к базе, но не исправляет плохой SQL и не гарантирует, что тяжёлый фильтр станет быстрым. Кэширование также требует контроля инвалидации: изменение цены или наличия должно отражаться в каталоге, а не оставаться скрытым до истечения срока хранения.

Фоновые задачи и импорт

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

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

Где предел и как его измерить

Универсальной цифры вроде «на 50 тысячах товаров нужен сервер такого-то размера» нет. Пиковое число посетителей, доля запросов кэш-хитов, объём вариантов товара, тяжесть темы и настройки базы меняют результат. Сначала зафиксируйте исходные условия и воспроизводимый сценарий, а затем сравнивайте изменения на том же наборе запросов.

Не снимайте выводы по одному быстрому тесту. Проведите тест на копии магазина или в согласованное окно, используя запросы, похожие на реальные. Отдельно проверьте обычную категорию, фильтр, поиск, карточку и оформление заказа. Запишите версии WooCommerce, WordPress, PHP, базы данных и плагинов: иначе сравнение до и после может оказаться бессмысленным.

Граничные случаи: когда обычные меры не помогают

Увеличение числа PHP workers не ускорит запрос, который долго выполняется в базе; напротив, оно может увеличить число одновременно работающих тяжёлых запросов. Добавление кэша не поможет странице, где всё время меняются персональные данные. Индексирование тоже не универсальная кнопка: индекс должен соответствовать запросу, а его создание и обновление имеют цену.

Сложные товары с большим числом вариаций и атрибутов могут нагружать магазин иначе, чем 50 тысяч простых товаров. Импорт, который массово меняет цены, способен сбросить кэш и вызвать дополнительную работу. А внешний поисковый сервис требует следить за тем, успевает ли индекс обновляться после изменений в каталоге.

• Если медленна только одна комбинация фильтров — исследуйте запрос плагина и его настройки индексации.
• Если медленны все динамические страницы — проверьте базу, PHP workers и плагины, которые выполняются на каждом запросе.
• Если проблема совпадает с импортом — измерьте длительность и параллельность фоновых задач.
• Если каталог быстрый, а оформление заказа нет — разбирайте checkout отдельно: его нельзя оценивать по скорости категорий.

Что делать дальше

Начните с журнала медленных запросов и профиля одного проблемного URL, а не с покупки более дорогого сервера. Сопоставьте медленные SQL с фильтром, поиском или фоновым заданием, затем меняйте по одному фактору и повторяйте тот же тест. После исправления следите за временем ответа, очередью задач, ошибками и свежестью цен и наличия. Конкретные настройки профилировщика и кэширования зависят от хостинга и плагинов; проверяйте их документацию для установленной версии WooCommerce.