Today, we are here to reveal some things about Magento 2 Page Cache performance. The aspects we are about to describe below may be well-known to you, however, it is useful to remind about them time after time.
Unlike Magento 1, Magento 2 includes the inbuilt Full Page Cache module, which greatly speeds up Magento 2 store.
On its principle, the module repeats M1 Enterprise Page Cache: page content is completely cached, but dynamic information is updated through AJAX requests. This technique reduces server response time for regular frontend pages.
Consequently, to configure the correct operation with page cache, all the additionally installed on your store extensions, should "pay attention" to this peculiarity. Thus, the dynamic information update will be made properly.
Another vital fact is a possibility to cache a page but only if this page excludes not-cacheable blocks.
It can be time-consuming to add/monitor/exclude them, in a case of a huge store, however a proper operation and up going benefits worth it. You can declare a not-cacheable block in layout files by adding an attribute cacheable="false" there.
To summarize, all the pages on the following list can not be cached by default:
- Login/registration/forgot password pages
- Customer account pages
- Search results pages (beginning from the version 2.2.4, it becomes possible to declare a few such pages to cache them)
- Cart page
- Checkout and also a part of another rarely visited pages
However, the good news is that key pages that get about 90% of users’ visitings are cacheable:
- Home page
- CMS pages
- Products list (category)
- Product details
Let’s go on and keep on talking on the cache operation cycle:
When a page is visited for the first time - the content of the page is generated from scratch and saved in cache with a unique identification.
When this page is subsequently visited in the future, it is "returned" from the cache it was previously added to. It significantly speeds up Magento 2 pages, greatly improves your customer experience and thus boosts sales.
This cycle is possible if 2 conditions are met:
- The cache lifetime is not expired yet (it is 24 hours by default)
- The previously cached page was not deleted from the cache. Thus deletion takes place in different cases, but the most basic reasons are change of related content (category, product) or reindex.
What is Hit Rate and why it is so important?
Now we are arriving at the most interesting thing - a hit rate or hit ratio.
What is this?
To make the long things short, the hit rate means the percent of queries returning a cached page (fast response).
I.e. if for 100 pages openings, 75 pages were given from page cache, the hit rate is 75%.
Hit rate (%) = [hits from page cache] / [total number of hits] * 100
Consequently, if the hit rate is low, most of your users will be waiting for the server response during a few seconds. It is not what we are looking for. So we should strive to make the rate tending to 100%.
Unfortunately, Magento 2 does not suggest any inbuilt techniques/engines either to monitor Magento 2 performance or to manage the coverage rate indicator.
On the bases of our experience, we want to note, in the process of our work we meet stores where Full Page Cache does not work at all very often!
It results from the fact that layout file default.xml, of one very popular extension, includes one not-cacheable block and this one completely disables the entire Page Cache.
We offer two tools for Page Cache management and performance enhancement in general:
- The first one is the Page Cache Warmer. Besides all other features, it increases the cache coverage rate by proceeding with page warming.
- The second one is our new extension named Health Monitoring Suite. It monitors coverage rate indicator (and many others, not only this one), and informs a user if there are some negative impacts on your store.
We will be glad if this essay was useful to you and will be waiting for your additional questions and feedbacks.
Please, always feel free to contact us, we are always ready to help you!