Хостинг для WooCommerce: вимоги до сервера і налаштування магазину

Для WooCommerce потрібен хостинг з PHP 8.3+, MySQL 8.0+ або MariaDB 10.6+, HTTPS і лімітом пам’яті від 256 МБ, а для поточної версії 11.2 ще й WordPress 7.0+. Але швидкість магазину визначають не ці мінімуми, а процесор і кількість PHP-воркерів: на нашому стенді кеш сторінок віддавав каталог за 0,3 мс, проте щойно покупець кладе товар у кошик, кожна його сторінка йде повз кеш і коштує 120-220 мс процесорного часу. Нижче виміри, перевірений конфіг nginx і таблиця розміру сервера для малого та середнього магазину.

Офіційні вимоги WooCommerce до сервера

Ми звірили сторінку вимог на woocommerce.com (перевірено 25.10.2026, остання редакція сторінки 25.05.2026) із заголовками самого плагіна з релізу 11.2.1 на GitHub.

Ліміт 256 МБ виглядає із запасом, і це правильно: звичайні сторінки на стенді брали до 18 МБ, але імпорт товарів, звіти й оновлення в адмінці споживають значно більше, а без OPcache навіть звичайна сторінка займала до 86 МБ.

Скільки коштує кожна сторінка магазину: виміри

Медіана TTFB у мілісекундах. «Кошик з товаром» означає, що запит ішов з куками сесії покупця, у кошику якого один товар.

Що з цього випливає:

• OPcache обов’язковий. Без нього каталог генерувався втричі довше (629 проти 212 мс), а пам’ять на запит зростала з 16 до 84 МБ.
• Сам WooCommerce важить навіть там, де магазину немає. Звичайний запис блогу з увімкненим плагіном відповідав за 103 мс замість 56 і робив 69 SQL-запитів замість 31.
• Кеш сторінок рятує лише відвідувачів без кошика. Після першого додавання товару каталог і картки товарів для цього покупця знову коштують 177-222 мс, бо правила кешу (нижче) пропускають усіх, у кого є кука кошика.
• Тема має значення. Зі Storefront каталог генерувався за 92 мс, товар за 95 мс, тобто вдвічі швидше, ніж на блочній Twenty Twenty-Five. Перед вибором тарифу варто поміряти саме свою тему.

Cart fragments: прихований запит на кожну нову сесію

Класичні теми з міні-кошиком у шапці, як-от Storefront, підключають скрипт wc-cart-fragments. Він надсилає POST-запит /?wc-ajax=get_refreshed_fragments, щоб оновити лічильник кошика. У коді WooCommerce 11.2.1 скрипт бере фрагменти з sessionStorage браузера і звертається до сервера, коли їх там немає (перша сторінка в новій вкладці чи сесії), коли змінився хеш кошика або минула доба. На стенді такий запит займав 30 мс і 30 SQL-запитів з порожнім кошиком, 35 мс і 38 запитів з товаром, і він не кешується: це POST.

На сайті з кешем сторінок це означає, що навіть «читач» каталогу щонайменше один раз за сесію доходить до PHP. Сам WooCommerce 11.2.1 підключає скрипт лише разом із класичним віджетом кошика, тому блочні теми з блоком Mini-Cart, як Twenty Twenty-Five, його не завантажують. Перевірити свій сайт просто: у DevTools на вкладці Network відфільтруйте wc-ajax.

Кеш сторінок для WooCommerce: перевірений конфіг nginx

Цей server-блок працював на стенді. Кеш увімкнено для всіх, крім POST-запитів, адрес з параметрами (?add-to-cart=, ?wc-ajax=, фільтри, сортування), сторінок кошика, оформлення й кабінету, службових адрес і відвідувачів з куками кошика, сесії WooCommerce чи входу. Якщо ви перейменували сторінки, наприклад на /koshyk/ чи /oformlennya/, змініть другий if.

