When a store starts feeling sluggish, the conversation usually jumps straight to solutions. Someone suggests a new theme. Someone else says Magento is just heavy. A third person mentions headless. All of that costs money, and none of it is based on a measurement.
We look at a lot of slow Magento stores, and the pattern is remarkably consistent. Four causes account for most of the lost time, they are all boring, and they are all fixable without touching how your store looks or works. Here is how to check each one.
1. The store is not running in production mode
Magento has three modes. Developer mode compiles code on every request and writes verbose logs. Default mode sits in between. Production mode uses precompiled code, cached configuration and minified assets. The difference is not subtle: a store in developer mode can be several times slower on every single page load.
It happens more often than you would expect. Someone switches to developer mode to debug an issue, the issue gets solved, and nobody switches it back. Months later the store is slow and nobody connects the two.
2. Caching is off, or configured to do nothing
Magento renders a category page by assembling it from dozens of database queries. Full page cache exists so it only has to do that once. Without it, every visitor triggers the full assembly again.
The failure mode here is rarely that someone disabled caching on purpose. It is that caching was disabled temporarily to reproduce a bug, or that the cache backend was never properly configured in the first place, so Magento falls back to writing cache files to disk instead of using Redis or Varnish.
A store on file-based caching with a busy catalogue is doing an enormous amount of unnecessary disk work. It will look fine in a quiet moment and fall over during a campaign.
- Check the cache status:
bin/magento cache:status. Everything should be enabled. - Check what backend it uses: look for Redis in
app/etc/env.php, not the default file backend. - Check whether Varnish is actually in front of the application, not just configured in the admin.
3. Indexers have fallen behind
Magento precomputes prices, stock, category membership and search data into index tables. Those tables are what makes a category page fast. When indexing falls behind, Magento has to work harder on every request, and in some cases customers see stale prices or products that should not be there.
The usual cause is the indexer mode. Set to Update on Save, every product change triggers a reindex, which is fine for a store with 200 products and catastrophic for one with 40,000. Set to Update by Schedule, reindexing happens in the background through cron, which is what you want. But that only works if cron actually runs.
4. Images were never optimised
This is the least technical item on the list and often the largest single win. Product photos get uploaded at whatever size they came out of the camera, Magento scales them in the browser, and every visitor downloads several megabytes to see something displayed at 400 pixels wide.
Modern formats make this worse to ignore. A photo served as WebP or AVIF is typically a fraction of the size of the same image as JPEG, at the same visible quality. If your store is still serving unoptimised JPEGs, you are paying for that on every page view, and your mobile visitors are paying for it twice.
- Open a product page, open the browser network tab, and sort by size. If images dominate, you have your answer.
- Check whether the images being downloaded are larger than the space they are displayed in.
- Check the format. If it says JPEG or PNG everywhere, there is easy ground to make up.
What if all four are fine?
Then the problem is somewhere more interesting, and that is exactly when a proper measurement earns its money. The usual suspects at that point are a single extension doing heavy work on every page load, a custom module running queries in a loop, or a hosting environment that cannot meet what Magento needs.
Those take profiling to find rather than a checklist. But it is worth ruling out the simple things first, because in most stores one of the four above is the answer, and finding it takes an afternoon instead of a project.
The order matters
Work through them in the order above. Production mode first, because it changes everything downstream. Then caching, then indexing, then images. Fixing images on a store that is running in developer mode is like tuning the engine while the handbrake is on.