At TII, I have been utilizing the Page Cache extension to give a tremendous user experience thrust to Magento applications. Full Page Caching (FPC) offers gold standard advantages such as quicker page load time, minimal server load and SEO friendliness. However, it did present a tricky situation on a recent e-commerce application development project, which had FPC turned on because of the huge number of projects to display. In order to go one step ahead, I had created blocks to store relevant product content. However, enabling this dynamic page functionality creates a contradiction with FPC functionality. This blog looks at a nifty way to overcome this issue with the help of ‘hole-punching’. So let’s dive in.
What is full page caching?
Simply put, the full page caching mechanism allows local storage of web content from a URL to a ‘container’ or cache. This way Magento does not need to fully initialize content and then load content to show to a user. This renders blazing fast page load speeds and lesser stress on backend databases. But it also makes the site less dynamic. However, Magento does recognize the emphasis on dynamic content and provides a built-in ’hole punching’ process to accomplish a dynamic page that provides much better and highly optimized performance.
What is hole-punching?
I am assuming that you are fairly proficient in Magento and its building blocks before you read further. The thought process behind Magento EE FPC is to create a container class that is derived from ‘Enterprise_PageCache_Model_Container_Abstract’ for every block having dynamic content. In order to preserve the dynamic relationship of blocks and templates with FPC, I can surround the files with a container. This denotes the working behind ‘hole punching’
The various states of Magento FPC
If you are using Full Page Caching (FPC), you ought to know the four states of Magento FPC
Page caching on but no dynamic blocks – In the simplest form, Magento gets a request to load a non-dynamic page. It looks up the page in the FPC repository and loads it to the user. This process puts no load on the server
Page caching on and dynamic block caching on – Again Magento gets a request to load a page (this time, a dynamic page). Now Magento encounters a container associated with a dynamic block. If the block is cached, it will use applyWithoutApp($content) and fill up the container accordingly. This type of content loading places minimal server load.
Page caching on and dynamic block caching off – Now imagine if Magento does not encounter a container. Now it needs to follow some steps as below
pagecache/request/process receives a request which then leads to its processing and routing to RequestController
- This accesses the method applyWithApp($content). Here, the dynamic block is initiated and built using .$this -> renderBlock() within the Enterprise_PageCache_Model_Container_Abstract container class
This way, the container is replaced with the static block and can be used later for caching.
Page Caching turned off – When the page is not cached, Magento takes the standard route of looking up the dynamic block, wrapping it around with its appropriate placeholders using the cache.xml file (present in Enterprise/PageCache/etc/cache.xml). It enables FPC with the help of a cache_id and relevant block and template information.
Imagine a visitor, Peter visits my site the first time. Now Magento will be fully initialized, FPC is newly enabled, and the desired page cache is loaded. On the second visit, only FPC hole entries and customer related cookies are loaded. On the third visit, however, the Magento remains fully initialized and hence server load is reduced drastically. For scores of site visitors, this first step is not repeated again and again for most visited pages (unless of course, Peter is visiting a non FPC page for the first time). Thus, overall server load is reduced, page load is quicker and performance is enhanced significantly. On the frontend, an increase in number of users still allows the site to work faster.