Find Out Exactly Why Your Magento Store Is Slow

It is a structured investigation into why your store is slow, and it begins with measurement rather than assumption. We profile the whole stack: backend PHP, database queries, indexers and cron, caching and Varnish hit rates, extension and third-party script load, frontend assets, and the hosting environment underneath. You receive a prioritised report of what is genuinely causing the slowness, with the evidence behind each finding and a plan for what to fix first. Most slow Magento stores have several contributing causes of very different sizes, so the ranking matters as much as the list itself. The aim is to know where the time goes before spending anything on removing it.

An audit is the diagnosis, speed optimisation is the treatment. The audit measures, finds the real bottlenecks and hands you a ranked roadmap. Optimisation is the engineering work of removing them. We offer both, and many clients deliberately start with the audit so the optimisation budget only goes where it will change a number. It also establishes the baseline you measure against afterwards, which is the only honest way to claim an improvement later. If you already hold solid profiling data and simply need the work carried out, you can go straight to optimisation, and we will tell you when that is the sensible choice.

By measured impact, not by how alarming something looks written down. Every finding is ranked on the time it actually costs a page, how many pages it affects, and how much work the fix involves, so the list is ordered by what will move your numbers rather than by category. That routinely puts an unglamorous fix such as an uncached block or a missing index above a long standing complaint about image sizes. We also mark the findings that cannot help until something else is fixed first, since a rendering improvement stays invisible while the server still takes four seconds to respond.

Less than most clients expect. Admin access to the store, read access to the codebase, and a way to see server level metrics, which usually means either a hosting panel login or somebody who can pull the figures for us. Where profiling is involved we ask for a staging copy rather than production. We do not need write access, deployment rights or anything that would let us change your store, and we would rather not hold them during an audit, because the value of the exercise depends on nothing shifting underneath the measurements while they are being taken.

Backend PHP profiling to find slow code paths, database and query analysis including missing indexes and repeated per-row queries, indexer and cron health, extension and third-party script load, full-page cache and Varnish hit rates, image and asset delivery, Core Web Vitals on real templates, and the server and hosting environment beneath all of it. We also check the configuration that is easy to get wrong at scale, such as indexer modes, cache backends and overlapping cron schedules. A slow store almost always has more than one cause, and the cheapest fix is rarely the largest one, so we measure the whole stack before ranking anything.

Yes. We measure Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint on real templates, then trace each poor score to its cause, whether that is render-blocking assets, an oversized or wrongly lazy-loaded hero image, third-party scripts, layout shift from unsized media, or slow server response. The thresholds are 2.5 seconds, 0.1 and 200 milliseconds at the 75th percentile, and Interaction to Next Paint replaced First Input Delay in March 2024, which caught out many stores that had been passing. One caution we give every client: field data uses a 28 day rolling window, so a fix takes roughly a month to show fully.

Because we measure first, and most failed speed work targets the wrong thing. Stores commonly arrive having bought more server capacity for a problem that turned out to be a single slow query, or having minified assets when the real cost was an extension issuing hundreds of requests on every page load. Profiling data shows where the time is actually spent, so effort goes to the bottleneck rather than to whichever fix is easiest to sell. We also agree the baseline and the success metric before starting, and we will say when a proposed change is not worth doing, which is what makes the ranking trustworthy.

A focused audit is usually a matter of days. What moves the timeline is how much evidence you need rather than how large the store is: a straightforward read on the main templates and the obvious bottlenecks is quick, while a deep dive with load testing, a full query trace and a peak-traffic simulation takes longer to run and longer to interpret. Some measurements also have to sit across a real trading pattern, because a store behaves differently on a quiet Tuesday morning than during a campaign. We agree the scope, the depth and the timeline up front so nobody is paying for open-ended investigation.

In a deep-dive audit, yes. We run load tests against a staging copy that mirrors production as closely as possible, then watch where it bends first, which is usually the database, a cache that stops being effective under concurrency, or an integration that queues behind itself. This is far more useful before a sale or campaign than after one, because the failure mode you care about only appears under concurrency and cannot be found by loading pages one at a time. We report the concurrency level at which response times start to degrade and what fails first, so capacity planning rests on a number.

Yes, and most of our audits are exactly that. An independent read on an inherited or third-party build is often the whole point: you get an assessment from someone with no stake in defending the decisions already made, and no incentive to describe the existing work as either better or worse than it is. We do not need the original team's cooperation, only the code, a staging copy and access to hosting metrics. If the current developers are still engaged we are happy to share findings with them directly, since the report is meant to be actionable rather than adversarial.

The diagnosis holds for months rather than weeks, provided the store is not changing much. Architecture, indexing, caching strategy and hosting shape do not drift on their own. What does age is anything tied to traffic volume or data growth, since a query that was acceptable against fifty thousand orders can be the bottleneck against half a million, and third party scripts get added by marketing without anyone treating it as a code change. If a year passes, or you have shipped a major release or a replatform, the numbers are worth taking again before acting on the older ranking.

Yes, because knowing that it is slow is not the same as knowing why, and the gap between those two is where budgets disappear. The audit converts a vague sense of slowness into a specific, ranked list of causes with the evidence attached, so you can fund the work that will move the number and decline the work that will not. It also gives you the baseline needed to prove the improvement afterwards. It frequently reframes the problem too: stores that arrive convinced they need new hosting often turn out to have a cache hit rate issue that costs a fraction as much to resolve.