14 January 2017

Magento 1 static assets and full page caching

Although Magento 2 already addresses this pretty well, proper handling of static assets when using a full page cache with Magento 1 is not something I have yet seen advice addressed.  This post attempts to provide a good working method to allow you to both update your static assets, but also keep your full page cache intact.

Consider the following.  You have your Magento store up and running, and have also implemented a full page cache.  This of course means that the URL's to all of the static assets for each page are also cached with the page HTML.  This in turn means that as soon as you add or remove a JS file, the full page cache for the affected pages becomes out of date because it doesn't contain the changes to static assets as this newly added or removed URL is not reflected in the cached HTML.  This is the case both with merging enabled or disabled.  When disabled each static asset on the page has it's own URL, and when it is enabled the URL for each merged asset is created by generating a hash of all of the files which have been combined to create the merged file.  In this case when you add or remove a CSS or JS asset, the resulting hashed file name for the merged asset changes, but this is of course not reflected in your cached page HTML.  So when a customer views an affected page, at best they will be served an outdated CSS/JS file without the latest file changes just made, or in the case of the merged CSS/JS cache being cleared, will be served an invalid URL pointing to a merged file which no longer exists.  The result of this is that the page will render without any CSS/JS functionality.

So that's the scenario we need to address.  There are really two things to consider when thinking about a solution.  The first is browser caching, and the second is the fact that because we are using a full page cache we don't want to have to change the page HTML when adding or removing CSS and JS assets.

A common approach is to implement some kind of file name change when altering static assets.  This is great to address the first consideration as there is no way the browser can use it's own cached content as it's a new file.  However this approach really doesn't work along side full page caching as changing a file name of course means you have to refresh the cached content so that the new asset changes are reflected.

We need a solution that combines the best of both worlds.  Intelligent browser caching of static assets, combined with no change of a pages HTML.  The solution requires changes to both the stores code and the webserver.  On the webserver we need to add headers for JS and CSS files to tell the browser it can use these assets cached, but it must check they do not need updating first.  We can do this with the addition of a simple Cache-Control: no-cache header for these file types.  By adding this header the browser is instructed (despite what no-cache may sound like, the no-store directive means the browser cannot cache the file) that it can use it's cached versions of these files but it must check with the server for a more recent version of the file before it does.

Implementing this header means that we can use the same file names for serving CSS and JS assets, and while they are unmodified the user will get the performance benefit of this, but as soon as we update the content of any of these files the browser will get the new copy.  This means that the user will always see the latest styling and functionality, but still have the performance benefit of browser caching.

Great, but what about addressing the scenario above?  This still doesn't help with maintaining the full page cached content the addition/substraction of CSS or JS will require a change in the affected pages cache as the HTML will need to be updated.  Well Magento gives us a partial solution with merging.  To greatly reduce the number of requests per page we highly recommend you always have this enabled in a production environment anyway, so we will take merging being enabled as starting point here.  I know there are arguments both for and against enabling merging, but the benefits really do far outweigh the negatives in our opinion (if you want to read more about this have a look at this post on speeding up Magento).

As discussed above, Magento creates merged CSS and JS file names by creating a hash of the files included in that merge.  Great if we don't mind the page source code changing, but here we do so the solution is to not have the names of these merged files change even when adding or removing assets from the merge.  Well that's exactly what we've done and we have included these changes in the soon to be released new version of Evolved Caching, 1.9.17.  This version will include a new setting to allow you to use common merged asset filenames giving you the freedom to deploy new CSS and JS file changes at will with CSS/JS merging enabled.  Evolved Caching will automatically re-generate the merged files for you, so needing to refresh the full page cache when for instance updating some styles or functionality with no page HTML changing has become a thing of the past!

If you are interested in purchasing a copy of Evolved Caching, our advanced  Magento Varnish and full page cache solution, then please visit our store here to find out everything you need to know before buying.

8 June 2016

Magento Varnish how to - part three


Part Three


Welcome back once again to the third and final part of this Magento Varnish mini series.  The first part discussed why you should be using Varnish on your store, the second part showed you some figures for the kind of performance benefit a Magento Varnish cache is likely to give, and this final part shows you just how straight forward it is to actually get a Magento Varnish cache up and running on your store by using the easy integration offered by Evolved Caching.

How do I setup a Magento Varnish cache?

 

Varnish cache can be a complex piece of software to setup and customise to your exact site requirements with the default configuration it ships with catering for some, but certainly nothing like all sites.  As discussed in part one of this series, it basically won't cache Magento's pages at all while running it's default configuration and so needs some work to allow it to cache correctly.

