No one wants a slow or sluggish website. And, no one wants to use a slow or sluggish website. With another lockdown upon us, businesses and their potential customers are more reliant on the web than ever.

Faster websites create better experiences for users, lead to more conversions and sales, and will typically rank higher in search engines (meaning your organic SEO reach will be better).

Optimising a website for performance is an art, and there are a lot of detailed elements that come into play even when shaving just milliseconds from your loading time.

In a recent optimisation for a new client, we decreased their average page load time from 7 seconds to 1 second. What we realised was that going into the fine details of optimisation is irrelevant unless you have solid foundations.

This is where the 80/20 rule comes into play. The Pareto principle explains that in most situations, 80% of the results will come from 20% of the efforts. And this is also true for web performance. In other words, don’t bog yourself down with the details until you have the basics in place. And it’s those basics that usually make up your 20% of efforts.

Over the years, we’ve helped many app or website owners speed things up. We’ve investigated and tracked why things were slow, implemented new loading time baselines before fully fixing up their site. In every case, at least one of the three basics had been neglected: image performance, caching or separation of concerns. Sometimes, it was all three!

Let’s see why they are important.

Image optimisation

Images, decorative or informative, will impact your page load time. There is no way around this – but there are ways to reduce this impact to a minimum.

• Reduce the overall file size. Compress your image, remove unnecessary embedded information and choose the right image format. And finally, don’t forget the relatively new Google WEBP format that will cut, on average, 25% of your image size.
• Resize the image for their maximum display size. An image will usually have a maximum width and height it will be used for, and there is no need to send your visitor a larger than required image. So audit your image sizes, and ensure that your image sizes are optimal.
• Serve optimal images per device/screen. New browsers support a new image tag attribute called ‘srcset’. To keep it simple, this tag allows you to define what image to serve depending on the visitor screen size. For example, using srcset, you can avoid sending your mobile visitor a super-wide desktop optimised image when you know that mobile size will never go above a certain size.
• Serve your images (and other assets) from a CDN. A CDN (Content Delivery Network) will ensure that your image is served from the closest location. The closer your delivery server is, the less time to travel your file have, and the faster they will reach your visitor website.

Caching

Typically, when you’re serving a web page, there are 3 entities at play: your visitor’s browser (client-side), your server (the backend) and your database server.

Someone recently asked me to explain caching without using any technical terms, and the best metaphor I could find was this one:

Imagine you want to bake 10 batches of cookies, all the same flavour. For each batch, you will need to make a new dough with the exact same ingredients. For batch one, you will need to get your flour, sugar, eggs and so on. You’ll also need to get a mixing bowl, scales and some utensils.

If after popping each batch in the oven, you were to put everything back in the cupboard, only to take it all out again 20 minutes later to bake the next batch, this is the equivalent to your uncached website. For every visitor request, you are asking the server to go and fetch some data in the database and making it take it all out again before sending it back to the client.

If, after each batch, you were to leave ingredients and utensils on the worktop ready to use again, this would be your cached equivalent. For every visitor request, you already have prepared what they will need, taking less work and time to respond to them with the information they want.

Caching your server response is the best way to ensure fast response time and reduce the stress load on your servers.

Similarly, you can also cache your assets (images, CSS, javaScript) on your visitor’s computer. This is client-side caching. Adopting a good client-side caching strategy is essential to avoid your visitor having to download each necessary file on every page visit.

Separation of concerns

Everything we’ve talked about so far is reducing the amount of data we’re sending to your visitor. One element often overlooked during development is separating concerns for your CSS and JavaScript files.

Imagine that your website is composed of two parts. One public part (that everyone can see) and one administrative part (where an admin user would go to change copy and images for example). It doesn’t make sense to send all the admin related styles and function files to visitors that are not logged as admins.

Unfortunately, this is something that is sometimes overlooked during development time – where it’s easier to have one file that will contain everything.

Similarly, some pages will have complex functionalities but limited visibility on your website. Maybe it would make sense to extract this complex logic on its own and only serve it when relevant.

So what if my website is still slow?

Once those basics are in place, and only then, should you start to think about other performance improvement techniques. The good news is that most websites or apps can be transformed without a major rebuild or disruptions. So, if you find yourself with a website that is slower than you’d like, or worse – have had visitor complaints about it, get in touch and our team will be able to guide you toward your next steps.