--- title: "Why Shopify Stores Slow Down Under Load | Evaluat" description: "Shopify's edge scales, but the theme, apps, and third-party JavaScript you add run in each shopper's browser and stall under load. Here is how to test it." url: "https://www.evaluat.com/blog/shopify-store-slow-under-load" last_modified: "2026-07-18" --- [Blog](https://www.evaluat.com/blog) [Ecommerce Performance](https://www.evaluat.com/blog/category/ecommerce-performance) # Why your Shopify store slows down under load Shopify is hosted, so buyers assume it scales, and its cached storefront genuinely does. The slowdown lives somewhere else: the theme, apps, and third-party JavaScript a merchant adds run in every shopper's own browser, where an HTTP load test never looks. Under load, that is where a Shopify store actually slows. Here is why, and how to see it. Written by: [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · 27 June 2026 · Updated 18 July 2026 ![On a Shopify store, the platform sends a cached page fast, but each shopper's browser still has to run the theme, app, and third-party JavaScript, which pushes Core Web Vitals from good toward poor under load.](https://www.evaluat.com/blog/shopify-store-slow-under-load-cover.svg) Summary Shopify's platform genuinely scales, and that's the trap. Its cached storefront is served from a global content delivery network, and Shopify's own data shows nearly ninety percent of shops on its latest themes hitting good Core Web Vitals, against under half of mobile sites across the web. So why does a store still crawl during a sale? Because the theme, the apps, and the third-party tags a merchant adds all run in each shopper's own browser, and no cache can do that work for them. Two costs compound at peak. First, the render tax is paid per device and never amortizes: the median mobile page spends nearly two seconds with its main thread blocked, more than twenty times the desktop figure, and the slowest devices show up in their largest numbers exactly when you're busiest. Second, the app and tag servers your scripts call serve thousands of sites at once, so your sale peak is their peak too. An HTTP load test misses all of this because it never opens a browser: in one benchmark, a server answered in about fifty milliseconds while the page took more than eight seconds to finish loading. To test safely, drive real browsers through the storefront and cart you control, not Shopify's sandboxed checkout, point them at a development store rather than your live shop, give every virtual user its own cart, and read Core Web Vitals per page and per session. Test the store you assembled, not the platform underneath. Listen to this article · 1:43 [Download the audio summary (MP3)](https://www.evaluat.com/blog/audio/shopify-store-slow-under-load.mp3) Key takeaways - Shopify field averages describe the platform under everyday traffic; they are not a forecast for your theme and apps at peak. - Theme apps, injected scripts, and checkout extensions often behave differently under concurrency than in a quiet admin preview. - Rehearse your journeys at selected conditions with real browsers; keep field CrUX as the source for the full device spread. ## Doesn’t Shopify scale automatically? Mostly, yes, and that is the trap. Shopify serves your storefront from a global content delivery network with full-page caching, so the server half of the response stays fast at almost any traffic. What it cannot cache is the JavaScript your theme and apps run inside each shopper’s browser, and that half slows down when a crowd arrives. A hosted platform runs the servers, the database, and the network for you, and Shopify’s scaling is real. It renders storefront pages on its own servers, stores the finished HTML in a cache, and serves it through a global CDN, [which Shopify’s developer docs name as Cloudflare](https://shopify.dev/docs/storefronts/themes/best-practices/performance/platform). A [2020 Shopify engineering write-up](https://shopify.engineering/simplify-batch-cache-optimized-server-side-storefront-rendering) describes the mechanism: once its renderer builds a page, it stores the output and hands that cached copy to later visitors, so a cached collection page costs the origin almost nothing even under heavy traffic. The result shows up in the field. Across the latest versions of its themes, [Shopify’s own data](https://performance.shopify.com/pages/theme-performance-data-table) puts a median 87.6% of shops at good Core Web Vitals (Google’s three metrics for loading, responsiveness, and visual stability) for at least 75% of their real users, as of June 2026. For contrast, only [48% of mobile sites across the web](https://almanac.httparchive.org/en/2025/performance) clear the same bar, according to the 2025 Web Almanac. On average, Shopify stores are fast. So where does the slowdown come from? The other half of the page load. Every response Shopify sends still has to be turned into pixels by the shopper’s own browser, which downloads and runs the theme’s JavaScript, each app’s scripts, and every third-party tag before the page is usable. That work runs on the visitor’s device, not on Shopify’s servers, and no cache can do it for them. The cart and account pages sharpen the split, because they are specific to one shopper and are not shared from the full-page cache the way a product listing is. It is like flat-pack furniture. The warehouse ships the box in minutes, but every customer still assembles it at home, and the more parts you add, the longer each assembly takes. Warehouse speed never changes that. Shopify’s 87.6% is a rolling field average, not a forecast for your store at peak. A controlled [e-commerce performance test](https://www.evaluat.com/solutions/ecommerce-performance-testing) can rehearse your apps and journeys at selected conditions, while field data remains the source for the full spread of customer devices. ## What actually runs in the browser on a Shopify store? Three layers of JavaScript stack up on a typical storefront: the theme’s own scripts, the apps a merchant installs, and the third-party tags like analytics, reviews, and chat. Each layer is downloaded, parsed, compiled, and executed on the shopper’s device, and each can call a server that Shopify does not control and cannot cache. Start with the weight. The median mobile page across the web now ships [2,164 KB in total and 646 KB of JavaScript](https://almanac.httparchive.org/en/2025/page-weight), per the 2025 Web Almanac, and commerce pages tend to sit heavier than the median because they carry more of the third layer. (Liquid, Shopify’s templating language, renders on the server, so it is not the client-side cost. The cost is the JavaScript the theme and its apps ship.) ### Theme JavaScript The theme is the store’s front end, and its scripts run the cart drawer, the product gallery, search, the variant picker, and animation. A well-built theme keeps this lean, but customizations accumulate over time: a slider here, a currency converter there, a countdown timer for the next sale, each adding code the browser has to run on every page. ### Apps and the scripts they inject Every app can add its own scripts to the storefront, and a typical store runs [around half a dozen apps by Shopify’s own reckoning](https://www.shopify.com/partners/blog/story-of-the-new-app-store), with heavily customized stores running many times that. Each app is more main-thread work and, just as important, an independent backend the script calls out to. This is a structural cost, not a verdict on any one app: more apps means more code to execute and more separate services that can fail or slow on their own. ### Third-party tags Analytics, consent banners, A/B testing, personalization, and chat widgets load from other companies’ servers and run in the shopper’s browser. They are nearly universal: [more than nine in ten pages use at least one third party](https://almanac.httparchive.org/en/2025/third-parties), and scripts are the largest single category of third-party requests. Because these tags only execute inside a browser, they are precisely the part of the page that a test without a browser never sees. ## Why does a Shopify store only slow down under load? Because two costs compound at peak, and neither one is the server. The browser render tax is paid in full by every visitor on their own device and never amortizes, so peak simply means the most people paying it at once. And the app and tag servers that JavaScript depends on reach their own peak at the same moment, so they slow exactly when your traffic does. ### The render tax is paid per device, and it never amortizes Server caching is powerful because it builds a page once and serves it to many. Client-side execution is the opposite: every visitor’s browser parses and runs the same JavaScript from scratch, on its own processor, with no sharing between them. A weak phone feels this most, and most shoppers are on phones. The 2025 Web Almanac measured the [median mobile page spending 1,916 milliseconds in total blocking time](https://almanac.httparchive.org/en/2025/performance), the stretch where the main thread is too busy to react to a tap, against just 92 milliseconds on desktop, more than twenty times as much. Here is the part that is easy to state wrong. Your shopper’s phone does not get slower because other people’s phones are busy; each device is independent. What changes at peak is how many devices are doing this at once, and which ones. The older phones on slower networks, your worst sessions, are present in their largest numbers exactly when you are busiest, so the aggregate experience is at its worst when it matters most. The render tax did not rise. The number of people paying it did. ### The services your scripts depend on slow down exactly when you do The second cost is genuinely load-coupled. The app backends and third-party tag servers your scripts call serve many sites at once, often thousands, and your sale peak is their peak too. When one of them slows or times out, the shopper’s browser sits waiting, long tasks pile up on the main thread, and the page stalls. A long task is [any main-thread task over 50 milliseconds](https://web.dev/articles/optimize-long-tasks), and a run of them is measured directly as poor Interaction to Next Paint (INP). Late or render-blocking scripts hit Largest Contentful Paint (LCP) instead, and reflowing content shifts Cumulative Layout Shift (CLS). All of it happens while Shopify’s cached HTML still came back fast. For the metric-by-metric detail, see [how to improve LCP](https://www.evaluat.com/blog/how-to-improve-lcp) and [Interaction to Next Paint, explained](https://www.evaluat.com/blog/interaction-to-next-paint). ## Why doesn’t an HTTP load test catch this? Because an HTTP load test never opens a browser. In HTTP mode, a protocol tool sends requests, reads the response bytes and status codes, and paces them to mimic users. It is fast, cheap, and accurate for what it measures, but it does not parse HTML, run JavaScript, load third-party tags, or paint a page. So it sees Shopify’s quick cached response and a 200 status, and reports that the store is healthy. That is a property of the model, not a fault in the tools. Protocol tools like [k6](https://www.evaluat.com/vs/k6) and JMeter are genuinely the right instrument for API and protocol concurrency, where there is no browser to run and a real one would be wasted overhead. Some of them now reach further: k6 ships a browser module that drives real Chromium and reports Core Web Vitals, which is a different mode from its HTTP core. But the default HTTP load test, the one most teams run first, measures the server’s half of the page and stops where the browser’s half begins. That gap is wide, and not only on Shopify. In a [2025 Catchpoint benchmark](https://www.catchpoint.com/learn/2025-saas-website-performance-benchmark-report) of SaaS websites, one site’s server answered in 52 milliseconds while its page took 8.4 seconds to finish loading. An HTTP load test pointed at that site would have reported 52 milliseconds and a clean pass. The user waited eight seconds. That is the distance between what the server returns and [what users see, not what scripts pretend](https://www.evaluat.com/blog/api-vs-browser-performance-testing). ![A single Shopify page-load timeline. An HTTP load test sees only the first segment, the server's response. A real browser sees the rest: HTML parse, theme and app JavaScript execution, third-party calls, and the Largest Contentful Paint and Interaction to Next Paint that decide what the shopper feels.](https://www.evaluat.com/blog/shopify-store-slow-under-load-timeline.svg) ## What an HTTP test sees versus what a real browser sees The two tests answer two different questions about two different layers. An HTTP test answers “did the server respond quickly,” which on a cached Shopify storefront is almost always yes. A real-browser test answers “did the page stay fast for the shopper at peak,” which is the question your revenue actually turns on. The table maps what each one can and cannot record during a single Shopify page load. | What happens during a Shopify page load | HTTP load test (HTTP mode) | Real-browser test | | ---------------------------------------------- | -------------------------- | --------------------------------------- | | Server sends the cached HTML | Measured, and fast | Measured, and fast | | Theme and app JavaScript parse and execute | Not run | Measured | | App and third-party servers respond under load | Not called | Measured | | Largest Contentful Paint | Not produced | Captured per session | | Interaction to Next Paint | Not produced | Captured per session | | Cumulative Layout Shift | Not produced | Captured per session | | Evidence of why one session was slow | None | Session video, network log, console log | The lesson is not that HTTP testing is wrong. It is that it measures a layer that rarely breaks on Shopify, and is blind to the layer that does. To see the layer that breaks, the test has to run the page the way a shopper’s device runs it. That is [real-browser load testing](https://www.evaluat.com/blog/real-browser-load-testing): every virtual user is a real browser. ## How to load test a Shopify storefront safely Test the storefront experience, in a real browser, against an environment you control. Walk the journey a shopper takes, from collection to product to cart, with the apps and theme configured the way production is, and watch the metrics climb as concurrency rises. The goal is to find the load at which the page stops feeling fast, before a sale finds it for you. A flash sale or a product drop is the hardest version of this, because the load lands in minutes rather than hours; that sharp case is [spike testing](https://www.evaluat.com/blog/what-is-spike-testing). 1. **Test what you control: the storefront and cart, not checkout.** Shopify hosts checkout itself. Since it [retired checkout.liquid for the checkout steps in 2024](https://shopify.dev/docs/storefronts/themes/architecture/layouts/checkout-liquid), checkout customizations run as [sandboxed extensions in a web worker](https://shopify.dev/docs/api/checkout-ui-extensions/latest) with no access to the page’s DOM, so you cannot weigh checkout down with arbitrary scripts the way you can a theme. The storefront and cart, the part you assemble, are where the performance risk and the test belong. 2. **Run it in a real browser.** Only a browser executes the theme, app, and third-party JavaScript that decides felt speed. A protocol run against the same store measures the cache, not the experience. 3. **Test a development store or staging theme, and check the terms first.** Drive load at an environment you own, not your live shop. Shopify’s public terms do not mention load testing, but they do prohibit automated access and working around technical limits, and stores sit behind bot mitigation, so heavy automated traffic at production can be blocked or breach the terms. Review Shopify’s terms and your third-party providers’ terms before you start. 4. **Give every virtual user its own data.** A virtual user is one simulated shopper the test drives, and each needs a unique cart and session to keep caching and app behavior close to a real crowd. Hundreds of users sharing one cart measure a scenario that cannot happen in production. 5. **Watch Core Web Vitals at load, per URL and per session.** [Core Web Vitals at load](https://www.evaluat.com/blog/core-web-vitals-load-testing) can move before any error appears, so read the Vitals and error rate together. Run from a region chosen to represent a key market, and read the slowest sessions rather than the average. For the revenue path itself, use a [checkout performance testing](https://www.evaluat.com/use-cases/checkout-performance-testing) scenario with unique carts and test data. ## How Evaluat tests a Shopify storefront under load Evaluat is a real-browser performance testing platform: every virtual user is a real, isolated browser that walks your storefront the way a shopper would, capturing Core Web Vitals under load along with session video, network logs, and console logs for each user. You build the journey once in a visual scenario editor, with no scripting; Datasets feed each virtual user its own cart and search terms; popup handlers dismiss the cookie and consent banners every storefront carries. Tests run from the region closest to your customers. When the page slows at peak, the report shows where. The per-URL view separates the collection pages that held from the product or cart step that did not, and the network log of any session shows which call stalled, an app’s backend, a tag server, a personalization request. Aggregate percentiles tell you something broke; they do not tell you who or why. A failure at peak isn’t a percentile. It’s a session. Open the session. Watch the moment it broke. Two honest boundaries. Evaluat watches your store from the outside: it shows which request was slow and what the controlled browser experienced, but tracing that slowness inside a third-party vendor’s backend still takes that vendor’s own monitoring. And for raw protocol concurrency with no rendering, an HTTP tool is the lighter instrument. The same divide on a self-hosted platform is covered in [why Magento checkout dies first under load](https://www.evaluat.com/blog/magento-checkout-slow-under-load) and [load testing a Hyvä storefront](https://www.evaluat.com/blog/load-testing-headless-hyva-storefront). ## Test the store you assembled, not the platform underneath The asymmetry is the lesson. Shopify gives you a platform that scales and a set of themes that, on their own, are fast. What it cannot give you is a guarantee about the store you built on top, with its apps, its tags, and its customizations, at the load you are about to put it under. That store lives in your shoppers’ browsers, and the only way to see it is to test it there. Stop reading “Shopify scales” as proof that your store is fast, and measure the journey that carries your revenue, in a real browser, at the load you expect. Test in real browsers. Debug in real sessions. [Book a demo](https://www.evaluat.com/demo?intent=performance). ![Ahmad Farzan, Founder at Evaluat](https://www.evaluat.com/authors/ahmad-farzan.jpg) About the author [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · Founder at Evaluat Founder of Evaluat. Has spent years building and load-testing Adobe Commerce and Magento storefronts, and built Evaluat to test sites the way real browsers actually hit them. [Ahmad Farzan on LinkedIn](https://www.linkedin.com/in/ahmadfarzan/) [Ahmad Farzan on GitHub](https://github.com/farzanahmad) [More from Ahmad →](https://www.evaluat.com/authors/ahmad-farzan) Common questions ## FAQ ### Why is my Shopify store slow even though Shopify is fast? Shopify's servers and CDN are fast, but server speed is not page speed. The slow part is the theme, apps, and third-party scripts that run in each shopper's browser after the fast response arrives, plus the app and tag servers those scripts call. Shopify caches the storefront HTML; it cannot cache what your JavaScript does once it reaches the browser. ### Do Shopify apps slow down your store? They can. Each app you install can inject scripts that download, parse, and execute on the shopper's main thread, and each one depends on its own vendor's backend. More apps means more main-thread work and more independent services that can slow at peak. The fix is not to fear apps, but to measure which ones add the most weight. ### Does Shopify slow down under high traffic? Shopify's cached storefront scales well, but merchant apps and third-party services can slow when shared demand peaks. Each shopper's device runs its own theme and app JavaScript; those devices do not share a CPU. There is no single "maximum users" number that describes every store, app stack, and journey. ### Can you load test a Shopify store? Yes, with two cautions. Test the storefront and cart you control, because Shopify hosts and sandboxes its own checkout, and test against a development store or staging theme rather than driving heavy automated traffic at your live shop. Review Shopify's terms and your third-party providers' terms first, since high-volume automated traffic can run into acceptable-use limits. ### Why do third-party scripts hurt Shopify performance? Third-party scripts download from servers you do not control and execute on the shopper's main thread, where they can block rendering and delay interaction. Their backends serve many sites at once, so they can slow at exactly the moment your traffic peaks. That combination drags Largest Contentful Paint and Interaction to Next Paint down even when Shopify's own response was fast. ### Does an HTTP load test measure Shopify Core Web Vitals? No. In HTTP mode, a protocol load test sends requests and reads the response bytes without ever running a browser, so there is nothing to render and no Largest Contentful Paint, Interaction to Next Paint, or Cumulative Layout Shift to record. Measuring Core Web Vitals under load requires a real browser that executes the page the way a shopper's device does. ### How do I improve Shopify Core Web Vitals under load? Start by reducing and deferring theme and third-party JavaScript, and audit which apps inject the heaviest scripts. Then measure the storefront journey in a real browser at your expected peak, reading Core Web Vitals per page and per session so you can see which call stalled. Optimizing without measuring under load tends to fix the wrong thing. ### Is a slow Shopify store a Shopify problem or a theme problem? Usually it is the front end the merchant assembled, not the platform underneath. Shopify hosts and scales the infrastructure and its themes are well built, but the apps, tags, and theme customizations you add are the part you control and the part that slows under load. That is also the part you can test and fix. Related reading ## More from the blog [![A fast backend is not a fast page. On the page-load timeline, the server response is a tiny sliver of about 50 milliseconds, while the browser then spends seconds downloading, parsing, running JavaScript, and painting before the page is usable at around 8 seconds. API performance testing measures only the server sliver; browser performance testing measures the whole wait. Figures are illustrative, drawn from a 2025 Catchpoint benchmark.](https://www.evaluat.com/blog/api-vs-browser-performance-testing-cover.svg)](https://www.evaluat.com/blog/api-vs-browser-performance-testing) ### [API performance testing vs browser performance testing: which your QA strategy needs](https://www.evaluat.com/blog/api-vs-browser-performance-testing) [Your API responds in fifty milliseconds. Your page still takes eight seconds to feel ready. API performance testing and browser performance testing measure different layers of that gap, and your QA strategy needs both. Here is what each one catches, what it misses, and how to decide which to run first.](https://www.evaluat.com/blog/api-vs-browser-performance-testing) [Ahmad Farzan · 8 June 2026](https://www.evaluat.com/blog/api-vs-browser-performance-testing) [![Three load-testing models compared: HTTP-script sends requests with no browser, shared-browser puts many virtual users in one browser, and real-browser gives each virtual user its own isolated browser. Only the real-browser model captures what users actually see.](https://www.evaluat.com/blog/real-browser-load-testing-cover.svg)](https://www.evaluat.com/blog/real-browser-load-testing) ### [Real-browser load testing, explained](https://www.evaluat.com/blog/real-browser-load-testing) [Most load testing tools fire HTTP requests at your server. A few share one browser across many simulated users. Real-browser load testing gives every virtual user its own isolated browser, so it measures what your customers' browsers actually do under load. Here is how the three models differ, what each one can and cannot see, and when each is the right call.](https://www.evaluat.com/blog/real-browser-load-testing) [Ahmad Farzan · 5 May 2026](https://www.evaluat.com/blog/real-browser-load-testing) [![Core Web Vitals at load: a page holds a good 2.1 second Largest Contentful Paint for one user, but as concurrent virtual users rise, LCP climbs and crosses the 2.5 second good threshold, ending near 3.4 seconds at 500 users.](https://www.evaluat.com/blog/core-web-vitals-load-testing-cover.svg)](https://www.evaluat.com/blog/core-web-vitals-load-testing) ### [Core Web Vitals at load, explained](https://www.evaluat.com/blog/core-web-vitals-load-testing) [A page can score green in a single-user Lighthouse run and still ship a red Largest Contentful Paint the moment real traffic arrives. Core Web Vitals change under load: the server slows, time to first byte grows, and interactions wait on a busy backend. This guide explains why each Vital moves under load, and how to measure them at concurrency.](https://www.evaluat.com/blog/core-web-vitals-load-testing) [Ahmad Farzan · 1 June 2026](https://www.evaluat.com/blog/core-web-vitals-load-testing) See it on your site Test in real browsers.\ Debug in real sessions. ## Want to see this measured on your app? 30 minutes. We build a scenario on your real customer journey, run a small test, and walk you through the report. [Book a demo](https://www.evaluat.com/demo?intent=performance) [How it works](https://www.evaluat.com/how-it-works)