Как ускорить WooCommerce — пошаговая оптимизация магазина

Почему WooCommerce может тормозить

WooCommerce в отличие от обычного блога часто выполняет больше PHP-кода и запросов. Даже обычная страница WordPress на сайте с WooCommerce может выполнять дополнительную работу: подключаются файлы WooCommerce, тема и расширения, используются куки и сессии, фрагменты корзины и другие динамические функции. Конкретная нагрузка зависит от версии WooCommerce, темы, блоков, расширений и настроек, поэтому одинаковый магазин на разных конфигурациях ведёт себя по-разному. Разберём четыре частые группы причин.

1. Page cache настроен без учёта динамических страниц магазина

Для WooCommerce page cache должен быть настроен с учётом динамических страниц. Корзина и checkout должны исключаться из общего page cache. Личный кабинет также требует учёта персонализированного содержимого. Конкретные правила зависят от используемого кэш-плагина и серверного кэша. Если /checkout/ или /cart/ ошибочно отдаются из общего page cache, это может привести к устаревшему содержимому корзины, проблемам с AJAX-запросами checkout и другим ошибкам. Подробно механику я разбирал в статье про неработающий checkout WooCommerce.

Пример: LiteSpeed Cache автоматически исключает Cart, Checkout и My Account из page cache для WooCommerce — это указано в документации LiteSpeed. Это не означает, что любой LiteSpeed Cache по умолчанию ломает корзину — важно проверить актуальные исключения в настройках конкретного сайта. В LiteSpeed Cache для WooCommerce также может использоваться ESI (Edge Side Includes), позволяющий кэшировать публичную часть страницы и отдельно обрабатывать приватные динамические элементы, например мини-корзину. Не нужно автоматически отключать весь page cache WooCommerce, если конкретная конфигурация корректно использует ESI.

На хостинге также может быть включён серверный page cache (Nginx FastCGI Cache, Varnish или другой механизм, если он используется). Название и расположение настроек зависят от тарифа и панели управления.

2. База данных выросла: postmeta, options, сессии и Action Scheduler

Каждый товар — это запись в wp_posts плюс строки в wp_postmeta (цена, остатки, атрибуты, галерея). Точное количество зависит от типа товара, вариаций и расширений. При классическом хранении заказов WooCommerce использует wp_posts и wp_postmeta, причём количество мета-записей зависит от состава заказа, его статуса и установленных расширений.

Дополнительно растут таблицы Action Scheduler (wp_actionscheduler_actions, wp_actionscheduler_logs), сессии WooCommerce (wp_woocommerce_sessions) и autoloaded options в wp_options. В результате база может значительно вырасти, но её размер нельзя достоверно оценить только по количеству товаров. При активном использовании магазина таблица wp_woocommerce_sessions также может накапливать данные о клиентских сессиях. На размер особенно влияют вариации, заказы, postmeta, Action Scheduler, логи плагинов и содержимое wp_options.

На странице списка товаров могут выполняться тяжёлые запросы к posts/postmeta, таблицам таксономий и данным плагинов. Отдельно большой объём autoloaded options увеличивает стоимость загрузки WordPress на каждом запросе. Эти две причины нужно диагностировать отдельно. Подробнее про раздутый wp_options и админку — почему тормозит админка WordPress, у магазина эффект может усиливаться.

3. Неоптимизированные изображения товаров

Один товар может иметь пять фото по 2 МБ — уже 10 МБ. Категория на 12 товаров при неудачной подготовке изображений может потребовать десятки мегабайтов. Неоптимизированные изображения могут существенно увеличить объём страницы и ухудшить LCP, при этом браузер параллельно загружает ресурсы и начинает строить страницу по мере их получения — не «сначала всё скачивает, потом рендерит».

Важно оценивать не только расширение файла, но и реальный размер, размеры изображения, responsive images и правильную загрузку. На скорость влияет и количество запросов, и формат, и CDN, и кэширование, а не только один фактор.

4. Устаревшая версия PHP, ограничения памяти и способ хранения заказов

