How to Prepare WooCommerce for Black Friday Traffic (Load Test + Checklist)

Black Friday is 27 November 2026, and Cyber Monday follows on 30 November. For most WooCommerce stores, that weekend brings more traffic in a few hours than a normal month. The stores that break are rarely the ones with the slowest homepage. They are the ones that never tested checkout under woocommerce high traffic, and found out during the sale that checkout was the weak point.

A homepage test will not save you. Your homepage is cached. Checkout is not, and it cannot be. Every shopper at checkout runs PHP and hits the database, at the same time as every other shopper. That is why this post starts with a load test, not a tips list. Test checkout first, fix what the test finds, then run the checklist.

What woocommerce high traffic means for your checkout

High traffic on a normal WordPress site mostly means more page views, and a page cache absorbs those. High traffic on a WooCommerce store is different, because a sale changes the mix of requests. On a quiet day, most requests are cached product and category pages. During a sale, a much larger share of requests are uncached: add to cart, refresh totals, apply a coupon, place the order, and return from the payment gateway. Each of those needs a PHP worker and a database connection.

One order is not one request. A single shopper going from product page to order confirmation makes several uncacheable requests along the way. So the number that matters is not visitors per minute. It is how many checkouts your store can finish per minute without errors, and how slow checkout gets as that number rises.

There is a simple way to estimate it. Take the number of PHP workers, or entry processes, your hosting plan gives you, and divide by how long one checkout takes in seconds. That gives you checkout requests per second. For example, 40 entry processes with a checkout that takes 2 seconds gives 20 checkout requests a second, or 1,200 a minute. That is an estimate, not a promise. The real number comes from the load test below, because a slow plugin or a heavy gateway call makes one checkout take far longer than 2 seconds, and that cuts your capacity fast.

The load test: k6 on checkout, not the homepage

Load testing means sending fake shoppers at your store in a controlled way, and watching when it slows down or starts failing. The tool for this is k6. It is free and open source, its scripts are JavaScript, and WooCommerce itself ships k6 performance tests that follow the same pattern this section uses. The official k6 docs explain how to install it and run your first test.

Run the test on a staging copy of your store, never on live. A load test places real test orders, sends real order emails, and can take a staging site down. That is the point of staging: find the limit where it is safe. Before you run it, put the payment gateway in test mode, turn off order emails, and plan to reset WooCommerce orders between runs.

A useful test follows a real shopper. One virtual user loads the homepage, opens a category, opens a product, adds it to the cart, loads the cart, and places an order. Repeat that with more and more virtual users at the same time. Ramp up slowly, hold at the peak, then ramp down. A simple starting shape is 2 minutes up to 50 virtual users, 5 minutes holding at 200, then 2 minutes back down. Set two pass marks before you start: 95 percent of requests under 3 seconds, and less than 1 percent failed requests. If the test breaks either mark, you have found your limit.

WooCommerce checkout needs one technical detail handled, or the test orders will fail for a fake reason. The checkout page returns a security value called the woocommerce-process-checkout-nonce, and the order request must send that same value back. A good script reads the nonce from the checkout page first, then passes it into the order request. WooCommerce’s own k6 tests do exactly this. If your orders fail with a nonce error, the script is wrong, not the store.

Here is a short starting script. It is a starting point, not a finished test. Adapt the product URL and the checkout fields to your own store.

import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
  stages: [
    { duration: '2m', target: 50 },
    { duration: '5m', target: 200 },
    { duration: '2m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<3000'],
    http_req_failed: ['rate<0.01'],
  },
};
export default function () {
  const base = 'https://staging.yourstore.com';
  http.get(`${base}/shop/`);
  sleep(1);
  http.get(`${base}/product/your-black-friday-product/`);
  sleep(1);
  http.post(`${base}/?wc-ajax=add_to_cart`, { product_id: '123', quantity: '1' });
  sleep(1);
  const checkoutPage = http.get(`${base}/checkout/`);
  // Read woocommerce-process-checkout-nonce from checkoutPage.body,
  // then post the order to /?wc-ajax=checkout with that nonce.
  check(checkoutPage, { 'checkout loads': (r) => r.status === 200 });
  sleep(1);
}

Run the command with k6 run script.js. Watch three things while it runs: the p95 response time for each step, the failed request rate, and your server’s CPU, RAM, and PHP worker count. The step where p95 first climbs past 3 seconds is your bottleneck. Fix that step first, then test again. One fix and one retest beats ten guesses.

For the full method on testing store pages the way shoppers use them, our WooCommerce speed test guide covers cart, checkout, and logged-in pages. For a published example of the k6 method, the HostingWC benchmark runs k6 ramping from 10 to 500 virtual users over 20 minutes, with a mix of 60 percent browse, 30 percent cart, and 10 percent checkout, and reports p95 per step. That mix is a good model: most shoppers browse, fewer add to cart, and only some check out.

What to cache and what never to cache

Caching is the single biggest lever for Black Friday, and the single easiest way to break a store. The rule is simple. Cache the pages that look the same for everyone. Never cache the pages that are different for each shopper.

Cache aggressively: homepage, category pages, product pages, and static files such as images, CSS, and JavaScript. Put a CDN in front of those if your shoppers are spread across regions. Use one page cache, not two stacked on top of each other.

Never cache these: cart, checkout, My Account, and any order confirmation page. Never cache a logged-in user, including customers and shop managers. Never cache a request carrying WooCommerce session cookies, such as woocommerce_items_in_cart and wp_woocommerce_session_, because a shopper with items in the basket must always see their own basket. If checkout gets cached, one shopper can see another shopper’s cart or a stale total. That is a classic high-traffic failure, and it is worse than a slow page.

