That’s why performance matters more on Black Friday than on any ordinary Tuesday (or Friday for that matter). A product
That’s why performance matters more on Black Friday than on any ordinary Tuesday (or Friday for that matter).
A product page that takes four seconds to load is already an annoyance. Let alone the same page under five times the traffic, with half your visitors hitting uncached pages, becomes a spinning wheel at the exact moment you’ve paid the most to bring people in. And the place where stores usually break isn’t the homepage. It’s the add-to-cart button and the checkout, the parts of the store that can’t be cached and that do the most work on every click.
We’ve spent years optimizing WooCommerce stores, from small shops to stores processing hundreds of orders a day, and the same patterns keep coming up. This guide walks through what we actually check and fix before peak season, including real examples of what we found when stores told us “checkout is slow.” If you’d rather read why speed affects revenue in the first place, start with our post on the benefits of a faster website.
Your 1–3 week plan
With three weeks, you can do this properly: a full audit, server and caching work, a database cleanup, frontend optimization, a careful look at checkout, and a load test before the traffic arrives. That’s the ideal, and it leaves room to fix what the load test uncovers.
With two weeks, the same plan still fits, but the frontend work gets lighter. You focus on the pages that carry your Black Friday traffic (the landing pages your ads point to, top categories and best-selling products) instead of polishing every template.
With one week, you can still make a real difference. It just means being strict about priorities and doing the fixes with the highest impact and the lowest risk first. We do this for stores every year, and a focused week is usually enough to remove the biggest bottlenecks before the sale starts.
Only have one week?
Start with HPOS (High-Performance Order Storage). If your store still keeps orders in the old posts and postmeta tables, every order lookup, admin order screen and checkout write competes with your products, pages and everything else in the same tables. HPOS moves orders into dedicated, properly indexed tables. Check that your plugins are compatible first (WooCommerce shows a list under Settings → Advanced → Features), then turn it on. Once all your order-related plugins support it, you can also switch off compatibility sync, which otherwise writes every order twice.
Next, make sure debug logging is off on your live site. It sounds trivial, but we regularly find WP_DEBUG and WP_DEBUG_LOG switched on in production. On one store we reviewed, it was writing about 31 MB of notices a day, around seven log writes on every single request. Under Black Friday traffic, that’s disk I/O you’re paying for and getting nothing back.
Then look at what loads on every page that doesn’t need to. Chat widgets, popups and a handful of tracking pixels add up quickly, both in the browser and, more importantly, on your server when plugins make external calls during the request. Delay or remove anything that isn’t directly helping people buy during the sale.
Clean up expired transients and old customer sessions. The sessions table in particular can grow and fragment badly on busy stores, and it’s read and written on almost every cart action.
Set up uptime and error monitoring with alerts that reach someone who can act. Only once monitoring is in place should you place a real test order through every payment gateway, logged out, as a normal customer would. That way you can see in your monitoring exactly what that checkout did and how long each part took, rather than just noting that it “worked.”
Finally, take a full backup and freeze the store. No plugin updates, no new features and no theme changes until December. Most Black Friday emergencies we’re called into begin with “we just updated a plugin.”
Don’t have time to do it yourself? Get our WordPress Performance Checklist with 70+ actionable steps for free using the code BFCM2026, valid until December 4, 2026. Or schedule a free 15-minute call, and we’ll get your store ready for Black Friday.
Audit and baseline
Before changing anything, measure. You need a baseline to know whether a fix helped and to compare against on the day.
Run Core Web Vitals and time to first byte (TTFB) on your key templates: the homepage, a category page, a product page, the cart and the checkout. If you’re unsure which metrics deserve the most attention, our guide on which metrics to target in Core Web Vitals explains the priorities.
Here’s the part most audits miss: test both cached and uncached. On one store we audited, the homepage loaded in 0.2–0.35 seconds from cache but took 2.6–3.2 seconds when the cache was bypassed. The product page showed the same gap. On a normal day, most visitors get the cached version. On Black Friday, many don’t, because they’re logged in, carry a cart cookie, arrive with campaign parameters, or land just after the cache was cleared by a price change. Our post on how to bypass the WordPress cache shows how to test this yourself.
Look back at last year’s peak if you have data: traffic, error logs and failed or abandoned checkouts. Then audit your plugins. We look for anything abandoned, anything unused, and overlaps, like two optimization plugins both rewriting the same CSS and JavaScript. Finally, check your hosting limits: PHP workers, CPU and memory, and any bandwidth caps. You want to know where the ceiling is before you hit it.
Advanced diagnostics: finding what’s really slow
PageSpeed Insights is great for the frontend, but it can’t tell you why checkout takes eight seconds. Slow add-to-cart actions, slow checkout and slow admin screens are server-side problems, and you need server-side tools to find them.
New Relic APM is the tool we reach for first on serious stores. It shows transaction traces broken down by database queries, PHP functions and external HTTP calls, so instead of guessing which plugin is slow, you can see that a given request spent 1.3 seconds waiting on a third-party API. Many managed hosts include it or make it easy to enable.
Code Profiler measures how much execution time each plugin and the theme add to a request. It’s excellent for answering “which plugin is costing us the most?” One warning from experience: remove it from production when you’re done. We’ve found profilers left active on live stores long after the investigation ended, along with their stored profiles taking up space.
Query Monitor shows every database query, hook and HTTP call made during a page load, which makes it ideal for spotting slow queries and external calls on a specific page.
Don’t overlook WooCommerce’s own logs under WooCommerce → Status → Logs. Payment gateways record every request and response there, and fatal errors are logged separately. Some of our most useful findings came from simply parsing months of gateway logs.
For frontend work, PageSpeed Insights and Chrome DevTools remain the standard. If you want to go deeper, see how to measure rendering time using Chrome DevTools, or connect PageSpeed Insights to Google BigQuery to track results over time.
One rule matters more than any tool: profile as a real customer. More on why in the case studies below.
Hosting and server
If your hosting needs an upgrade, do it now. Hosting providers get busy in November, and migrating or resizing a server the week before Black Friday adds risk you don’t need.
WooCommerce is dynamic. Every add-to-cart, cart update and checkout runs PHP and hits the database, and each of those requests occupies a PHP worker until it finishes. When all workers are busy, new visitors wait in a queue, and that queue is what turns a traffic spike into a slow site. Ask your host how many workers you have, and whether they can be scaled temporarily for the sale.
Make sure you’re on a current PHP version and that OPcache has enough memory. A typical WooCommerce stack compiles thousands of PHP files. On a medium store, 256 MB of OPcache with max_accelerated_files set above your actual file count is a sensible starting point. Check the hit rate, too: if it falls below about 99%, or OPcache shows restarts, it needs more room.
Caching and CDN
Page caching handles anonymous visitors, but the cart, the checkout and logged-in customers can’t be served from it. That’s where an object cache earns its place. Redis or Memcached keeps the results of repeated database queries in memory, so dynamic pages don’t rebuild the same data from MySQL on every request. On a busy store, this is often the single biggest server-side improvement for uncached pages.
A CDN takes images, CSS and JavaScript off your server and serves them from locations close to your visitors, which frees your server for the work only it can do. Make sure those static files are sent with long cache lifetimes. Our guide on serving static assets with an efficient cache policy covers the setup for different servers.
Database cleanup
WooCommerce databases grow faster than most store owners expect. Every order adds rows, every variation is stored as its own product, and plugins quietly create tables and options that stay around long after the plugin is gone.
Start with autoloaded options, the settings WordPress loads on every request whether they’re needed or not. We aim to keep these under about 800 KB. Sometimes one setting is responsible, as we explain in our post on the large _transient_dirsize_cache issue.
Clear expired transients, old sessions, post revisions and any backlog in Action Scheduler, the queue WooCommerce uses for background jobs. Look for tables left behind by plugins you’ve removed, and for large backup files sitting in wp-content. We’ve found multi-gigabyte backup archives and old SQL dumps in wp-content on live stores, inflating every backup the host takes.
Then look at indexes. Core WooCommerce tables are indexed well, but many plugins create their own tables with only a primary key. That’s fine at a thousand rows and painful at several million, as one of our case studies below shows.
Product variations deserve a special mention. Each variation is stored as a separate product with its own metadata, and variable product pages send the data for every variation to the browser. In a case study we’ve written about before, a store with just 29 products had 801 variations, and those variations were the bottleneck holding everything else back. If your options don’t need their own stock or SKU, a product options plugin that stores them as simple form fields can be far lighter.
Frontend performance
Once the server side is solid, work on what visitors see. Serve images in modern formats (see how to serve images in WebP format), at the right sizes, and lazy-load images below the fold.
Be careful not to lazy-load the main image a visitor sees first. On one site we worked on, an image optimization plugin lazy-loaded the hero image, so the caching plugin saw a decorative background pattern as the most important element and preloaded that instead. The pattern appeared first, then the real image flashed in late. Loading the real image eagerly with high priority fixed it. Our guide on how to optimize LCP on a WordPress site goes through these cases in detail.
WooCommerce also loads its scripts and styles on pages that don’t need them, such as blog posts and landing pages. Load them only where they’re used, remove unused CSS, and keep an eye on JavaScript, which affects how quickly the page responds to taps and clicks. Our posts on INP (Interaction to Next Paint) and fixing large layout shifts cover the rest.
Checkout and cart
The cart and checkout are where stores break first, because they can never be served from a page cache. Every request runs fully, for every customer.
It helps to know what actually happens when a customer clicks “Place order.” The order is created, the payment gateway is called, and then a chain of other things may run: anti-spam checks, CRM or ERP syncs, order confirmation emails, stock updates, analytics. The customer waits for all of it. When a store owner tells us checkout feels slow, the payment gateway is usually not the problem. It’s everything else that runs in the same request.
The fix is to keep only what’s essential inside checkout and move the rest to background jobs. CRM syncs, ERP updates and other integrations can usually run through Action Scheduler a few seconds later without the customer ever noticing.
While you’re there, test every gateway end to end and review its fraud settings. Overly strict address (AVS) and card code (CVV) rules can decline genuine customers, and on Black Friday that’s lost revenue. Test your coupons, scheduled sales and bulk price changes at realistic scale too, since a sale that changes thousands of prices at midnight can lock up a database if it runs all at once.
Third-party scripts and external calls
Every integration is a dependency, and on Black Friday every dependency is a risk. Frontend scripts like chat, popups, review widgets and pixels slow the page in the browser, so delay or remove the ones that don’t help the sale. If you need a hand with that, see how to fix “Reduce JavaScript execution time”.
The bigger danger is server-side: plugins that call external APIs while the customer is waiting. In one investigation, add-to-cart and other uncached requests had become very slow. New Relic showed long external requests to several services, but the strongest signal pointed to a customer messaging plugin making slow outbound calls. Turning it off caused an immediate drop in long external requests and response times recovered. In the same case, bot traffic hitting a system folder was being processed by a tracking plugin, adding load the site didn’t need.
Timeouts matter as much as speed. A plugin that waits up to 10 or even 60 seconds for an outside service can hold a checkout open that long if that service has a bad moment. Shortening timeouts, or moving the call out of the customer’s request, protects you when a third party struggles under its own Black Friday traffic. Multilingual stores should also check how their translation setup behaves, since translation plugins can slow down your site more than expected.
Case studies: what we found in real stores
“Slow checkout is causing card declines”
A store owner came to us with checkout taking 8–10 seconds and genuine customers, including repeat buyers, having their cards declined. The assumption was that the slow checkout was causing payments to time out.
The data said otherwise. We parsed nearly 500 payment gateway transactions from the store’s logs. The gateway was fast and healthy, with a median of about 1.5 seconds, no timeouts and no connection errors. The wait came from what ran after the charge was approved: an anti-spam API check that averaged about 1.3 seconds per order, a CRM sync and transactional emails, all running inside the checkout request.
There was a twist. An earlier profiling session had concluded that the anti-spam check was negligible. But that test ran as an administrator, and administrators were excluded from the check, so the test never paid the cost every real customer did. That’s why we always profile as a logged-out customer.
The declines were a separate problem. About 38% of them came from the gateway’s own address-mismatch filter rejecting cards before the bank even saw them, a setting in the merchant portal rather than a bug on the site. Slow checkout and declined cards turned out to be two unrelated issues, and fixing them meant tackling each one directly.
New Relic flags slow database queries
On another store, New Relic showed slow SQL inside admin-ajax requests, slow background jobs and slow payment calls at checkout. Timing the queries directly told the story: a quiz and funnel plugin kept millions of rows in tables with no indexes beyond the primary key. Its reports took 13–22 seconds to load in the admin, and some lookups ran on the frontend too, adding 0.8 to 4.8 seconds to pages that displayed quizzes.
The same review turned up debug logging writing about 31 MB a day on production, a profiling plugin left active, several gigabytes of backup files inside wp-content, and HPOS compatibility sync still adding work to every order. Adding the right indexes is expected to bring those queries under a second, and the rest of the cleanup is low-risk housekeeping. Under Black Friday traffic, hidden slow queries like these multiply, which is why we look for them before the sale, not during it.
29 products, 801 variations
In a case from our performance checklist, a store was spending heavily on ads but customers weren’t converting. Add-to-cart had no feedback for several seconds, product pages took five seconds or more, and the site crashed at peak hours. The standard fixes helped, but the breakthrough came from the variations: 29 products carried 801 variations. Once those were handled properly, average load time dropped from 5.2 to 1.8 seconds, bounce rate fell by 35% and conversions rose by 21%.
Load testing
The only way to know how your store behaves under Black Friday traffic is to simulate it before customers do. Test on a staging copy, and simulate realistic behavior: people browsing categories, adding to cart and checking out at the same time, not just thousands of homepage visits that the cache will absorb anyway. The goal is to find your breaking point and see which part gives way first, whether that’s PHP workers, the database or an external service, while you still have time to fix it.
Backups, freeze and monitoring
In the days before the sale, take full backups and freeze the store. Plugin updates, new features and theme changes can wait until December. Keep monitoring running throughout: uptime checks, error alerts and, ideally, New Relic or a similar APM tool so you can see slowdowns as they happen rather than hearing about them from customers. Make sure someone who can act is on call for the weekend.
During and after the sale
During the sale, watch your error logs, failed orders and response times. A rise in failed or pending orders is often the first sign that something in checkout is struggling. Afterwards, compare your results against the baseline you took at the start, and use what you learned before Cyber Monday and next year’s peak. For larger stores, the Chrome UX Report is useful for tracking performance changes over time.
Get your store ready
Black Friday rewards stores that respond instantly and punishes those that make shoppers wait. Most of the work above is invisible to customers. They won’t notice the indexes, the object cache or the background jobs. They’ll just notice that your store was fast when the others weren’t.
Don’t have time to do it yourself? Get our WordPress Performance Checklist for free with the code BFCM2026 (valid until December 4, 2026), or schedule a free 15-minute call, and we’ll get your store ready for Black Friday. If you’d like us to handle the whole thing, see our advanced optimization for WooCommerce, or read the proven site speed tips from 164 completed optimization projects.
