Partner Helps S.A.R.T. Shake off the Shackles of Slow Sites

When we graduated St Francis Xavier College in 2017, we didn’t think we’d be back here writing a blog so soon. The great wheel that is the S.A.R.T. keeps turning, churning out iteratively better robots every few months. But one element of the project has been stuck in the past since we first built it in 2016 – and that is our website.

It seems strange that it has been neglected for so long. After all, it won us the inaugural Open Source Award in 2017 and again in 2018. So why does it still ask visitors to download 50 MB of data and wait 30 seconds to load?

The Old Site

Enter Qirx, a Canberra-based systems integrator and St Francis Xavier College’s preferred IT provider for 5 years. More recently, Qirx has become a partner of the Semi Autonomous Rescue Team and employer of our own Alumnus Aaron Maggs.

With Aaron’s help, the Semi-Autonomous Rescue Team was able to secure a sponsorship with Qirx. Qirx has provided hosting space on one of their servers to host our new site, free of charge. Delivering blazing fast speeds (especially to the Canberra region where we are all based), this was the perfect first step and reminder to bring our site into the current era for 2019.

Qirx made this site optimization possible.

Server Hosting Sorted: But it’s only the first step. We need a WordPress theme built with the modern web in mind. Infinite is Goodlayers’ new flagship theme built on a new framework with their third generation page builder that makes the old Versatile page builder seem clunky and outdated.

Theme installation went smoothly. The honour of clicking the “enable” button went to Connor, who then worked with Aaron to get the navbars and sliders perfected in less than 2 hours.

Look familiar? Our new site is designed to provoke nostalgia with an updated yet familiar theme.

The Site had a Fresh, New Look: But it still took almost as long to load. That’s where I came in. Using GTmetrix, I started working through the most prominent issues.

The first to be tackled were unnecessary redirects – in other words, going straight from “” to the default secure “” without visiting the non-SSL “” in between. This was done with a few simple lines in the .htaccess file. The fix shaved a few seconds off the site load time since the browser doesn’t have to wait to resolve an unnecessary redirect.

With that working, I changed tack and started resizing the images used on the homepage – including the 185 images used in the blog section. As they are resized by CSS to 340px in width, anything larger was unnecessary. Images varied wildly from a few kilobytes to, in one case, 18 megabytes. This process, although it took all day, shrank the homepage from more than 45 MB to just under 8 MB, and with it went a considerable chunk of loading time.

I invested some time in configuring the WordPress plugin “LiteSpeed”. Its flagship feature is a fast page caching system, however since that requires additional serverside software, I left it disabled. I’m glad I didn’t uninstall it immediately, because everything else it does is brilliant. We now have automatically optimised images, minified CSS and JavaScript, combined CSS and combined JavaScript all across the site, just to name a few of the features.

The site was loading fast, and a tiny 4.5 MB in size. We could continue like this for many more years, but one underlying problem remained. Because we wanted to stick with our one-page design, every time we post a blog, another image gets added to the homepage. Eventually, the site would grow back to 45 MB in size, and it wouldn’t stop there. There’s only so much compressing of images that you can do. So, what if we didn’t load images that the user can’t see?

That’s right. Thanks again to LiteSpeed, we implemented lazy loading. This was something I had wanted to do for a long time, far before we changed our theme. I’ve said since the beginning that lazy loading would be the single best thing we could do for site performance, and in a few clicks, we went from this…

To this.

Lazy loading only loads the images that the browser can see in the viewport, saving on bandwidth and HTTP requests. Since I’d already optimised the images to only 20-40 KB each, the change to the total page size isn’t all that extreme. If I’d done this on the old site, we’d be looking at a drop of about 40 MB. However, HTTP requests dropped significantly, and our PageSpeed score rose to an acceptable “B”.

I found it difficult to set up browser caching, since specifying “ExpiresByType” in .htaccess requires the Apache module mod_expires.c, which is apparently not installed on the server. However, I found a WordPress plugin that could specify browser caching times on the site itself. “WP Fastest Cache” does much the same thing as LiteSpeed (except lazy loading and image optimisation, so we still need both plugins), so I had to disable many of the options to ensure optimal compatibility. After all was said and done, only “Browser Caching” was left ticked – everything else is handled by LiteSpeed.

The Results Are In: Our efforts have transformed our slow, old site into a beautiful modern masterpiece truly befitting a project like the S.A.R.T. GTmetrix provides historical data for all the times I ran their service on our domain. In every case, we drastically improved where it mattered.

Page timings – Lower is better
Page sizes and HTTP requests – Lower is better
PageSpeed and YSlow Scores – Higher is better.
The final results show a vastly improved experience.


The final thing we could do to speed up the site would be to serve our images via a Content Delivery Network, or CDN. A CDN hosts our images closer to end users, so that rather than downloading images from the Qirx server in Canberra, Australia, international visitors could download from a CDN node in, say, a datacentre in France, if it happens to be closer. This saves time on pings and translates to a much faster experience for these far-away-folk.

But that, my friends, is a task for another time.

2 Responses

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.