Skip to content
The Architecture Brief

What a 40-Point Magento Performance Audit Actually Contains

Every checkpoint in a 5-day Magento Performance Audit, ungated — 40 points across eight areas, from Core Web Vitals and caching to the checkout path.

Process & Transparency 7 min read

Most "Magento audits" are a Lighthouse screenshot and a sales call.

You get a red score, a vague "your site is slow," and a quote. Nobody tells you what was checked, why each thing matters, or which fix moves revenue first. That's not an audit. That's a lead magnet wearing a lab coat.

So here's the whole thing. Below is every category my 5-day Performance Audit covers — 40 checkpoints, grouped into eight areas — with one line on what each one catches. No gate, no email wall. If you have a developer and a free afternoon, you can run a third of this yourself. The other two-thirds is where senior judgment earns its $1,500: not finding problems, but ranking them against each other so you fix the one that's actually costing you checkouts.

The frame: 5 days, one PDF, ranked by impact

Before the list, the shape of the engagement, because transparency starts here:

  • $1,500 flat. No hourly creep. You know the number before I start.
  • 5 working days. Day 1–3 is measurement; Day 4 is synthesis; Day 5 is the write-up and a 1-hour call.
  • The deliverable is a PDF action plan, not a slide deck of complaints. Every finding has a severity, an estimated effort, and a place in a priority roadmap — quick wins separated from structural work.
  • It ends with a decision, not a retainer pitch. Plenty of audits surface fixes you can hand straight to your own team. If the work needs an architect, I'll say so. If it doesn't, I'll say that too.

Now the 40 points.

1. Frontend & Core Web Vitals

This is what Google measures and what your customer feels.

  1. LCP element on the home page and your top 3 landing templates — target under 1.5s on a throttled 4G connection, not on your office fibre.
  2. CLS — layout shift from unsized images, injected banners, and late web fonts (the checkout that jumps as you tap "Pay").
  3. INP / main-thread blocking — long tasks from third-party JavaScript that make the page look ready before it can respond to a tap.
  4. Image strategy — WebP/AVIF delivery, responsive srcset, explicit dimensions, and real lazy-loading below the fold.
  5. CSS & JS delivery — critical CSS, bundling/minification, RequireJS bundling, and deferred non-critical scripts.

2. Caching layers

Where most "Magento is just slow" verdicts turn out to be wrong.

  1. Full Page Cache backend — Varnish vs. the built-in cache, and the actual hit ratio under real traffic.
  2. Redis configuration — separate instances for cache and sessions, with a sane maxmemory and eviction policy (not one Redis doing everything).
  3. ESI / hole-punching — are dynamic blocks (cart, customer name) punched correctly, or is one mini-cart busting the whole page cache?
  4. Cache invalidation — over-broad cache tags that purge half the catalog when one product changes.
  5. Browser cache & static versioning — long max-age plus fingerprinted asset URLs so repeat visits cost nothing.

3. PHP & application configuration

The cheap wins live here. They're cheap because most sites get them wrong.

  1. PHP version & extensions matched to your Magento/Adobe Commerce version.
  2. OPcache enabled and sized, validate_timestamps off in production, and a realpath cache that isn't choking on Magento's file count.
  3. Deploy mode = production, DI compiled, static content deployed ahead of time — not generated on the first request.
  4. Composer autoloader optimized (authoritative classmap), not resolving classes the slow way on every request.
  5. PHP-FPM pool sizing against real per-request memory, so you're not swapping under load or starving at 20 concurrent users.

