Why is my Magento store slow?

How do you measure where the time goes?

Before you change anything, you measure. Otherwise you will not know afterwards what it achieved.

There are two parts:

• The server. How long until the first byte of the page arrives? That is the work of Magento, PHP, the database and the cache.
• The browser. How long after that until the page is usable? That is the work of the theme: scripts, styles, fonts and images.

Measure a few fixed types of page: the homepage, a category, a product, the cart and the checkout. Each behaves differently.

Which figures do you look at?

On the server, the time to first byte, per type of page and with and without cache.

In the browser, Google’s Core Web Vitals: how quickly the largest element is on screen (LCP), how quickly the page responds to a click (INP) and whether the layout shifts while loading (CLS). You measure them in a test setup and, where Google has seen enough visitors, with real visitors too. The second counts most: a test on a fast laptop says little about a customer on an old phone.

Is the page cache doing its job?

This is the cause we find most often, and usually the quickest win.

Magento can serve pages ready-made from a cache. Adobe strongly recommends Varnish for that in production; the built-in cache is much slower. But the cache only works if the page can be cached. If one block on a page is marked as uncacheable, that applies to the whole page. One module doing that on the product page, and every visitor to every product page goes through PHP and the database.

If such a marker sits in the general layout, the shop caches no page at all. That happens more often than you would think.

Are cron and the indexers keeping up?

Magento keeps indexes for prices, stock, categories and search. They can recalculate on every change in the admin, or on a schedule through cron.

If they recalculate on every change, the admin gets slow as soon as a lot changes, for example with an import from a supplier. If they are on a schedule but cron is not running properly, prices and stock in the shop fall behind. Both show up when we measure whether cron keeps up.

Are the modules doing too much?

A module is code that runs along at certain moments. A good module does little. A bad one makes an external call or a heavy query on every page.

We measure what each module costs. Then we discuss what can go, what needs to change and what is better rebuilt. How we build modules ourselves has its own page.

Is it the frontend?

Magento’s standard theme loads a lot of JavaScript. You notice that mostly on phones. What helps:

• Bundling scripts and deferring what is not needed straight away
• Taking a critical look at third-party scripts: chat, tracking, reviews
• Images in WebP or AVIF, at the size the screen asks for, and only loading what comes into view

Sometimes a lighter theme such as Hyvä is the biggest step. That does mean the theme and part of the modules get rebuilt. First we get what can be had without a new theme.

Is the hosting set up for Magento?

Magento asks more than an ordinary website. Too few PHP processes, no OPcache, a database that has not been tuned or a search engine running somewhere other than the shop: it all adds up. So does a database full of old carts, logs and expired sessions.

If we host the shop, we fix that on the server. If you host elsewhere, we describe what your hosting company needs to change.

How do we approach it?

Measure, fix, measure again. You get the measurements before and after yourself, with our conclusion, and no promised figures up front. More on Magento speed and Magento hosting.