Чому гальмує WooCommerce: HPOS, роздута база і фонові завдання

Плагін кешу стоїть, зображення стиснуті, а магазин на WooCommerce все одно гальмує: вітрина відкривається по кілька секунд, оформлення замовлення підвисає, менеджер чекає на список замовлень. Нижче — де магазин втрачає час (база даних, черга фонових завдань, сервер), як перевірити це вбудованими засобами WordPress і WooCommerce та що можна виправити без розробника.

Де гальмує магазин: вітрина, кошик чи адмінка

У магазину на WooCommerce чотири типові місця сповільнення, і в кожного — свій симптом.

• Головна, категорії та картки товарів відкриваються повільно навіть у гостя. Виміряйте час відповіді сервера: у Chrome F12 → Network → запит самої сторінки → Timing, рядок Waiting for server response (у документації Chrome — Waiting (TTFB)). Якщо сервер відповідає довго, причину шукайте в запитах каталогу до бази, фільтрах і плагінах. Якщо швидко, а PageSpeed скаржиться на скрипти та зображення, проблема у фронтенді — про нього стаття про Google PageSpeed Insights.
• Каталог гортається нормально, а кошик і оформлення замовлення працюють із паузами. Ці сторінки кешувати не можна, кожен запит до них проходить через PHP і базу, а до цього додаються розрахунок доставки, платіжні модулі та звернення до зовнішніх сервісів.
• Повільна адмінка WooCommerce: список замовлень, картка замовлення, звіти. Зазвичай винна база: старий спосіб зберігання замовлень (розділ про HPOS нижче), черга фонових завдань або розрослі таблиці. Рідше — плагіни, які на екрані замовлення звертаються до зовнішніх сервісів. Є й менш помітне навантаження: кожна відкрита вкладка адмінки WordPress раз на 15–120 секунд звертається до сервера через Heartbeat API; п’ять менеджерів із десятком вкладок у кожного — це постійний потік запитів.
• Усе працює, але в певні години сайт «лягає». Шукайте завдання за розкладом: вивантаження цін і залишків з облікової системи, імпорт, масові фонові завдання, резервне копіювання на сервері.

Запишіть, на яких сторінках і о котрій годині магазин гальмує сильніше: за цим списком розробник зрозуміє, з чого починати.

Чим вимірювати

Почніть із вбудованих інструментів. «Інструменти → Здоров’я сайту» у WordPress з версії 6.6 попереджає, якщо обсяг автозавантажуваних опцій перевищує 800 КБ. Там само WordPress перевіряє наявність постійного об’єктного кешу та кешу сторінок; перевірка кешу сторінок вважає проблемою відповідь сервера, повільнішу за 600 мс. Обидві перевірки кешу працюють лише на робочому сайті, на тестовій копії їх не буде. WooCommerce додає сюди свої пункти, зокрема про синхронізацію сховища замовлень.

У «WooCommerce → Статус» є звіт про систему з блоком «База даних» і розміром кожної таблиці. За ним видно, що розрослося: wp_options, wp_postmeta, таблиці actionscheduler_* або wp_woocommerce_sessions (префікс wp_ на вашому сайті може бути іншим). Поруч вкладка «Заплановані дії» з чергою фонових завдань.

Безплатний плагін Query Monitor показує запити до бази на відкритій сторінці, позначає повільні, дубльовані та помилкові й групує їх за плагінами і темою — видно, який плагін витрачає найбільше часу. Окремо він виводить зовнішні HTTP-запити з часом відповіді: на сторінці оформлення замовлення це секунди очікування служби доставки. Сама собою кількість плагінів мало про що говорить: один плагін, який на кожній сторінці звертається до зовнішнього сервісу, шкодить сильніше за десять акуратних. Ставте Query Monitor на час діагностики (краще на тестовій копії), а після — видаляйте. Вимикати плагіни по одному теж можна лише на тестовій копії: на робочому магазині вимкнений модуль оплати чи доставки ламає замовлення.

На сервері стане в пригоді лог повільних запитів MySQL. За замовчуванням він вимкнений, а поріг long_query_time дорівнює 10 секундам — для сайту це багато, тому на час вимірювань поріг знижують. Налаштування MySQL змінюють на рівні сервера (на віртуальному хостингу — через службу підтримки хостера, на VPS — через адміністратора).

