Почему тормозит WooCommerce: HPOS, раздутая база и фоновые задачи

Плагин кеша стоит, картинки сжаты, а магазин на WooCommerce всё равно тормозит: витрина открывается по несколько секунд, оформление заказа подвисает, менеджер ждёт список заказов. Ниже — где магазин теряет время (база данных, очередь фоновых задач, сервер), как проверить это штатными средствами WordPress и WooCommerce и что можно исправить без разработчика.

Где тормозит магазин: витрина, корзина или админка

У магазина на WooCommerce четыре типичных места замедления, у каждого свой симптом.

• Главная, категории и карточки товаров открываются медленно даже у гостя. Измерьте время ответа сервера: в Chrome F12 → Network → запрос самой страницы → Timing, строка Waiting for server response (в документации Chrome — Waiting (TTFB)). Если сервер отвечает долго, причину ищите в запросах каталога к базе, фильтрах и плагинах. Если быстро, а PageSpeed жалуется на скрипты и изображения, проблема во фронтенде — о нём статья про Google PageSpeed Insights.
• Каталог листается нормально, а корзина и оформление заказа идут с паузами. Эти страницы кешировать нельзя, каждый запрос к ним проходит через PHP и базу, а к этому добавляются расчёт доставки, платёжные модули и обращения к внешним сервисам.
• Медленная админка WooCommerce: список заказов, карточка заказа, отчёты. Обычно виновата база: старый способ хранения заказов (раздел про HPOS ниже), очередь фоновых задач или разросшиеся таблицы. Реже — плагины, которые на экране заказа обращаются к внешним сервисам. Есть и менее заметная нагрузка: каждая открытая вкладка админки WordPress раз в 15–120 секунд обращается к серверу через Heartbeat API; пять менеджеров с десятком вкладок у каждого — это постоянный поток запросов.
• Всё работает, но в определённые часы сайт «ложится». Ищите задачи по расписанию: выгрузку цен и остатков из учётной системы, импорт, массовые фоновые задачи, резервное копирование на сервере.

Запишите, на каких страницах и в какое время магазин тормозит сильнее: по этому списку разработчик поймёт, с чего начинать.

Чем измерять

Начните со встроенных инструментов. «Инструменты → Здоровье сайта» в WordPress с версии 6.6 предупреждает, если объём автозагружаемых опций превышает 800 КБ. Там же WordPress проверяет наличие постоянного объектного кеша и кеша страниц; ответ сервера медленнее 600 мс проверка кеша страниц считает проблемой. Обе проверки кеша работают только на рабочем сайте, на тестовой копии их не будет. WooCommerce добавляет сюда свои пункты, в том числе о синхронизации хранилища заказов.

В «WooCommerce → Статус» есть отчёт о системе с блоком «База данных» и размером каждой таблицы. По нему видно, что разрослось: wp_options, wp_postmeta, таблицы actionscheduler_* или wp_woocommerce_sessions (префикс wp_ на вашем сайте может быть другим). Рядом вкладка «Запланированные действия» с очередью фоновых задач.

Бесплатный плагин Query Monitor показывает запросы к базе на открытой странице, помечает медленные, дублирующиеся и ошибочные и группирует их по плагинам и теме — видно, какой плагин тратит больше всего времени. Отдельно он выводит внешние HTTP-запросы со временем ответа: на странице оформления заказа это секунды ожидания службы доставки. Само количество плагинов значит мало: один плагин, который на каждой странице обращается к внешнему сервису, вредит сильнее десяти аккуратных. Ставьте Query Monitor на время диагностики (лучше на тестовой копии) и удаляйте после. Отключать плагины по одному тоже допустимо только на тестовой копии: на рабочем магазине отключённый модуль оплаты или доставки ломает заказы.

На сервере пригодится лог медленных запросов MySQL. По умолчанию он выключен, а порог long_query_time равен 10 секундам — для сайта это много, поэтому на время замеров порог снижают. Настройки MySQL меняют на уровне сервера (на виртуальном хостинге — через поддержку хостера, на VPS — через администратора).

