Insurance Chat Performance Improvements

Today was all about performance optimization for some of my clients.

I will be sharing some of the sites’ scores in a series of posts.

The first site to be written about is http://www.insurancechat.co.za/. This was not the first site I optimized but will be the first one to be discussed. Before I started with any optimization, I ran a test on gtmetrix.com to get a baseline score. At the very least I just wanted something to compare against.

Page Timings

As seen above, the Time to First Byte (TTFB) started at 1.7s which is very bad. Running Google PageSpeed Insights, you would usually get an error stating that you should reduce server response time. There are various causes for the slow response, but the likely culprit is the use of a badly written theme or badly written plugins. The easiest solution would be to use some form of caching plugin. After trying various solutions and configurations I finally ended up with a TTFB of 0.7s which is a saving of 1s. This may not seem like much, but it is a decrease of 58.8%.

The Onload Time (OT) is a common metric used to gauge website performance and in terms of JavaScript, this means how long until the window.onload event is triggered. The OT is affected by the number of resources loaded by a page as well as the size of those resources. Requesting a lot of stylesheets, images and scripts will cause the OT to increase. The easiest improvement you can make is to reduce the number and size of your page’s resources. Combining and minifying your stylesheets and JavaScript files will have a massive impact on this metric. You should also consider removing any unnecessary scripts and styles and by extension, plugins. With WordPress, this is an especially common issue. Insurance Chat’s OT started at 7.0s and after some tinkering, I got the OT down to 4.7s, which is a decrease of 32.86%.

The Fully Loaded Time (FLT) is just what it sounds like. How long the page takes to completely fetch, compile and render. There isn’t much I can say about this one. Even with all the improvements above as well as all the improvements below, I was only able to reduce the FLT from 7.3s to 6.9s, shaving off 5.48% of the time. I am certain I can reduce this by removing more images from the homepage, but as of now, I am quite happy with the page’s performance. I will maybe revisit this in the future.

Page Size and Request Count

The site started out making 80 requests on an empty cache and hard-refresh. After combining files, modifying widgets and jumping through various other hoops, I got the requests down to just 52 on an empty cache. On subsequent page loads, only 4 requests are made! So that is a decrease of 35% during the first load and 95% on subsequent loads.

The HTML Size (HS) is the actual size of the HTML document sent to your browser by the server. This excludes any and resources. The number of HTML nodes in the document, the amount of text on the page as well as comments and whitespace affects the end-result. The simplest method to reduce your HS is to reduce the number of HTML elements on the page. If you have a banner or post slider, consider displaying/fetching only 3 posts instead of 9 as users will most likely never see the other 6. You can also utilize HTML minification, but that should be used with caution as many plugins rely on comments in the HTML to function correctly. We started out at 18.4KB and ended at 15.2KB which is a decrease of 17.39%. Nothing to write home about, but the fact that performance is a feature means every byte counts!

The Total Page Size (TPS) will be the size of the entire page including all resources when the page has completely loaded. You should always try to keep your page size to a minimum because smaller pages load faster and also save your website’s visitors’ time and bandwidth and by extension money. The homepage loaded 1.40MB in the beginning on an empty cache and after doing everything above I was able to reduce the TPS to 1.15MB and saving 17.86% on bandwidth. On return visits, only 134KB of data is transferred resulting in a decrease of 90.43%!

PageSpeed and YSlow Scores

As a summary, I will quickly mention the Google PageSpeed (GPS) scores as well as the Y-Slow (YS) scores and the difference all the incremental improvements resulted in. I started out with a GPS score of 74, which is not actually that bad, and ended up with a score of 85. A nice increase of 14.86%.

The YS score was a pathetic 65%, but with a lot of work, I was able to bump that up to 91. That translates into a massive increase of 40%!

Note: Any tool used to measure performance will give you varying results and should be considered a guideline rather than a truth. There are a lot of factors to consider when looking at website performance and your mileage will surely vary from mine. The same goes for SEO tools, but that is a topic for another time.