4. Database & indexing

  1. MySQL/MariaDB version and an InnoDB buffer pool actually sized to your working set.
  2. Indexer mode = "Update by Schedule," plus a check for stuck or invalid indexers silently serving stale data.
  3. Slow query log review — the top offenders, missing indexes, and full table scans on hot paths.
  4. Table bloatquote, log, and report tables growing unbounded because nobody scheduled the cleanup cron.
  5. Catalog denormalization — whether flat catalog helps or hurts at your specific SKU count (it's not always the right call).

5. Catalog, search & category pages

  1. Catalog weight — products per category, page size, and pagination strategy on your biggest listing pages.
  2. Elasticsearch/OpenSearch — version, cluster health, and relevance config (a slow search box is a slow conversion path).
  3. Layered navigation — the aggregation cost of your filterable attributes; the "filter by color" that runs six expensive queries.
  4. Category TTFB on a cache miss — what a logged-in customer with a cart actually waits for, not the cached anonymous view.
  5. URL rewrites table — size, duplicates, and rotting rewrites from products deleted three years ago.

6. Third-party extensions & custom code

The most common single cause of a slow Magento store is the 47th extension.

  1. Module inventory — count, vendor, last-updated date, and modules that are "disabled" but still loaded.
  2. Plugin (interceptor) overheadaround plugins stacked on hot methods, each one wrapping the last.
  3. N+1 query patterns in custom blocks and collections — the loop that loads a product model 200 times to render one page.
  4. Conflicting overrides — preference chains and rewrites where two modules fight over the same class.
  5. Layout XML bloat — widgets and blocks rendered server-side and then hidden with CSS.

7. Infrastructure, hosting & ops

  1. Web server config — Nginx tuning, HTTP/2 or /3, Brotli/gzip, and a TLS setup that isn't adding a round-trip.
  2. CDN in front of static and media, with cache-control headers that agree with the origin instead of fighting it.
  3. Cron health — a single correct cron:run, no overlapping jobs, and a job schedule that isn't backed up by hours.
  4. Message queue consumers — async indexing, email, and integration consumers actually running and supervised, not died-on-deploy.
  5. Static & media pipeline — deploy strategy, local vs. object storage, and whether images are optimized once or never.

8. Checkout, integrations & conversion path

The 1% that decides whether the other 39 points were worth measuring.

  1. Checkout step timing — blocking AJAX on shipping and payment estimates, the spinner between "Continue" and the next step.
  2. Third-party scripts on checkout — tag managers, chat widgets, and A/B tools competing for the main thread at the worst possible moment.
  3. Payment & shipping API resilience — timeouts and graceful degradation when a carrier's API has a bad day.
  4. API response times — GraphQL/REST latency for any headless storefront, PWA, mobile app, or ERP integration hanging off the platform.
  5. Security bottlenecks that masquerade as performance — admin and REST rate limiting, bot/crawler load hammering uncached pages, and WAF rules. (This is the security bottleneck report that ships alongside the speed findings.)

Five you can check before you ever talk to me

Transparency isn't only about showing the list — it's about you not needing me for the easy ones. Before booking anything, have your developer confirm:

  • Deploy mode is production (bin/magento deploy:mode:show). If it says default, you've found real money in five minutes.
  • Indexers are "Update by Schedule," not "Update on Save."
  • OPcache is on and validate_timestamps is 0 in production.
  • There's a Full Page Cache (Varnish ideally) and it's actually hitting.
  • The quote table isn't sitting at several million abandoned-cart rows.

If all five are already right, you have a competent team and the audit will go straight to the structural findings. If two or three are wrong — which is the norm — you've just seen exactly the kind of thing I'm looking for, multiplied across 40 points and then ranked by what it's costing you.

Why publish the whole checklist?

Because the value was never the list. A good developer could reconstruct most of it. The value is the 5 days of measuring your store under your traffic, and the judgment to say: fix these three things this month, schedule these five for next quarter, and ignore the rest until you've grown into them.

A store that's slow because of an unindexed category page needs a different first move than one that's slow because of a third-party loyalty extension — even though both score red in Lighthouse. Telling them apart, in order of revenue impact, is the work.


Want this run on your store? The Performance Audit is $1,500 flat, 5 working days, and ends with a prioritized PDF action plan and a 1-hour strategy call — findings you can hand to your own team or to me. Book the audit →

Not ready to book? Send me your store's details — I'll tell you straight whether an audit is even worth your money.

Senior, evidence-backed, honest

Want this measured on your store?

A senior architect measures your store under real traffic and hands you a roadmap ranked by revenue impact — the Performance Audit, $1,500 flat.