Чи витримає ваш магазин на WooCommerce Black Friday? Чекліст із 10 пунктів, який проходимо ми

Black Friday цього року — 27 листопада 2026, Cyber Monday — 30 листопада. Для більшості магазинів ці вихідні коштують як кілька звичайних тижнів. І це ті самі вихідні, коли повільне оформлення замовлення, крихкий плагін і ліміт хостингу вилазять в одну годину — саме тоді, коли реклама витрачає найбільше за рік.

Це чекліст Black Friday, який ми проходимо з кожним магазином, що готуємо до піку. Пункти стоять у тому порядку, у якому їх варто робити, і в кожному написано, чим обходиться пропущений пункт і як перевірити його самому за десять хвилин.

Правка, випущена 24 листопада, — це саме та правка, яка ламається 27 листопада. Тому робота стоїть у жовтні, а не в останньому тижні.

Перш ніж щось тестувати, запишіть три числа з минулого Black Friday або зі свого найзавантаженішого дня: замовлень у пікову годину, відвідувачів у цю годину і як це співвідноситься зі звичайним днем. Для магазинів, які пишуть листи й рекламуються, це зазвичай 3–5× від звичайного.

Це і є ваша мета. Навантажувальний тест «на 1 000 користувачів» не означає нічого, якщо ваш справжній пік — 150. Або 3 000.

Якщо пропустити: ви протестуєте не те число і будете спокійні без причини.

Перевірка за десять хвилин: Google Analytics — відвідувачі по годинах, WooCommerce → Звіти → Замовлення — замовлення по днях. Запишіть три числа там, де їх побачать і розробник, і хостинг.

Ваша головна майже напевно закешована і швидка. Покупці Black Friday на ній не залишаються: вони шукають, фільтрують категорію, кладуть у корзину й оформлюють замовлення — а ці сторінки будуються для кожного відвідувача окремо.

Тестуйте весь шлях на копії магазину: категорія → товар → додати в корзину → оформлення з тестовою оплатою, на 1×, 3× і 5× вашого піку. Дивіться на два числа — 95-й процентиль часу відповіді й частку помилок. Те, що зламається першим, і є виправлення номер один.

Якщо пропустити: звіт про швидкість покаже 95 зі 100, а оформлення все одно відвалиться о восьмій вечора в п’ятницю.

Перевірка за десять хвилин: відкрийте власне оформлення з телефону, на мобільному інтернеті, з трьома товарами в корзині. Якщо вже зараз повільно — під навантаженням буде значно гірше.

Тієї миті, коли покупець кладе щось у корзину, WooCommerce видає йому cookie сесії, і більшість кешів сторінок перестають віддавати йому закешовані сторінки. Далі кожна сторінка, яку він відкриває, будується PHP і базою — а платить вам саме він.

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

Перевірити треба три речі: які cookie змушують кеш відступити (корзина й сесія це норма, усе інше помилка), чи працюють cart fragments на кожному перегляді сторінки і чи є постійний об’єктний кеш — Redis або Memcached, — щоб некешовані сторінки були хоч дешевими.

Якщо пропустити: найзавантаженішу годину року сервер проведе, збираючи сторінки з нуля для всіх, у кого повна корзина.

Перевірка за десять хвилин: запустіть безкоштовну експрес-перевірку нижче. Вона завантажує головну з кешу і так, як її отримує покупець із корзиною, і показує обидва числа поруч.

Некешовані запити обслуговують воркери PHP. Коли всі воркери зайняті, нові запити стають у чергу — а на піку черга перетворюється на таймаути й сторінки 502 або 504.

Запитайте в хостингу письмово: скільки у вас воркерів PHP, скільки з’єднань з базою і чи можуть вони додати потужності на вихідні Black Friday. Більшість керованих хостингів продають тимчасові потужності, і це набагато дешевше за простій. Перевірте і правила CDN: картинки та статика не повинні доходити до вашого сервера.

Якщо пропустити: ви знайдете свою межу в найгірший момент, і підняти її в п’ятницю ввечері вже нікому.

Перевірка за десять хвилин: один лист у хостинг із цими трьома питаннями.

Ваше оформлення — це не тільько ваш код. Одне замовлення чекає на сервіс розрахунку доставки, сервіс податків, антифрод, платіжний шлюз і часто ERP — усередині того самого запиту, на який дивиться покупець.

Тому тестуйте так, як цим користуються: оплатіть кожним способом, який у вас є, включно з картами 3-D Secure й гаманцями, з телефону. Перевірте купони, порогові суми безкоштовної доставки й правила доставки для кожного регіону. Тримайте резервний платіжний шлюз, який можна ввімкнути, якщо основний почне притримувати платежі. І захистіть оформлення від ботів, що перебирають картки — їхній трафік теж зростає навколо Black Friday.