Сховище замовлень HPOS: що змінилося у 2026 році

Довгий час WooCommerce зберігав замовлення так само, як WordPress зберігає записи блогу: основний рядок замовлення в таблиці wp_posts, кожне поле (адреса, телефон, спосіб оплати, номер накладної) — окремим рядком у wp_postmeta, упереміш із даними товарів, сторінок і всього іншого. Що більше замовлень і товарів, то довше база шукає потрібний рядок у спільній таблиці.

HPOS (High-Performance Order Storage, високопродуктивне сховище замовлень) переносить замовлення в окремі таблиці wc_orders, wc_order_addresses, wc_order_operational_data і wc_orders_meta з індексами під типові запити магазину. Для нових інсталяцій HPOS увімкнено за замовчуванням з WooCommerce 8.2 (жовтень 2023). Магазини, запущені раніше, WooCommerce сам не переводить: перемикають вручну.

Поточний режим видно у «WooCommerce → Налаштування → Розширені → Функції» (в англійському інтерфейсі Advanced → Features), пункт про сховище замовлень. Варіантів три:

1. Старе сховище на записах WordPress. Замовлення у wp_posts і wp_postmeta.
2. Режим сумісності. WooCommerce тримає замовлення в обох сховищах і дублює кожну зміну. Основним може бути старе сховище (так починають перехід) або HPOS (так перевіряють роботу після перемикання). Режим потрібен на час переходу, щоб можна було відкотитися.
3. HPOS без синхронізації. Кінцевий стан.

Що змінили версії 10.7 і 10.8

WooCommerce 10.7 (вийшов 14 квітня 2026) за замовчуванням вимкнув синхронізацію під час читання (sync on read). Раніше в режимі сумісності WooCommerce під час відкриття замовлення підтягував у HPOS дані, які якийсь плагін записав напряму у wp_posts або wp_postmeta. Тепер не підтягує: якщо плагін доставки старого зразка зберігає номер накладної функцією update_post_meta, у режимі HPOS цей номер у замовленні може не з’явитися. Розробник може повернути попередню поведінку фільтром (хуком WordPress) woocommerce_hpos_enable_sync_on_read, але команда WooCommerce попереджає, що в майбутніх версіях цей механізм можуть прибрати зовсім, і радить переписати інтеграцію на стандартні функції роботи із замовленнями (анонс зміни).

WooCommerce 10.8 (26 травня 2026) додав індекси у wc_orders і wc_reserved_stock, повернув стовпець meta_value до індексу таблиці wc_orders_meta (виправив сповільнення пошуку за метаданими замовлень) і скоротив кількість запитів у кошику, архівах товарів і REST API. Версія 10.8 вимагає WordPress 6.9 або новіший: магазин на старому ядрі цих поліпшень не отримає.

Чи переходити на HPOS

Якщо магазин досі на старому сховищі, ми радимо планувати перехід: оптимізації запитів до замовлень у 10.7 і 10.8 зроблені для таблиць HPOS, і далі WooCommerce розвиватиме саме їх. Порядок:

1. Зробити повну копію сайту на тестовому сервері.
2. Перевірити сумісність плагінів. WooCommerce попереджає на екрані «Функції» та у списку плагінів, якщо плагін заявлений як несумісний з HPOS. Плагіни без такої позначки теж потрібно перевірити вручну, насамперед доставку, оплату та обмін з обліковою системою.
3. Увімкнути режим сумісності й дочекатися, поки фонові завдання перенесуть старі замовлення (одне завдання переносить 25 замовлень). У великому магазині розробник запускає перенесення командою wp wc hpos sync, як описано в офіційному посібнику для великих магазинів.
4. Перемкнутися на HPOS, залишити синхронізацію на час перевірки, потім вимкнути її.

На робочому магазині без резервної копії перехід починати не можна. Найбільше часу забирає перевірка інтеграцій; саме перемикання — це кілька кліків. У тому ж посібнику WooCommerce пише, що в їхніх тестах увімкнена синхронізація (поки основним залишалося старе сховище) помітно не сповільнювала магазин, тож вимикати її заради швидкості немає сенсу; вимикають після перевірки всіх плагінів.

Роздута таблиця wp_options: autoload і транзієнти