PHP 7.4 формально может оставаться совместимым с некоторыми версиями WooCommerce, но PHP 7.4 достиг EOL в ноябре 2022 года. Для актуального магазина WooCommerce рекомендуется использовать PHP 8.3 или новее. Переход с устаревшей версии PHP на современную может заметно сократить время выполнения PHP-кода, но конкретный прирост зависит от темы, плагинов и нагрузки — нельзя гарантировать «заметно быстрее» для любого магазина.

Малый memory_limit чаще приводит к ошибкам и невозможности выполнить тяжёлую операцию (например, открытие списка товаров с фильтрами), а не автоматически делает каждый запрос медленнее. Значение нужно подбирать по фактической потребности, а не ставить фиксированные 512M как обязательную норму.

HPOS (High-Performance Order Storage) появился в WooCommerce как развитие Custom Order Tables, а стабильным и включённым по умолчанию для новых установок стал начиная с WooCommerce 8.2 (октябрь 2023 года). HPOS хранит данные заказов в специализированных таблицах WooCommerce вместо стандартных wp_posts и wp_postmeta с индексами, предназначенными для работы с заказами. HPOS использует специализированные таблицы:
wp_wc_orders,
wp_wc_order_addresses,
wp_wc_order_operational_data,
wp_wc_orders_meta
(префикс wp_ может отличаться). Это уменьшает количество операций с общими таблицами WordPress и может заметно улучшить производительность операций с заказами, особенно на магазинах с большим количеством заказов. Точный прирост зависит от магазина, запросов и используемых плагинов. На каталог товаров HPOS напрямую не влияет — это прежде всего хранение заказов.

Как ускорить WooCommerce пошагово — от измерения к точечным исправлениям

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

Шаг 1. Измерьте, где именно тормозит

Без замера легко лечить не ту причину. Для первого измерения используйте Query Monitor и инструменты хостинга. Slow query log имеет смысл включать на VPS или выделенном сервере, если у вас есть необходимые права и вы понимаете влияние настройки — на shared-хостинге у пользователя обычно нет прав на изменение глобальных настроек MySQL/MariaDB.

# Размер autoloaded options
# Для старых баз также могут встречаться значения yes/no
wp db query "SELECT COUNT(*), SUM(LENGTH(option_value))/1024/1024 AS mb FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto');"
 

# Размер таблиц WooCommerce и Action Scheduler
# В SQL замените wp_ на фактический префикс таблиц вашего сайта. Набор таблиц зависит от версии Action Scheduler и конфигурации; при необходимости сначала определите фактические таблицы базы данных. таблиц вашего сайта
SELECT table_name, ROUND(data_length/1024/1024,1) AS mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
AND (
  table_name LIKE 'wp_wc_%'
  OR table_name LIKE 'wp_actionscheduler_%'
)
ORDER BY data_length DESC;

В современных версиях WordPress используются значения on, off, auto-on, auto-off и auto. Значения yes и no сохраняются для обратной совместимости. Из них autoload выполняется для on, yes, auto-on и auto. Для старых версий WordPress достаточно учитывать yes; перед выполнением SQL проверьте фактические значения autoload в базе.

В Query Monitor смотрите не только количество запросов, но и их суммарное время, самые медленные запросы, HTTP API calls, PHP errors, хуки и запросы конкретных плагинов. 120 запросов сами по себе не означают проблему с базой — 120 быстрых запросов могут быть быстрее пяти плохо оптимизированных.

Для проверки page cache используйте режим, предусмотренный вашим кэш-плагином или сервером, либо временно очистите соответствующий кэш. Параметр вроде ?nocache=1 сам по себе ничего не делает, если сервер или плагин специально его не обрабатывает.

Шаг 2. Настройте кэш правильно — исключите динамические страницы

Правило: кэшируем статику и публичные страницы, но динамические страницы магазина не должны превращаться в общий page cache. Page cache сохраняет готовый HTML и позволяет не выполнять WordPress/PHP для повторного запроса. Object cache (например, Redis) сохраняет результаты отдельных операций WordPress/PHP и не является заменой page cache. Для WooCommerce оба механизма могут использоваться одновременно, но динамические страницы нельзя кэшировать как общие публичные страницы.

LiteSpeed Cache:

