Start with the customer journey
Which part of checkout is slow?
“Checkout takes too long” is a useful symptom, but it is not yet a diagnosis. Describe the action a shopper takes and what they wait for. If the storefront itself is slow, start with our wider Magento speed guide.
- Opening the cart or checkout: note whether the page is blank, the spinner stays visible, or the page appears but controls do not respond. Compare a simple basket with the basket that causes trouble.
- Entering an address: identify whether the delay begins after a postcode, country or address change. Address validation, tax calculation and shipping-rate requests are possible dependencies to investigate.
- Choosing delivery: record which delivery method is affected and whether alternatives behave differently. An unavailable carrier response can look like a slow Magento checkout.
- Selecting or submitting payment: distinguish a slow payment widget from a delay after submission. A bank authentication challenge is a separate stage; record where the wait occurs.
- Waiting for confirmation: establish whether an order or payment already exists before repeating the purchase. A missing confirmation page does not prove payment failed.
Also note whether this affects guests, signed-in customers, particular devices or everyone. A repeatable example with an approximate time is more useful than a single overall speed score.
Is the delay broader than checkout?
If public pages also wait before responding, compare the initial server-response evidence. If public pages repeatedly miss cache or show old content, review cache behaviour separately. A store that stops accepting orders needs the incident-response checklist.
Separate browser work from server waiting
A checkout can feel slow even when its initial HTML arrives quickly. JavaScript may still be loading, rendering payment fields or processing a large amount of work on the customer’s device. Conversely, a responsive-looking form may be waiting for a slow application response.
A developer can use the browser’s network and performance tools to identify the request or task that aligns with the wait. The useful question is not simply “how large is the page?” but “what must finish before this customer can continue?” Server traces and application logs can then be correlated with that time.
A long server response might involve custom code, a database query, contention, limited PHP worker capacity or an external call. These are investigation paths, not conclusions that can be drawn from a spinner. Testing during a quiet period may also miss a problem that appears only when shoppers, imports and background jobs compete for resources.
For a browser-side delay, examine checkout extensions, third-party scripts, repeated requests and errors before choosing a fix. Test the affected device and connection as well as a developer’s fast laptop. A laboratory run is controlled evidence; it is not a substitute for what real shoppers experience.
Check shipping, tax and payment dependencies
Checkout brings several systems together. A shipping provider, tax service, address lookup or payment integration can add waiting time even when catalogue pages are fast. The investigation should identify which dependency is called, how long it takes and what happens when it fails or times out.
Look for a change that matches the start of the problem: a newly enabled delivery method, an extension update, configuration changes or a recent deployment. Correlation helps narrow the search, but it does not establish the cause. Preserve the evidence and compare behaviour in a suitable test environment.
Do not disable live payment or checkout extensions simply to see what happens. Use a controlled reproduction with agreed test payment methods and a rollback plan. Avoid repeated real purchases: if payment appears stuck, an authorised team member should check the order and provider records before another attempt.
A checkout that no longer accepts orders is an operational incident. Our emergency support service has its own acceptance and pricing process; a scheduled performance investigation is for planned diagnosis.
Why full-page caching is not a checkout fix
Caching public product and category pages can reduce work and make browsing faster. Checkout contains customer-specific information and follows different rules. Adobe’s documentation identifies checkout as a non-cacheable page by default.
Do not try to solve a slow checkout by putting its personalised responses into a shared full-page cache. Review the actual bottleneck: the application request, dependent service, browser work or resource contention. Session handling and cache configuration may still matter, but changes need to preserve customer isolation and correct cart behaviour.
The practical distinction is simple: a fast cached product page does not demonstrate that checkout can handle the same workload. Test the journey you need to improve, including the relevant basket and customer state.
Technical reference: Adobe’s public and private content caching guidance.
A short brief that helps an investigation
You do not need to diagnose Magento before asking for help. Supply the minimum information that makes the symptom understandable:
- The affected action: for example, “shipping methods take a long time to appear after entering a UK postcode”.
- When it happened: an approximate date, time and time zone, plus whether it happens consistently or during busy periods.
- The conditions: device/browser, guest or signed-in checkout, relevant delivery/payment method and whether a particular basket triggers it.
- Recent changes: updates, extensions, hosting changes or deployments that may be relevant.
- A safe illustration, if available: a screenshot or short recording with personal and payment details removed.
Do not put passwords, card details, session cookies or customer records into an enquiry. Browser network exports can contain sensitive information; share them only through an agreed secure process after review. If technical access is needed, we request it through the secure access workflow.
Optional detail is welcome, but a concise, reproducible example is enough to start a conversation. If you have not isolated the conditions, say so rather than making assumptions.
Choose investigation or implementation
An automated speed test can flag browser-facing symptoms. A performance investigation adds interpretation, agreed scope, evidence and prioritised next steps. Optimisation is the separate work of making and verifying changes.
Our Performance Investigation packages explain the distinction. Snapshot examines public storefront pages from outside; it does not provide internal profiling of a private checkout journey. Full Investigation includes sampled application and infrastructure investigation with suitable access. Direct purchase eligibility depends on the storefront setup; custom and headless implementations need scoping first.
Tell us checkout is the priority so the relevant journey and limitations can be agreed. Peak Readiness is separately scoped for staging workload tests; it is not a promise of future live capacity. The package page contains the current scope, delivery periods and fictional sample reports.
When the evidence is already available, our Magento performance optimisation service can help scope the changes and how they will be checked. Measure the same journey before and after under comparable conditions, including errors and successful completion—not only the headline timing.
Common questions about slow Magento checkout
Why is checkout slow when product pages are fast?
Product pages may be served from a shared cache, while checkout performs customer-specific work and calls delivery, tax or payment services. Trace the slow checkout stage rather than assuming the catalogue result applies to it.
Will a better PageSpeed score fix checkout delays?
Not necessarily. A public-page score does not reproduce every basket, customer state, payment interaction or server dependency. Use browser measurements alongside evidence from the affected checkout journey.
Should I replace my one-step checkout extension?
Only if evidence supports that decision. First establish whether the extension causes the delay, whether there is a compatible fix and whether the problem can be reproduced in a test environment. Replacing checkout also requires functional testing.
Can an external Snapshot diagnose the whole checkout?
No. Snapshot has a public-storefront scope. Private checkout behaviour and internal application bottlenecks may require suitable technical access and a different investigation scope.
What if a customer was charged but saw no confirmation?
Have an authorised team member check the payment provider and Magento order records before asking the customer to pay again. Treat missing or inconsistent order/payment states as a functional issue, not simply a speed score problem.