“The site is slow” is the vaguest expensive sentence in ecommerce. A structured performance audit turns it into a list of fixable causes in a day. Magento slowness almost always decomposes into server time (TTFB), frontend weight, or both - and the order you investigate in saves hours. Here is the triage sequence we run.
Step 1: Split Server from Frontend
Load the homepage in browser dev tools and read the waterfall: how long until the first byte versus how long until the page is usable?
- TTFB over 600ms cached (over ~1.5s uncached) - server-side problem, go to step 2
- Fast TTFB, slow page - frontend problem: JS weight, images, third parties, go to step 4
- Usually both. Fix TTFB first; it gates everything
Step 2: The Cache Layer
Full page cache is Magento’s first line of defence. Check:
- Is FPC actually enabled (
bin/magento cache:status) - on more inherited stores than you would believe, it is not - Hit ratio: in Varnish logs or Fastly analytics. Below 90 percent on catalog pages means cache is leaking - hunt for blocks marked
cacheable="false"in layout XML (one such block disables FPC for the whole page), excessive personalised blocks, and session creation on every request - Redis running for cache and sessions (not files), with
maxmemoryand eviction policy set sanely
Step 3: Database and Indexers
- Slow query log for a day; anything frequent over 500ms is a finding
- Indexer modes on schedule, mview backlogs near zero,
url_rewriteand log tables not bloated (see our database maintenance post) - Cron healthy - stale indexers cause wrong data and wasted query work
Step 4: The Frontend
- JavaScript: bundle analysis on Luma, or honest assessment - Luma’s RequireJS stack on mobile is the common ceiling. If INP and JS parse times dominate, the conversation becomes Hyva migration, not micro-optimisation
- Images: WebP/AVIF with srcset? Hero preloaded? A single uncompressed banner outweighs a week of CSS tuning
- Third-party scripts: tag manager audit. Every pixel costs main-thread time; defer, consent-gate, and delete the ones nobody reads reports from
Step 5: Hosting Reality Check
Magento is resource-hungry by design. The honest minimum for production: 2+ vCPU, 4GB+ RAM for PHP alone, plus separate resources for MySQL, Redis, OpenSearch - ideally separate services entirely. A store sharing one small VPS for everything has found its ceiling. APM data (New Relic, Tideways) showing time split across PHP, database and external calls makes this conversation evidence-based instead of speculative.
Turning Findings into a Plan
We bucket every finding: quick wins (days), structural work (weeks), strategic change (Hyva, hosting re-architecture). Report with measured baselines so improvements are provable.
The sequence - TTFB, cache, database, frontend, hosting - works because each layer gates the ones after it. Audit in order, fix in order, measure between steps. Performance work done that way is one of the few investments in ecommerce that reliably pays for itself in conversion.