Magento performance investigation: an example report

From the sample report to your own store

Compare investigation scopes and see how to prepare useful examples for the work.

• Magento performance audit cost: choose the scope you need
• Preparing for a Magento performance investigation

What a useful performance report should tell you

A performance report should help you decide what to do next. It should explain which customer journeys are affected, what the evidence shows, what remains uncertain and which change deserves attention first. A list of scores without that context leaves the difficult decisions with you.

At Midoriweb, we want an investigation to give both the business and its developers a shared starting point. The business needs a clear explanation of impact and priority. The implementation team needs enough detail to reproduce the problem, understand the proposed change and recognise a successful result. Those are different needs, and a useful report serves both.

This guide walks through a fictional example. It is an explanation of how to read findings, not a customer case study, a measured result or a promise that every store has the same problems. The scope of your actual report depends on the investigation purchased and the access available. See the Performance Investigation packages for the current deliverables.

Begin with the question and the sample

Imagine a retailer whose product pages feel slow on mobile, although its homepage seems acceptable. The question is not simply whether the website can achieve a higher score. It is whether customers can see the product, choose a variant and reach the basket without an avoidable wait.

The report first records the pages and conditions examined: the selected products, store view, device profile, network conditions, consent state and whether the visitor is signed in. It distinguishes an initial visit from a repeat visit. It also records when evidence was collected, so later changes to the store do not make the results impossible to interpret.

A public storefront assessment cannot establish what is happening inside a database or PHP worker pool. If those systems have not been examined, the report should say so. For example, a slow document response is evidence of a delay before the browser receives the page; it is not, by itself, proof that a particular extension is responsible. Our slow Magento guide explains how these layers fit together.

Read the executive finding before the technical detail

An illustrative executive finding might read: “The sampled product journey has two separate delays. The main image becomes available late, and selecting a variant triggers work that needs further investigation. Addressing only image size would not establish that the variant interaction is fixed.”

Notice what this statement does. It identifies a customer journey, separates two symptoms and avoids claiming a cause that has not been demonstrated. It gives the business a reason to prioritise the product page without promising a particular conversion increase.

The summary should also identify what was not found. If the sampled homepage behaves consistently during the assessment, that is useful context. It does not establish that every page, every customer session or a future promotion will behave the same way. A report earns its value by drawing a clear boundary around the conclusion.

Worked example: turn an observation into an action

Consider a fictional finding labelled “Product image discovered late”. The observation is that the main image request begins after work that is not necessary to identify the product image. The supporting evidence would be the relevant request sequence and page markup, captured under recorded conditions. The report would explain why this could delay the point at which the shopper sees the product.

The recommendation might be to review how the theme exposes the main image and whether an interaction script controls its discovery. That is a proposed investigation or implementation task, not permission to disable every image script. Product galleries, alternate images and variant selection still need to work.

An acceptance check would repeat the same page conditions, confirm the image request begins at the intended point and test gallery behaviour on mobile and desktop. The implementation team should also check that the correction has not caused an unnecessary image download elsewhere. A successful change improves the intended journey without quietly breaking another one.

Separate confidence, priority and effort

A finding can be well evidenced but commercially minor. Another can have serious potential impact while its cause is still uncertain. Combining both into a single red warning makes the report harder to use.

We would separate the strength of the evidence from the proposed priority. For the fictional image example, confidence might be high that discovery is late, while confidence in the precise implementation fix remains provisional until the theme is reviewed. Priority depends on how important those product pages are to the business. Effort depends on the code and dependencies, not just how simple the recommendation sounds.

This distinction helps you agree a sensible first piece of work. A contained, reversible correction with a clear acceptance check may be a better starting point than a broad rewrite. An uncertain infrastructure issue may first need a short diagnostic task. Neither should be presented as a guaranteed quick win simply because the store is slow.

Understand what each investigation can establish

Snapshot examines external evidence from four agreed public URLs. It is useful when you need a contained first assessment or cannot yet provide internal access. It includes a limited external full-page cache check and public competitor context; it does not include application profiling, a database investigation or staging load testing.

Full Investigation adds sampled application and infrastructure evidence within the agreed access. Its published scope covers one installation, up to eight page types and three selected store views, with twelve sampled URLs or journeys in total. Custom or headless setups need scoping before payment. The report should distinguish examined evidence from areas that access limitations prevented us from assessing.

Peak Readiness adds an agreed workload and capacity assessment, including scoped staging load testing. Its scenarios and limits belong in the proposal. A point-in-time storefront result should never be presented as proof that a store will withstand an unspecified promotion. The load testing guide explains the questions a meaningful peak scenario needs to answer.

Use the report to brief the implementation team

Give each accepted recommendation an owner and a clear definition of completion. Include the original evidence reference, affected journey, dependencies, intended correction and verification conditions. If the implementation team chooses another approach, record why and preserve the same business acceptance criteria.

Keep unrelated improvements separate. A report about a slow product journey should not become an open-ended redesign without a new scope. Equally, a developer should be able to flag a dependency that changes the effort before work begins. Clear boundaries protect both the budget and the quality of the result.

Implementation and retesting are separately agreed services, not included automatically in the investigation fee. You can take the findings to your existing team or discuss Magento performance optimisation with Midoriweb. The report should make either route easier.

Technical references

Use the documentation that matches your installed version and deployment.

• Google: Web Vitals

Continue with a related guide

• Headless commerce: when is the complexity worth it?

Explore the complete topic library →