Хостинг для WooCommerce

Чем требования магазина отличаются от блога

Разница не в количестве страниц, а в доле запросов, которые проходят мимо кэша.

У информационного сайта 95% трафика — это анонимные посетители, читающие статьи. Первый из них запускает генерацию страницы, все остальные получают готовый HTML из кэша: PHP не стартует, база не опрашивается, сервер работает как раздатчик файлов. Именно поэтому блог с 20 000 визитов в сутки живёт на тарифе за 119 ₽.

В магазине картина другая. Как только покупатель кладёт товар в корзину, WooCommerce выставляет cookies woocommerce_items_in_cart и woocommerce_cart_hash, а страницы корзины, оформления заказа и личного кабинета помечает константой DONOTCACHEPAGE. Дальше каждый шаг воронки — это полноценная генерация страницы: пересчёт содержимого корзины, расчёт доставки и налогов, проверка купонов, обращение к API платёжного шлюза. Один такой запрос занимает PHP-процесс на 1–3 секунды. На shared-тарифе таких процессов выделено 5–10 — и если после рассылки к оформлению одновременно подошли двадцать человек, половина встанет в очередь и увидит белый экран.

Второй источник нагрузки — база данных. WooCommerce хранит заметно больше, чем блог:

• Вариации товаров. Товар с тремя атрибутами по пять значений — это до 125 отдельных записей с собственными метаданными. Каталог «на 500 товаров» в базе легко превращается в 20 000 объектов.
• Метаданные заказов. Каждый заказ тянет за собой десятки строк с позициями, адресами, налогами и данными платежа.
• Разрастание wp_options. Транзиенты WooCommerce, кэш вариаций, сессии — всё это оседает в таблице опций, часть с флагом автозагрузки. Автозагружаемые опции читаются при каждом запросе к сайту, включая те, что должны отдаваться из кэша. Когда объём autoload переваливает за мегабайт, тормозить начинает вообще всё.
• Очередь Action Scheduler. Отправка писем, обновление статусов, синхронизация остатков — WooCommerce складывает это в собственные таблицы и разбирает фоном.

Третье отличие — цена отказа. Для блога полчаса недоступности означает потерянные позиции в выдаче, для магазина — потерянные заказы, причём в самый неудачный момент: пик нагрузки и пик продаж — это одно и то же время.

Технический минимум для WooCommerce

Чек-лист с объяснением, что именно сломается без каждого пункта.

PHP 8.1 минимум, рабочий вариант — 8.2 или 8.3. WooCommerce 9.x официально требует 7.4, но на восьмой ветке магазин работает ощутимо быстрее на той же машине. Без переключателя версий в панели вы окажетесь заложником провайдера, когда очередное обновление плагина потребует свежий PHP.

memory_limit от 512 МБ. Один процесс WooCommerce занимает 120–200 МБ против 60–80 у блога. На 256 МБ магазин запустится и будет работать, но упадёт с «Allowed memory size exhausted» на первом же импорте каталога или при генерации отчёта за год. Для админки имеет смысл поднять лимит отдельно через WP_MAX_MEMORY_LIMIT.

MySQL 8 или MariaDB 10.6+. Более старые версии хуже работают с длинными JOIN по wp_postmeta, а именно такие запросы порождают фильтры каталога по атрибутам.

Объектный кэш — Redis или Memcached. Для магазина это не опция, а требование. Некэшируемые страницы всё равно генерируются на лету, и единственный способ их ускорить — не ходить в базу за одними и теми же данными. Redis снимает 40–70% SQL-запросов на странице корзины. На виртуальных тарифах его заявляют единицы: из каталога это NetAngels (Redis и Memcached на всех тарифах) и SpaceWeb, где выделенный Redis появляется с тарифа «Уран» за 1 199 ₽/мес. У остальных провайдеров объектный кэш в описании shared-тарифов не значится — спрашивайте поддержку до оплаты, и если ответ «поставьте плагин кэширования», значит кэша нет.