Хранилище заказов HPOS: что изменилось в 2026 году

Долгое время WooCommerce хранил заказы так же, как WordPress хранит записи блога: основная строка заказа в таблице wp_posts, каждое поле (адрес, телефон, способ оплаты, номер накладной) — отдельной строкой в wp_postmeta, вперемешку с данными товаров, страниц и всего остального. Чем больше заказов и товаров, тем дольше база ищет нужную строку в общей таблице.

HPOS (High-Performance Order Storage, высокопроизводительное хранилище заказов) переносит заказы в отдельные таблицы wc_orders, wc_order_addresses, wc_order_operational_data и wc_orders_meta с индексами под типичные запросы магазина. Для новых установок HPOS включён по умолчанию с WooCommerce 8.2 (октябрь 2023). Магазины, запущенные раньше, WooCommerce сам не переводит: переключают вручную.

Текущий режим виден в «WooCommerce → Настройки → Расширенные → Функции» (в английском интерфейсе Advanced → Features), пункт о хранилище заказов. Вариантов три:

1. Старое хранилище на записях WordPress. Заказы в wp_posts и wp_postmeta.
2. Режим совместимости. WooCommerce держит заказы в обоих хранилищах и дублирует каждое изменение. Основным может быть старое хранилище (так начинают переход) или HPOS (так проверяют работу после переключения). Режим нужен на время перехода, чтобы можно было откатиться.
3. HPOS без синхронизации. Конечное состояние.

Что поменяли версии 10.7 и 10.8

WooCommerce 10.7 (вышел 14 апреля 2026) по умолчанию отключил синхронизацию при чтении (sync on read). Раньше в режиме совместимости WooCommerce при открытии заказа подтягивал в HPOS данные, которые какой-то плагин записал напрямую в wp_posts или wp_postmeta. Теперь не подтягивает: если плагин доставки старого образца сохраняет номер накладной функцией update_post_meta, при HPOS этот номер в заказе может не появиться. Разработчик может вернуть прежнее поведение фильтром (хуком WordPress) woocommerce_hpos_enable_sync_on_read, но команда WooCommerce предупреждает, что в будущих версиях этот механизм могут убрать совсем, и советует переписать интеграцию на штатные функции работы с заказами (анонс изменения).

WooCommerce 10.8 (26 мая 2026) добавил индексы в wc_orders и wc_reserved_stock, вернул столбец meta_value в индекс таблицы wc_orders_meta (исправил замедление поиска по метаданным заказов) и сократил число запросов в корзине, архивах товаров и REST API. Версия 10.8 требует WordPress 6.9 или новее: магазин на старом ядре этих улучшений не получит.

Переходить ли на HPOS

Если магазин до сих пор на старом хранилище, мы советуем планировать переход: оптимизации запросов к заказам в 10.7 и 10.8 сделаны для таблиц HPOS, и дальше WooCommerce будет развивать именно их. Порядок:

1. Сделать полную копию сайта на тестовом сервере.
2. Проверить совместимость плагинов. WooCommerce предупреждает на экране «Функции» и в списке плагинов, если плагин заявлен как несовместимый с HPOS. Плагины без такой пометки тоже нужно проверить вручную, в первую очередь доставку, оплату и обмен с учётной системой.
3. Включить режим совместимости и дождаться, пока фоновые задачи перенесут старые заказы (одна задача переносит 25 заказов). В большом магазине разработчик запускает перенос командой wp wc hpos sync, как описано в официальном руководстве для крупных магазинов.
4. Переключиться на HPOS, оставить синхронизацию на время проверки, затем отключить её.

На рабочем магазине без резервной копии переход начинать нельзя. Самое трудоёмкое — проверка интеграций; само переключение занимает несколько кликов. В том же руководстве WooCommerce пишет, что в их тестах включённая синхронизация (пока основным оставалось старое хранилище) заметно не замедляла магазин, так что отключать её ради скорости незачем; отключают после проверки всех плагинов.

