Page Speed Optimisation

Introduction

It would be fair to say that in our industry, PageSpeed is often something that is overlooked until the end of a project as an afterthought. However, what happens if you give this statistic a little more priority and built with it in mind right from the start? Well recently we have done exactly that.

Initially we were going to do some work for an existing client on their ExpressionEngine website and decided that before starting on the updates, we would move the website into CraftCms and also update the whole hosting environment. We did this proactively for our client and were able to find some quick wins very early in the rebuild which helped to justify it to them as to why it was needed.

The Lay of the Land

For the hosting we were using a dedicated server running plesk which also hosted a few other websites that we manage. This particular site was running on php 5.6 and ExpressionEngine 2, it is from a time before layout files where the templates are full of stash variables, snippets, and embeds. This can make it quite convoluted at times to see where you are needing to make changes in the code.

As this site was built a few years ago, it has areas that require some serious improvement. Website development has come a long way over this time period and the way in which we do things has moved on a little. There are always multiple ways of solving a problem and I firmly believe that if you look back at the code you wrote a few years ago and can’t see any flaws, then you haven’t progressed as a developer.

Benchmarking

Our first task before we get started is to measure the speed of the current website. This sets our benchmark and allows us to test if we are truly improving the performance of the site. For this task we use a number of different tools but the main ones are as follows:

