In Magento, full page caching improves load speed response time on your website. A cached page will be stored after one visit or pre-generated and stored. A cached page takes much less time to open in a browser. Fast load speed is crucial to your customers’ shopping experience, and customers will commonly abandon stores that are slow to load or respond.
Magento Enterprise Edition offers caching for category, product, and CMS pages. For caching purposes, visitors are categorized as follows:
Non-sessioned visitors, who are simply browsing and have not interacted with the store
Sessioned visitors, who have engaged with the store by comparing products or adding them to their cart or wish list
Customers, who are logged in and belong to a customer group.
Enabling & Configuring Full-Page Cache auto generation
Navigate to System > Configuration > System
In the Full Page Cache panel, configure the following values
Cache Lifetime (minutes) – Set the amount of time until a cache is removed. After this time expires, it will be re-created the next time the visitor lands on the page.
Maximum Allowed Page Depth – Determines the number of layered parameters that can be applied in order for a page to be cached. This allows you to limit the number of cached files that will be stored.
Enable Cache For Not Default Currencies – (yes) will enable caching for currencies in the store’s allowed currency list. (no) will only cache pages for the default currency
Enable or Disable page caching
Full page caching by default is enabled but can be turned on and off as needed. Caching is usually disabled during development so that updates become immediately apparent.
Navigate to System > Cache Management
Select Page Cache (Cache Storage Management)
Select Enable or disable from the Action drop-down on the right
Manually Clearing the page cache
After updating CMS pages or other content, changes may not appear until the cache is cleared. You can do this manually in the admin
Navigate to System > Cache Management
Select Page Cache
Select Refresh from the Action drop-down on the top right
Magento Caching Problems
Magento caching can affect a website’s performance if not configured correctly from the beginning. There are a number of caching extensions/options for Magento. Primarily they break down into Full Page Caching vs Block Level Caching. For Magento full page caching, our experience is with Magento EE Full Page Caching and Amasty’s‘s Full Page Caching.
The challenge faced with Magento Page Caching is that these two extensions are designed specifically to work with Magento as it is installed out of the box. Every additional extension needs to provide configuration information for how that extension affects the caching settings for a page. This is especially problematic for extensions such as SubscribePro and Sweet Tooth Rewards where content is inserted on pages for specific customer groups! For bigger Magento websites, which consist of over 60 third party extensions, we have run into breakages after enabling page cache every single time.
For Block level caching, annoyingly this is “built in” to Magento – full featured and well defined. Yet there is only a single block provided by Magento themselves, the footer block, which takes advantage of it. Because of this, very few other extensions provide block level caching configuration so none of those blocks are cached.
Configuring block level Magento caching is time-consuming and requires much testing. It requires editing a lot of XML files, in some cases adding observers to force caching, and is basically a large pile of work with unknown benefits.
We recommend installation of the SimEnt Product list block cache extension by default on any website https://github.com/siment/product-list-block-cache
This very simple extension enables block level caching for one and only one block, the category listing block. However, that is the most important and time-consuming block – and using this extension requires minimal effort.
For more advanced block caching, the free Made Cache extension, https://github.com/madepeople/Made_Cache allows for configuring very detailed block level caching parameters for a large number of different block types – as well as adding new block caches, perhaps it could be made to cache Amasty Landing page blocks, which replace category listing blocks and thus can lead to the same large performance issues.
Magento Caching – Installation of simple product list
Always always always install a profile tool, such as AOE Profile before implementing caching.
Profile page load time on production, not development. A dev server with zero load and zero external API connections provides meaningless metric data.
Review page generation time before and after making cache configuration changes, including turning cache on and off.
Keep in mind cost/benefit analysis. Caching increases maintenance cost by a random amount. A conservative estimate is an additional 3 weeks/120 hours of support time troubleshooting caching issues.
On new builds, we highly recommend enabling caching from the start – not at the end. Because the primary issue with caching relates to third party extension configuration – turning it on a site with 30+ third party extensions already installed means trying to figure out which ones need to be modified – adding hours and hours of post deployment work. If caching is enabled on /development/ from the very start – then we will know right away when a specific extension breaks. For example, on a particular project we’re working on, we disabled all caches on the development environment and only turned it on a week after the “soft launch”. At that point, we had no time at all to troubleshoot/make it work and had to disable it.
Document caching issues, to avoid repeating the same mistakes over a dozen times because of weeks, and sometimes mere days, after a cache is disabled due to the site breaking – the dev team enables the cache as part of another ticket.
Site Testing Scenarios with cache enabled are quite complex. More than once we have found that Magento caches a page or block the first time it is accessed one way and uses it for other access. Most notably, if a catalog page is accessed by one customer via HTTP first, and then another customer via HTTPS – ALL THE LINKS are HTTP. Magento uses the page cached the first time!
This will also apply to multiple stores, pricing modifications by customer group, etc.
Typical testing is to: test one thing, a wholesale customer, for example. Log out. Flush the Magento cache. Test a retail customer. You cannot do this. You need to test wholesale and retail customers browsing the website simultaneously!! That’s my thoughts on Magento caching best practices and troubleshooting.
To get an overview on how the caching works in Magento 2, please check our other article here. If you would like to discuss Magento caching in more detail or would like us to review your current setup, please feel free to get in touch with us
Systems Manager
