Narrow the performance question
Follow the category journey or the changes introduced by an upgrade before choosing the next investigation.
Put the plan into practice
Explore the decisions, examples and acceptance checks behind this work.
When the bottleneck is Admin or search
Internal workflows need their own evidence. See our slow Magento Admin guide for grids and product saves, or the Magento search diagnosis guide for missing results, slow queries and search errors.
Start with a Magento Performance Investigation
Get evidence of what is slowing your store down, a clear report and prioritised next steps. Compare Snapshot, Full Investigation and Peak Readiness to choose the scope you need. Optimisation and implementation are quoted separately.
Introduction
A slow Magento store can mean several different things. A category page might take too long to appear, a product image might arrive late, or checkout might pause after a customer chooses delivery. Treating all three as one problem makes it easy to pay for work that misses the cause.
The useful starting point is a clear account of what customers experience, when it happens and which parts of the buying journey are affected. From there, an investigation can separate application delays, browser work, external services and background activity. This guide sets out a practical order for that investigation and explains what a meaningful performance review should deliver.
In brief
Start with the customer journey. Separate server and browser delays. Check caching, images, third-party scripts, extensions and background processes. Prioritise changes by their likely effect on customers, then verify both speed and functionality under comparable conditions.
Match the symptom to the next useful check
If product pages are slow, compare the first server response with the work the browser does afterwards. If only cart or checkout is affected, examine the customer-specific requests and external services involved. A single public-page score cannot distinguish all of these causes.
For address, delivery or payment delays, use our slow Magento checkout diagnosis guide. For a planned assessment with evidence and a prioritised report, compare the Performance Investigation packages.
Follow the symptom to a focused guide
- A long wait before the page responds: separate connection, cache and application evidence.
- Cache misses or stale public pages: identify the cache layer and expected behaviour.
- A store outage or 503 error: capture the incident and protect transactions.
Record a useful performance baseline
Use a short measurement record for each affected journey. Record the URL or action, device and browser, connection conditions, signed-in state, cache state and approximate time. Keep personal information out of screenshots and shared request logs. Repeat the same journey under comparable conditions before and after a change.
- Slow initial response: note the wait for the document response and whether it changes between a first and repeat visit. This narrows the investigation; it does not prove that PHP or the database is the cause.
- Fast response, late main image: record when the image request begins and when it finishes. A late request and a slow download require different follow-up checks.
- Delay after a click: identify the action and the request that remains pending. Checkout, address changes and search can be slow even when the homepage looks fast.
- Intermittent slowdown: record several affected and unaffected times, then compare them with deployments, imports and scheduled workloads. Correlation is a lead to investigate, not proof of causation.
A useful finding connects this baseline to supporting evidence, a proposed correction and a repeatable acceptance check. Our Performance Investigation packages define the diagnostic scope; implementation is quoted separately. Public storefront measurements cannot establish the cause of an internal Admin or server problem without the corresponding access and evidence.
1. Start with the customer journey
Choose representative pages and actions before running tests. Include a busy category, a product with options, search, add to basket and checkout. Look at the journey on a phone as well as a desktop. Compare a first visit with a repeat visit, and consider whether returning or signed-in customers experience something different.
Write down the page, action, device, approximate time and observed delay. “The delivery options take several seconds to appear after entering a postcode” is more useful than “the website feels slow”. Ask the people handling customer enquiries which complaints recur. Their observations can reveal problems that a homepage speed test never encounters.
Keep a short record of recent releases, catalogue imports, promotion changes and extension updates. The aim is to establish a timeline, rather than blame the most recent change automatically. If the problem appears only during a campaign or at a particular hour, include that pattern in the investigation brief.
2. Separate server delays from browser delays
A page that waits before receiving its initial response needs a different investigation from one that arrives promptly but remains difficult to use. The first pattern can involve application code, database work or external calls. The second can involve JavaScript, imagery, fonts and the browser's work to assemble and update the page.
Use several sources of evidence. A browser network view shows the sequence and duration of requests. Application traces and logs can help explain slow operations behind those requests. A screenshot of a performance score is useful context, but it is not a diagnosis or a specification for a fix.
Controlled tests and real-user measurements also answer different questions. A repeatable test helps compare a change under consistent conditions; field data reflects visitors using different devices and connections. Where both are available, consider them together and explain disagreements. Avoid presenting one favourable test run as the experience of every customer. See Google's explanation of lab and field data.
3. Check caching before changing capacity
Full-page caching can avoid repeatedly generating suitable storefront pages. However, an enabled setting does not establish that the pages customers visit are actually being served from cache. Check representative category, product and content pages, and investigate unexpected misses or frequent invalidation. Adobe's page caching guidance explains how a non-cacheable block can affect an entire page.
Personalised information needs separate care. Customer names, addresses, basket details and account information must not be exposed to other visitors through shared caching. Follow the platform's private-content approach and test different sessions when reviewing customisations. Making checkout publicly cacheable is not an acceptable speed fix.
Record cache-clearing activity during the investigation. A cold cache after a release is a different test condition from a warmed store during normal trading. Review what triggers repeated clearing instead of assuming that another flush is the remedy. Changes to cache infrastructure should follow evidence about the existing setup and a plan for checking both correctness and performance.
4. Look closely at images and third-party scripts
Product photography matters, but a small mobile card should not need an unnecessarily large image. Check the actual files delivered, their dimensions and the space they occupy. Give prominent first-screen imagery appropriate priority; images far down the page can have different loading behaviour. Google's Largest Contentful Paint guide explains why discovering the main visual late can delay its appearance even when the file itself is small.
Marketing tags, chat, reviews and personalisation can also add work. Make an inventory of what is loaded, why it exists and who owns it. The useful question is whether each tool justifies its cost at that point in the journey. Test the effect of removing duplication or delaying non-essential features in a controlled environment.
Check business behaviour after every change. Analytics events, consent choices, product options and checkout must still work. Agree with the relevant owner before removing a commercial tool. The third-party JavaScript guide and tag-management guidance provide useful background for this review.
5. Review extensions and custom code
The number of extensions alone does not explain performance. A single feature used on every product page may matter more than several tools used occasionally in the Admin. Focus the review on behaviour: repeated requests, slow operations, overlapping functionality and changes to critical shopping actions.
Connect a suspected problem to a reproducible example. For instance, compare a product page where a feature is present with one where it is absent, while accounting for other differences. Ask what evidence would confirm or disprove the suspicion before paying for a replacement extension or a large rewrite.
Avoid switching unfamiliar modules off on a trading store as a first experiment. Payment, stock, fulfilment and integration dependencies may not be visible from the storefront. Use a suitable test environment, establish what depends on the feature and record the change. A useful investigation leaves a clear explanation of the cause, the proposed remedy and how the result was checked.
6. Investigate work behind the storefront
Imports, scheduled tasks, indexing, backups and integrations can overlap with customer activity. Look for a relationship between slow periods and that background work. A recurring delay at a particular time may be more revealing than an average taken across the day. Check for failed or overlapping jobs as well as jobs that appear to finish normally.
Adobe's configuration guidance covers scheduling and indexing considerations. Apply guidance to the actual edition, version and infrastructure rather than copying settings without checking their purpose. The investigation should explain which workload is competing for which resource and whether the pattern is expected.
More capacity can be justified when a genuine limit has been reached. It can also be a temporary measure while a deeper problem is addressed. Ask for those two decisions to be distinguished in the plan, including the ongoing cost and what evidence would show that additional work is still needed.
7. Prioritise and verify the improvements
Turn the findings into an ordered plan. Each item should identify the affected journey, supporting evidence, proposed change, dependencies, risk and expected benefit. Put customer-critical problems near the top. A slow or unreliable basket deserves attention even when a cosmetic adjustment offers a more attractive headline score.
Before release, agree the test cases and how the change can be reversed if necessary. Compare the same pages and actions under comparable conditions. Record device and network settings, cache state and relevant background activity. Repeat measurements enough to understand normal variation, and report the conditions alongside the result.
Verify functionality as well as speed. Include search, product selection, basket updates, delivery options and the payment paths affected by the work. Continue observing the store after deployment: a short test cannot represent every visitor or trading period. Keep the release record so that later changes can be compared with a known starting point.
Routine performance improvements should be planned and measured. If downtime or severe failures are disrupting live trading, see our working-hours emergency Magento support or out-of-hours Magento support. We assess the incident and confirm scope and start time before payment.
What should a performance review deliver?
A useful review gives you a basis for decisions. Ask for a baseline, an explanation of the main bottlenecks and a prioritised plan with a clear scope. If changes are included, the report should distinguish completed work from recommendations and show what was retested. Unresolved questions belong in the handover too.
Good documentation makes the work easier to maintain. Your team or existing development partner should be able to understand the evidence, reproduce the relevant checks and see who owns follow-up tasks. A report that promises a score without defining the pages, conditions or scope gives you much less to assess.
Performance review deliverables checklist
- Baseline measurements for agreed customer journeys.
- Evidence explaining the main bottlenecks.
- A prioritised action plan with dependencies and risks.
- A record of implemented changes and rollback arrangements.
- Comparable test results and functional checks.
- Clear outstanding issues, monitoring and handover responsibilities.
FAQs
Will a faster server solve the problem?
It may help when server capacity is the constraint. It will not necessarily resolve slow external calls, excessive browser work or inefficient application behaviour. Ask which measurement supports a hosting change and how the improvement will be verified before committing to ongoing cost.
Can an existing Magento store be improved without a rebuild?
Often the sensible first step is to investigate the existing store and identify targeted improvements. A rebuild is a wider decision involving maintainability, functionality and business plans. The performance review should explain when a limited change is sufficient and when a broader option deserves consideration.
Can performance work affect checkout?
Yes. Checkout can depend on custom code, scripts and external payment or delivery services. Define the affected paths and test them in an appropriate environment. A faster page that loses delivery choices or fails to complete an order is not a successful outcome.
What should I prepare before asking for help?
Bring your store URL, examples of the affected journeys, approximate times and a list of recent changes. Existing reports or monitoring can help, but you do not need to diagnose the cause yourself. Discuss access requirements separately; do not put passwords, payment details or customer records into an initial enquiry.
From a performance finding to delivered work
Midoriweb's Magento performance optimisation service connects the investigation with the development needed to act on it. We can work on custom code, extension behaviour, catalogue processing and the services supporting the store. That allows a finding to be followed into the relevant implementation instead of ending with a recommendation your team must translate into a separate project.
Consider a review that identifies a slow external call during checkout. The next step is to establish why the call is made at that point and which result the transaction needs. The implementation might require a change to the integration or the surrounding application logic, with the correct approach depending on the business rule. The acceptance checks must then cover the order and payment behaviour as well as the delay. This is an illustration of the reasoning, not a claimed client result.
The same principle applies to infrastructure. If monitoring shows memory pressure during a scheduled catalogue job, the work may involve capacity, scheduling or the job's implementation. Our server management service and Magento development capability allow those options to be assessed together. You receive a recommendation linked to the workload and a defined correction to review.
We prioritise the work with your business and agree how the outcome will be measured. After implementation, we compare relevant evidence and check affected functionality. The handover records the changes, completed checks and remaining dependencies. This makes the result useful for future maintenance and gives you a basis for deciding whether further optimisation is justified.
Bring your performance priorities to Midoriweb
Tell us what customers are experiencing and which parts of the store matter most to your business. We can discuss a sensible starting point, define the investigation scope and agree what evidence you need before committing to wider changes.
Book a consultation or tell us about your store. We can define a focused review or implementation scope around the journeys that matter to your business.
