Checkout and cart ceiling
The paths that convert are the paths no cache can serve. Rehearse cart, shipping, and payment at forecast peak before the sale finds the limit for you.
Solutions · Magento
Magento load testing that measures the store, not the cache.
Evaluat load tests Magento and Adobe Commerce stores in real browsers, at the concurrency you forecast for a sale. Every virtual user is a real browser with its own cart. You get a verdict stakeholders can read, and the sessions that slowed for your engineers.
Performance Testing is available through assisted private access.
The thesis
One store, two ceilings.
A Magento store runs at two speeds. The pages the full page cache can serve, category and product pages mostly, stay fast under almost any traffic. The pages it cannot touch, cart, checkout, login, and every block marked cacheable="false", hit PHP, the database, and your third-party integrations on every single request.
Quiet-day monitoring lives almost entirely on the cached side, which is why a store can look healthy in every dashboard and still fold when a sale starts. The moment traffic peaks is the moment shoppers pile onto the uncacheable side. That is the side worth rehearsing, and it is the reason Magento checkout dies first under load.
Where Magento breaks
What we rehearse on Magento stores.
Qualitative and specific on purpose. We do not invent conversion statistics. We test your store at your forecast peak.
Full page cache blind spots
One block marked cacheable="false" punches a hole through a whole page. Find the templates that quietly bypass FPC before the crowd does.
Third-party payment and shipping calls
Checkout waits on gateways, tax, and shipping quotes. Under concurrency those waits stack and park PHP workers. The network log shows which call held each session.
Session locking
Magento serializes requests per session, so one slow call can queue everything else a shopper clicks. It only shows when many real sessions run at once.
Promotion and price-rule weight
Cart price rules and coupon checks run on the uncacheable path, exactly when the promotion drives peak traffic to it.
Hyvä and headless replatforms
A lighter frontend does not raise the backend ceiling. Run the same journey on old and new before you cut over.
Method
How do you load test a Magento store?
-
1.Script the journey, not a URL list
Browse, product page, add to cart, checkout. A test that only requests cached catalog URLs measures your full page cache, not your store. The journey is assembled in a visual step editor, no scripts; element targets use CSS selectors.
-
2.Give every virtual user its own cart and data
Datasets vary the accounts, search terms, and products each virtual user touches, so no two sessions follow the same path and the cache cannot flatter the run.
-
3.Point it at staging, with payments in sandbox
Full-concurrency checkout runs belong on a staging environment with a payment sandbox. Production runs stay small and bounded, with the target agreed first.
-
4.Ramp to your forecast peak, then past it
Ramp up, hold at the concurrency you expect on the day, and push a step beyond it. The goal is to find the ceiling while there is still time to raise it, not to confirm a comfortable number.
-
5.Read the results per step and per session
The slowest steps name the bottleneck layer. Open the sessions that slowed, watch the video, and read the network log to see which call held the line.
The same journey, held at expected traffic, is a load test. Pushed past it, a stress test. Spiked in minutes, a spike test. Same scenarios, same report, different traffic shape. More on the mechanics on How it works.
Frontends
Luma, Hyvä, or headless. Same question.
Because every virtual user is a real browser, the test does not care which frontend renders the page. A Luma theme, a Hyvä rebuild, and a headless storefront on Magento APIs all get the same rehearsal: real sessions walking the journey while Core Web Vitals, video, and logs are captured per user.
What changes is where the evidence points. Hyvä usually moves the bottleneck from frontend JavaScript to the backend ceiling; headless splits it between the storefront app and the Magento APIs behind it. We wrote up the differences in load testing a headless or Hyvä storefront.
Fit
The right instrument for each layer.
Choose Evaluat when the question is what shoppers experience under load: Core Web Vitals on the journey, checkout that holds, third-party calls that do not, and a forensic record of the sessions that failed.
Choose a protocol tool such as Magento's JMeter-based performance toolkit or k6 when you need raw API concurrency without a rendered page. The comparison with JMeter covers where each layer stops. Many teams use both.
Results describe what controlled browsers saw under the selected test conditions. They are not a substitute for field CrUX data from your customers' own devices. This page sits under ecommerce performance testing; for the calendar-driven version, see peak readiness.
Questions
FAQ
What is Magento performance testing?
Magento performance testing measures how a Magento or Adobe Commerce store behaves at real shopper concurrency: how fast pages render, whether cart and checkout hold, and where the store breaks first. Evaluat runs the test in real browsers, so the numbers reflect what shoppers see, not only what the server answered.
How do you load test a Magento store?
Build the full browse-to-checkout journey in a visual step editor, give every virtual user its own cart and data, run at your forecast peak from the region your customers shop from, then read the results per step and per session. Testing only cached catalog URLs measures your cache, not your store.
Why is a Magento store slow under load?
Usually because the uncacheable paths saturate. The full page cache absorbs browsing, so catalog pages stay fast while cart, checkout, login, and anything marked cacheable="false" queue on PHP workers, the database, and third-party payment and shipping calls. That is why a store can feel fine right up until the sale starts.
What tools can load test Magento?
Two layers. Protocol tools, such as Magento's own JMeter-based performance toolkit or k6, drive API and HTTP concurrency cheaply but never render a page. Real-browser platforms such as Evaluat run each virtual user in a real browser, capturing Core Web Vitals, session video, and network and console logs for the journey shoppers actually take. Many teams use both.
Can you load test a production Magento store?
Yes, with bounds agreed first. Prefer a staging environment with payment sandboxes for checkout at full concurrency. Production runs stay small and bounded unless you explicitly ask for more, and the exact target, time window, and exclusions are agreed before any traffic goes out.
Does a Hyvä or headless frontend change the test?
The frontend changes what renders; the backend ceiling stays. Hyvä ships far less JavaScript, and a headless storefront moves rendering into its own app, but cart, checkout, and the Magento APIs behind them remain the shared bottleneck under load. The same browse-to-checkout rehearsal answers both.
Is this available now?
Performance Testing is available through assisted private access.
Checkout-specific questions are answered in why Magento checkout dies first under load; more general ones on the FAQ page.