SSL с автопродлением. Без HTTPS не заработает ни один платёжный шлюз, а браузеры покажут предупреждение на форме оплаты. Достаточно бесплатного Let’s Encrypt, важно только, чтобы продление было автоматическим: истёкший сертификат в субботу вечером — это остановленные продажи до понедельника.

HTTP/2 или HTTP/3. Страница каталога — это 60–100 запросов за картинками товаров. На HTTP/1.1 браузер грузит их по шесть соединений, на HTTP/2 — мультиплексом в одном.

Системный cron вместо wp-cron. По умолчанию WordPress запускает отложенные задачи при посещении страниц. В магазине этих задач много: Action Scheduler разбирает очередь письмами, обновлениями статусов и синхронизацией остатков. Пока трафика нет, очередь стоит; когда трафик появился, она разгребается прямо в момент пиковой нагрузки, конкурируя с покупателями за те же PHP-процессы. Правильно — отключить DISABLE_WP_CRON и повесить системный cron раз в 1–5 минут.

Отдельно про скорость самой витрины: страничный кэш на магазине закрывает каталог, но не корзину и не оформление заказа — что с этим делать, разобрано в материале об ускорении WordPress.

HPOS — хранилище заказов высокой производительности. В свежих версиях WooCommerce заказы лежат в собственных таблицах wc_orders, а не вперемешку с постами в wp_posts и wp_postmeta. Для магазинов, которые переехали со старых версий, режим часто остаётся выключенным — проверьте в «WooCommerce → Настройки → Дополнительно → Функции». На каталоге с историей заказов включение HPOS ускоряет админку в разы и снимает нагрузку с самой раздутой таблицы базы.

Кэширование в магазине: где обычно всё ломается

Это раздел, из-за которого магазины теряют деньги чаще всего.

Что нельзя кэшировать

Четыре зоны должны отдаваться каждому покупателю индивидуально:

• /cart/ — корзина;
• /checkout/ — оформление заказа;
• /my-account/ — личный кабинет;
• AJAX-запросы вида ?wc-ajax=get_refreshed_fragments, которыми WooCommerce обновляет счётчик корзины в шапке.

WooCommerce сообщает об этом плагинам кэширования сам, и нормальные плагины его слушают. Проблемы начинаются, когда кэш настраивают на уровне сервера или CDN в обход WordPress — например, включают полное кэширование в панели провайдера или ставят агрессивные правила в Nginx.

Классическая авария

Выглядит она так: покупатель А кладёт товар в корзину, сервер кэширует страницу вместе с его содержимым, покупатель Б открывает тот же URL и видит чужую корзину. В худшем варианте кэшируется /my-account/ — и посторонний человек получает страницу с именем, адресом и историей заказов другого клиента. Это уже не просто баг, а утечка персональных данных со всеми вытекающими.

Проверить свой магазин можно за пять минут: откройте сайт в обычном окне и в приватном, добавьте товар в корзину в первом, обновите второе. Если счётчик корзины в шапке приватного окна показал товар — у вас та самая проблема. Второй способ — посмотреть заголовки ответа для /cart/: там должно быть Cache-Control: no-store, no-cache и отсутствовать признак попадания в кэш вроде X-Cache: HIT.

Почему объектный кэш важнее страничного

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

Настроить его — это плагин Redis Object Cache и три строки в wp-config.php с указанием хоста, порта и уникального префикса ключей. Префикс важен, если на сервере несколько сайтов: без него они перезапишут кэш друг другу.

ESI и фрагментное кэширование

Идеальный вариант — кэшировать страницу целиком, оставляя динамическими отдельные куски: счётчик корзины, блок «вы недавно смотрели», приветствие авторизованного пользователя. Это делает механизм ESI (Edge Side Includes) — из доступного в рунете он есть в LiteSpeed вместе с плагином LiteSpeed Cache, который умеет помечать виджет корзины как ESI-блок. Тогда каталог отдаётся из кэша мгновенно, а корзина в шапке остаётся живой.

Если LiteSpeed нет, работает более простой приём: отключить AJAX-обновление фрагментов корзины на всех страницах, кроме карточки товара и самой корзины. Этот единственный запрос на каждой странице сайта — самая частая причина «сайт быстрый, но чувствуется тормозным».

