Skip to content
MAGENTO

Magento Performance Optimization: The Full Checklist

The checklist we run on slow Magento stores: caching, frontend weight, the database, module bloat, and the infrastructure underneath.

Shane Blandford
Shane Blandford · FOUNDERPUBLISHED · 3 MIN READ

Slow Magento is rarely one problem. Most stores we audit have the same five problems in different proportions, and the fix is working through them in order of payoff. This is the checklist we use, top to bottom.

1. Caching: Varnish and Redis, actually configured

The built-in full-page cache works, but Varnish is what the platform is designed for in production. Put Varnish in front, move sessions and the backend cache to Redis, and confirm the hit rate before you tune anything else. A store serving categories from PHP on every request will be slow no matter what you do downstream.

  • Varnish for full-page cache, not the file system
  • Redis for sessions and the default cache backend
  • Check the hit rate - a cache that misses is decoration

2. Frontend weight

The stock Luma frontend ships more JavaScript than most stores ever use. Hyvä replaces that stack and is the single biggest frontend win available to a Magento 2 store today - it's why we became a Hyvä partner. If a retheme isn't on the table yet: serve images as WebP or AVIF, lazy-load everything below the fold, and audit every third-party script tag. Marketing pixels accumulate; nobody ever removes them.

3. The database

Set indexers to Update by Schedule and make sure cron is actually running - a surprising number of slow admins trace back to a dead cron and a reindex backlog. Trim the log and report tables Magento grows silently, and read the slow query log before blaming hosting. Layered navigation and badly written module collections show up there first.

4. Third-party modules

The quietest performance cost in Magento is the extension pile. Every observer, plugin, and layout update runs whether you use the feature or not. The method is unglamorous: disable suspects on staging, measure, and keep a list. We regularly find double-digit TTFB improvements from removing modules the store stopped using years ago.

5. Infrastructure

Run a current PHP 8.x with OPcache sized properly, HTTP/2 or HTTP/3 at the edge, and a CDN for static assets. If you're on an old PHP because your Magento version demands it, that's not an infrastructure problem - that's an upgrade problem wearing a disguise.

Measure like a customer

Core Web Vitals are the scoreboard: LCP under 2.5 seconds on product pages, TTFB under 200ms. Test the pages customers actually hit - category, product, cart - not just the homepage, and test on a mid-range phone, because that's where your traffic is.

This is the checklist; the labor is the hard part. Our Magento performance optimization service runs it for you - Hyvä, Varnish, Redis, and MySQL tuning from the team that's done it since 2008. The store audit is free.

FAQ

What's a good TTFB for a Magento store?+
Under 200ms from cache. If cached pages are slower than that, the problem is configuration, not Magento.
Does Hyva actually make Magento faster?+
Yes, and it's mostly about what it removes: the legacy JavaScript stack the default frontend ships. It's the largest single frontend improvement available to a Magento 2 store.
Why is my Magento admin slow?+
Usually a reindex backlog from a dead cron, bloated log tables, or a third-party grid modification. All three are findable in an afternoon.
How often should performance be re-checked?+
After every extension install, theme change, and version upgrade - the things that made it slow the first time.
Shane Blandford

Shane Blandford

FOUNDER

Founder of Orange Collar Media, a Denver ecommerce agency behind 800+ Magento and Shopify builds. In Magento since version 1.x - building, rescuing, and supporting revenue-critical stores since 2008.

All posts by Shane Blandford

KEEP READING

Related from the Journal.

Your store can sell more. Let's find out how much.

Start a project