Раздутая таблица wp_options: autoload и транзиенты

В таблице wp_options WordPress и плагины хранят настройки. У каждой опции есть признак автозагрузки (autoload): такие опции WordPress загружает при старте на каждом запросе, нужны они этой странице или нет. Документация WordPress предупреждает, что лишняя автозагрузка снижает производительность, особенно если опции используются редко.

Раздувают автозагрузку обычно плагины. Одни пишут в опции логи и кеши. Другие заводят по опции на каждый заказ: в мае 2026 на форуме wordpress.org разбирали плагин доставки, который создал сотни автозагружаемых опций вида _boxnow_parcel_order_id_*. Третьи после удаления оставляют свои данные в базе. С WordPress 6.6 новые опции крупнее 150 КБ по умолчанию не автозагружаются, но накопленное раньше никуда не делось.

Признак проблемы — предупреждение в «Здоровье сайта» о превышении 800 КБ. Дальше разработчик находит самые большие опции, определяет их плагин и решает: отключить автозагрузку, удалить остатки снятого плагина или заменить сам плагин. Удалять опции по маске «похоже на мусор» плагинами-чистильщиками опасно: так стирают настройки работающего модуля оплаты.

Транзиенты — временный кеш, который WordPress по умолчанию хранит в той же wp_options. Срок жизни у них есть, но просроченные записи WordPress чистит нечасто, и в магазине с большим каталогом они копятся. Для них есть безопасная кнопка в «WooCommerce → Статус → Инструменты», пункт про просроченные транзиенты. Если на сервере подключён постоянный объектный кеш (Redis или Memcached), транзиенты хранятся в памяти и таблица опций от них не растёт.

Фоновые задачи: Action Scheduler и WP-Cron

Многое в магазине происходит в фоне: отправка части писем, вебхуки, импорт данных в раздел «Аналитика», перестройка служебных таблиц товаров, перенос заказов в HPOS, задачи плагинов подписок и интеграций. Все эти задачи WooCommerce ставит в очередь Action Scheduler. Очередь хранится в таблицах с префиксом actionscheduler_, посмотреть её можно в «WooCommerce → Статус → Запланированные действия» или в «Инструменты → Запланированные действия».

По умолчанию очередь запускает WP-Cron, не чаще раза в минуту; за проход берётся 25 задач, на обработку отводится до 30 секунд. Сам WP-Cron срабатывает только при открытии страниц сайта: ночью, без посетителей, задачи ждут, а утром выполняются одновременно с запросами покупателей. Выполненные и отменённые задачи Action Scheduler удаляет через 31 день, задачи с ошибкой с версии 4.0 хранит три месяца. Проблемы начинаются в трёх случаях:

• Задачи создаются быстрее, чем выполняются. В статусе Pending тысячи записей, часть просрочена, письма уходят с опозданием, статусы заказов обновляются не сразу.
• Какой-то плагин раз за разом создаёт задачи, которые завершаются ошибкой. Таблица actionscheduler_actions и журнал actionscheduler_logs растут на сотни тысяч строк, админка тяжелеет.
• Таблица повреждена. Летом 2026 на форуме wordpress.org описан случай: при переносе сайта на сервере закончилось место, и MySQL пометил actionscheduler_actions как повреждённую (marked as crashed). Задачи падали без видимых ошибок, аналитика магазина перестала обновляться.

Что можно сделать самому: открыть «Запланированные действия», отфильтровать задачи по статусам Pending (ожидают выполнения) и Failed (ошибка) и посмотреть столбец с именем хука — по нему обычно понятно, какой плагин создаёт задачи. Массово удалять ожидающие задачи нельзя: среди них могут быть письма покупателям и продления подписок.

