Magento 2 Performance Optimisation Checklist

Slow Magento 2 stores are rarely slow for a single reason. The fastest route to meaningful performance improvement is profiling — measuring what is actually slow before deciding what to fix. This is the checklist we run on every Magento performance engagement, ordered by the sequence we follow and the impact we typically find.

Step 1: Establish Baselines Before Touching Anything

Before making any change, capture your current state. Without a baseline, you have no way to know whether a change helped, hurt or did nothing. Measure: Core Web Vitals (LCP, INP, CLS) from real users via Google Search Console; Time to First Byte (TTFB) from multiple locations; server response time for key page types (home, category, product, cart, checkout); database query time for the top 20 slowest queries; and Varnish / FPC hit rate.

Step 2: Infrastructure Audit

• Is Varnish (or another full-page cache) in place and configured correctly for your catalogue and store views?
• Is Redis configured for both session storage and the Magento cache backend (not the file system)?
• Is Elasticsearch / OpenSearch running and indexed? Is it being used for catalogue search and layered navigation?
• Are PHP-FPM worker pool settings correctly sized for your traffic pattern?
• Is the web server (Nginx/Apache) serving static assets with appropriate cache headers?
• Are CDN and image optimisation in place? Unoptimised images are one of the most common LCP killers.

A misconfigured Varnish that is bypassed for most requests is often the single biggest performance issue on Magento stores. Check your hit rate — it should be above 80% for a healthy store in normal trading.

Step 3: Database Query Profiling

The Magento database is the most common performance bottleneck on stores with large or complex catalogues. Use the Magento Profiler, New Relic or a MySQL slow query log to identify the slowest queries, then investigate each one.

• Run EXPLAIN on slow SELECT queries — missing indexes are common, especially on EAV attribute tables
• Check for N+1 query patterns in custom modules — particularly in product collection loading
• Look for unbounded queries that load entire collections without pagination or limits
• Review any custom reports or dashboard widgets that run heavy aggregation queries on the main database
• Check log table sizes — core_url_rewrite, report_event and quote tables often grow unchecked and slow down maintenance operations

Step 4: Magento Configuration Review

• Production mode enabled (not developer mode — a surprisingly common oversight on staging-promoted stores)
• All Magento caches enabled and warming correctly after deploys
• Flat catalogue tables enabled for large catalogues (category and product flat)
• Asynchronous indexing configured for high-write scenarios
• Cron jobs running on schedule — stuck or overloaded crons cause widespread secondary performance problems
• Email queue processing asynchronous, not inline
• JavaScript and CSS merging/bundling evaluated — in some configurations these make performance worse

Step 5: Extension Audit

Third-party Magento extensions are one of the most common sources of performance problems. Each installed extension adds potential for slow observers, blocking API calls, additional database queries and JavaScript weight. A store that has accumulated extensions from multiple agencies over years is particularly vulnerable.

• Audit every installed extension — is it still in use? Is it actively maintained? Is there a more performant alternative?
• Profile which extensions contribute most to page render time using the Magento Profiler or Blackfire
• Check for extensions that make synchronous external API calls on page render
• Look for extensions that disable or override Magento's full-page cache for more pages than necessary

Step 6: Frontend Performance

• Audit third-party JavaScript tags (tag managers, analytics, chat widgets) — each one adds to page weight and can block rendering
• Implement lazy loading for below-the-fold images
• Check LCP image is preloaded correctly and not lazy-loaded
• Audit CSS delivery — unused CSS from third-party themes is common and adds significant weight
• Consider a progressive web app (PWA) storefront if you need maximum frontend performance

Step 7: Load Testing Before Peak

A store that performs well in normal trading can still fail during a sale event. Load testing with a realistic traffic profile (not just concurrent users, but realistic journey mixes across browse, add to cart and checkout) should be part of every peak trading preparation.

Tools: k6, Gatling or Locust. Profile during load testing as well as measuring response times — the bottleneck under load is often different from the bottleneck in normal trading.