Magento 2: Full Page Cache Issue

Well this week was an interesting one. Fresh out of training and tasked to work on a technical problem where a site wasn’t utilising the built in Full Page Cache (FPC) provided in Magento 2 despite being turned on. I’m aware that best practise would be using a reverse HTTP proxy such as Varnish, but this site isn’t.

Initially the investigation started because on the live production site the FPC was constantly invalidated even after a cache flush or clear, but that is another story.

When loading this live production site the Time to First Byte (TTFB ) was longer than expected, approximately 1950ms. The output from browser dev tools can be seen below.

Fortunately FPC issues and problems can be debugged by placing the site in development mode and checking the server response headers.
Whilst the site is in developer mode you should see one of the following:

• X-Magento-Cache-Debug: HIT
• X-Magento-Cache-Debug: MISS

On first page load the cache will be cold and will provide the MISS response, then any subsequent page loads provide the HIT response header to indicate that the FPC is being used for that page. In our example case, any page loaded was returning the MISS result and never providing a HIT.

During my training with Vijay at the Magento 2 essentials course we touched on the front end and something that stuck at the back of my mind was that if any block on a layout is marked with cachable=”false” then that would render the entire page uncacheable by the FPC. The developer docs confirm this fact, “To create an uncacheable page, mark any block on that page as uncacheable in the layout using cacheable="false".”

So it should come as no surprise that only a select few pages should be marked with this block tag. In fact the dev docs clearly states “Do not configure content pages (i.e., catalog, product, and CMS pages) to be uncacheable. Doing so has an adverse affect on performance.”. Upon investigation a number of layout blocks included within the installed theme contained these cacheable=”false” tags, the most pertinent being within the layouts default.xml file. This tag was rendering all pages as uncacheable and as you would expect impacting on page load times. The tag had also been used in a third party module modifying the catalog_product_view.xml preventing these pages from entering the FPC.

The Magento 2 dev docs goes into detail about public and private content and how to handle blocks requiring dynamic private data on a cacheable page.

After removing these tags the load times significantly decreased with TTFB averaging around 40ms in developer mode and headers returning HIT responses from the cache. The HIT response and sample TTFB can be seen in the images below.

Of course, identifying the issue is the first step, fixing these so that the site operates as expected is next.

The other action that needs considering is code profiling to see where these slow execution times originate, because caching alone will not solve performance-based issues.
A user will hit the site with a cold cache and the page load still needs to be reasonably snappy. Magento 2’s demo content store demonstrates this to good effect.

Hopefully this article will help someone else who is suffering poor page load times and FPC issues.