У таблиці wp_options WordPress і плагіни зберігають налаштування. У кожної опції є ознака автозавантаження (autoload): такі опції WordPress завантажує на старті на кожному запиті, потрібні вони цій сторінці чи ні. Документація WordPress попереджає, що зайве автозавантаження знижує продуктивність, особливо якщо опції використовуються рідко.

Роздувають автозавантаження зазвичай плагіни. Одні пишуть в опції логи та кеші. Інші створюють окрему опцію на кожне замовлення: у травні 2026 на форумі wordpress.org розбирали плагін доставки, який створив сотні автозавантажуваних опцій вигляду _boxnow_parcel_order_id_*. Треті після видалення залишають свої дані в базі. З WordPress 6.6 нові опції більші за 150 КБ за замовчуванням не автозавантажуються, але накопичене раніше нікуди не поділося.

Ознака проблеми — попередження у «Здоров’ї сайту» про перевищення 800 КБ. Далі розробник знаходить найбільші опції, визначає, якому плагіну вони належать, і вирішує: вимкнути автозавантаження, видалити залишки видаленого плагіна чи замінити сам плагін. Видаляти опції за маскою «схоже на сміття» плагінами-чистильниками небезпечно: так стирають налаштування робочого модуля оплати.

Транзієнти — тимчасовий кеш, який WordPress за замовчуванням зберігає в тій самій wp_options. Термін життя в них є, але прострочені записи WordPress чистить нечасто, і в магазині з великим каталогом вони накопичуються. Для них є безпечна кнопка у «WooCommerce → Статус → Інструменти», пункт про прострочені транзієнти. Якщо на сервері підключений постійний об’єктний кеш (Redis або Memcached), транзієнти зберігаються в пам’яті й таблиця опцій від них не росте.

Фонові завдання: Action Scheduler і WP-Cron

Багато що в магазині відбувається у фоні: надсилання частини листів, вебхуки, імпорт даних у розділ «Аналітика», перебудова службових таблиць товарів, перенесення замовлень у HPOS, завдання плагінів підписок та інтеграцій. Усі ці завдання WooCommerce ставить у чергу Action Scheduler. Черга зберігається в таблицях із префіксом actionscheduler_, подивитися її можна у «WooCommerce → Статус → Заплановані дії» або в «Інструменти → Заплановані дії».

За замовчуванням чергу запускає WP-Cron, не частіше ніж раз на хвилину; за прохід береться 25 завдань, на обробку відводиться до 30 секунд. Сам WP-Cron спрацьовує лише під час відкриття сторінок сайту: уночі, без відвідувачів, завдання чекають, а вранці виконуються одночасно із запитами покупців. Виконані та скасовані завдання Action Scheduler видаляє через 31 день, завдання з помилкою з версії 4.0 зберігає три місяці. Проблеми починаються у трьох випадках:

• Завдання створюються швидше, ніж виконуються. У статусі Pending тисячі записів, частина прострочена, листи надходять із запізненням, статуси замовлень оновлюються не одразу.
• Якийсь плагін раз у раз створює завдання, які завершуються помилкою. Таблиця actionscheduler_actions і журнал actionscheduler_logs ростуть на сотні тисяч рядків, адмінка стає повільнішою.
• Таблиця пошкоджена. Улітку 2026 на форумі wordpress.org описано випадок: під час перенесення сайту на сервері закінчилося місце, і MySQL позначив actionscheduler_actions як пошкоджену (marked as crashed). Завдання падали без видимих помилок, аналітика магазину перестала оновлюватися.

Що можна зробити самому: відкрити «Заплановані дії», відфільтрувати завдання за статусами Pending (очікують виконання) і Failed (помилка) та подивитися стовпець з іменем хука — за ним зазвичай зрозуміло, який плагін створює завдання. Масово видаляти завдання в очікуванні не можна: серед них можуть бути листи покупцям і продовження підписок.

Решта — робота розробника або адміністратора сервера. Для великих сайтів документація Action Scheduler рекомендує запускати чергу через WP-CLI, а не через WP-Cron (рекомендації щодо продуктивності). На практиці це три дії: вимкнути запуск WP-Cron під час відкриття сторінок рядком define( 'DISABLE_WP_CRON', true ); у wp-config.php, налаштувати системний cron на сервері, очистити старі записи командою wp action-scheduler clean. Збільшувати кількість паралельних потоків черги без вимірювань не радимо: та сама документація попереджає, що це може покласти сайт.