fastcgi_cache_path /var/cache/nginx/woo levels=1:2 keys_zone=WOO:20m max_size=512m inactive=60m;
server {
  # listen, server_name, root /var/www/shop; index index.php; ...
  set $skip_cache 0;
  if ($request_method = POST) { set $skip_cache 1; }
  if ($query_string != "")    { set $skip_cache 1; }
  if ($request_uri ~* "/(cart|checkout|my-account)/|/wp-admin/|/wp-json/|/xmlrpc.php|wp-.*\.php|/feed/|sitemap") { set $skip_cache 1; }
  if ($http_cookie ~* "woocommerce_items_in_cart|woocommerce_cart_hash|wp_woocommerce_session_|wordpress_logged_in_|wp-postpass|comment_author") { set $skip_cache 1; }

  location / { try_files $uri $uri/ /index.php?$args; }
  location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_cache WOO;
    fastcgi_cache_key "$scheme$request_method$host$request_uri";
    fastcgi_cache_valid 200 301 10m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    fastcgi_cache_use_stale error timeout updating http_500;
    fastcgi_cache_lock on;
    add_header X-Cache $upstream_cache_status always;
  }
}

Перевірка заголовками (curl -s -o /dev/null -D - адреса), скорочено:

/shop/ перший запит          X-Cache: MISS
/shop/ другий запит          X-Cache: HIT
/cart/                       Cache-Control: no-cache, must-revalidate, max-age=0, private  X-Cache: BYPASS
/checkout/                   X-Cache: BYPASS
/my-account/                 X-Cache: BYPASS
/?add-to-cart=601            X-Cache: BYPASS
/wp-json/wc/store/v1/cart    Cache-Control: no-store  X-Cache: BYPASS
/shop/ з кукою woocommerce_items_in_cart=1   X-Cache: BYPASS
/shop/?orderby=price         X-Cache: BYPASS

Документація WooCommerce також називає куку woocommerce_recently_viewed. Додавайте її до правила, лише якщо показуєте блок «Нещодавно переглянуті»: вона з’являється після перегляду товару, тож кеш для таких відвідувачів вимкнеться.

Чого не можна робити. Ми окремо перевірили поширену «агресивну» конфігурацію без цих правил, але з fastcgi_ignore_headers Cache-Control Expires Set-Cookie. Покупець A додав товар через ?add-to-cart=600, і nginx закешував відповідь разом із його кукою сесії. Новий відвідувач B на тій самій адресі отримав X-Cache: HIT і ту саму куку wp_woocommerce_session_, а потім на свіжій некешованій сторінці кошика побачив товар покупця A. Тобто кеш віддав чужу сесію. Без fastcgi_ignore_headers кошик на стенді не закешувався: WooCommerce відповідає заголовками no-cache, private. Але без правил обходу nginx віддасть уже закешовану анонімну сторінку каталогу і покупцеві з кошиком, тож правила потрібні в будь-якому разі.

Чому магазину потрібно більше PHP-воркерів, ніж блогу

Ми прогнали через закешований сайт по 100 імітованих відвідувачів, 10 одночасно. «Читач» відкривав головну, каталог, два товари й запис блогу: 500 запитів, усі HIT, жодного звернення до PHP, 3 секунди на всіх. «Покупець» відкривав головну, каталог і товар, додавав товар у кошик, повертався в каталог, відкривав кошик і оформлення: з 700 запитів 400 пішли в PHP, і 2 vCPU працювали на повну 32 секунди. Сторінок покупці відкрили лише на 40% більше, а роботи для PHP створили незрівнянно більше: у читачів її не було зовсім.

Далі ми навантажили некешовані запити 20 одночасними клієнтами і змінювали кількість воркерів PHP-FPM (запитів за секунду, у дужках 95-й перцентиль часу відповіді):

Висновок з двох частин. Коли запит лише рахує (додавання в кошик 34 мс, оформлення 117 мс процесорного часу), упираєтеся в ядра: 2 vCPU віддавали близько 17 сторінок оформлення за секунду, і додаткові воркери лише з’їдали пам’ять. Але в реальному магазині оформлення чекає на зовнішні сервіси: розрахунок доставки, платіжний шлюз, облікову систему. Ми імітували таку затримку на 300 мс, і тоді 2 воркери пропускали 4,7 запиту за секунду, а 10 воркерів уже 14,3: поки один процес чекає відповіді API, інші працюють. Саме тому ліміт одночасних процесів PHP на тарифі для магазину важливіший за обсяг диска, а при його вичерпанні з’являється помилка 508 Resource Limit Is Reached або помилка 503 Service Unavailable.

