What's new
kishansavaliyakb@gmail.com
Chat on WhatsApp
Toggle Nav
My Cart

Magento performance checklist — 30+ items I run on every audit

Every item is one I have personally run on a live Magento 2.4.4 — 2.4.9 store and seen move the needle on Core Web Vitals, TTFB, or admin response time. Copy this. Print it. Use it on your next audit.

Magento 2 performance checklist (30+ items)

This Magento performance checklist is the working list I run when I audit a Magento 2.4.4 — 2.4.9 store. It is not "best practices in general" — it is the specific 30+ items I have seen actually move Core Web Vitals, TTFB and admin response time on real stores. Every item is one CLI command, one config flag, or one file change. Skip nothing.

The items are grouped by layer — frontend, backend / PHP, server, caching, database — because that is how you triage performance. You fix the slowest layer first. For most stores in 2026 the slowest layer is the frontend (Luma's JavaScript), so that section is longest. If you have already moved to Hyvä, jump straight to backend.

Frontend optimisation checklist

The frontend is where most Magento stores lose Core Web Vitals. Luma ships ~300 KB of compiled JavaScript on a cold PDP, plus RequireJS overhead, plus jQuery, plus Knockout.js bindings, plus an LESS pipeline. Every item below cuts JS, CSS, or critical-path render time.

  1. Move to Hyvä if you can. A Hyvä migration is the single biggest frontend win — ~90% less JavaScript on the wire, no RequireJS, no jQuery, no Knockout. See my Luma → Hyvä migration playbook.
  2. Enable Magento's production mode. Run bin/magento deploy:mode:set production. Never run a live site in developer mode.
  3. Pre-compile static content. Run bin/magento setup:static-content:deploy -f on every deploy. Never ship without static deploy.
  4. Turn on JS / CSS minification in Stores → Config → Advanced → Developer (production mode only). On Hyvä this is a no-op; Hyvä ships pre-minified.
  5. Bundle JS off; merge JS off. Counter-intuitive on Luma — modern HTTP/2 means many small files beat one giant bundle. Keep both off unless you are on HTTP/1.1.
  6. Defer non-critical CSS. Use a module like mage2kishan/module-advanced-seo with deferred-CSS support — but never defer requirejs/require.js; PageBuilder's inline require.config() on the homepage breaks if RequireJS is async.
  7. Preconnect to critical origins. Add <link rel="preconnect"> for fonts, analytics, and CDN in default_head_blocks.xml.
  8. Self-host fonts. Move Google Fonts / Adobe Fonts to pub/static, use font-display: swap, and preload the one font weight used for the LCP element.
  9. Convert product images to WebP. Magento 2.4.7+ ships native WebP support; older versions need an image-pipeline module. WebP cuts image weight 25–35% vs JPEG.
  10. Resize images on the server. Use Magento's image resizer (catalog:images:resize) and serve a tight responsive set, not a single 2000px hero.
  11. Lazy-load below-the-fold images. Add loading="lazy" to gallery, related-products, and footer images. Never lazy-load the LCP image.
  12. Reserve space for images (CLS). Always set width and height attributes on <img>. Reserve aspect-ratio for gallery slides.
  13. Defer Google Tag Manager / Clarity. Move third-party tags to defer or load after requestIdleCallback. On Luma this typically cuts TBT by 800–1,200ms.
  14. Strip Font Awesome if unused. Use a <head><remove> in your theme to drop unused icon CSS — see my LCP / INP / CLS recipe.
  15. Inline critical CSS. Extract the above-the-fold CSS, inline it in <head>, defer the rest. On Hyvä this is built-in.

Backend / PHP optimisation checklist

PHP-side wins are smaller individually but they add up to a meaningful TTFB drop. The big two are OPcache and dependency injection compilation. Everything else is hygiene.

  1. PHP 8.3 minimum, 8.4 preferred. Magento 2.4.7+ supports PHP 8.3; 2.4.9 supports 8.4. PHP 8.4 is 8–12% faster than 8.2 on real Magento workloads.
  2. OPcache tuned. Set opcache.memory_consumption=512, opcache.max_accelerated_files=130000, opcache.validate_timestamps=0 in production. Validate timestamps must be off in prod — leaving it on costs you ~15% per request.
  3. OPcache JIT on. opcache.jit=tracing, opcache.jit_buffer_size=128M. Measure before/after — JIT helps catalog-heavy stores.
  4. Realpath cache tuned. realpath_cache_size=10M, realpath_cache_ttl=600.
  5. DI compile on every deploy. bin/magento setup:di:compile. Never ship without it — production mode requires it.
  6. Composer optimised autoload. composer dump-autoload --optimize --apcu with APCu enabled. Cuts autoload overhead 5–10%.
  7. APCu on for Magento's app cache. Set apc.enabled=1, apc.shm_size=128M in php.ini. Magento uses APCu transparently when available.
  8. PHP-FPM pool sized correctly. pm=static or pm=dynamic with pm.max_children = (available_RAM / avg_process_size). Most stores undersize this.
  9. Disable unused Magento modules. Run bin/magento module:status, disable every module you do not use. Adobe Stock, Amqp, Inventory* (if not multi-source), TwoFactorAuth (if SSO), etc.
  10. Remove dev-only logging in prod. No $this->logger->debug() on hot paths. Set system/log/enabled=0 in env.php for noisy modules.

Server and infrastructure checklist

The server layer is where you stop the work from happening in the first place — Varnish serves a cached page in 5ms regardless of how slow your PHP is. These items are about getting Magento's traffic served by something other than PHP.

  1. Varnish in front of Magento. Magento ships official VCL — use it. Varnish + Magento full-page cache is the single biggest server-side win.
  2. HTTP/2 on (HTTP/3 if available). Both work with Magento. HTTP/2 multiplexing especially helps Luma's many-small-files pattern.
  3. Brotli compression on. Brotli beats gzip 15–25% on HTML / CSS / JS. Configure in nginx with brotli_static on; brotli on; brotli_comp_level 6;.
  4. Redis / Valkey for sessions and default cache. Move sessions and the default cache from filesystem to Redis. cache_backend = Redis db 0, page_cache backend = Redis db 1, session_save = Redis db 2 — never share databases.
  5. OpenSearch tuned. 4 GB heap minimum, dedicated host for stores over 50K SKUs. Magento 2.4.7+ requires OpenSearch 2.x; 2.4.9 supports OpenSearch 2.12+.
  6. CDN for static assets. Cloudflare, Fastly, BunnyCDN — anything fronting pub/static and pub/media. Cuts global TTFB and lifts LCP for international traffic.
  7. HTTP keep-alive on. nginx keepalive_timeout 65; minimum. Closes connections too aggressively kill repeat-visit performance.

Caching and Varnish checklist

Caching is where Magento's architecture pays you back — the platform is built around aggressive caching and most performance problems are someone accidentally breaking that contract.

  1. Full Page Cache (FPC) on Varnish, not built-in. In env.php set 'system' => ['default' => ['system' => ['full_page_cache' => ['backend' => 'Magento\\Framework\\App\\Cache\\Backend\\RemoteSynchronizedCache']]]] — but really just configure Varnish in Stores → Config → Advanced → System.
  2. customer-data cache hot. Magento's private-customer JS cache (cart count, name, wishlist) must be served via customer-data, never server-rendered into a cacheable block. Server-rendering customer-specific content breaks FPC for everyone.
  3. Cache tag warming. After a deploy, hit the top 100 PDPs / PLPs to pre-warm Varnish. Use the panth:cache:warmer approach or a simple sitemap-driven curl loop.
  4. ESI for the mini-cart only if needed. ESI in Varnish costs you a sub-request — only use it for blocks that genuinely change per visit. The mini-cart's customer-data approach is faster.
  5. Block cache lifetime set. Long-lived blocks (footer, header, nav) should have cache_lifetime ≥ 86400. Short-lived blocks (cart) should be 0 (do not cache server-side).
  6. Browser cache headers. Static assets in pub/static get Cache-Control: public, max-age=31536000, immutable. Versioned via Magento's static signature.

Database and indexer checklist

The database layer is where most "this store was fast and then slowed down over time" stories live. Indexes drift. Schedules go stale. Cron stops running silently. Watch these closely.

  1. Slow query log on. MySQL slow_query_log=ON, long_query_time=1, log_queries_not_using_indexes=ON. Read it weekly.
  2. Indexers on schedule, not save. Set all indexers to "Update on Schedule" via bin/magento indexer:set-mode schedule. Saving products with on-save indexers can take 30+ seconds per save.
  3. Cron running every minute. Magento's indexers, queues, and reindex jobs depend on cron. * * * * * bin/magento cron:run in the magento user crontab. Verify with bin/magento cron:status.
  4. InnoDB buffer pool sized. innodb_buffer_pool_size = 70–80% of RAM on a dedicated DB host, lower on shared. The single most important MySQL setting for Magento.
  5. Tablespace per file. innodb_file_per_table=1 — never share tablespace across all tables in production.
  6. Query cache off. MySQL 8.0 removed it; on MariaDB ensure query_cache_type=0. The query cache hurts Magento more than it helps.
  7. Asynchronous order processing. Magento 2.4.x supports async order placement via message queues — turn it on for stores over 1,000 orders/day.
  8. Clean log tables. customer_log, customer_visitor, report_event, session all grow unbounded. Schedule cleanup in System → Config → Advanced → System.
  9. Reindex audit. Run bin/magento indexer:status weekly. Any indexer stuck in processing with no PID is a stale lock — indexer:reset and rerun.

How to use this checklist in an audit

Treat the list as a triage tool, not a sequential script. The order I use it on a real audit: first run a Lighthouse + WebPageTest measurement against the homepage, a PDP, and a PLP — capture LCP, INP, CLS, TBT and TTFB. Then look at the slowest metric and jump to the matching section. LCP slow? Frontend section. TTFB slow? Backend + server. INP slow? Frontend, specifically items 1, 6, 13. CLS slow? Items 11, 12.

For each item I tick, I also record the measurable before / after. A real performance audit deliverable is not "I did 47 things" — it is "LCP went from 4.2s to 1.8s, INP from 380ms to 140ms, here is the receipts JSON from CrUX". That receipts approach is how I run my Magento performance optimization service and how I track the live TTFB optimization case study.

If you want me to run this checklist on your store, the audit is fixed-fee $499 (~20h @ $25/hr) and lands as a written report with prioritised fixes. The full performance sprint that ships the fixes is $2,499 (~99h @ $25/hr).

Frequently asked questions

Is this checklist valid for Magento 2.4.9?

Yes. Every item works on Magento 2.4.4 through 2.4.9, on Magento Open Source, Adobe Commerce, and Mage-OS. PHP version requirements differ by Magento version — 2.4.7+ wants PHP 8.3, 2.4.9 supports 8.4.

Will following this checklist pass Core Web Vitals?

On most stores, yes — especially items 1 (Hyvä), 17 (OPcache), 26 (Varnish), 29 (Redis), 40 (indexers on schedule). I have not seen a store fail Core Web Vitals after running all 40+ items on a Hyvä build.

What about Hyvä — do I still need this checklist?

Hyvä handles the frontend section automatically. The backend, server, caching and database sections still all apply. Hyvä is roughly half the checklist; the other half is your job.

Which item gives the biggest single win?

For Luma stores: Hyvä migration (item 1). For Hyvä stores already in place: Varnish full-page cache (item 26) and OPcache tuning (item 17). For stores already on Varnish + Hyvä: database indexer mode (item 40).

Should I run all these items on staging first?

Yes. Every config change in items 17–24, 26–32 should land on staging first with measurements before / after. The frontend items (1–15) are safer to roll forward in small batches.

Does this work on Adobe Commerce Cloud?

Most items apply. Adobe Commerce Cloud locks down some infrastructure (Varnish, Redis, OpenSearch are managed) but the Magento-level items (frontend, indexers, modules, DI compile) all work the same.

How long does running the full checklist take?

The audit pass (measure + tick items) is about 20 hours of work. The fix pass (actually implementing) is 60–100 hours depending on how many items the store fails. Hence my fixed-fee structure: $499 audit, $2,499 sprint.

What tools do you use to measure each item?

Lighthouse (Docker, not PSI API — rate limits), WebPageTest, CrUX Dashboard, Magento's bin/magento cache:status + indexer:status, MySQL slow query log, New Relic if available, php-fpm status page, and Varnishadm.

Can you turn this into a downloadable PDF?

Working on it. For now, this page is the canonical version — copy it, share it, use it. License is "do whatever you want, just don't repackage and sell it".

Want this checklist run on your store? Written audit + prioritised fix list, fixed-fee $499 audit · $2,499 sprint · ~99h @ $25/hr.

Book the audit