Most WooCommerce-aware caching plugins exclude cart, checkout, and My Account by default. Check the exclusion list anyway, especially if you have a custom checkout URL or a quote cart. Then prove it with a simple test. Add a product to the cart in one browser, then open the store in a private window in another browser. You should not see that cart. If you do, the cache is wrong.

One more request deserves attention: cart fragments. The request wc-ajax=get_refreshed_fragments fires on every page view, whether or not the visitor has a cart, and it is one of the most common hidden costs in a WooCommerce store. On pages that do not need a live mini cart, remove it or disable it there. Keep it only where the mini cart must update without a page reload.

Server limits to raise before the sale

Caching handles the browsing crowd. These limits handle the checkout crowd, because checkout always reaches the server.

PHP workers, or entry processes, are first. Each uncached request needs one worker for as long as it runs. When all workers are busy, the next shopper waits. Ask your host how many workers your plan includes, and what happens at a few times your normal peak. If the load test shows workers maxing out, you need more workers or a faster checkout, and only your host can add workers.

Object cache is second. A persistent object cache such as Redis takes repeated database work off your server, and it matters most during checkout spikes. If your host supports Redis, turn it on, then confirm it is actually being hit. An object cache that is installed but not used helps no one.

Database load is third. Open WooCommerce, then Status, then Scheduled Actions, and check for failed or overdue pending jobs. Action Scheduler jobs that pile up add database work at the worst moment. Clear the failed ones, and check that pending jobs are running on time. Clean up old sessions and expired transients before the sale, not during it.

PHP memory and execution time are fourth. Open WooCommerce, then Status, and read what it flags. If it flags a low memory limit or a short execution time, raise them before the sale. The exact numbers depend on your store and your host, so use the flags and the load test as your guide, not a number from a blog post.

Finally, freeze changes. From about 20 November to 30 November, change nothing unless something is broken. No plugin updates, no theme changes, no new tracking scripts. A new plugin the week of the sale is a new way to fail, and there is no time to fix it properly during the sale.

The Black Friday checklist: week by week

Black Friday is 27 November and Cyber Monday is 30 November. Work backwards from those dates.

This week, by 13 November: run the load test on staging. Fix what it finds. Update plugins and themes for the last time. Confirm cart, checkout, and My Account are excluded from cache. Check Scheduled Actions for failed jobs. Put the payment gateway in test mode on staging only, and confirm a full test order completes.

Week of 16 November: test checkout and payments on a real phone over a normal mobile connection, not just on desktop. Most holiday spending happens on phones. Allow guest checkout, so shoppers are not forced to create an account. Remove checkout fields you do not need. Test every coupon against the sale products, because a coupon that excludes the sale items will fail in front of customers. Check stock counts on your sale products. Confirm order emails send, and confirm the gateway is in live mode on the live store.

Week of 23 November, sale week: freeze changes. Watch the store during the sale, not after it. Keep a rollback plan ready: know how to turn off a sale price, disable a coupon, or put the store in maintenance mode if something breaks. After Cyber Monday, review the load test against what actually happened, and write down what to fix before the next sale.

Checkout and payment checks before you open the sale

A green uptime monitor on the checkout page is not enough. The page can load while the payment step fails, or while a webhook never updates the order. Prove the full purchase journey end to end, with a real order, on staging, and with the same gateway the live store uses.

Test guest checkout and logged-in checkout both. Test at least one order with each payment method you offer. Confirm the gateway is not still in test mode on live, because that is a mistake that only shows up when a real customer pays. Confirm shipping costs and delivery dates show before the final step, so shoppers are not surprised at the last screen. And confirm stock: a product that sells out mid-sale should show out of stock cleanly, not let shoppers pay for something you cannot send.

Baymard Institute puts the average cart abandonment rate at about 70 percent, and about 17 percent of US shoppers have left an order because checkout was too long or complicated. During Black Friday, each lost checkout costs you more, because the shopper came from a sale email or ad you already paid to send.

Frequently Asked Questions

Q: How many visitors can WooCommerce handle on Black Friday?

A: There is no single number. It depends on your PHP workers, how long checkout takes, and how much of the traffic reaches checkout. Run the k6 load test on staging and read the virtual user count where p95 first passes 3 seconds. That is your store’s answer.

Q: Should I cache the WooCommerce cart and checkout?

A: No. Cart, checkout, My Account, and order confirmation pages must stay out of the cache, along with any visitor who has items in the basket. Cache product and category pages instead.

Q: What is the best load test tool for WooCommerce?

A: k6 is a good choice. It is free and open source, its scripts are JavaScript, and WooCommerce itself ships k6 performance tests. Loader.io is another option named in many WooCommerce guides. Either way, test checkout, not just the homepage.

Q: Can I load test my live store?

A: No. Load test a staging copy only. A load test places test orders and can take a site down. Test on staging, fix what it finds, then ship the fix to live.

Q: How long before Black Friday should I load test?

A: At least two weeks before, so there is time to fix what the test finds. For Black Friday on 27 November 2026, that means by 13 November.

Q: Will a CDN fix a slow checkout?

A: No. A CDN speeds up static files and cached pages, but checkout bypasses the cache by design. A CDN helps the browsing crowd. Only more PHP workers, a faster checkout, and a clean database help the checkout crowd.

What to do next

Black Friday rewards the stores that tested early. Run the load test on staging this week, fix the first bottleneck it finds, and retest. Then run the checklist, freeze changes from 20 November, and watch the store during the sale. If you want a second pair of eyes on the result, a free speed audit can turn the test numbers into a clear list of what to fix first.