Щоб прискорити WooCommerce у 2026 році, недостатньо встановити ще один плагін кешування. Швидкість магазину залежить від теми, запитів до бази даних, каталогу, зображень, сторонніх інтеграцій, checkout і того, як розширення підключають свої скрипти.
Правильна оптимізація починається з вимірювань і рухається від найбільшого вузького місця до наступного. Цей чекліст допоможе побудувати системний процес, а не набір випадкових «прискорень».
1. Зафіксуйте початкові метрики
Перед змінами виміряйте щонайменше чотири типи сторінок:
- головна або landing page;
- категорія товарів;
- картка товару;
- кошик і checkout.
Запишіть LCP, INP, CLS, TTFB, кількість запитів, обсяг переданих даних і час відповіді сервера. Тестуйте як анонімного користувача, так і користувача з активним кошиком. Офіційні рекомендації WooCommerce для розширень пропонують орієнтуватися на Lighthouse Performance 90+ для простого тестового магазину, але реальна ціль має враховувати каталог і бізнес-функції.
Важливо порівнювати однакові сценарії на однаковому середовищі. Один «зелений» запуск Lighthouse не замінює повторюваний benchmark.
2. Налаштуйте кеш без поломки кошика
Page cache добре працює для каталогу, статей і більшості публічних сторінок. Але кошик, checkout і особистий кабінет містять дані конкретної сесії та зазвичай мають бути виключені з повносторінкового кешу.
Перевірте:
- винятки для cart, checkout, my-account і службових endpoint-ів;
- поведінку фрагментів кошика та Store API;
- правила CDN для cookies і query parameters;
- очищення кешу після зміни ціни, залишку або статусу товару;
- object cache на Redis або Memcached, якщо його підтримує хостинг.
Кешування має зменшувати роботу сервера, а не приховувати повільні SQL-запити або створювати застарілі ціни.
3. Підключайте assets лише там, де вони потрібні
Плагін доставки не повинен завантажувати великий JavaScript на сторінці блогу, а скрипт галереї товару — на сторінці контактів. У темі та кастомних розширеннях перевіряйте контекст перед wp_enqueue_script() і wp_enqueue_style().
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_product() ) {
return;
}
wp_enqueue_script(
'my-product-ui',
plugins_url( 'assets/product.js', __FILE__ ),
array(),
'1.0.0',
true
);
} );
Також видаляйте невикористаний CSS, розділяйте великі bundle-и й відкладайтe необов’язкову логіку. Мінімізація корисна, але умовне завантаження зазвичай дає більший ефект.
4. Оптимізуйте запити та кеш-інвалідацію
Проблеми великих магазинів часто починаються не з одного «повільного» запиту, а з сотень повторів. Шукайте:
- N+1-запити в циклах товарів;
- повторне завантаження однакових meta й terms;
- запити без індексів до великих таблиць;
- транзієнти, які скидаються занадто часто;
- повні перерахунки каталогу після незначної зміни.
У WooCommerce 11.1–11.2 команда оптимізувала збереження товарів: data stores пропускають частину no-op записів, коли значення фактично не змінилося. За даними WooCommerce Developer Blog, це може скоротити кількість SQL-запитів під час збереження товару до 45%.
Але є нюанс для кастомних інтеграцій: callbacks на set_object_terms не повинні припускати, що hook спрацьовує при кожному збереженні незалежно від зміни terms. Таку логіку краще переглянути й, за потреби, перенести на більш відповідний hook на кшталт woocommerce_update_product або save_post_product.
5. Використовуйте HPOS свідомо
High-Performance Order Storage зберігає замовлення в таблицях, оптимізованих для ecommerce-запитів. Це зменшує залежність від універсальної структури posts/postmeta й полегшує роботу з великим обсягом замовлень.
Перед увімкненням або завершенням міграції:
- перевірте сумісність усіх платіжних, доставкових і CRM-розширень;
- протестуйте створення, редагування, повернення й експорт замовлень;
- перевірте custom SQL, який напряму читає
wp_postsабоwp_postmeta; - зробіть backup і міграцію на staging;
- переконайтеся, що Action Scheduler не накопичує помилки синхронізації.
6. Оптимізуйте медіа для каталогу
Зображення товарів часто формують основну частину page weight. Практичний набір правил:
- завантажуйте зображення у WebP або AVIF там, де це підтримує pipeline;
- не віддавайте 2500px-файл у картці шириною 400px;
- перевіряйте коректність
srcsetіsizes; - не застосовуйте lazy loading до головного LCP-зображення;
- задавайте width і height, щоб уникати layout shifts;
- стискайте галереї до завантаження, а не лише на льоту.
7. Вимірюйте вплив кожного розширення
WooCommerce рекомендує тестувати магазин із розширенням і без нього. Це найпростіший спосіб відрізнити системну проблему від регресії конкретного плагіна.
Для кожного важливого розширення порівняйте:
- час відповіді сторінки;
- кількість SQL-запитів;
- обсяг JavaScript і CSS;
- фонові задачі Action Scheduler;
- поведінку кешу;
- checkout і Store API.
Корисно автоматизувати хоча б критичний маршрут: відкрити категорію, перейти до товару, додати його в кошик і пройти checkout у тестовому режимі.
8. Не плутайте швидкість із агресивним кешем
Неправильно налаштований кеш може показати чудовий синтетичний результат і водночас віддавати неправильну валюту, стару ціну або чужий кошик. Перевіряйте магазин у кількох сесіях, мовах і валютах, якщо вони підтримуються.
Після кожної зміни повторюйте бізнес-сценарії, а не тільки технічний benchmark.
Короткий порядок робіт
- зняти baseline для ключових сторінок;
- виправити серверний TTFB і кешування;
- скоротити зайві assets;
- знайти повторні та дорогі SQL-запити;
- перевірити HPOS і фонові задачі;
- оптимізувати зображення каталогу;
- протестувати розширення по одному;
- повторити вимірювання та зафіксувати результат.
Висновок
Швидкий WooCommerce — це результат дисципліни: виміряти, знайти bottleneck, внести одну зміну й перевірити знову. Кеш, HPOS, оптимізовані зображення й чисті запити працюють найкраще разом. Якщо ж магазин має кастомні інтеграції або великий каталог, performance-аудит коду часто дає більше, ніж черговий універсальний «optimizer».
Детальні базові рекомендації доступні в офіційній документації WooCommerce Performance Best Practices.
Матеріал актуальний станом на 24 вересня 2026 року.
en