Сколько ресурсов нужно по размеру каталога

Главное уточнение к таблице: нагрузку создаёт не каталог, а одновременность. Десять тысяч товаров, которые никто не смотрит, занимают место на диске и не стоят серверу почти ничего. Двести человек, одновременно пришедших по рекламе и фильтрующих каталог по трём атрибутам, положат сервер на любом каталоге.

Считать нужно три величины: пиковое число одновременных посетителей, долю тех, кто доходит до корзины, и объём фоновых задач. Фоновое часто недооценивают — регулярный обмен с 1С, выгрузка на маркетплейсы, пересчёт остатков и генерация фида для рекламы съедают ресурсы независимо от посетителей, а идут обычно в рабочие часы, то есть в пик.

Отдельно про поиск. Встроенный поиск WordPress делает LIKE '%запрос%' по таблице постов — на каталоге в 10 000 позиций такой запрос выполняется секундами и не использует индексы. Фильтры каталога по нескольким атрибутам порождают многоэтажные JOIN по wp_postmeta. Именно здесь обычно возникает ощущение «сервер не тянет», хотя добавлять ядра бесполезно — нужно вынести поиск и фильтрацию в Elasticsearch через ElasticPress или аналог.

Платежи, SSL и PCI DSS: что реально требуется в России

Самое распространённое заблуждение при выборе хостинга под магазин — что нужен «PCI-совместимый хостинг». В подавляющем большинстве случаев это не так, и переплачивать за это не нужно.

Логика стандарта проста: требования применяются к тем, кто хранит, обрабатывает или передаёт данные платёжных карт. Если у вас подключена ЮKassa, CloudPayments, Т-Касса или эквайринг банка, покупатель вводит номер карты не у вас: он либо уходит на страницу платёжного сервиса, либо заполняет форму в iframe, загруженную с домена шлюза. Данные карты идут напрямую на сторону провайдера платежей и вашего сервера не касаются вообще. В терминах стандарта это уровень SAQ A — самая простая анкета самооценки, никаких требований к сертификации вашего хостинга она не создаёт.

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

Что нужно всегда, независимо от способа приёма платежей:

• HTTPS на всём сайте, не только на странице оплаты. Бесплатного Let’s Encrypt достаточно, «расширенный SSL» за деньги ничего не добавляет.
• TLS 1.2 или выше. Платёжные шлюзы отказываются работать со старыми версиями; это настройка веб-сервера, у нормального провайдера она уже корректна.
• Актуальные версии WordPress, WooCommerce и платёжного плагина. Дыра в плагине оплаты — реальный способ потерять и деньги, и данные клиентов.
• Корректные вебхуки. Платёжный шлюз уведомляет магазин об успешной оплате запросом на ваш URL. Если сервер в этот момент недоступен или отвечает дольше таймаута, заказ останется в статусе «ожидает оплаты», хотя деньги списаны. Это ещё один аргумент за стабильность хостинга: последствия недоступности в магазине не заканчиваются в момент, когда сайт снова поднялся.

Защита магазина

Магазин привлекает больше нежелательного внимания, чем блог, — и часть защиты обеспечивается именно на уровне хостинга, а не плагинами.

Перебор паролей к админке. wp-login.php и XML-RPC перебирают непрерывно, десятками попыток в минуту. Плагин лимита попыток помогает, но каждая попытка всё равно запускает PHP и обращается к базе — то есть съедает ресурсы, которые нужны покупателям. Блокировка на уровне сервера (fail2ban, WAF провайдера) отсекает запрос до PHP и потому эффективнее.

Боты, заваливающие корзину. Автоматические добавления товаров в корзину создают сессии и записи в базе; при массовости это выглядит как внезапный рост нагрузки без роста продаж. Помогает капча на добавление в корзину и ограничение частоты запросов на уровне Nginx.

Фрод-заказы и перебор карт. Через форму оплаты злоумышленники проверяют украденные карты мелкими суммами. Это бьёт по репутации мерчанта у эквайера, вплоть до отключения. Минимум — капча на оформление заказа и лимит попыток оплаты с одного IP.