That's where Evolved Caching comes in.  While Evolved Caching is a highly performance driven, advanced Magento full page caching solution in it's own right, it also massively simplifies using Varnish to cache your store pages by way of it's caching key cookie.  This cookie contains a unique reference describing everything about each page, including data that is normally stored in the session.  The cookie is delivered to Varnish for every request, and so rather than caching only by URL - which is extremely limiting in the case of Magento, Varnish can then cache the full breadth of possible page variations Magento can generate, and this includes caching pages when products are in the cart, or the customer is logged in.

Evolved Caching takes care of everything related to adding dynamic content to the page, defining which pages should be cached (or not) and allows Varnish to just get on the with the job of serving super fast cached content.  You can also manage the Varnish cache from within admin including automatic cache clearing and warming of pages as they are updated.  Evolved Caching does all the hard work for you!

So how can you get a Magento Varnish cache for your store?  This is how to do it.

The easy integration is given by Evolved Caching so as a starting point you can grab your copy here and follow the quick setup guide to get running with that.  You also need a clean, unmodified install of Varnish and you can find full instructions here.

Once you have these basic requirements in place there are just three simple steps you need to follow to get your Magento Varnish cache.
  1. Use our vcl configuration file for either Varnish 4 or Varnish 3 in /etc/varnish/default.vcl on your server.
  2. Enable 'flush varnish cache' under the general options section of the Evolved Caching settings.
  3. Turn on 'enable cookie' under the caching key cookie section of the Evolved Caching settings.
That's it!

Now you just need to restart Varnish, and clear the Magento cache (including the Evolved Caching cache) and you should see Varnish serving cached content as you navigate the site.  the Varnish cache will also be cleared and populated as you use admin.  If you are not sure how to tell if Varnish is serving cache or not have a look at the bottom of our Evolved Caching Varnish documentation page.

Thanks for reading this mini series, we hope you find your Magento Varnish cache gives your store a real performance boost!

Magento Varnish how to - part two


Part Two


Welcome back to part two of this mini series on how to get a Magento Varnish cache on your Magento store.  Part one talked about why Varnish is something you should be using, and this part talks about the kind of performance increase you should be seeing by using Varnish on your store.  The next and final part shows you how easy it is to actually get Varnish working on your Magento using Evolved Caching.

Magento Varnish performance

 

So we've hopefully convinced you that using Varnish on your Magento store is a great idea, but what kind of performance increase are you likely to see?  This does depend to some extent on the spec of the server Varnish is running on, but whatever the spec Varnish is going to deliver it's cached content many, many times faster than having Magento process the request.  To give you an idea, here are some benchmarks we ran with an Evolved Caching Magento Varnish setup as described in the last part of this mini series.  The times shown below are the time it takes the server to generate a full page of HTML content to deliver to a customers browser (being the part that Magento is slow at), it doesn't take into account connection speed which can vary greatly for each user.

Home page

With standard Magento caches enabled the server takes an average of 175ms to build this page of HTML.

With Varnish serving a cached page the server takes an average of 18ms to build this page of HTML

Varnish is therefore around 10x faster in this case.

CMS page

With standard Magento caches enabled the server takes an average of 140ms to build this page of HTML.

With Varnish serving a cached page the server takes an average of 18ms to build this page of HTML

Varnish is therefore around 8x faster in this case.

Product page

With standard Magento caches enabled the server takes an average of 370ms to build this page of HTML.

With Varnish serving a cached page the server takes an average of 18ms to build this page of HTML

Varnish is therefore around 21x faster in this case.

Custom page

With standard Magento caches enabled the server takes an average of 480ms to build this page of HTML.

With Varnish serving a cached page the server takes an average of 18ms to build this page of HTML

Varnish is therefore around 27x faster in this case.


So you can see there is quite a difference in the time it takes the various pages to be built by Magento, while Varnish keeps a consistent 18ms to serve it's cached content throughout.  Because more complex pages take a longer amount of time to build by Magento, it makes sense that you see a greater performance benefit on these pages than on simple pages which are quick for Magento to build.  Category and product pages are obviously key to every Magento store and it's on these pages you are likely to see the greatest improvement.  So the longer and more complex your stores pages are, the greater performance benefit you are going to see by using Varnish.  If you want to see more, you can find the benchmarks for Evolved Caching here - the performance of Evolved Caching's own full page cache is virtually identical to Varnish so these figures are directly comparable to the same setup using Varnish.  Our store also uses Varnish so you are welcome to browse and test there as well.

Thanks for reading part two of this Magento Varnish cache mini series, the last part shows you how easy it is to get Varnish working on your Magento store by using Evolved Caching.