It’s worth knowing that probably the single key performance improvement that can be done to a Magento site is to install a good caching mechanism so that website pages do not have to be recomputed regularly. These caches are often called Full Page Caches, or FPCs in abbreviated form, in Magento lingo, and are also sometimes referred to “page accelerators”. This article is aimed at site owners rather than technical experts; and it’s worth noting that while this article focuses on Magento because it is often slow, most of what we write here applies equally to any website technology, whether WordPress, Joomla, Drupal or something else.
What is a Full Page Cache?
As background to why this is so important, Amazon did tests that showed they would lose $1.6 BILLION every year if they slowed down by just one second. While users of your site could be more tolerant, that result still suggests strongly that you will lose business if your site is slow. Similar statistics suggest that 40% of people will abandon your site if it takes longer than 3 seconds to load. Kissmetrics says that a 1 second delay in page response can result in a 7% reduction in conversions, and that 40% of people abandon a website that takes more than 3 seconds to load. Given these statistics, it’s pretty clear that slow eCommerce sites are needlessly reducing their financial effectiveness!
A full page cache works by pre-computing page the details of contents of a page, and saving the resulting page. When the site is visited next, the computation work is already done and the site simply displays the pre-computed page. By the way, to add further context, while Magento 2 does now include a full page cache in the free Community Edition (“CE”), Magento version 1 does not include a full page cache in CE. Magento also has a “block cache” which can provide some benefit though nowhere near the results that an FPC will give.
An important point, given the above, is that a full page cache (“FPC”) doesn’t make the site faster until the page is actually cached, which usually takes place the first time it is viewed. As a result what you would see is that the first view of any page on the site is slower as it requires the page to be built in memory and then saved, and then subsequent page views would be much faster. For instance, computing the page the first time could take 2-3 seconds, whereas getting it from the cache typically takes 0.1 – 0.2 seconds, or even less.
Working out how your site is going
You can get a good idea of the time your site is taking to display pages by examining the TTFB time (“Time to First Byte”) and we’ll show you how to do that in a moment. To explain a little what this is, it is the time before the server starts to respond at all with the contents of the page. It’s an excellent measure as to how long the server is taking to build the page in memory – both in computation time and in database accesses. A good rough measure is that if a page is taking more than 3 seconds in TTFB time regularly, then you’d expect your site would benefit strongly from a page cache of some sort. If your page has a high TTFB, you should see a rapid slowdown if the server gets busy.
To check your site’s TTFB, visit www.webpagetest.org. Simply visit the site, enter your full page URL and click “Start Test”, then wait a few minutes for the test to run. These tests should be run both at times when your server is as quiet as possible and when it is busy, to help compare between the two, and without an FPC you should see the page slow down if TTFB is high and the server is busy when you run tests. Note that the different page types on your site will have different performance characteristics, so you will want to test a representative sample of page types (home, product, catalog, blog etc).
A quick tip for the use of webpagetest.org is to create a user and login (avoid the use of Google to login as it makes it hard to share the login with others). Once you have created a user, any test you run will be available to be retrieved via the “Test History” menu choice, which allows you to see how your site is faring over time. It’s common in the lifecycle of a site for it to slow down over time as various enhancements are made, each slowing the site down a little. Of course, if the site has an FPC that will usually be sufficient to stop that from happening.
Once you’ve got your test result, look for the “First Byte” column which will show you how long your site took to display on the First and Repeat Views. You’ll want to run a number of tests to be confident of the result.
Rate of hits is critical
Even a fast server has a limit on how many simultaneous page hits it can cope with. A fast server may present pages very quickly when it is quiet, but the cumulative “compute time” for each page hit can make it very slow. This is where a caching plugin is at it’s most effective – it allows the server to compute a page once then just present it from cache without re-doing the computation every time the page is displayed. This can allow the same server to process hundreds of times more page hits simultaneously without suffering an impact on speed.
One small trap is that it’s very easy to turn the page cache off and forget it’s been turned off. While this doesn’t result in page hits being slower initially, as soon as the site experiences load you’ll see it get many times slower. if you have a large site, you may be able to get your developers to ensure that the page cache is re-enabled every hour or so, to prevent it being left off.
Summary
If you advertise on TV or radio or social media, it’s essential to have a page cache active on your site as it wil ensure your potential customers all get to see your pages, and see them at top speed.
* Note for techies: This article has discussed using a Full Page Cache module, which is only one method of making a site faster. There are other methods, chief among them being using the Varnish server caching mechanism. Varnish works well, especially for Apache-based servers, but can take more work to set up. An FPC with a fully optimized server offers speed benefits that would be considered similar to the benefits of Varnish, especially if your server uses a web server technology like nginx that is fast for static pages and runs PHP in some cacheable form (such as FPM or DSO).
References:
- How the full page cache works in Magento 2: https://inviqa.com/blog/how-full-page-cache-works-magento-2
- Reasons why website speed matters: https://www.bitcatcha.com/blog/2015/6-reasons-why-website-speed-matters-how-amazon-would-lose-1-6-billion-if-it-slowed-down/
- How loading time affects your bottom line: https://blog.kissmetrics.com/loading-time/