Сценарий знакомый: магазин тормозит, ставят кеширующий плагин, на главной PageSpeed подрастает, и на этом всё. Каталог открывается так же медленно, корзина — ещё медленнее, а в часы, когда посетителей больше обычного, сайт начинает отваливаться по таймауту.
Причина в том, что WooCommerce устроен так, что самые тяжёлые страницы кешированию не подлежат вообще, а на остальных кеш снимается сам. Разбираю, где именно ломается логика и что на самом деле даёт результат.
Что кеш страниц не кеширует никогда
Полностраничный кеш работает по одному принципу: сохранить готовый HTML и отдавать его всем без запуска PHP. Это возможно, только если HTML одинаков для всех посетителей. В WooCommerce такими не являются корзина, оформление заказа, личный кабинет, любые страницы для авторизованных пользователей — и любая страница, где в шапке выводится мини-корзина с количеством товаров.
Последний пункт — ключевой. Мини-корзина есть почти в каждой теме, и она превращает в персональную каждую страницу сайта. WooCommerce решает это через AJAX: HTML отдаётся из кеша с пустой корзиной, а сразу после загрузки браузер делает отдельный запрос ?wc-ajax=get_refreshed_fragments, который заново считает содержимое корзины.
Этот запрос полностью минует кеш и поднимает полноценный WordPress — загрузку ядра, всех плагинов и темы. То есть на каждой странице у вас есть один некешируемый запрос к PHP, который на медленном хостинге занимает те же полсекунды-секунду, что и обычная генерация страницы. Формально страница отдалась из кеша за 40 мс, фактически интерфейс дёргается и «доходит» почти секунду.
Что с этим делают: отключают обновление фрагментов там, где корзины на странице нет, и подгружают их только при непустой корзине. Признак непустой корзины — куки woocommerce_items_in_cart и woocommerce_cart_hash: по их наличию понятно, есть ли смысл вообще делать запрос.
Если после установки кеша главная летает, а карточка товара нет — почти всегда дело в обновлении фрагментов корзины и в скриптах, которые выполняются до отрисовки, а не в самом кеше.
Настоящее узкое место — база
Кеш страниц маскирует проблему, но не решает её: первый посетитель, у которого кеш пустой, всё равно ждёт полную генерацию. А генерация в WooCommerce упирается в базу.
Таблица wp_postmeta. Товар в WooCommerce — это запись типа product, а все его свойства живут в wp_postmeta отдельными строками: _price, _regular_price, _sale_price, _stock, _stock_status, _sku, _thumbnail_id и ещё десятки. Каталог на пять тысяч товаров — это легко несколько сотен тысяч строк. Любая сортировка по цене или фильтр по наличию превращается в запрос с несколькими JOIN к этой таблице.
Начинать стоит с группировки по meta_key с подсчётом строк: верхние позиции обычно показывают, какой плагин насыпал больше всех. Осиротевшие записи — метаданные без существующего поста — чистятся безопасно одним DELETE с LEFT JOIN на wp_posts.
Таблица wc_product_meta_lookup. Начиная с WooCommerce 3.6 существует плоская таблица с одной строкой на товар и колонками min_price, max_price, stock_quantity, stock_status, onsale, average_rating, total_sales. Сортировки и фильтры должны ходить в неё, а не в postmeta. Если тема или плагин фильтров написаны до 3.6 и лезут в postmeta напрямую через meta_query, никакой кеш этого не спасёт. Таблицу можно перестроить: WooCommerce → Status → Tools → Regenerate product lookup tables.
Автозагрузка wp_options. Каждый запрос к WordPress начинается с выборки всех опций, помеченных autoload = yes. Плагины, которые давно удалили, свои опции обычно оставляют. Суммарный объём автозагрузки до 500–800 КБ — нормально; несколько мегабайт означают, что на каждый запрос, включая тот самый запрос фрагментов, из базы поднимается и десериализуется лишнее. Отдельно смотрите просроченные транзиенты — записи с префиксом _transient_.
Action Scheduler. WooCommerce ставит фоновые задачи в таблицы actionscheduler_actions и actionscheduler_logs. На магазине с активными заказами и синхронизациями они растут до сотен тысяч строк, и часть запросов на фронте начинает их задевать. Завершённые задачи чистятся штатно, в разделе Scheduled Actions, либо ограничением срока хранения.
Объектный кеш вместо кеша страниц
Полностраничный кеш помогает анонимному посетителю на статичных страницах. Объектный кеш помогает всегда — в том числе на корзине, чекауте, в админке и в тех самых AJAX-запросах. Это файл object-cache.php в wp-content, который перенаправляет вызовы wp_cache в Redis или Memcached вместо того, чтобы каждый раз ходить в MySQL.
На магазине это обычно даёт больше, чем любой кеширующий плагин: количество запросов к базе на генерацию страницы падает в разы. Проверить, что он работает, можно через Query Monitor — в панели видно и число запросов, и попадания в объектный кеш.
Ставить его имеет смысл вместе с базовой гигиеной: PHP 8.2 или новее с включённым opcache (на продакшене с отключённой проверкой временных меток и обязательным reload php-fpm после деплоя), innodb_buffer_pool_size не меньше размера рабочего набора базы. Это уже уровень сервера, а не сайта — то, чем занимается администрирование.
Плагины и то, что грузится до отрисовки
Отдельный разговор — количество активного кода. Магазин с сорока плагинами генерирует страницу дольше не потому, что плагинов много, а потому что каждый из них вешает свои обработчики на init, wp_enqueue_scripts и хуки вывода каталога.
Инструмент один — Query Monitor: он показывает время на плагин, медленные запросы и количество вызовов. Смотреть надо на карточке товара и на странице категории с включённым фильтром, а не на главной, где половина этого кода не работает.
Отдельно — конструкторы страниц. Elementor или WPBakery на карточке товара добавляют собственный CSS и JS на каждую страницу независимо от того, используются ли они там. Это не лечится кешем: файлы всё равно скачиваются и парсятся браузером. Если магазин собирается с нуля, вопрос решается на этапе выбора стека — об этом мы писали в сравнении Битрикса и WordPress.
Что реально видит посетитель
Кеш страниц влияет на TTFB. LCP — на что смотрит и поиск, и человек — определяется другим.
- Главная картинка товара: WebP, в нужном размере, с приоритетом загрузки и без ленивой загрузки — WordPress иногда ставит lazy на LCP-элемент сам, и это прямой минус к метрике
- Шрифты: font-display: swap и preload для того начертания, которым набран заголовок; три семейства по четыре начертания почти всегда лишнее
- Сторонние скрипты — чаты, пиксели, виджеты отзывов: их место в отложенной загрузке, а не в head
- CLS: у всех картинок и баннеров заданы width и height, иначе каталог прыгает при загрузке
Порядок, который работает
- Query Monitor на категории и карточке товара: сколько запросов, сколько времени, какие плагины и какие запросы медленные
- Чистка wp_postmeta и автозагрузки wp_options, перестройка lookup-таблицы, чистка Action Scheduler
- Объектный кеш в Redis, PHP 8.2+ с opcache, настройки MySQL под размер базы
- Фильтры и сортировки перевести на lookup-таблицу
- Обновление фрагментов корзины отключить там, где корзина пуста
- Картинки, шрифты, сторонние скрипты — под LCP и CLS
- И только потом полностраничный кеш, как последний слой, а не как решение
Кеширующий плагин — не ошибка, он нужен. Ошибка — считать его первым и единственным шагом: он ускоряет ровно те страницы, которые и без него самые лёгкие.
На магазине на WooCommerce кеш страниц не касается ни каталога с фильтром, ни корзины, ни чекаута — то есть всего пути, по которому идут деньги. Если сайт уже живой и переделывать его не хочется, начинать стоит с замеров: ускорение сайта — это не набор плагинов, а последовательность измерений, где на каждом шаге видно, что именно дало секунду. Общая методика по каталогам, не только на WooCommerce, разобрана в статье про Core Web Vitals, а поддерживать результат помогает регламент поддержки сайта: без него база снова обрастает метаданными за несколько месяцев.
