Midoriweb practical guide

Magento performance audit cost: choose the scope you need

Understand what drives investigation cost, compare Midoriweb’s package scopes and follow the service page for current pricing and delivery conditions.

Abstract technology illustration

Buy an answer to a business question

A Magento performance audit price is useful only when you know what the investigation can answer. A public storefront review, an internal application investigation and a capacity assessment require different evidence. Comparing them by the number of pages in a report can make a small external assessment look equivalent to work that includes code, infrastructure and sampled internal journeys.

Begin with the decision you need to make. Do you want an independent view of visible page performance? Are you trying to understand why the store remains slow despite hosting changes? Or do you need to plan for an agreed promotional workload? Write that question before choosing the cheapest or largest package. It gives both your team and the investigator a clear test of whether the scope is appropriate.

Compare Midoriweb's investigation scopes

Our Performance Investigation page shows the current package prices, inclusions and delivery conditions. Use that page when budgeting, purchasing or making an enquiry. This guide explains how to compare the work rather than reproducing a price list that could become outdated. For a scoped proposal, use the price and schedule agreed for that proposal.

Snapshot covers agreed public URLs and external assessment. Full adds access-dependent application and infrastructure investigation within its stated sample. Peak adds a separately agreed workload and readiness scope, including staging load testing. These are investigation services; purchasing a report is not the same as commissioning every resulting implementation task. Review the full inclusions, limits and terms on the service page before buying.

Compare the investigation question · Scroll sideways on smaller screens
RouteEvidence focusQuestion it helps answer
SnapshotAn agreed sample of public storefront pages.What can external evidence reveal about the visible experience?
Full InvestigationAccess-dependent application and infrastructure evidence.What is happening inside the sampled customer journeys?
Peak ReadinessAn agreed workload and readiness assessment.How should we investigate the planned peak scenario?
ImplementationSeparately scoped changes after diagnosis.How will the accepted recommendations be delivered and checked?

Why a score is not the same as a diagnosis

A browser assessment can identify visible symptoms and provide useful evidence about the sampled page. It cannot directly inspect an internal database query or prove why a PHP worker is waiting. Internal tools can add that evidence, but they need suitable access, time and a clear relationship to the affected customer journey. More dashboards do not automatically produce a better explanation.

Ask what each finding will contain. A useful finding describes the observation, the conditions in which it occurred, the supporting evidence, the confidence and the next action. It should distinguish a demonstrated cause from a plausible hypothesis. Our illustrative report guide shows how those elements fit together without presenting fictional improvements as client results.

Match scope to the questions you cannot currently answer

If a store owner needs to understand the public experience before committing to deeper work, an external assessment can be a sensible starting point. If the problem is a slow Admin task, database contention or intermittent server saturation, public-page evidence alone cannot settle it. Choosing a smaller scope does not make those internal questions disappear.

Similarly, a responsive store at quiet times may still struggle during a promotion. That is a workload and capacity question. A normal browsing sample is useful background, but it cannot certify a chosen number of simultaneous shoppers. Define the peak scenario and environment before considering a load-testing proposal. The load-testing guide explains why the business journey matters as much as the request count.

Choose a performance investigation scope
  1. 01DescribeWhat is slow and what it affects
  2. 02MatchPublic sample, internal diagnosis or peak question
  3. 03ConfirmAccess, coverage and delivery conditions
  4. 04DecideUse the findings to scope implementation

Separate investigation, implementation and validation budgets

An investigation reduces uncertainty and prioritises work. Implementation changes the system. Validation checks whether the agreed change produced the intended result without breaking neighbouring behaviour. These stages may be commissioned together or separately, but the proposal should state which are included. This avoids an awkward handover where the business expects fixes and the supplier has priced only a report.

Ask whether recommendations can be used by your existing team. A practical action should explain the problem and the acceptance evidence, rather than merely naming a product to buy. Where implementation effort cannot yet be estimated reliably, the report should say what discovery remains. Treat precise savings or conversion forecasts without a credible baseline as assumptions, not money already recovered.

Understand what makes a scope more complex

Multiple installations, store views, bespoke themes, headless frontends and extensive integrations can create additional journeys and dependencies. The relevant question is which of those need to be sampled to answer the brief. A large catalogue is not automatically difficult in every area, and a smaller store can still have a complicated checkout or integration path.

Explain unusual architecture before purchase if it may sit outside a package's stated fit. Do not assume the words “full investigation” mean unlimited installations, every possible URL or continuous monitoring. Agree how the investigation handles unavailable access and evidence that cannot be collected. Clear boundaries protect the quality of the work as well as the budget.

Prepare enough information to avoid wasted discovery

Provide the website, a plain description of the symptom, relevant URLs and the most useful known time periods. If the issue followed a release, record what changed. If it affects only one customer group or country, say so. You do not need to arrive with a technical diagnosis; a reproducible example is often more useful than a long list of suspected modules.

The investigation preparation guide gives a short evidence brief. Keep credentials out of general enquiry text and email. Where internal access is required, use the requested secure workflow and grant access appropriate to the agreed work. Avoid creating an extensive administrative task before the actual requirements have been confirmed.

Decide whether the problem is urgent

An investigation package is designed to answer a scoped question within its delivery terms. It should not be mistaken for immediate incident acceptance when checkout is failing now. If customers cannot place orders or the site is unavailable, use the emergency support route and describe the current business impact.

After containment, planned analysis may still be valuable. The distinction is the immediate objective: restoring a critical journey versus understanding performance and prioritising future work. One does not eliminate the need for the other, but commissioning them in the wrong order can frustrate a team that needs the store trading again.

What a worthwhile outcome looks like

Before work starts, agree who will read the report and who can act on it. A merchant needs priorities and consequences; a developer needs sufficient evidence and acceptance criteria. The same finding should connect those two views. Reserve time for the debrief and record unresolved questions instead of leaving the document unused in an inbox.

Judge the investigation by whether it helps you make a defensible next decision. That may mean prioritising a measured bottleneck, ruling out a proposed infrastructure change or identifying where more evidence is required. No honest investigation can guarantee a ranking increase or a revenue uplift simply because a package was purchased.

Common questions

Must we buy Snapshot before Full Investigation?

No. The live service page allows the appropriate package to be selected directly. Choose according to the question and access required rather than treating the packages as compulsory steps.

Are performance fixes included in an investigation price?

Do not assume they are. Check the current service inclusions and any written proposal. Investigation findings and implementation work are different deliverables, and additional work needs its own agreed scope.

Can we compare suppliers using price alone?

Compare access depth, sampling, deliverables, exclusions and validation as well. A lower price for a smaller external review may be appropriate, but it should not be presented as the same work as an internal investigation.

Midoriweb expertise

Make the next technical decision with evidence.

From diagnosis to scoped development, connect the technical work with the result your business needs.

Midoriweb

Tell us about your project.

Tell Midoriweb what you want to build or improve. We will help define the development, support or integration work you need.

  1. 01 Project
  2. 02 Details
  3. 03 Contact
Project
What do you need help with?
What platform are you using?

Platform names and logos identify the services you use. Shopify · WooCommerce · Adobe Commerce · Magento