Кошик, сесії та кеш сторінок

Кеш сторінок зберігає готовий HTML і віддає його наступним відвідувачам, не збираючи сторінку заново й не звертаючись до бази. Для каталогу це працює добре. Кошик, оформлення замовлення та особистий кабінет WooCommerce вимагає виключати з кешу, бо на цих сторінках дані конкретного покупця (документація з налаштування плагінів кешу). Крім того, у покупця з товаром у кошику з’являються cookie woocommerce_items_in_cart, woocommerce_cart_hash і wp_woocommerce_session_…, і багато систем кешування за цими cookie віддають відвідувачу сторінки в обхід кешу. Тому плагін кешу пришвидшує лише перегляд каталогу гостями, а швидкість оформлення замовлення — моменту, коли магазин заробляє, — визначають PHP, база, плагіни доставки та оплати.

Cart fragments: запит на кожній сторінці

Скрипт wc-cart-fragments оновлює мінікошик у шапці: після завантаження сторінки браузер надсилає AJAX-запит ?wc-ajax=get_refreshed_fragments, який не кешується. З WooCommerce 7.8 скрипт підключається лише разом із віджетом мінікошика, але багато тем підключають його самі. Перевірка: відкрийте будь-яку сторінку магазину в Chrome, натисніть F12, на вкладці Network введіть у пошук get_refreshed_fragments. Якщо запит є, кожна переглянута сторінка дає серверу додаткове звернення до PHP в обхід кешу; якщо запит ще й відповідає повільно, лічильник кошика в шапці оновлюється із затримкою. Вимикати скрипт можна лише після перевірки, що лічильник кошика й далі оновлюватиметься. Іноді простіше замінити мінікошик теми на блок Mini Cart.

Сесії покупців

Сесії покупців разом із вмістом кошиків WooCommerce зберігає в таблиці wp_woocommerce_sessions. Сесія гостя за замовчуванням живе дві доби, потім її видаляє фонове завдання (у поточних версіях WooCommerce — з тієї ж черги Action Scheduler). Якщо черга стоїть, таблиця сесій росте. Росте вона і через ботів, які переходять за посиланнями «Додати в кошик»: кожен перехід створює сесію. У «WooCommerce → Статус → Інструменти» є кнопка видалення сесій, але вона очищає кошики всіх поточних покупців, тому натискати її можна лише у спокійний час і розуміючи наслідки.

Зовнішні запити під час оформлення

Під час зміни адреси або способу доставки сторінка оформлення перераховує вартість. Якщо модуль доставки під час кожного перерахунку звертається до API перевізника й не кешує відповіді, покупець чекає на відповідь стороннього сервера. Query Monitor показує такі затримки в розділі HTTP-запитів. Лікується доопрацюванням модуля: кешуванням довідників відділень і тарифів, тайм-аутами, завантаженням довідників за розкладом.

Каталог, фільтри та обмін з обліковою системою

Візьмімо магазин із варіативними товарами та фільтром за двадцятьма характеристиками. Кожна варіація (розмір, колір) зберігається в базі окремим записом типу product_variation зі своєю ціною, залишком і атрибутами. Якщо фільтр показує кількість товарів поруч із кожним значенням, з кожним кліком він перераховує ці числа для всіх значень усіх характеристик. Без відповідних індексів такі підрахунки стають найважчими запитами сайту.

Для пришвидшення фільтрації у WooCommerce є службова таблиця атрибутів товарів (product attributes lookup table); сторонні плагіни фільтрів будують власні індекси. Відкрийте в Query Monitor сторінку категорії з увімкненими фільтрами й подивіться, які запити найдовші та який плагін їх робить. Якщо гальмує плагін фільтра, допоможе налаштування його індексації або заміна плагіна. Зі стандартним фільтром розробник перевіряє, чи заповнена службова таблиця атрибутів і чи ввімкнено її використання.

