Почему WooCommerce медленно работает и что проверить первым

Корзина крутится 8 секунд, «Оформить заказ» зависает, реклама уходит — а PageSpeed Mobile на 38. В практике WooCommerce «тормозит» реже из-за самого плагина, чаще из-за связки: 22 расширения, shared-хостинг, два кэша и картинки Full size. Ниже — шесть причин и порядок проверки без смены CMS.

WooCommerce сам по себе не «тяжёлый»

Чистый WooCommerce на лёгкой теме (Storefront, Astra) и нормальном хостинге даёт приемлемую скорость. Магазин начинает «ползти», когда на него навешивают:

• конструктор (Elementor) + 3 аддона к нему;
• фильтры, таблицы, CRM, доставки, маркетинг — каждый своим плагином;
• кэш «для скорости» поверх другого кэша;
• общий тариф хостинга под каталог на 5 000 SKU.

Разберём шесть причин в порядке, как их проверяют на аудите — от быстрых к более глубоким.

Причина 1. Лишние и дублирующие плагины

Типичный WooCommerce-проект: сам WooCommerce + платёж (ЮKassa) + доставка (СДЭК) + CRM + SEO + кэш + SMTP + 2 формы + слайдер + «улучшайзер корзины». Часть из них дублирует функции или грузит CSS/JS на каждой странице.

Что проверить:

• Два SEO, два кэша, три счётчика аналитики — оставить по одному.
• Плагины «улучшения checkout», если checkout уже настроен в теме или WooCommerce Blocks.
• Неактивные плагины — удалить, не хранить «на потом».

Подробный чек-лист аудита — в статье «Лишние плагины WordPress: золотая середина». После чистки на типовом магазине PageSpeed Mobile часто растёт на 10–20 пунктов без смены хостинга.

Причина 2. Хостинг и PHP

Каталог на 3 000–10 000 товаров с фильтрами по атрибутам на тарифе «сайт-визитка» упирается в CPU и лимиты MySQL. Признаки:

• TTFB главной > 1,5 сек на мобильном;
• админка WooCommerce «висит» при сохранении товара;
• в логах хостинга — Maximum execution time или медленные запросы.

Минимум для рабочего магазина: PHP 8.1+, memory_limit 256M (512M для тяжёлой админки), нормальный лимит max_execution_time. На Beget/Timeweb часто помогает переход на тариф с большим CPU или VPS — но сначала стоит убрать лишние плагины: иногда хватит текущего тарифа. Критерии выбора тарифа — в статье про хостинг для WordPress.

Причина 3. Два кэша или кэш режет корзину

Кэш нужен, но на магазине его настраивают иначе, чем на визитке:

• Страницы корзины, checkout, «Мой аккаунт» — не кэшировать (или cookie-based cache для гостей).
• admin-ajax.php и REST WooCommerce — в исключениях defer/merge JS.
• Один кэш-плагин: WP Rocket, LiteSpeed Cache или аналог — не два.

Типовой баг: после включения агрессивного кэша гость видит пустую корзину или «зависает» кнопка «Применить купон». Исправляется правилами исключений в настройках кэша + проверкой checkout в режиме инкognito.

Причина 4. AJAX корзины и мини-корзины

Добавление в корзину, обновление количества, виджет мини-корзины в шапке — всё через admin-ajax.php. Если какой-то плагин вешает тяжёлый обработчик на каждый AJAX-запрос (старый кэш, security, «оптимизатор»), корзина тормозит.

Проверка:

1. DevTools → Network → фильтр admin-ajax → смотреть время ответа при «Добавить в корзину».
2. Временно отключить подозрительные плагины (не WooCommerce!) — повторить тест.
3. Query Monitor на staging — кто добавляет запросы к БД на AJAX.

Знакомый кейс: CF7 + старый плагин кэша давали fatal на AJAX — форма и корзина крутились бесконечно (см. кейс id 8 в портфолио).

Причина 5. Картинки и Elementor на карточках

60–80% веса страницы каталога — изображения. Частые ошибки:

• размер Full для миниатюр в сетке;
• нет WebP/AVIF;
• Elementor-шаблон single product с десятком виджетов и Google Fonts с CDN.

Если магазин на Elementor — часть оптимизаций из чек-листа PageSpeed 34→86 переносится на витрину один в один: Experiments, локальные шрифты, один кэш, WebP.

Причина 6. Раздутая база и wp-cron

Таблицы wp_options (autoload), ревизии, transients, логи плагинов, сессии WooCommerce — со временем база растёт. Плюс wp-cron на каждом заходе гостя гоняет десятки задач: бэкап, рассылка, синхронизация CRM.

Что делать:

• Раз в квартал — чистка transients, ревизий (WP-Optimize, вручную или через хостинг).
• Системный cron вместо pseudo-cron — в wp-config.php: define('DISABLE_WP_CRON', true); и задача в crontab хостинга.
• Проверить autoload в wp_options — строки > 100 КБ часто от «забытых» плагинов.

Чек-лист за 2 часа (до смены хостинга)

1. Аудит плагинов — дубли, неактивные, «комбайны» (разбор).
2. Один кэш, исключения для cart/checkout/account/ajax.
3. PageSpeed / WebPageTest на главной, категории, карточке, checkout.
4. Network → время admin-ajax при добавлении в корзину.
5. Картинки: не Full, WebP, lazy-load.
6. PHP 8.1+, memory_limit, при необходимости — cron на системе.

Зафиксируйте цифры «до» — потом проще понять, что сработало.

Что НЕ делать

• Не ставить второй кэш «для ускорения WooCommerce» поверх первого.
• Не отключать WooCommerce session/cookie ради PageSpeed — сломается корзина.
• Не переезжать на другую CMS «потому что WooCommerce медленный» — см. разбор про смену платформы.
• Не жать Update All по 25 плагинам перед распродажей — сначала бэкап и staging.

Когда звать специалиста

Если после чек-листа PageSpeed Mobile ниже 50, корзина всё ещё > 3 сек или checkout падает с 500 — нужен разбор глубже: индексы БД, конфликт темы, Redis, настройка хостинга. Сделаем замер «до/после» — услуга ускорения и доработка WooCommerce.

После ускорения проверьте, что письма о заказах доходят, и что SMTP настроен — инструкция.