LiteSpeed Cache → Cache → Excludes → Do Not Cache URIs:
/cart/
/checkout/
/my-account/
/wc-api/*
/wc-ajax/*

Проверьте актуальные исключения в документации вашей версии плагина. LitеSpeed уже исключает Cart/Checkout/My Account по умолчанию, но дополнительные пути вроде /wc-api/* стоит проверить.

WP Rocket:

Настройки → Дополнительно → Никогда не кэшировать URL:
/cart/ (.*)
/checkout/ (.*)
/my-account/ (.*)

На хостинге также проверьте серверный page cache (Nginx FastCGI Cache, Varnish или другой механизм, если он используется). Название и расположение настроек зависят от тарифа и панели управления.

Пример логики исключения для FastCGI cache:

if ($request_uri ~* "/(cart|checkout|my-account|wc-ajax|wc-api)/") { set $skip_cache 1; }
if ($http_cookie ~* "woocommerce_items_in_cart|wp_woocommerce_session") { set $skip_cache 1; }

Не добавляйте cookie-правила вслепую — проверьте, какие cookies и правила поддерживает конкретная система кэширования.

Cloudflare: динамические страницы корзины и checkout должны обрабатываться с учётом сессии и не должны кэшироваться как общие публичные страницы. Cloudflare может уменьшить время доставки статических ресурсов и использовать CDN и edge-инфраструктуру. Реальный эффект для динамического WooCommerce зависит от маршрута пользователя, origin-сервера, настроек кэширования и региона. Лимиты Cloudflare зависят от продукта и тарифа.

Шаг 3. Почистите базу аккуратно и проверьте HPOS и lookup-таблицы

Сделайте резервную копию перед любыми действиями с базой: на Beget — панель → Бэкапы → Создать, на Timeweb — ISPmanager → Резервные копии, или wp db export ~/backup-$(date +%F).sql.

# Экспорт перед чисткой
wp db export /tmp/backup-wc-$(date +%F).sql

# Просроченные WordPress transients
wp transient delete --expired

WooCommerce transients можно очистить через админку: WooCommerce → Статус → Инструменты → WooCommerce Transients / Expired Transients. Сам wp transient delete --expired — корректный WP-CLI для просроченных transients.

# Найти тяжёлый autoload (топ-20)
# Замените wp_ на фактический префикс
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto') ORDER BY size DESC LIMIT 20;"

В топе обычно: _transient_wc_*, опции кэш-плагинов, логи. При использовании persistent object cache transients могут обслуживаться через object cache, поэтому их наличие и объём в wp_options зависит от конфигурации сайта. Удаляйте только опции удалённых плагинов — не трогайте active_plugins, rewrite_rules и другие неизвестные autoloaded options. Для очистки autoload сначала определите владельца опции и убедитесь, что она действительно принадлежит удалённому плагину.

Action Scheduler: сначала откройте WooCommerce → Статус → Запланированные действия и проверьте pending/failed/completed задачи. Большое количество pending или failed задач может быть причиной нагрузки. Важно смотреть не только количество задач, но и их возраст, повторяемость и плагин, который их создаёт. Постоянно растущая очередь pending/failed часто указывает на проблему с WP-Cron, внешним API, платёжным или интеграционным плагином или конкретной фоновой задачей. Не удаляйте записи Action Scheduler напрямую SQL-запросами как стандартный шаг — очередь используется не только WooCommerce core, но и сторонними расширениями, а очистка уже предусмотрена самим Action Scheduler. Ручной DELETE FROM wp_actionscheduler_actions нельзя подавать как безусловно безопасную операцию.

Сессии WooCommerce: механизм хранения сессий используется при необходимости. WooCommerce использует customer sessions для хранения данных о состоянии покупателя, в том числе корзины; стандартное хранение сессий использует таблицу wp_woocommerce_sessions (имя зависит от префикса). Полагайтесь на штатные инструменты и автоматическую очистку.

WooCommerce → Статус → Инструменты содержит штатный инструмент Clear Customer Sessions. Используйте его только если действительно требуется очистить клиентские сессии: это удалит активные сессии, включая содержимое корзин. Не очищайте customer sessions на работающем магазине без необходимости — это может удалить текущие корзины покупателей.

Оптимизация таблиц не является универсальным способом ускорить WooCommerce и обычно не должна быть первым шагом диагностики. На больших таблицах операция может быть длительной и создавать дополнительную нагрузку.

Product lookup tables: если каталог или фильтры работают медленно, проверьте состояние product lookup tables. WooCommerce предоставляет штатный инструмент их регенерации: WooCommerce → Статус → Инструменты → Product lookup tables → Regenerate. Не запускайте регенерацию без необходимости на большом магазине в часы пик.

Включите HPOS корректно (актуальный путь): WooCommerce → Настройки → Дополнительно → Возможности (Features). Для существующего магазина сначала включается режим совместимости, чтобы синхронизировать старые post/postmeta данные с новыми таблицами HPOS. После завершения синхронизации можно выбрать High-Performance Order Storage. WooCommerce выполняет синхронизацию фоновыми задачами; не нужно ожидать, что она закончится за фиксированное количество минут. WooCommerce рекомендует некоторое время сохранить compatibility mode после перехода, чтобы убедиться в корректной работе расширений и синхронизации. Скорость синхронизации зависит от сервера и количества данных — нельзя заранее обещать «10–40 минут на 5000 заказов».

Шаг 4. Оптимизируйте изображения — формат, размер и загрузка

Используйте подходящий современный формат — WebP или AVIF там, где это поддерживается вашей инфраструктурой. JPEG также может быть оптимальным для некоторых фотографий. Важнее не само расширение файла, а реальный размер файла, размеры изображения, responsive images и правильная загрузка. Официальная документация WooCommerce рекомендует оптимизацию формата, сжатие, ленивую загрузку и responsive images.

Для карточек и каталогов обычно следует стремиться к минимальному размеру файла без заметной потери качества. Конкретный размер зависит от разрешения, содержания изображения и требуемого качества — универсальной нормы «80–150 КБ на фото» нет.

Обычные изображения товаров WooCommerce хранятся в wp-content/uploads/ по годам и месяцам, а wp-content/uploads/woocommerce_uploads/ используется в частности для защищённых загружаемых файлов — не используйте этот путь как универсальный для конвертации изображений каталога.

Пример консольной конвертации — только пример, сам по себе он не заставит WordPress использовать созданные WebP, не обновит attachment metadata и не учтёт srcset:

# Пример: конвертировать JPEG в WebP (требует установленного cwebp)
# Не охватывает всю структуру uploads и не обновляет метаданные WordPress
cwebp -q 80 input.jpg -o output.webp

Для массовой конвертации лучше использовать специализированный инструмент, плагин или серверный image optimizer, который корректно работает с attachment metadata и srcset.

После изменения размеров миниатюр можно выполнить:

wp media regenerate --yes

Эта команда регенерирует зарегистрированные размеры изображений из исходных файлов согласно зарегистрированным размерам. Сама по себе она не конвертирует JPEG в WebP.

WordPress поддерживает native lazy loading с версии 5.5. Не следует одновременно включать несколько независимых механизмов lazy loading без проверки результата. Особенно важно не применять lazy loading к изображению, являющемуся LCP-элементом — для такого изображения lazy loading может ухудшить LCP, и оно должно загружаться приоритетно.

Шаг 5. Проверьте, какие скрипты действительно лишние

Не удаляйте WooCommerce CSS и JS глобально. Современный WooCommerce может использовать block assets и другие механизмы загрузки, поэтому названия handles и фактический набор файлов могут отличаться. Сначала в Query Monitor или Chrome DevTools определите конкретные handles, которые действительно загружаются на странице и не нужны ей. Затем отключайте их только на страницах, где они точно не используются.

Пример — только после диагностики и только если вы убедились, что стиль или скрипт действительно лишний на конкретной странице:

После диагностики отключайте конкретный ресурс только на тех страницах, где он точно не используется. Для этого используйте фактический handle ресурса и условие конкретной страницы. Универсального кода для всех магазинов WooCommerce нет.

Учитывайте, что is_woocommerce() не включает Cart, Checkout и My Account, поэтому дополнительные проверки is_cart(), is_checkout(), is_account_page() логичны, но не покрывают все кастомные endpoints — проверяйте по фактическим страницам магазина.

wc-cart-fragments может создавать дополнительную динамическую работу и запросы, поэтому его имеет смысл отключать там, где действительно не нужна динамическая мини-корзина. Но это не универсально самый тяжёлый запрос WooCommerce, и его удаление может сделать мини-корзину неактуальной. В современных версиях WooCommerce поведение корзины и связанных блоков менялось, поэтому перед отключением wc-cart-fragments проверьте, используется ли этот скрипт вообще и зависит ли от него мини-корзина темы. Отключайте только если убедились, что на странице мини-корзина не нужна:

// Отключить фрагменты корзины вне магазина — только если мини-корзина не используется
add_action('wp_enqueue_scripts', function() {
    if (!is_woocommerce() && !is_cart() && !is_checkout() && !is_account_page()) {
        wp_dequeue_script('wc-cart-fragments');
    }
}, 99);

Сложные фильтры могут генерировать дополнительные SQL-запросы, JOIN, AJAX или REST-запросы и вычисления, но разные фильтры используют разные механизмы: WP_Query, lookup tables, собственные индексы и т. д. Конкретное утверждение «каждый фильтр добавляет JOIN к каждому запросу» или «WOOF добавляет 3–4 JOIN» нельзя считать универсальным — влияние нужно проверять по фактическим запросам.

Шаг 6. Проверьте PHP, OPcache и object cache по фактической потребности

Устанавливайте memory_limit по фактической потребности. Повышение лимита само по себе не является оптимизацией производительности — оно лишь увеличивает доступный объём памяти и может предотвратить memory exhaustion. Слишком большой лимит не лечит неэффективный код.

Не задавайте memory_limit вслепую. Сначала проверьте фактический WP memory limit в WooCommerce → Статус → Система. Если конкретная операция действительно завершается с memory exhaustion, увеличьте лимит до необходимого значения. Для актуальных версий WooCommerce в серверных рекомендациях указан WordPress memory limit 256 MB или больше, но это именно рекомендация, а не универсальное значение для каждого магазина — на уровне PHP, хостинга или WordPress.

Пример — только пример, а не универсальные значения:

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Это только пример, а не универсальные значения.

В панели хостинга проверьте версию PHP (название пункта панели и доступность функции зависят от тарифа и текущей версии панели хостинга):

• Beget: Сайты → ваш сайт → Настройки PHP → версия 8.3 или новее
• Timeweb: Сайты → ваш сайт → PHP → 8.3 или новее
• Reg.ru: ISPmanager → WWW-домены → PHP → 8.3 или новее, проверьте OPcache

OPcache кэширует скомпилированный байт-код PHP. Проверьте, включён ли он на вашем тарифе:

opcache.enable=1
opcache.memory_consumption=128
; Остальные параметры OPcache подбираются под количество PHP-файлов и конфигурацию сервера.
Если на production используется opcache.validate_timestamps=0, изменения PHP-файлов не будут автоматически подхватываться
; до сброса OPcache или перезапуска PHP-FPM — используйте только если готовы
; корректно сбрасывать кэш после деплоя

На shared-хостинге настройки OPcache могут быть недоступны. Не отключайте проверку timestamps вслепую.

Redis Object Cache позволяет хранить persistent object cache вне обычной памяти PHP-процесса и уменьшать повторное выполнение некоторых операций WordPress, которые используют объектный кэш. Он не заменяет page cache и не гарантирует ускорение на любом сайте. Рассматривайте его как дополнительный persistent object cache после измерений:

# Если Redis доступен на сервере
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
# затем: Плагины → Redis Object Cache → Enable

Проверка результата — как понять, что помогло

Сравнивайте значения до и после на одном и том же URL, при сопоставимой нагрузке и с одинаковым режимом кэширования. Для серверной части сравнивайте время генерации и TTFB, для клиентской — LCP, INP, CLS и вес ресурсов. Главное — улучшение фактической скорости без потери функциональности.

1. Chrome DevTools → Network: откройте категорию магазина при одинаковых условиях кэширования. Смотрите время генерации и суммарный вес ресурсов, а не только количество запросов.
2. Query Monitor → Queries: смотрите суммарное время запросов и самые медленные запросы, а не только их количество. Сравните время генерации до и после.
3. PageSpeed Insights: прогоните URL категории и карточки товара. Ориентиры Core Web Vitals: LCP < 2.5 сек, CLS < 0.1, INP < 200 мс — оцениваются по 75-му перцентилю полевых данных реальных пользователей. PageSpeed Insights показывает как лабораторные данные Lighthouse, так и полевые данные Chrome UX Report, если для URL и происхождения доступны соответствующие данные. В лабораторных тестах дополнительно смотрят TBT. TTI как основной современный показатель лучше не использовать.
4. Админка: сравните время открытия /wp-admin/edit.php?post_type=product до и после на том же объёме данных и при той же нагрузке.
5. Лабораторные и полевые данные: для лабораторного сравнения используйте Chrome DevTools, PageSpeed Insights, WebPageTest или GTmetrix. Для реальных пользователей — RUM или аналитику, если она собирает соответствующие показатели. Не используйте «Яндекс.Метрика → Скорость» как прямой аналог server-side профилировщика.

Дополнительно: общий подход к ускорению без плагинов уже рассмотрен — как ускорить WordPress без плагинов.

Когда ускорение не сработает сразу

• Ограничения тарифа. На бюджетных shared-тарифах WooCommerce с большим каталогом может упираться в лимит CPU, памяти или IO. Правки могут дать заметный прирост, но не всегда делают из shared полноценный аналог VPS — решение зависит от фактической нагрузки. У WooCommerce нет фиксированного лимита товаров, после которого магазин «всегда» тормозит.
• Очень большой каталог без анализа запросов — отдельный сервер БД или кастомная архитектура нужны только при подтверждённой нагрузкой необходимости, а не просто из-за количества товаров. Отдельный сервер БД или кастомная архитектура нужны только при подтверждённой нагрузкой необходимости, а не просто из-за количества товаров. На каталогах в десятки тысяч товаров сначала нужно проверить product lookup tables, фактические SQL-запросы, индексы и работу фильтров. Кастомная индексация требуется только при доказанной проблеме, при этом WooCommerce уже имеет lookup tables и специализированные индексы. Запросы к wp_postmeta с фильтрацией по meta_value на больших объёмах данных могут быть дорогими. Стандартная таблица имеет индекс, включающий meta_key, но это не означает, что любой запрос к meta_value будет выполняться эффективно. Сначала анализируйте конкретный SQL-запрос и его план выполнения.
• Сложные фильтры. Производительность фильтров зависит от реализации конкретного запроса. Универсальных цифр вроде «3–4 JOIN на каждый запрос» нет — проверяйте фактические SQL и AJAX.
• Тяжёлый шаблон страницы. Если на странице категории используется конструктор с большим количеством виджетов, попапами и сторонними скриптами, TTFB может быть низким, а LCP всё равно высоким из-за большого DOM. В этом случае помогает разбор страницы и удаление лишнего — один только кэш не решит проблему.
• Возможная компрометация или повреждённые данные. Неожиданные PHP-файлы в wp-content/uploads — серьёзный повод проверить сайт на компрометацию, поскольку в нормальной конфигурации WordPress загрузка PHP-файлов в uploads не требуется. Сам факт наличия файла с расширением .php в uploads не доказывает взлом, но является поводом для проверки. При этом большой wp_options сам по себе не означает malware или повреждение базы — его нужно диагностировать отдельно. Сначала проверьте безопасность и устраните причину компрометации, затем занимайтесь оптимизацией.
• Недоступные механизмы кэширования. Если persistent object cache или OPcache недоступны на тарифе, это ограничивает часть вариантов оптимизации, но нельзя заранее определить процент потери производительности.

Сопровождение и поддержка сайта

WooCommerce: оплата, доставка, письма.

от 5.400 ₽/мес

Подробнее

Техническая оптимизация

Ускорю WooCommerce, оптимизирую код.

7.200

Подробнее