Окрема тема — обмін з обліковою системою. Типова схема: раз на кілька хвилин на сайт завантажується повний прайс з усіма залишками. Кожне збереження товару скидає його транзієнти, ставить у чергу завдання на оновлення таблиці атрибутів і запускає обробники всіх плагінів, підписаних на цю подію. Магазин гальмує хвилями, за розкладом вивантаження. Ми радимо передавати лише позиції, що змінилися, а повні вивантаження переносити на ніч і запускати системним cron або з командного рядка, без вебзапитів.

Хостинг: версія PHP, об’єктний кеш, ресурси

Хостинг перевіряють після діагностики, а не замість неї. Переїзд на VPS не виправить запит, який перебирає сотні тисяч рядків: той самий запит виконається трохи швидше, не більше.

• Версія PHP. WooCommerce рекомендує PHP 8.3 або новіший. WooCommerce 11.6, запланований на лютий 2027, вимагатиме мінімум PHP 8.1. У PHP 8.2 підтримка безпеки закінчується 31 грудня 2026 року; про перехід — стаття про кінець підтримки PHP 8.2.
• Постійний об’єктний кеш. Redis або Memcached тримають у пам’яті дані, які WordPress інакше на кожному запиті заново дістає з бази; туди ж потрапляють транзієнти. «Здоров’я сайту» повідомить, якщо за розміром сайту WordPress вважає об’єктний кеш корисним. На віртуальному хостингу такий кеш часто недоступний.
• OPcache. Розширення PHP, яке тримає скомпільований код у пам’яті, щоб PHP не завантажував і не розбирав файли WordPress і плагінів на кожному запиті. На більшості хостингів OPcache уже ввімкнено; якщо ні, його вмикають насамперед — запитайте хостера або адміністратора сервера.
• Ресурси. Кошик, оформлення замовлення, адмінку, фонові завдання та ботів обслуговують ті самі PHP-процеси. Коли процесів не вистачає, запити стають у чергу, і магазин гальмує весь одразу. Це видно за логами сервера та графіками навантаження; тест швидкості однієї сторінки такого не покаже.

Що зробити самому, а що — розробнику

Самостійно й без ризику для даних:

• подивитися «Інструменти → Здоров’я сайту» і записати всі попередження про продуктивність;
• у «WooCommerce → Статус» знайти найбільші таблиці бази;
• відкрити «Заплановані дії» та порахувати завдання у статусах Pending і Failed;
• перевірити в «Налаштуваннях → Розширені → Функції», яке сховище замовлень увімкнено;
• знайти у браузері запит get_refreshed_fragments і подивитися час відповіді;
• дізнатися в панелі хостингу версію PHP;
• видалити плагіни, якими давно не користуються (спершу переконавшись, що вони не потрібні оплаті, доставці чи обміну);
• очистити прострочені транзієнти кнопкою у «WooCommerce → Статус → Інструменти».

Розробнику або адміністратору сервера:

• перехід на HPOS і перевірка інтеграцій, які пишуть замовлення напряму у wp_postmeta;
• розбір wp_options і вимкнення зайвого автозавантаження;
• очищення таблиць Action Scheduler, переведення черги та WP-Cron на системний cron;
• лог повільних запитів, індекси, налаштування фільтрів каталогу;
• підключення об’єктного кешу, оновлення PHP, розподіл ресурсів сервера;
• переробка обміну з обліковою системою.

Перед будь-якою дією, що змінює базу, потрібна свіжа резервна копія бази та файлів, причому перевірена — така, яку реально можна розгорнути. Зміни краще спершу прогнати на тестовій копії. Одна невдала «оптимізація» таблиці замовлень коштує дорожче, ніж місяць повільної адмінки.

Як із цим допомагає RIVERIT

Беремо магазини на WooCommerce на техпідтримку WordPress: оновлюємо ядро та плагіни (зазвичай щомісяця), робимо резервні копії, стежимо за доступністю сайту. Клієнтам на підтримці відповідаємо протягом години, аварії виправляємо і в неробочий час, якщо це входить у тариф. Діагностику та виправлення з цієї статті, від переходу на HPOS до переробки інтеграцій, виконуємо як доопрацювання. Магазини на VPS або виділеному сервері беремо на адміністрування: аналізуємо логи, налаштовуємо сервер, ізолюємо сайти один від одного. Якщо старий магазин простіше перезібрати, ніж лікувати, пропонуємо розробку інтернет-магазину.