Остальное — работа разработчика или администратора сервера. Для больших сайтов документация Action Scheduler рекомендует запускать очередь через WP-CLI, а не через WP-Cron (рекомендации по производительности). На практике это три действия: отключить запуск WP-Cron при открытии страниц строкой define( 'DISABLE_WP_CRON', true ); в wp-config.php, настроить системный cron на сервере, очистить старые записи командой wp action-scheduler clean. Увеличивать число параллельных потоков очереди без замеров не советуем: та же документация предупреждает, что это может уронить сайт.

Корзина, сессии и кеш страниц

Кеш страниц сохраняет готовый HTML и отдаёт его следующим посетителям, не собирая страницу заново и не обращаясь к базе. Для каталога это работает хорошо. Корзину, оформление заказа и личный кабинет WooCommerce требует из кеша исключать, потому что на этих страницах данные конкретного покупателя (документация по настройке плагинов кеша). Кроме того, у покупателя с товаром в корзине появляются cookie woocommerce_items_in_cart, woocommerce_cart_hash и wp_woocommerce_session_…, и многие системы кеширования по этим cookie отдают посетителю страницы в обход кеша. Поэтому плагин кеша ускоряет только просмотр каталога гостями, а скорость оформления заказа — момента, когда магазин зарабатывает, — определяют PHP, база, плагины доставки и оплаты.

Cart fragments: запрос на каждой странице

Скрипт wc-cart-fragments обновляет мини-корзину в шапке: после загрузки страницы браузер отправляет AJAX-запрос ?wc-ajax=get_refreshed_fragments, который не кешируется. С WooCommerce 7.8 скрипт подключается только вместе с виджетом мини-корзины, но многие темы подключают его сами. Проверка: откройте любую страницу магазина в Chrome, нажмите F12, на вкладке Network введите в поиск get_refreshed_fragments. Если запрос есть, каждая просмотренная страница даёт серверу дополнительное обращение к PHP в обход кеша; если запрос ещё и отвечает медленно, счётчик корзины в шапке обновляется с задержкой. Отключать скрипт можно только после проверки, что счётчик корзины продолжит обновляться. Иногда проще заменить мини-корзину темы на блок Mini Cart.

Сессии покупателей

Сессии покупателей вместе с содержимым корзин WooCommerce хранит в таблице wp_woocommerce_sessions. Сессия гостя по умолчанию живёт двое суток, затем её удаляет фоновая задача (в текущих версиях WooCommerce — из той же очереди Action Scheduler). Если очередь стоит, таблица сессий растёт. Растёт она и из-за ботов, которые переходят по ссылкам «Добавить в корзину»: каждый переход создаёт сессию. В «WooCommerce → Статус → Инструменты» есть кнопка удаления сессий, но она очищает корзины всех текущих покупателей, поэтому нажимать её можно только в спокойное время и понимая последствия.

Внешние запросы при оформлении

При смене адреса или способа доставки страница оформления пересчитывает стоимость. Если модуль доставки при каждом пересчёте обращается к API перевозчика и не кеширует ответы, покупатель ждёт ответа чужого сервера. Query Monitor показывает такие задержки в разделе HTTP-запросов. Лечится доработкой модуля: кешированием справочников отделений и тарифов, тайм-аутами, загрузкой справочников по расписанию.

Каталог, фильтры и обмен с учётной системой

Возьмём магазин с вариативными товарами и фильтром по двадцати характеристикам. Каждая вариация (размер, цвет) хранится в базе отдельной записью типа product_variation со своей ценой, остатком и атрибутами. Если фильтр показывает число товаров рядом с каждым значением, при каждом клике он пересчитывает эти числа для всех значений всех характеристик. Без подходящих индексов такие подсчёты становятся самыми тяжёлыми запросами сайта.

Для ускорения фильтрации у WooCommerce есть служебная таблица атрибутов товаров (product attributes lookup table); сторонние плагины фильтров строят собственные индексы. Откройте в Query Monitor страницу категории с включёнными фильтрами и посмотрите, какие запросы самые долгие и какой плагин их делает. Если тормозит плагин фильтра, поможет настройка его индексации или замена плагина. Со штатным фильтром разработчик проверяет, заполнена ли служебная таблица атрибутов и включено ли её использование.

