So, you’ve turned on Full Page Cache, Redis, Varnish, and pushed assets to a CDN, but your site is still slow. Here’s what’s actually going on.
Caching only handles what’s already fast
Magento’s caching speeds up content that’s already been built. If your theme is slow, your extensions are bloated, or your database is struggling, caching won’t fix any of that. It just hides it.
And anything that involves the actual shopper (logging in, adding to cart, checking out) bypasses the cache completely. That all has to run in real time, every time.
Where it usually breaks down
Customer sections are never cached
When a shopper lands on a page, Magento serves the cached version fast. But things like the cart, login state, and personalised pricing aren’t part of that cached page at all. They load separately, via what Magento calls customer sections, pulled in through an AJAX call after the page loads.
If that part is slow, the page feels slow. Doesn’t matter how well the cache is set up.
Layered navigation multiplies pages
Every time a shopper filters by size, price, or colour, Magento treats that as a completely different page. Filter by two things at once? That’s another new page. The combinations add up fast.
Most of those filtered views will never have been cached before, so Magento has to run the full query from scratch each time. Layered navigation is one of the biggest cache killers on a busy catalogue.
One block can opt a whole page out
If a single block on a page is flagged as cacheable=”false”, Magento won’t cache that page at all. The whole thing gets rebuilt on every load.
It’s a common leftover from a quick fix or a third-party extension that wasn’t built with Full Page Cache in mind. One small block, and the cache benefit is gone for that entire page.
Indexing running at the wrong time
If your indexers are set to “Update on Save”, every time a product or price changes, Magento kicks off a reindex immediately. During live traffic, that reindexing is competing with real shoppers for database resources.
Switching indexers to “Update on Schedule” means that work happens in the background, at a time that isn’t affecting anyone browsing the store. Newer Magento installs default to schedule mode, so this is mainly worth checking on older stores or ones that have been upgraded over time.
That last sentence is the only change. If you’d rather keep it tighter, your original version is still correct as it stands.
Server sizing hasn’t kept up
What worked when the store launched might not be enough now. If PHP-FPM doesn’t have enough workers to handle current traffic, requests start queuing up regardless of how fast each one actually is.
Redis has the same problem. If it’s running low on memory, it starts dropping cache entries to make room. So pages that should be cache hits are quietly becoming misses, and nobody notices until the site starts dragging.
Front-end weight nobody’s touched
Caching makes the server fast. It doesn’t make the page light.
Heavy JavaScript bundles, uncompressed product images, and third-party scripts (chat widgets, analytics, tracking pixels) all load on their own, after the server has already done its job. If the front end is carrying too much, the page will still feel slow even if the server response is instant.
The Cache Isn’t the Problem
Caching is doing its job. The question is whether everything around it is doing its job too.
A slow Magento store after caching is turned on isn’t a caching problem; it’s a sign something else needs attention. A bloated theme, a struggling database, a front end carrying too much weight. These six areas are the right place to start looking.
Sort those out, and the cache will actually have something worth serving.
Hi! My name is Dion, Account Manager at Hypernode
Want to know more about Hypernode's Managed E-commerce Hosting? Schedule your online meeting.
schedule one-on-one meeting +31 (0) 648362102
