Magento 2.3 is the latest iteration of the enterprise-class eCommerce platform, Magento, that many of our customers at Section use. In fact, it is estimated that one in four of all businesses use the Magento software. The open source platform officially began development in 2007 and the first public beta version was released seven months later that same year. It is known for its wealth of customizable options and extra adaptations, designed to suit a wide range of use cases and provide a host of useful features such as cart customization and robust security.
Magento 2.0 was launched in 2015 with the goals of heightening user engagement, offering smoother navigation, and increasing conversion rates. With various architectural differences, Magento 2.0 boasts improvements in usability, speed and optimization. It has various new features, including a revised security directory, an advanced payment option and a “friendlier” approach to installation and updates.
Despite the benefits that Magento 2 offers, there are many eCommerce stores who remain on Magento 1. As with any major system upgrade, companies and/or developers who have become comfortable with one version’s mechanisms and paradigms may prefer to stay with the original to avoid extra resource strain and/or maintenance and potential downtime. However, we believe that remaining on Magento 1 shouldn’t mean sacrificing performance. Section allows Magento 1 users to take advantage of Full HTML Caching by emulating the same behavior that Magento 2 provides out of the box, with just a small amount of additional work needed on the web application.
How to Configure Full HTML Caching for Magento 1
We recently helped one of our eCommerce customers, Australia’s largest online retailer of costumes, accessories and party supplies, overcome some performance challenges that they were experiencing with Magento 1 by leveraging Section’s Full HTML Caching feature. Pages on the site are tagged with a custom HTTP response header that contains the product IDs of products displayed on that page. By working with Section’s Customer Engineering Team, now whenever they update a product, their Magento application automatically sends a cache flush API call to Section, whereby we then flush all product and category pages containing a specific product ID.
We wanted to ensure that despite being on the older iteration of the platform, customers using Magento 1 could still take advantage of the benefits provided by Section’s Full HTML Caching feature. The main benefit is faster page load times, something which we have found consistently leads to more product page views and ultimately a higher rate of cart conversion and increased sales revenue.
To benefit from these caching improvements, Magento 1 customers need to take the following steps:
- Lift personalized content, such as mini cart and login status, on web pages from HTML to AJAX, so that the HTML is generic;
- Either turn off CSRF* tokens, or inject them via AJAX calls;
- Pages that contain mostly personalized content (e.g. checkout, account, etc.) can be left as is, they can be excluded from caching;
- Product pages need to be tagged with a unique ID; this ID should take the form of a HTTP response header value (e.g. prod-ID: 12345);
- Any page, such as a category page, needs to be tagged with IDs of all the products on that page. The HTTP header should look like like this: prod-ID: 12345, 12346, 12223
- A server side module/script needs to be created, which can call the Section cache flush API with a conditional cache clear of only items with a specific prod-ID;
- Finally, this module needs to be hooked into the Save button in Magento. Whenever a product page is edited and the Save button is pushed, this module should call the Section API to flush any page with that product in order to reflect the latest state.
With the above in place, long cache times can be placed on HTML pages, drastically cutting down on the number of requests to origin servers. This should lead to much higher concurrent user counts, a faster user experience and overall reduced server cost.
Contact us if you’d like assistance implementing performance improvements on your Magento site.
* Cross-Site Request Forgery (CSRF) tokens are not needed on most pages. As defined by OWASP, CSRF is “an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated”. The Synchronizer Token, while a strong method to defend against CSRF, is dependent on session cookies and server-side state, which unfortunately negatively impacts cacheability. There are other ways to reduce the incidence of CSRF; several ideas for alternative solutions are listed here.