Отдельная тема — обмен с учётной системой. Типичная схема: раз в несколько минут на сайт загружается полный прайс со всеми остатками. Каждое сохранение товара сбрасывает его транзиенты, ставит в очередь задачу на обновление таблицы атрибутов и запускает обработчики всех плагинов, подписанных на это событие. Магазин тормозит волнами, по расписанию выгрузки. Мы советуем передавать только изменившиеся позиции, а полные выгрузки переносить на ночь и запускать системным cron или из командной строки, без веб-запросов.

Хостинг: версия PHP, объектный кеш, ресурсы

Хостинг проверяют после диагностики, а не вместо неё. Переезд на VPS не исправит запрос, который перебирает сотни тысяч строк: тот же запрос выполнится чуть быстрее, и только.

• Версия PHP. WooCommerce рекомендует PHP 8.3 или новее. WooCommerce 11.6, запланированный на февраль 2027, потребует минимум PHP 8.1. У PHP 8.2 поддержка безопасности заканчивается 31 декабря 2026 года; о переходе — статья про конец поддержки PHP 8.2.
• Постоянный объектный кеш. Redis или Memcached держат в памяти данные, которые WordPress иначе на каждом запросе заново достаёт из базы; туда же попадают транзиенты. «Здоровье сайта» сообщит, если по размеру сайта WordPress считает объектный кеш полезным. На виртуальном хостинге такой кеш часто недоступен.
• OPcache. Расширение PHP, которое держит скомпилированный код в памяти, чтобы PHP не загружал и не разбирал файлы WordPress и плагинов на каждом запросе. На большинстве хостингов OPcache уже включён; если нет, его включают в первую очередь — спросите хостера или администратора сервера.
• Ресурсы. Корзину, оформление заказа, админку, фоновые задачи и ботов обслуживают одни и те же PHP-процессы. Когда процессов не хватает, запросы встают в очередь, и магазин тормозит весь сразу. Это видно по логам сервера и графикам нагрузки; тест скорости одной страницы такого не покажет.

Что сделать самому, а что — разработчику

Самостоятельно и без риска для данных:

• посмотреть «Инструменты → Здоровье сайта» и записать все предупреждения о производительности;
• в «WooCommerce → Статус» найти самые большие таблицы базы;
• открыть «Запланированные действия» и посчитать задачи в статусах Pending и Failed;
• проверить в «Настройках → Расширенные → Функции», какое хранилище заказов включено;
• найти в браузере запрос get_refreshed_fragments и посмотреть время ответа;
• узнать в панели хостинга версию PHP;
• удалить плагины, которыми давно не пользуются (сначала убедившись, что они не нужны оплате, доставке или обмену);
• очистить просроченные транзиенты кнопкой в «WooCommerce → Статус → Инструменты».

Разработчику или администратору сервера:

• перевод на HPOS и проверка интеграций, которые пишут заказы напрямую в wp_postmeta;
• разбор wp_options и отключение лишней автозагрузки;
• очистка таблиц Action Scheduler, перевод очереди и WP-Cron на системный cron;
• лог медленных запросов, индексы, настройка фильтров каталога;
• подключение объектного кеша, обновление PHP, распределение ресурсов сервера;
• переделка обмена с учётной системой.

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

Как с этим помогает RIVERIT

Берём магазины на WooCommerce на техподдержку WordPress: обновляем ядро и плагины (обычно ежемесячно), делаем резервные копии, следим за доступностью сайта. Клиентам на поддержке отвечаем в течение часа, аварии исправляем и в нерабочее время, если это входит в тариф. Диагностику и исправления из этой статьи, от перевода на HPOS до переделки интеграций, выполняем как доработки. Магазины на VPS или выделенном сервере берём на администрирование: анализируем логи, настраиваем сервер, изолируем сайты друг от друга. Если старый магазин проще пересобрать, чем лечить, предлагаем разработку интернет-магазина.