An independent, evidence-based review of exactly what's making your Magento store slow - measured, not guessed. You get your real Core Web Vitals, TTFB and throughput numbers, the root cause behind each, and a prioritised roadmap to fix them.
A Magento performance audit is an independent, evidence-based review of your store's speed: Core Web Vitals (LCP, INP, CLS), TTFB and back-end throughput, measured on your real store and traced to root cause. You get a severity-rated report and a prioritised, costed fix roadmap. It starts at $2,200, with the report delivered in about 7 business days.
A Magento performance audit measures how fast your store actually is for real users, not just a synthetic score in a dashboard. The core metrics are Google's Core Web Vitals - Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS) - plus server response time (TTFB) and back-end throughput under load. I measure both lab data (a controlled test) and field data (what real visitors experience, from the Chrome UX Report), because a store can look fine in a lab and still fail for the people paying you.
How long the main content - usually the hero or product image - takes to render; "good" is 2.5s or less.
Responsiveness to taps and clicks across the whole visit; "good" is 200ms or less, and much harder to pass on Luma.
Visual stability - how much the layout jumps as the page loads; "good" is 0.1 or less.
Time to first byte, the server's share of the delay - on Magento, usually where the real problem lives.
How many requests per second the store sustains before response times degrade under real traffic.
Slow Magento is rarely one thing. It's normally three or four overlapping problems, which is exactly why guessing is expensive and measuring is cheap. A speed audit separates cause from symptom, so you spend engineering budget on the fixes that actually move the numbers rather than the ones that feel productive. These are the causes I find most often, roughly in order of impact.
For most Magento 2 stores the biggest slice of load time is TTFB - the time your server spends before the browser receives a single byte. No amount of front-end tuning fixes a 1.5-second TTFB; you have to fix the back-end. A performance audit profiles the request path to find where those milliseconds go: PHP execution, the database, the cache, and third-party API calls made during page render. The usual wins are a correctly working Varnish full-page cache, Redis for cache and sessions, killing N+1 queries, moving blocking API calls out of the render path, and right-sizing PHP-FPM and OPcache. TTFB is one of the first things I check, because it sets the floor for every other metric.
The audit is evidence-based and non-invasive. I work on a copy of your code and an anonymised copy of the production database, so nothing runs against your live store and customers keep shopping while I diagnose it. I combine synthetic testing, real-user field data and back-end profiling, because each catches problems the others miss. Every finding in the report traces back to a measurement or a specific line of code, never an opinion.
You hand over the source code as an archive or read access to the repository, plus an anonymised copy of the production database (no real sensitive data) and credentials to test accounts for every integration. We talk through your goals and which pages hurt most. Nothing runs against your live store, so there is no downtime and customers keep shopping while I work.
I run Lighthouse and PageSpeed against your key templates and pull real-user field data from the Chrome UX Report, then use WebPageTest filmstrip and waterfall views to see exactly what blocks rendering and in what order. You get your true Core Web Vitals - lab and field side by side - instead of a single dashboard number that hides the problem.
New Relic and Blackfire trace the request path to find the slow PHP paths and database calls behind a high TTFB, while the MySQL slow-query log and n98-magerun2 surface expensive queries, indexer state and cache-backend misconfiguration. This is where most of the milliseconds hide, so it is where I spend the most time and where the biggest wins usually come from.
k6 drives synthetic traffic at the store to measure how many requests per second it sustains and the exact point where response times start to degrade. You learn where your store falls over under real traffic - before a campaign or a sale finds that ceiling for you, in front of paying customers.
PHPStan and phpcs tie each performance symptom back to the exact custom code that causes it, so every finding is traceable to a line, not an opinion. I separate cause from symptom throughout, which is what lets the roadmap put your budget on the fixes that actually move the numbers rather than the ones that just feel productive.
You get a severity-rated written report with your real numbers and a prioritised, costed fix roadmap, followed by a 90-minute live session where we walk the results together and I answer your team's questions. You leave able to act on it - with your own team, another agency, or with me - and nothing in the document is a sales pitch.
The front-end theme sets a hard ceiling on how fast your store can be, and no amount of back-end tuning lifts you above it. Luma - Magento's default theme - ships megabytes of RequireJS, Knockout and jQuery that block the main thread, which makes a "good" INP genuinely hard to reach on a busy store. Hyvä replaces that stack with lightweight Alpine.js and Tailwind, cutting JavaScript by roughly an order of magnitude and starting from a far better position on LCP and INP. The audit tells you honestly which situation you're in: whether targeted fixes can get your Luma store to "good" Core Web Vitals, or whether you've hit Luma's ceiling and a Hyvä migration is the cheaper long-term answer. Headless (PWA Studio or a custom front-end) is a third path with its own trade-offs, and I audit those too.
The deliverable is a document you can act on - with your own team, another agency, or with me - not a sales pitch. Every finding is severity-rated and tied to hard data, with an effort estimate so you can weigh cost against impact. The point is to let you make decisions on facts, not opinions.
The audit ends with a roadmap, and you decide who executes it - the whole point is that you're not locked in. Many clients take the report to their existing team or agency and implement it themselves; the findings are specific enough to act on directly. If you'd rather I do the work, I can implement the fixes or lead your team through them, and I'll re-measure afterwards so the improvement is proven, not assumed. Illustrative outcomes from this kind of work look like TTFB dropping from ~1.4s to under 300ms once Varnish and Redis are configured correctly, or LCP going from 4.1s to 0.9s after critical-path and image fixes - the exact numbers depend on where your store starts.
Get a Magento performance audit from $2,200, with your real Core Web Vitals and a prioritised fix roadmap in about 7 business days. Start with a free 30-minute call - tell me what hurts and I'll tell you whether and how I can help.