You can't load test a Shopify store in the way you'd load test an app you host yourself, and you shouldn't try. Pointing k6 or JMeter at your storefront will get your IPs throttled, produce numbers that mean nothing, and possibly a note from Shopify. What you can test is everything you added on top: the theme's front end, every app script, your pixel stack, and any endpoint you own that the store calls during a sale. That's where stores actually fall over on Black Friday, and it's work that has to be finished in October, because the theme should be frozen by mid-November.
Black Friday lands on 28 November this year. Count backwards. If you want field data to reflect your fixes before the traffic arrives, you have about three usable weeks left.
What Shopify absorbs, and what it hands straight to you
Shopify runs the infrastructure: edge CDN, product and collection rendering, cart, checkout, inventory writes, payment capture. During peak minutes it will put shoppers in a queue rather than drop them. You will not out-trade that infrastructure, and you don't need to plan for it.
What Shopify does not absorb is the 600 KB of JavaScript your team bolted on over eighteen months. Theme sections that query metafields in a loop. A review widget that renders above the fold. Four analytics pixels, two attribution tools, a heatmap recorder, a chat bubble, and a subscription app that injects its own copy of a date picker on every product page. All of that runs on a shopper's phone, on a hotel wifi connection, on a four-year-old Android. Under load, Shopify's servers stay fine and your Largest Contentful Paint goes to five seconds.
So the useful framing for Shopify load testing before Black Friday isn't "will the servers hold". It's "how slow does my own code get when 40,000 people hit it from cold caches on mobile data".
Can you load test a Shopify store? Partly, and only the parts you own
Synthetic traffic against .myshopify.com or your custom domain is a bad idea. Shopify's acceptable use terms don't allow unauthorised stress testing, and the platform rate-limits bursts of requests from a single source, which is exactly the shape of a naive load test. You'll measure your own throttling. If you're on Plus and genuinely expect a flash drop, raise it with your Merchant Success Manager rather than running it yourself.
Here's what is fair game, and what we actually test in October:
- Anything you host. A zip serviceability lookup, a gift-with-purchase rules service, a custom bundle builder API, a ERP stock-sync middleware, a headless frontend. These are usually the real single point of failure. We've seen a store's entire PDP block on a $7/month container that fell over at 60 concurrent requests.
- Webhook consumers. Your 3PL integration, your ERP order push, your custom app's
orders/createhandler. Black Friday doesn't send you orders evenly. It sends 900 in ninety minutes. If your consumer processes serially at 400ms each, that's a six-hour backlog and a very bad Saturday. - Your theme, under throttled conditions. Not concurrency — device and network constraints. Which is the test that matters most and the one most people skip.
For the hosted bits, pick a target and prove it. We usually aim for p95 under 300ms at four to five times expected peak requests per second, sustained for ten minutes, with no error rate above 0.1%. Run it against staging with production-sized data, not an empty database.
"How many apps slow down Shopify" is the wrong question
Nobody has ever been saved by uninstalling their eleventh app because eleven sounded like too many. A store with 28 apps can load faster than one with nine. What matters is bytes of JavaScript, main-thread blocking time, and how many of those scripts run before the hero image paints.
The app script performance impact you care about splits three ways. Apps that only touch the admin cost you nothing on the storefront. Apps that inject a script tag site-wide cost you on every page whether or not the feature appears. Apps that render above the fold cost you LCP directly. Audit by that classification, not by count.
Open DevTools, Network tab, filter by domain, hard reload with cache disabled, sort by transfer size. Then run a Performance trace with CPU throttled 4x and look at long tasks. Ten minutes of that tells you more than any app-count heuristic.
One apparel store we audited in September: 9 third-party origins, 612 KB of compressed JavaScript, 1,180ms total blocking time on a mid-tier Android profile. Two apps accounted for 341 KB of the 612. One was a review widget rendering stars above the fold; it could be swapped for Shopify's own metafield-driven rating output. The other was a wishlist app the merchant had stopped promoting a year earlier. Removing one and deferring the other took third-party JS to 301 KB and blocking time to roughly 520ms. LCP went from 3.2s to 2.1s without touching a single image.
Weigh your pixels, then decide what you can live without
The typical US D2C stack by October: GA4, Google Ads, Meta, TikTok, Klaviyo or Attentive, an attribution platform, maybe a session recorder, maybe a post-purchase survey. Each one looks small. Collectively, the third-party pixel weight on a Shopify storefront routinely clears 300 KB and eats half a second of main thread before anything useful renders.
Three practical moves. Push every pixel you can into Shopify's Customer Events (Web Pixels) sandbox rather than a theme script tag — it runs in a worker and stops a broken vendor script from taking the page with it. Delete anything whose data nobody has opened in ninety days; session recorders are usually first on that list. And audit your Google Tag Manager container as if it were an app, because a container with 40 tags from three agency relationships is a performance problem wearing a disguise.
While you're in there: if someone sold you an accessibility overlay script, be aware it's both extra weight and, on the evidence of how ADA suits have actually gone, thin protection. Fix contrast, focus states and form labels in the theme instead.
LCP optimisation on a Shopify theme usually comes down to one image
On nine out of ten stores we look at, the LCP element is the homepage hero or the PDP's first product image. Fix that one asset and most of the gap closes.
Continuing the example above. The hero was a 2,400px PNG at 410 KB, lazy-loaded by the section's default settings. Served as WebP at 1,200px wide with Shopify's CDN sizing parameters, it came down to 78 KB. At an effective 1.6 Mbps mobile connection, 410 KB takes 410 × 8 ÷ 1600 ≈ 2.05 seconds to transfer. 78 KB takes 0.39 seconds. That's 1.66 seconds of pure download time deleted. Add fetchpriority="high", remove the lazy-load attribute from the above-fold image only, and preload the font the headline uses, and LCP went from 2.1s to 1.4s.
Two caveats we keep running into. Preloading everything makes things worse, because you're competing with yourself for bandwidth. And an app block sitting above the hero in the section order will steal LCP no matter how well you've optimised the image. Check your section order before you optimise anything.
If you want this measured and tracked rather than checked once in October and forgotten, SwiftStore scans the store, fixes what it safely can, and keeps watching the score. Our deeper speed optimisation work picks up the parts an app can't touch, like Liquid that loops over metafields on every render.
Shopify checkout speed under traffic: what you control is narrower than you think
Checkout is Shopify's. You can't optimise the page, and you shouldn't want to. What you can do is stop adding latency to it.
On Plus with checkout extensibility, every UI extension is a render dependency, and every Shopify Function runs inside a tight execution budget. Three discount Functions, a delivery customisation and two UI extensions will be noticeable. More importantly, a third-party tax service like Avalara called at checkout is a network round trip you don't own — if their response time degrades on the busiest afternoon of the year, your checkout degrades with it. Know whether you're on Shopify Tax or an external provider, and know what your fallback is. If you're not sure your Plus setup is carrying its weight, that's a conversation worth having with a Plus-focused team before November, not during it.
The other checkout risk is boring and common: a shipping rate API you built that times out. Shopify will fall back, but the shopper sees a spinner first. Load test that endpoint. It's yours.
Core Web Vitals before Black Friday have a 28-day lag problem
Chrome's field data uses a rolling 28-day window. Ship an LCP fix on 25 October and your p75 in the Chrome User Experience Report won't fully reflect it until roughly 22 November. Search Console's Core Web Vitals report inherits the same lag. So if part of your reason for doing this work is organic visibility going into the season, the deadline is earlier than the traffic.
Don't rely on lab scores alone to judge progress. Install a real-user monitoring snippet, or read the field data in PageSpeed Insights per page template rather than per site. Homepage, a collection page with 60 products, your three best-selling PDPs, and the cart. Those four templates are 90% of your sessions.
A workable October sequence
- Week one — baseline. Record p75 LCP, INP and CLS from field data for your four key templates. Then a lab trace each at 4x CPU throttle: total JS transferred, third-party origin count, total blocking time, TTFB. Write the numbers down. You will want them in December.
- Week two — subtract. Uninstall dead apps properly, which means checking the theme for leftover script tags and snippets after uninstall. Most apps don't clean up. Collapse the GTM container. Move pixels into Customer Events.
- Week three — the image and font pass. LCP element per template, correct dimensions, WebP, priority hints, font preload, remove render-blocking CSS from app blocks that only appear below the fold.
- Week four — load test what you host. Webhook consumers, custom endpoints, shipping rate APIs, middleware. Five times expected peak, ten minutes, p95 target agreed in advance. Then fix the queue depth, not just the response time.
- By 14 November — freeze. No theme deploys after that. Content and merchandising changes only, through sections, metafields and the theme editor. Keep one tested rollback theme published-ready.
The freeze is the part people negotiate with, and it's the part that saves them. A 10pm CSS change on Thanksgiving to fix a banner has broken more Black Fridays than any traffic spike.
What to record so this is easier next year
During the weekend itself, log hourly: conversion rate by device, checkout initiation vs completion, error rate on your own endpoints, and a Lighthouse run on your top PDP at the busiest hour. In January, that log tells you whether the slow Saturday was traffic, a vendor script, or your own middleware. Memory won't.
If you'd rather have someone else do the September-style audit pass before the window closes, our free store audit covers the script and LCP work specifically, and the US team works to BFCM timelines. Either way, get the baseline numbers written down this week. You can't improve what you measured for the first time in December.