Взлом через уязвимый плагин. Основной вектор проникновения в WordPress — не подбор пароля, а устаревший плагин. Поэтому staging-окружение для магазина не роскошь: обновляться нужно быстро, но проверять обновление на копии, а не на живой кассе.

Минимальный набор, который стоит требовать от хостинга: WAF или хотя бы базовые правила фильтрации, fail2ban на вход, запрет выполнения PHP в wp-content/uploads, отдельный системный пользователь под сайт и двухфакторная аутентификация в панели самого провайдера. Последнее забывают, а зря: доступ к панели хостинга — это доступ ко всему сразу, включая бэкапы.

Бэкапы для магазина — отдельная история

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

Что нужно магазину:

1. Частые копии базы данных. Файлы меняются редко — раз в сутки достаточно. База меняется постоянно, её нужно копировать каждые 1–6 часов. Формулируйте требование через RPO: сколько часов заказов вы готовы потерять в худшем случае.
2. Хранение вне сервера. Копия на том же диске не спасает при отказе диска, а копия внутри аккаунта не спасает при блокировке аккаунта. Нужен внешний адрес — объектное хранилище, второй сервер, облако.
3. Проверенная процедура отката. Бэкап, который ни разу не разворачивали, — это надежда, а не резервная копия. Разверните копию на тестовой площадке хотя бы раз и засеките, сколько это заняло: эта цифра и есть ваше реальное время восстановления.
4. Глубина хранения. Взлом или порча данных обнаруживаются не сразу. Семи дней мало, месяц — рабочий минимум. Из провайдеров каталога 30 копий хранит REG.RU, у FirstByte схема на месяц вглубь — семь ежедневных, две недельных и одна месячная, NetAngels держит ежедневные копии в отдельных дата-центрах.
5. Отдельный экспорт заказов. Полезная привычка: регулярная выгрузка заказов и клиентов в CSV, лежащая независимо от бэкапов сайта. Восстановить магазин из дистрибутива и настроить заново — вопрос дня, а вот восстановить утраченные заказы неоткуда.

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

Shared, VPS или managed под магазин

Матрица решения по трём осям — размер каталога, поток заказов и наличие человека, который будет обслуживать сервер.

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

VPS — когда нужен контроль над стеком: свои параметры PHP под обмен с 1С, Elasticsearch, отдельные пулы процессов, специфичное расширение. Условие — есть кто-то, кто настроит и будет обновлять сервер. Магазин без администратора на VPS опаснее магазина на shared.

Managed-хостинг — вариант по умолчанию для работающего магазина без своего сисадмина: кэш, обновления, бэкапы и мониторинг входят в тариф, а разница в цене с VPS окупается одним неслучившимся простоем.

Чек-лист перед запуском магазина

Пройдите по пунктам до того, как включите рекламу:

1. PHP 8.2+, memory_limit 512 МБ, max_execution_time от 300 секунд — проверьте в «Инструменты → Здоровье сайта».
2. Redis подключён и работает — плагин Redis Object Cache показывает статус «Connected», в «Здоровье сайта» виден постоянный объектный кэш.
3. /cart/, /checkout/, /my-account/ исключены из кэша — проверено в приватном окне, как описано выше.
4. wp-cron отключён, системный cron стоит на 1–5 минут — очередь Action Scheduler в «WooCommerce → Статус → Запланированные действия» не накапливается.
5. HPOS включён, если магазин не переезжал со старой версии с самописными доработками.
6. SSL выпущен и продлевается автоматически, весь сайт на HTTPS, платёжный шлюз в боевом режиме.
7. Тестовый заказ проведён полностью: оплата, вебхук, письмо покупателю, письмо администратору, смена статуса.
8. Бэкап базы чаще раза в сутки, хранится вне сервера, восстановление проверено.
9. Staging-копия существует и на ней обновляются плагины перед продом.
10. Мониторинг доступности с уведомлением в телеграм — минуту простоя магазина вы должны узнавать от робота, а не от покупателя.

Общие критерии выбора провайдера — в чек-листе выбора хостинга, сравнение конкретных тарифов по TTFB, аптайму и цене второго года — в рейтинге хостингов.