Якщо пропустити: один повільний сторонній сервіс тримає ваше оформлення, а покупці бачать помилку з повною корзиною. Один магазин прийшов до нас після Black Friday, де повільне оформлення забрало близько 15% замовлень — що ми знайшли і виправили.

Перевірка за десять хвилин: оформіть одне справжнє замовлення з телефону й порахуйте секунди від «Оформити» до сторінки «дякуємо».

Замовлення Black Friday запускають багато роботи, якої ви не бачите: оновлення складу, синхронізації з ERP і маркетплейсами, листи, вебхуки, заплановані дії. Коли ця робота йде в тих самих PHP і базі, що й оформлення, вона забирає воркерів у ваших покупців.

Якщо пропустити: черга росте весь вечір, замовлення доходять до ERP із запізненням на години, а залишки перестають відповідати дійсності.

Перевірка за десять хвилин: WooCommerce → Статус → Заплановані дії. Сотні дій у черзі або з помилками у звичайний день стануть тисячами на піку. Заодно перевірте ліміт відправлення листів у свого провайдера.

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

Якщо пропустити: ви не зможете сказати, яка кампанія себе окупила. Алгоритм — теж.

Перевірка за десять хвилин: порівняйте вчорашні замовлення WooCommerce з покупками в GA4 і в Meta. Розбіжність більша за кілька відсотків означає, що трекінг зламаний уже зараз — під навантаженням стане гірше. Серверний трекінг робить події покупок значно надійнішими.

Оновіть WordPress, WooCommerce, плагіни й тему у жовтні, спочатку на копії, і приберіть те, чим не користуєтесь. Після заморозки не оновлюється нічого, крім перевіреного вами виправлення безпеки.

Якщо пропустити: ви або йдете в пік на старому коді з відомими помилками, або оновлюєтесь у найгірший тиждень року.

Перевірка за десять хвилин: порахуйте плагіни з доступними оновленнями і плагіни, призначення яких ніхто не може назвати.

Заморозка коду — це не бюрократія. Це спосіб переконатися, що замовлення приймає той самий магазин, який ви протестували.

Напишіть на одну сторінку: як відновити вчорашній бекап, як перемкнути платіжний шлюз, як безпечно вимкнути плагін і хто робить кожен крок.

Якщо пропустити: о дев’ятій вечора в п’ятницю троє людей вгадують у спільному чаті.

Перевірка за десять хвилин: відкрийте свою систему бекапів і подивіться, коли відновлення перевіряли останній раз. Не робили копію — саме перевіряли відновлення.

З ранку п’ятниці до вечора понеділка хтось має дивитися за доступністю, оформленням і платежами — і знати магазин достатньо, щоб діяти за хвилини. Якщо своєї людини немає, для цього є підтримка WooCommerce. Дайте цій людині контакти хостингу й платіжного провайдера до п’ятниці, а не під час аварії.

Якщо пропустити: магазин лежить дві години, перш ніж хтось помітить, і першим помічає покупець.

Перевірка за десять хвилин: назвіть людину й запишіть її номер. Якщо не можете — це і є діра.

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

Якщо ви передаєте це далі, ось конкретика, яку варто перевірити в коді й конфігурації:

• Обхід кешу: які cookie в списку виключень; чи працює wc-ajax=get_refreshed_fragments на кожному перегляді; чи об’єктний кеш постійний і який у нього hit rate на піку.
• Навантажувальний тест: копія на тих самих версіях PHP і бази, каталог і таблиця замовлень такого ж розміру, сценарії категорія → товар → додати в корзину → оформлення, прогони на 1×, 3× і 5× заміряного піку; дивимо p95, частку помилок і завантаженість воркерів, а не середні.
• Шлях оформлення: таймаути й повтори для кожного зовнішнього виклику — доставка, податки, антифрод, шлюз; що відбувається, коли один із них перестає відповідати; які з цих викликів можна винести з запиту.
• Фонова робота: глибина черги Action Scheduler і частка помилок, cron із системи, а не з переглядів сторінок, важкі синхронізації в черзі й поза піком.
• Трекінг: події покупок із сервера з дедуплікацією і щоденне порівняння замовлень із GA4 та рекламними кабінетами.

Саме це входить у нашу перевірку готовності до Black Friday: навантажувальний тест на копії магазину, оформлення й оплати під цим навантаженням, ліміти хостингу, інтеграції та облік замовлень. Ви отримуєте письмовий список ризиків із виправленнями й годинами протягом 48 годин після доступу. Це коштує $490, і ця сума зараховується, якщо далі береться спринт виправлень.