Google Pagespeed Insights (https://developers.google.com/speed/pagespeed/insights/)

Pingdom (https://tools.pingdom.com)

WebPageTest (https://www.webpagetest.org)

GT Metrix (https://gtmetrix.com)

Out of the above tools, we tend to use Google Pagespeed Insights the most; we still use the others as they can be very important for understanding server setup, but we don’t check them as frequently. Our initial test on Google Pagespeed Insights is actually giving us a fairly low score. This is a high traffic site in the summer season so finding a low pagespeed score is not good. But it does however give us the opportunity to show large gains to our client if we can fix it. The initial benchmarking results are shown below:

As you can see from the above screenshots, we have a poor score of 21/100 on mobile and 23/100 on desktop so there are many improvements that need to be made. Some of our tasks are in the code, whereas others are around the hosting environment.

Our next test we perform is through the pingdom service. I have obscured the website url and preview image for the purposes of this blog article.

As you can see we have a performance grade of 67 out of 100. This is coming back as a better result than our first test but we can still see some suggestions for optimisation. This is why we use a few different tools because we get a good spread of suggestions of where we can improve the website.

Our last two testing tools are a little different to the first two as they are more suited to testing the server rather than the front end of the site.

As you can see in the image above, it is all about the server statistics of how long it took to load the page, as well as what resources were used by the server. Our final test on GT Metrix is as follows:

As you can see, each of these 4 services will offer us suggestions on where we can improve performance. A few of these have already become part of our internal processes when building a website since this one was originally built. So now lets get started with making our changes.

Craft CMS

Earlier I mentioned that we are moving away from ExpressionEngine 2 and rebuilding the website in Craft CMS. It quickly became part of our standard set-up on new builds, and with industry SEO experts like Moz now using Craft CMS, it is a CMS that is gaining traction and recognition.

We find it a joy to work with, as all those stash variables we mentioned before are no longer needed, we can instead just use Twig. We no longer need to worry about parse order, or loops within loops to access a single attribute, or using an embed to load a new object model within a loop; some of the pain-points of working with ExpressionEngine. All of this is handled by Craft CMS and Twig in a better way than ExpressionEngine ever could in our experience. Straight away we are cutting down on the number of times that we spin up the server to process a template, or call in a plugin when dealing with a single page load.

When using crafts native caching tags and plugins such as Imager and Minify, we are already dealing with some of the suggestions made during our benchmarking phase. When you add in the benefits of having a native live preview and how powerful SEOmatic can be, it is a good upgrade for our clients also. We don’t want to end up in a position where we are rebuilding the website into a different CMS that offers less to the client but more to us as developers. Craft CMS in this case, is the perfect tool for the job.

Let’s Get Critical

You may or may not have come across CriticalCSS already, but we have recently started implementing it and now try to use it wherever possible. Effectively this is a gulp task on the server which is used to load up a number of pages and process the 'above the fold' CSS rules. These rules are then saved to a generated file, one for each template, and we can call this in at the top of our template to inline these rules.

Craft makes this relatively simple to do and a great article on how to do this can be found here: https://nystudio107.com/blog/implementing-critical-css This is the best solution we have found for the “Eliminate render-blocking JavaScript and CSS in above-the-fold content” suggestion made by Google PageSpeed Insights.

Servers

As our old dedicated server is getting on a bit now, we have started using Digital Ocean droplets running php 7.1. These let us scale up and down at will and use cloud based technology instead of static hardware. We have been using a tool called ServerPilot to set up our servers and manage them; more recently we have started using Laravel Forge to do this for us. Having new architecture will be a good start for us to improve our server's speed results which were found to be rather poor during the benchmarking phase.

Progress Check

OK, let’s run another benchmark and see how we are doing. By this point we have rebuilt the site in CraftCMS, moved to a new hosting environment, are using a newer, more efficient version of php (from 5.6 to 7.1), applied CriticalCSS, created some htaccess or nginx rules (whatever your flavour may be) and addressed as many of our benchmark suggestions as we can. First up is Google PageSpeed Insights, we were seeing a result of 21 and 23 out of 100.

As you can see we have increased our scores to 97 and 98 out of 100 now. The server response time is at 0.2 seconds; this could be addressed by scaling up our droplet, something we couldn't do on the old servers. As for leveraging browser caching, the files it has flagged come from Google and Facebook; as they are not from our domain, we cannot set any htaccess or nginx rules to cache them. So this will probably be as good as we can get it without removing the files all together, but we need them in place for our SEO and remarketing campaigns. OK great, that is a really good start; let’s check the rest of our tools.

Pingdom is now also showing a similar improvement, there are still some suggestions for improvements which we can look at a little later, but for now the rebuild looks to have made a huge dent in the page load times. Now to look at our server with the last two tools and see how moving to Digital Ocean and Laravel Forge has impacted on our hosting environment.

OK, so it looks like we have exchanged those Fs for As. Technically we are using a CDN, but it is a subdomain of the website and not a recognised service such as Amazon S3. This will come later though when our client has given the go ahead for S3 under their own account for billing purposes.

And finally, we have GT Metrix; we can see that there is still some work to do highlighted by the YSlow test but overall we have made a huge improvement from where we were.

Outcomes

The website has not changed in appearance for its end users; the backend however has vastly changed and we feel that Craft CMS is an easier CMS to use for our clients. We can see that our benchmarking comparisons have overwhelmingly indicated that the new site is an improvement, but what does that actually mean? Are these just meaningless numbers or do they have a real world impact on the business?

Well, we can see that our page load speed across our tests has dropped from an average of 7.4 seconds down to 2.9 seconds. We can also see that our average page size has decreased from 4.2MB down to 1.3MB. This may not mean much for us working on high powered machines using fast fibre broadband connections, but in the real world when someone does a Google search on their mobile phone whilst outside on a 4G (or even 3G) connection, it is very noticeable.

By making the page load faster and reducing the size in megabytes, we are making it more likely that someone will not get frustrated and go elsewhere. With a drop in bounce rates and a faster page load, we can safely presume that the site will generate more business for our client. A fast and smooth process can also help the conversion ratings as people don’t get frustrated with a slow loading basket page. People have little patience when browsing on their mobile; they want their information quickly, and to be able to make their purchase as painlessly as possible. And in the case of our client's customers; they are usually holiday-makers or day-trippers, so are normally out and about and busy doing other things; they don't want to waste time waiting on a website to load.

We have done this for a number of websites now and can see that cart abandonment has dropped along with the bounce rates also decreasing. This leads to a happy client after you’ve been proactive in making these changes to their site. For certain circumstances and clients, it may not be beneficial or a good use of time to change the CMS or move the hosting environment. The tools provided in this post will still be able to highlight some areas for improvement though. It may be as simple as adding a few htaccess rules that you never knew about. Let’s all make the internet a better place to be, one fast website at a time.