Ще одна деталь: кожне додавання в кошик новим відвідувачем створює рядок у таблиці wp_woocommerce_sessions. Після наших тестів їх було 1333. Боти, що ходять за посиланнями ?add-to-cart=, роздувають цю таблицю, тому потрібен справний cron: WooCommerce чистить прострочені сесії запланованим завданням.

Який сервер потрібен магазину: таблиця розміру

Таблиця побудована з виміряних витрат на запит (у середньому близько 130 мс процесорного часу на некешований запит покупця, 30-35 МБ PSS на воркер після навантаження, OPcache 128 МБ спільно) і припущення, що покупець з товаром у кошику робить один некешований запит раз на 5-10 секунд. Це орієнтовна оцінка, а не гарантія: важкі плагіни, фільтри й API доставки можуть подвоїти витрати.

Формула, щоб порахувати свій випадок: воркерів PHP ≈ некешованих запитів за секунду × середній час відповіді в секундах × 2 (запас), vCPU ≈ запитів за секунду × процесорний час запиту ÷ 0,7, RAM ≈ воркери × 50 МБ + 0,5-1 ГБ на MariaDB + 0,5 ГБ на систему. Процесорний час запиту легко поміряти на копії свого магазину тим самим curl -w "%{time_starttransfer}" з сервера. Як вибирати конфігурацію, ми розібрали в статті як вибрати VPS, а загальні критерії для магазинів у гіді як вибрати хостинг для інтернет-магазину.

Мінімальний чек-лист перед запуском

• PHP 8.3 або 8.4 з OPcache, memory_limit 256M, WordPress 7.0+ для актуального WooCommerce.
• Кеш сторінок з правилами обходу кошика, оформлення, кабінету, POST, параметрів і кук WooCommerce. Перевірте заголовок X-Cache, як вище.
• HPOS увімкнено (WooCommerce > Налаштування > Додатково > Функції або wp wc hpos enable).
• Системний cron замість відвідувачів: define('DISABLE_WP_CRON', true); і завдання wp cron event run --due-now кожні 5 хвилин.
• Ліміт процесів PHP на тарифі не менший за розрахований вище. Інші способи пришвидшення зібрані в статті як пришвидшити WordPress.

Для нового магазину з невеликим каталогом зазвичай вистачає якісного віртуального хостингу: на тарифах хостингу для WordPress від RichHost є NVMe-диски, безкоштовний SSL Let’s Encrypt і сервери в Європі та США. Коли некешованих запитів у піку стає більше за 3-5 за секунду, плануйте VPS.

Часті запитання

Чи вистачить віртуального хостингу для WooCommerce?

Для малого магазину так, якщо є OPcache, кеш сторінок і ліміт хоча б 4-6 одночасних процесів PHP. На нашому стенді 2 vCPU віддавали близько 17 сторінок оформлення замовлення за секунду, а 100 імітованих покупців повністю завантажили їх на 32 секунди.

Скільки PHP-воркерів потрібно магазину?

Помножте пікову кількість некешованих запитів за секунду на середній час відповіді й подвойте. Якщо оформлення чекає на API доставки чи оплати, воркерів потрібно більше, ніж ядер: у тесті з затримкою 300 мс перехід з 2 на 10 воркерів збільшив пропускну здатність з 4,7 до 14,3 запиту за секунду.

Чи вимикати cart fragments?

Лише якщо в шапці немає міні-кошика, який від нього залежить. Сам запит недорогий (30-35 мс), але не кешується. Блочні теми його не використовують, класичні на кшталт Storefront без нього не оновлюватимуть лічильник кошика.

Які версії потрібні для WooCommerce 11?

WooCommerce 11.2.1 вимагає WordPress 7.0 або новіший і формально PHP 7.4+, але офіційна рекомендація PHP 8.3+, MySQL 8.0+ або MariaDB 10.6+ і 256 МБ пам’яті.