Magento speed test & optimization

Magento (now Adobe Commerce, with Magento Open Source alongside) is powerful and heavy. Most slow stores are running without Varnish, outside production mode, or with a pile of extensions adding JavaScript. Test a category page and a product page, then work down the list.

Try:

Free, no sign-up. Lighthouse on mobile and desktop at once, plus real-user Chrome data, in about 20–40 seconds.

What you can change on Magento

You control the server stack, caching, deploy mode, theme and extensions. That is a lot of levers, and the defaults are not tuned for speed. Each fix below lists the metric it usually moves; check that metric in your test result to pick where to start.

  1. TTFB

    Run in production mode

    Developer and default modes generate static files on the fly and show debug output. Production mode serves pre-deployed static content and is what live stores should use (bin/magento deploy:mode:set production).

  2. TTFB

    Use Varnish for the full-page cache

    Magento has a built-in full-page cache, but Adobe recommends Varnish for production. With a warm cache, category and product pages can be served without touching PHP.

  3. TTFB

    Set indexers to Update by Schedule

    “Update on Save” reindexes during admin saves and can slow the store under load. “Update by Schedule” runs reindexing via cron instead. Make sure cron is actually running.

  4. TBT

    Cut down the JavaScript

    The default Luma theme loads many RequireJS modules. Audit extensions that add scripts to every page, and consider a lighter frontend (for example a Hyvä-based theme or a headless storefront) if JavaScript dominates your Total Blocking Time.

  5. LCP

    Optimise catalogue images

    Serve product images in WebP or AVIF at the size the theme displays, through a CDN, and keep the main product image out of lazy loading.

  6. FCP

    Minify and merge CSS carefully

    Magento can minify CSS and JavaScript in production. Test after each change: merging and bundling JavaScript can make things slower over HTTP/2 rather than faster.

Common mistakes

  • Leaving the store in developer mode after a deploy.
  • Turning on JavaScript bundling without measuring; built-in bundling often produces one very large file.
  • Running cron irregularly, which leaves indexes and caches stale.

For platform-independent fixes, see the speed optimization checklist, and check page weight with the page size checker.

Questions people ask

Why is my Magento store slow?

The most common causes are no Varnish full-page cache, the store not running in production mode, under-powered hosting, and extensions that add JavaScript to every page. A slow server response in the test points to the first three.

Does Magento need Varnish?

It isn’t required, but Adobe’s documentation recommends Varnish as the production full-page cache because it is much faster than the built-in file cache.

Is Hyvä faster than Luma?

Hyvä themes replace Luma’s RequireJS and Knockout frontend with far less JavaScript, which usually improves Total Blocking Time and LCP. It is a paid theme and a frontend rebuild, so measure first to confirm JavaScript is your bottleneck.