Most Shopify speed advice is written for a normal Tuesday afternoon, a handful of concurrent visitors, standard traffic patterns, nothing unusual happening. That advice, while useful, doesn’t tell you what happens to your store when traffic spikes to several times your normal volume within the space of an hour on Black Friday morning, which is a genuinely different technical scenario.
Shopify’s core infrastructure, the platform itself, is built to handle massive concurrent traffic; that’s one of the platform’s real structural advantages over self-hosted or less mature ecommerce platforms, and it’s not something most merchants need to worry about at the infrastructure level. What actually breaks under BFCM load is almost always something layered on top of that infrastructure: a slow theme, an app calling an external API that can’t keep up, or checkout-adjacent scripts that weren’t built with peak-load performance in mind. This post covers how to actually find and fix those weak points before peak traffic arrives, not after.
What “Stress Testing” Actually Means for a Shopify Store
To be clear about scope: you’re not load-testing Shopify’s core platform, that’s Shopify’s responsibility and it’s built for events exactly like BFCM across its entire merchant base. What you’re testing is everything you’ve added on top of that foundation: your theme, your installed apps, and any custom code or third-party scripts running on your storefront and checkout. That’s where load-related problems for individual merchants actually originate.
Step 1: Audit Every App for What It Actually Does Under Load
Start with a full list of installed apps and ask a specific question for each one: does this app make a call to an external API (outside Shopify’s own infrastructure) on page load, add-to-cart, or checkout?
Apps that fall into this category are your highest-risk candidates for BFCM slowdowns, because their performance depends on a third party’s infrastructure holding up under your traffic spike, not just Shopify’s:
- Reviews and loyalty widgets that pull data from an external service on page load
- Personalisation or recommendation apps calling out to a recommendation engine in real time
- Live chat widgets that load a separate script and connect to an external service
- Currency conversion or geolocation apps making an external lookup call per session
None of these are automatically a problem, most handle normal traffic fine. The point of the audit is identifying which apps you should specifically watch during a load test, and which ones you might consider disabling for the BFCM period if they’re non-essential and adding measurable page weight.
Step 2: Check Theme Performance With Realistic BFCM Content, Not a Clean Test Page
A common mistake: testing site speed on a default, near-empty product page, then assuming that result holds once your actual BFCM content is live, sale badges, countdown timers, promotional banners, and a fuller cart with multiple line items and applied discounts.
Test with the actual conditions your BFCM traffic will experience:
- Your real BFCM homepage and collection pages, with sale badges, banners, and any promotional apps active, not a clean baseline
- A cart with multiple items and a discount code applied, since discount calculation and cart re-rendering can be measurably slower than an empty cart
- Mobile specifically, tested on a throttled connection speed rather than your office wifi, a large share of BFCM traffic arrives via mobile from paid social and email, often on real-world mobile connections that are considerably slower than what your testing environment likely reflects
Run this through Google’s PageSpeed Insights or Lighthouse for a structured score, but also do manual clicks through the actual purchase journey, automated tools catch a lot, but they don’t always catch a slow-loading third-party widget that visually blocks content while it loads.
Step 3: Simulate Concurrent Traffic, Not Just Single-Session Speed
A page that loads fast for one visitor can behave differently under genuine concurrent load, particularly where apps rely on external APIs with their own rate limits or capacity constraints. This is harder to test perfectly as an individual merchant, but there are practical steps:
- Ask your key app vendors directly what their infrastructure’s capacity and rate limits look like, and whether they’ve had issues during previous BFCM periods with merchants on similar traffic tiers to yours. Vendors who’ve been through several BFCM cycles usually have a clear, confident answer to this; vague answers are a warning sign worth taking seriously.
- Use a load-testing tool (there are several general-purpose website load testing services) to simulate multiple concurrent sessions hitting key pages, homepage, a bestselling product page, and checkout initiation, and watch for response time degradation as concurrent load increases.
- Watch Shopify’s own app and theme performance reporting where available, which can flag apps contributing meaningfully to page load time under Shopify’s own Lighthouse-based scoring.
Step 4: Test the Actual Checkout Flow Under Discount and Payment Load
Checkout is the highest-stakes place for a BFCM slowdown, because it’s the final step before revenue, and it’s also where discount calculation, shipping rate lookups, and payment method availability logic all run together.
- Place real test transactions through every payment method you offer (card, Shopify Payments, Afterpay, Zip, PayPal), with your actual BFCM discount active, not a placeholder test discount
- Test shipping rate calculation speed specifically if you’re using real-time carrier rate calculation rather than flat rates, real-time rate lookups depend on the carrier’s own API responding quickly, which is a genuine point of slowdown if you haven’t tested it under realistic conditions
- Confirm discount stacking behaves correctly and calculates quickly when a customer has multiple eligible discounts or a large cart
What to Do With What You Find
Once testing surfaces specific weak points, the fixes generally fall into a few categories:
- Disable genuinely non-essential apps for the BFCM period if they’re adding measurable load without a proportional benefit, a recommendation widget that adds 400ms to page load for a marginal conversion lift is a worse trade during peak traffic than during normal traffic.
- Move from real-time to flat or table-rate shipping temporarily if real-time carrier rate lookups are proving slow under load, accepting a small accuracy trade-off for reliability during the highest-stakes traffic window.
- Ask vendors for their BFCM-specific guidance or known limitations, some apps publish this proactively each year; if yours doesn’t, ask directly rather than assuming it’ll be fine.
- Simplify theme sections that aren’t earning their weight, countdown timers, animated banners, and heavy promotional graphics all add load; keep the ones that are genuinely converting and cut the rest.
Tools Worth Using for This
You don’t need enterprise-grade infrastructure monitoring to do a reasonable job of this as a Shopify merchant. A practical toolkit:
- Google PageSpeed Insights / Lighthouse for structured, repeatable speed scoring on individual pages, and for flagging specific render-blocking resources you can then investigate further.
- Shopify’s own theme and app performance reporting, available in admin, which can flag apps contributing disproportionately to page load time based on Shopify’s own measurement.
- Browser developer tools’ Network tab, manually reviewed on your key pages, to see exactly which requests are slow and whether they’re first-party (Shopify) or third-party (an app or external service), this is often the fastest way to spot a specific slow-loading script without needing specialised tooling.
- A general-purpose website load testing tool to simulate concurrent sessions, useful specifically for checking how key pages hold up when multiple visitors hit them at the same time, which single-session speed testing tools don’t capture.
None of these tools test Shopify’s core platform capacity, again, that’s not the merchant’s responsibility to verify, but together they give a reasonably complete picture of where your specific theme and app stack is likely to struggle under real BFCM conditions.
Building a Rollback Plan, Not Just a Prevention Plan
Even with thorough testing, it’s worth planning for the scenario where something still goes wrong during the actual event, since no amount of pre-testing eliminates risk entirely on the day itself:
- Know which apps can be safely disabled quickly if one turns out to be causing problems live, without breaking core store functionality, this is much easier to know in advance than to figure out under pressure during a live traffic spike.
- Have a fallback shipping rate method ready (flat or table rate) if real-time carrier rate calculation starts timing out under load, so you can switch quickly rather than leaving checkout partially broken while you investigate.
- Assign clear ownership for who’s monitoring the store during peak hours, with a direct line to whoever can actually make changes (disable an app, adjust a setting) if an issue is spotted, rather than discovering a problem and then losing time figuring out who’s able to fix it.
Pre-BFCM Speed and Load Testing Checklist
- [ ] Full app audit completed, external API dependencies identified and flagged
- [ ] Theme tested with real BFCM content (banners, sale badges, promotions active), not a clean baseline
- [ ] Mobile tested on throttled connection speed, not office wifi
- [ ] Concurrent load simulated on homepage, bestselling PDP, and checkout initiation
- [ ] Every payment method tested with actual BFCM discount active
- [ ] Real-time shipping rate calculation speed checked, fallback plan ready if too slow
- [ ] Non-essential apps identified and a decision made on disabling for peak period
- [ ] Vendor guidance requested from any app with known BFCM-period performance risk
When to Bring in a Specialist
If testing surfaces a genuine bottleneck, a theme that’s structurally too heavy, an app conflict at checkout, or performance issues that don’t have an obvious single fix, that’s worth addressing properly rather than patching around it days before peak traffic hits. This kind of load and speed diagnostic work is exactly what we do as part of Shopify performance optimisation, and it’s far more effective done with weeks of runway than the week of BFCM itself.
FAQ
Does Shopify itself slow down during Black Friday traffic spikes?
Shopify’s core platform infrastructure is built to handle major concurrent traffic events like BFCM across its entire merchant base, this is a genuine structural strength of the platform. Performance problems during peak traffic almost always come from apps, theme code, or third-party scripts layered on top, not Shopify’s underlying infrastructure itself.
How do I know if an app will slow down my store during BFCM?
Check whether the app makes calls to an external API on page load, add-to-cart, or checkout, those are the highest-risk apps, since their performance depends on a third party’s infrastructure holding up under your traffic spike. Ask the vendor directly about their BFCM-period capacity and any known limitations.
Should I disable apps before Black Friday?
Consider disabling genuinely non-essential apps that add measurable page weight without a proportional conversion benefit, particularly ones that call external APIs. This is a judgement call specific to each app and store, best made after testing rather than as a blanket rule.
What’s the best way to test my Shopify checkout before BFCM?
Place real test transactions through every payment method you offer with your actual BFCM discount active, and specifically test real-time shipping rate calculation speed if you use it, since that depends on carrier API response times rather than Shopify’s own speed.
How far in advance should I stress-test my Shopify store before BFCM?
Ideally with enough runway to actually fix what you find, several weeks out rather than the final week, since meaningful fixes (app changes, theme adjustments, shipping method changes) need time to implement and re-test properly before peak traffic arrives.
Want Your Store Load-Tested Properly?
If you’d rather have a specialist stress-test your app stack, theme, and checkout before BFCM traffic hits, book a call and we’ll help you find the weak points while there’s still time to fix them.
