Don't shave time, take chunks from it
Once you've tackled the TTFB of your store, its time to move on to improving the total load time. The approach for reducing the total page load time is unfortunately a little less focused and a little more generic.
There are several principles that apply when reducing total page load time, a lot of those are going to be in line with the suggestions you'll see from the likes of Google PageSpeed Insights and Pingdom FPT.
Like with improving TTFB, we can easily categorise tasks into quick wins and slow wins.
If you remember nothing else, remember this
Achieving peak performance is not a case of following a guide and doing everything it suggests. Just because I'll make some recommendations, it by no means you should consider them gospel. Testing is absolutely paramount to determine whether a change is going to have a positive, neutral or negative effect.Now, please apply this when using Google PageSpeed Insights, GTMetrix and Pingdom FPT. They'll all give you scores, ratings and recommendations - all of which are meaningless if your store isn't any faster.
For part of this reason, I'm going to cover some myths to help undo changes that reduce performance in the real life, but improve performance in synthetic tests. Don't expect ground-breaking new ideas, just some easy ways to improve performance that you might have overlooked.
Total load time basics
There's two simple rules to follow,
- Fewer requests will improve performance
- Smaller sized requests (eg. smaller images, or smaller JS/CSS files) will improve performance
In addition to this, there's two other rules to follow to improve total render time,
- Less CSS (or less complicated CSS)
- Less JS (or less complicated JS)
Uncombine your CSS/JS
JS/CSS combination, in theory, is a great practice; but with Magento can often lead to negative performance. If you take a typical Magento store, there is global JS loaded site wide and there are specific JS files loaded on certain pages only.
Take the following example,
|prototype.js ccard.js ... imagesloaded.js minicart.js
|weee.js msrp.js msrp_rwd.js
|directpost.js centinel.js accordion.js opcheckout.js opcheckout_rwd.js
For a quick win, disable all CSS and JS combine.
For a great solution, its best to combine all the assets that are loaded on every single page, then load in the single assets that are page specific - unfortunately, this is a little more involved, but it is covered in the next article.
There is a technique called losslessly compressing images, this essentially means reducing the downloaded size of an image (not the resolution) without losing any quality. Its a win without any downsides. This means images use less disk space and are served to the customer faster - without losing any quality.
Its completely automated, fast and safe to use - and you can set it up to execute on a nightly cron to auto-optimise new files. Best of all, MageStack does all of this automatically for you. Read more on optimising images.
Historically, we would advocate the use of static subdomains and parallelised delivery. But as HTTP/2 adoption has become more mainstream, the recommended route is now to use a single subdomain (eg. cdn.example.com) and enable HTTP/2 support for content delivery.
Setting up static subdomains is quick and easily implemented, read more on static subdomainsFor HTTP/2 delivery, we recommend using CloudFlare. By creating a single subdomain routed through CloudFlare, you are able to fully take advantage of HTTP/2 multiplexing and their global CDN service.
Reconsider sliding banners
The majority of websites now feature huge sliding banners on the homepage; often simply because everyone else does it, rather than it having a true value add for customers.
Measuring engagement on your sliding banners might actually tell you if customers even interact with them or not. At the very least, consider using lower resolution, smaller images and reducing the number of banners; or consider total removal.
During a peak scenario, you might find it unlikely to fully support your customers by live chat. Disabling it during a promotion, by completely removing the JS that loads it, will improve performance.
Often, the biggest bottleneck in frontend performance isn't your store at all - its the data you are trying to load from remote servers, things like,
- Social data (Twitter feeds, Facebook, Instagram, Share This etc.)
- Tracking code (Google analytics, Google adwords, Criteo, Hotjar, Conversionmonk, CloudIQ)
- Fonts (Typekit, Google Fonts)
Reducing this can make a huge difference on the frontend for the customer experience; a simple Facebook widget alone can add about 15 seconds to page load time. Especially when you should consider the volume of traffic these other sites will be indirectly seeing from e-commerce store's being busy at peak.
Making the decision to evaluate what is really adding value to your site versus adding a social feed for the sake of it, can mean the difference between a 2 second total page load time and a 10 second total page load time.