How to investigate a slow Magento 2 checkout
A checkout can render slowly, respond slowly to an address change, or take too long to place an order. Start by finding which delay the customer actually encounters.
1. Name the delay before choosing a metric
Write down the slow step: opening checkout, updating the basket, choosing a delivery method, submitting payment or receiving confirmation. Measure the time until the customer can complete that step, as well as the work underneath it.
Largest Contentful Paint (LCP) measures when the largest eligible visible content element renders. It helps describe loading, but it does not tell you when an order completes. Interaction to Next Paint (INP) measures responsiveness to interactions; it does not include the whole wait for an asynchronous payment request. Keep these separate from request and transaction timings.
2. Make the slow journey repeatable
Use an agreed test basket, customer state, delivery address and payment method. Record the browser, device, network conditions and whether the relevant caches are warm or cold. Run the same sequence more than once. A guest with no saved address and a returning customer can exercise different paths.
Capture a baseline before changing the theme, modules or backend. Label local and staging results clearly: their infrastructure and data may differ from production. Where field data is available, use it to check whether a repeatable lab problem also affects real customers.
3. Follow the requests behind the wait
Record the slow step in the browser’s Network panel. Inspect the request waterfall, initiators and timing breakdown to see which request starts the next, which requests repeat and where a response holds up the interface. The Chrome DevTools Network reference explains those views. If a response is slow, trace it through application logs or server profiling before deciding that the browser is the problem.
Turn the trace into questions the team can answer. Is the same information fetched twice without a state change? Does delivery selection trigger a totals refresh that immediately triggers another? Is work needed only after an interaction blocking the initial render? A repeated request is a lead, not proof that it can safely be removed.
4. Make reuse and invalidation explicit
Before reusing a response, define what makes it valid and what makes it stale. Basket contents, customer group, address, delivery method and coupons can change checkout state. Customer-specific data needs appropriate isolation; a general shared cache is not a safe shortcut for a slow checkout.
Write the dependency down before moving a call or removing a fetch. Agree what happens on a timeout or failure, too. Showing an old delivery quote quickly is not an improvement if the order then uses the wrong amount.
5. Check correctness alongside speed
Change one identified source of delay at a time and repeat the baseline. Test the affected order paths, including guest and signed-in customers, discounts, delivery changes, tax and totals, and payment failures. Check that a successful order reaches the downstream systems with the expected values. Automated regression checks and a rehearsed rollback make these changes easier to release with confidence.
Compare like-for-like measurements and keep the range of results, not just the fastest run. After release, watch both performance and order errors. A lab improvement needs confirmation under real traffic.
What changed on our Magento checkout
At Floor Giants, the team removed redundant fetches and reduced blocking work. Measured checkout LCP fell from 5.8 seconds to 1.6 seconds. That is a rendering result, not a claim that the full purchase completed in 1.6 seconds.
The full checkout case study covers the work and the reported conversion change, including its attribution limits. It is evidence from one store, not a performance guarantee for every Magento installation. The useful starting point is the same: follow the actual customer journey, find the unnecessary work, and measure the result against a repeatable baseline.
Related work
- Planning a Hyvä migration around checkout and backend dependencies
- Our Magento security patching and release workflow
For a second opinion on a Magento performance investigation, get in touch.