If you fix only one thing on a slow Magento 2 store, make it caching. Full-page caching is what lets Magento serve a page without rebuilding it from the database and layout on every request, and it is the difference between a store that buckles under traffic and one that shrugs it off. This guide covers how full-page caching works, why Varnish beats the built-in cache, how Redis fits in, and how to keep the cache warm. It is one of the deeper guides on the Magento Optimization hub.
What full-page caching actually does
Building a Magento page is expensive: the platform assembles layout XML, runs blocks, queries the database for products, prices and categories, and renders templates. Full-page cache (FPC) stores the finished HTML for a page so the next visitor gets the stored copy instead of triggering all that work. For catalog and content pages, which are the same for most visitors, this turns a heavy dynamic request into a near-instant static one.
Varnish, not the built-in cache
Magento can store the full-page cache in files or in Varnish. For any real store, use Varnish. It is a caching HTTP reverse proxy that sits in front of Magento and serves cached pages before the request ever reaches PHP, so cached traffic barely touches your application server at all. The built-in file cache still runs through PHP and is only suitable for development. Configure Varnish under Stores > Configuration > Advanced > System > Full Page Cache, export the VCL, and point your web server at it.
Redis for cache and sessions
Varnish handles the full-page cache; Redis handles everything else. Use Redis for Magento’s default cache (config, layout, block HTML) and for session storage. It is far faster than file-based storage and, on multi-server setups, lets every web node share the same cache and sessions. Keep the default cache and sessions in separate Redis databases, so flushing the cache never logs your customers out.
Hole-punching: keeping dynamic bits dynamic
A cached page still needs some personal parts: the cart count, a customer’s name, a form key. Magento handles this with private content loaded separately by the browser after the cached page arrives, rather than by caching each visitor’s page individually. Understanding this matters because a common mistake, marking a block as uncacheable, disables full-page caching for the entire page it appears on. One badly configured block can quietly turn caching off across a whole page type.
Warming the cache
The first request for a page after a cache flush is slow, because it has to build the page and store it; every request after is fast. On a busy store real visitors warm the cache for you. On a large catalog, or right after a deployment that flushes everything, use a cache warmer to crawl your important URLs so customers are not the ones paying the cold-cache cost. This is why “Magento is slow right after I clear the cache” is normal, not a fault.
A CDN in front
Put a CDN in front of the whole stack to serve static assets, and cached pages where possible, from a location near the shopper. The CDN cuts latency and offloads your origin. Together, CDN plus Varnish plus Redis means most requests are served without ever running PHP or querying the database, which is exactly what makes a Magento store fast and resilient.
Frequently asked questions
Which Magento caches should be enabled in production?
All of them. Every cache type under System > Cache Management should be enabled on a live store, with the full-page cache backed by Varnish and the default cache backed by Redis. Disabling cache types is a development convenience that has no place in production; a store with caches off is doing enormous, needless work on every request.
Why is Magento still slow when caching is enabled?
Usually because the cache is not actually being hit. A misconfigured Varnish, an uncacheable block that disabled FPC for a whole page type, a low cache lifetime, or pages that are genuinely dynamic (cart, checkout, logged-in views) can all mean requests still hit PHP. Check your cache hit rate before assuming caching is doing its job; “enabled” and “being used” are not the same thing.
How do I verify that Magento cache is working?
Look at the response headers: a Varnish-served page carries cache headers showing a hit, and its Time to First Byte will be a fraction of an uncached page’s. You can also watch Varnish’s own statistics for hit rate, and compare TTFB on a cached catalog page versus an uncacheable page like checkout. If TTFB is high everywhere, caching is not working.
Should I use the built-in cache, Redis, or Varnish?
Use all three for their jobs: Varnish for the full-page cache, Redis for the default cache and sessions, and the built-in file cache only in development. They are not alternatives to choose between; a production store uses Varnish in front for whole pages and Redis behind it for everything else.
Does clearing the Magento cache improve speed?
No, it does the opposite in the short term. Clearing the cache forces Magento to rebuild pages from scratch, so the store is slower until the cache refills. Clearing is for when stale content is being served, not a speed fix. If clearing the cache “fixes” a slowness, the real problem is usually a cache invalidation or configuration issue worth diagnosing.
Can clearing the cache too often reduce Magento performance?
Yes. Every flush throws away work the store then has to redo, so a store whose cache is flushed constantly, by an over-eager cron, a misbehaving extension, or frequent deployments, never gets to serve warm cache and feels permanently slow. Flush selectively (only the cache types that changed) rather than everything, and warm the cache afterward.
How does full-page caching work in Magento?
Magento stores the rendered HTML of a page the first time it is requested, keyed by the page and a few context values. Subsequent requests for that page return the stored HTML instead of rebuilding it, with the small personal parts (cart, customer data) loaded separately as private content. With Varnish, the cached page is served by the proxy before the request reaches Magento at all.
Why are my Magento indexes always processing?
Usually because indexers are set to “Update on Save” on a store with frequent catalog changes, so every edit queues reindexing, or because cron is not running to process scheduled indexing. Set indexers to “Update by Schedule” and confirm cron runs every minute. Indexes stuck processing make category, search and price data slow and inconsistent.
How do I fix slow Magento indexing?
Switch indexers to schedule-based, make sure cron is healthy, and ensure the database and search backend are adequately resourced. On large catalogs, reindexing is inherently heavy, so it should run on a schedule during quieter periods, not on save during shopping hours. A one-off manual bin/magento indexer:reindex resets a store that has drifted.
Should Magento indexers update on save or by schedule?
By schedule, on any real store. “Update on Save” triggers reindexing inside the request that saved a product, which slows the admin and can pile up under bulk edits or imports. “Update by Schedule” batches the work through cron so it does not block anyone. On-save is only reasonable on a tiny catalog with rare changes.
Does dependency injection compilation improve performance?
Yes, and it is part of production mode. Compiling the dependency injection configuration (bin/magento setup:di:compile) generates the code Magento would otherwise build at runtime, so requests skip that work. You get it automatically when you deploy in production mode, which is one more reason never to run a live store in developer mode.
How do I warm the Magento cache after a deployment?
Use a cache warmer that crawls your important URLs, category pages, top products, CMS pages, right after the deploy flushes the cache, so the pages are rebuilt and stored before customers hit them. Without warming, the first visitor to each page pays the cold-cache cost, which is why a store can feel slow for a few minutes after every deployment.
Why is Magento slow right after clearing the cache?
Because the cache is empty and every page has to be rebuilt and stored on its first request. This is expected behavior, not a bug. It passes as the cache refills, and you can avoid customers feeling it by warming the cache after any flush or deployment. If a store is slow long after a flush, the cache is not filling, which points to a configuration problem.
Related
- Magento Optimization: a practical walk through making a slow Magento store genuinely fast, area by area, with every guide in this cluster in one place.
- A Magento 2 Performance Optimization Checklist
- Core Web Vitals and Frontend Performance for Magento 2
- How to Optimize Magento Speed
- Magento Optimization FAQ
