Magento Caching — Cache Types, Full Page Cache, Varnish and Redis
In this tutorial, you'll learn how Magento caching works across its cache types, how Full Page Cache with Varnish accelerates storefront performance, and how Redis stores cache and session data for high-traffic stores.
What You'll Learn
- The purpose of each Magento cache type (CONFIG, LAYOUT, BLOCK_HTML, etc.)
- How to manage caches from the admin panel and CLI
- How Full Page Cache works and why Varnish is recommended
- How to configure Redis for cache and session storage
- How cache invalidation triggers on product or configuration changes
Why It Matters
Magento is a powerful platform, but it is also resource-intensive. Without proper caching, page load times can exceed 5 seconds, hurting conversions and SEO rankings. A well-tuned caching strategy with Varnish and Redis can bring response times under 200 milliseconds.
Real-World Use
A fashion store with 10,000 daily visitors experienced 4-second page loads and a 60% bounce rate. After enabling Varnish as the Full Page Cache and Redis for session storage, page loads dropped to 180ms and bounce rate fell to 35%. The changes required no code modifications — only configuration.
Learning Path
flowchart LR
A[CLI Commands] --> B[Caching]
B --> C[Indexing]
B --> D[Performance Optimization]
C --> E[Import & Export]
D --> E
style B fill:#3b82f6,color:#fff
Cache Types and Their Purposes
Magento has multiple cache types, each storing specific data. Understanding them helps you decide which to clean when troubleshooting.
| Cache Type | Code | Stores |
|---|---|---|
| Configuration | CONFIG | System config values merged from all config.xml files |
| Layout | LAYOUT | Compiled layout instructions for each page |
| Block HTML | BLOCK_HTML | Rendered HTML output of blocks |
| Collections | COLLECTION | Database query results for collections |
| Reflection | REFLECTION | Class reflection data for dependency injection |
| Database DDL | DB_DDL | Database schema definitions |
| EAV | EAV | Entity-Attribute-Value metadata for attributes |
| Web Services | CONFIG_API | API configuration definitions |
| Full Page | FULL_PAGE | Entire rendered page output |
| Translations | TRANSLATE | Translated strings for storefront and admin |
Cache Management
Admin Panel
Navigate to Stores > System > Cache Management. You will see a table of all cache types with their status. You can:
- Select individual caches to enable, disable, or clean
- Use "Flush Magento Cache" to clear all cache storage
- Use "Flush Cache Storage" to clear every cache entry including third-party
CLI Management
As covered in the CLI Commands tutorial, you can manage caches faster from the command line:
# Check status
bin/magento cache:status
# Clean specific types
bin/magento cache:clean config layout
# Flush all
bin/magento cache:flush
Full Page Cache
Full Page Cache (FPC) stores the fully rendered HTML of each page. When a visitor requests a page, Magento checks the cache first. If a cached copy exists and is valid, it serves that instead of generating the page from scratch.
Built-in FPC vs Varnish
Magento includes a built-in Full Page Cache, but it stores cached pages in the filesystem or database. For production stores, Varnish is recommended because it handles cache storage and delivery in memory, making it significantly faster.
Enable Varnish
- In the admin panel, go to Stores > Configuration > Advanced > System > Full Page Cache
- Set Caching Application to Varnish
- Click Export VCL for Varnish to download the recommended VCL configuration
- Configure Varnish to listen on port 80 and Magento on port 8080
Example Varnish configuration in env.php:
'http_cache_hosts' => [
[
'host' => '127.0.0.1',
'port' => '8080',
]
],
Redis for Cache and Session Storage
Redis is an in-memory data store that Magento uses for cache backend and session storage. It is faster than filesystem-based caching.
Configure Redis in env.php
Open app/etc/env.php and add Redis configuration for cache:
'cache' => [
'frontend' => [
'default' => [
'backend' => 'Cm_Cache_Backend_Redis',
'backend_options' => [
'server' => '127.0.0.1',
'port' => '6379',
'database' => '0',
],
],
'page_cache' => [
'backend' => 'Cm_Cache_Backend_Redis',
'backend_options' => [
'server' => '127.0.0.1',
'port' => '6379',
'database' => '1',
'compress_data' => '0',
],
],
],
],
Configure Sessions in Redis
Sessions in Redis improve performance by removing filesystem I/O:
'session' => [
'save' => 'redis',
'redis' => [
'host' => '127.0.0.1',
'port' => '6379',
'database' => '2',
],
],
Verify Redis Connection
redis-cli ping
Response should be PONG. To check Magento cache keys:
redis-cli --scan --pattern '*magento*' | head -10
Cache Invalidation
Magento automatically invalidates cache entries when related data changes. Understanding when invalidation happens helps you plan maintenance.
Events That Trigger Invalidation
- Product save — Invalidates block HTML and full page cache for product pages
- Category change — Invalidates category and product listing caches
- Configuration change — Invalidates config cache
- Reindex — Invalidates related caches after index completion
Purge on Save
When Varnish is used, Magento sends HTTP PURGE requests to Varnish for specific URLs. This removes only the affected pages from cache, not the entire cache.
Cache Warm-up
After cache invalidation, the first visitor triggers a cache miss and a slower page load. Cache warm-up tools request popular pages ahead of time to pre-populate the cache. Consider using a warm-up script after deployments:
#!/bin/bash
URLS=("https://mystore.com/" "https://mystore.com/mens" "https://mystore.com/product/shoe-100")
for URL in "${URLS[@]}"; do
curl -s -o /dev/null -w "%{http_code}" "$URL"
echo " $URL"
done
Monitoring Cache
Use varnishstat to monitor Varnish cache performance:
varnishstat -1
Key metrics:
MAIN.cache_hit - Number of cache hits
MAIN.cache_miss - Number of cache misses
MAIN.hit_rate - Hit rate percentage
A hit rate above 90% indicates a well-optimized cache. Below 80% suggests configuration issues or excessive dynamic content.
Common Mistakes
- Disabling Full Page Cache during development and forgetting to re-enable it in production, causing extremely slow site performance
- Using the built-in Full Page Cache instead of Varnish for production stores, missing out on significant performance gains
- Not configuring separate Redis databases for default cache and page cache, causing interference between the two
- Skipping cache warm-up after deployment, resulting in slow first-page loads for real customers
- Flushing the entire cache when only one cache type needs cleaning, wasting resources and slowing the site for all visitors
Practice Questions
- What is the difference between the built-in Full Page Cache and Varnish?
- How do you configure separate Redis databases for default cache and page cache in env.php?
- What events trigger full page cache invalidation for product pages?
Challenge: Set up Varnish on a local Magento installation, export the VCL from the admin panel, and verify the cache hit rate is above 90% using varnishstat.
FAQ
Mini Project
Configure Redis for cache and session storage on a Magento installation. Edit app/etc/env.php to add Redis cache frontends for default and page cache, then configure session storage in Redis. Verify the configuration by connecting to Redis CLI and listing Magento cache keys. Measure the page load time before and after using Chrome DevToolsk "DevTools" >}}.
What's Next
Now that caching is tuned, explore Magento Indexing to understand how data is prepared for fast storefront access. Then continue with Magento Performance Optimization for CDN integration and database tuning.
Built by the developers of DodaTech
Doda Browser, DodaZIP & Durga Antivirus Pro