Working Out What Can Be Improved

Speed. One of the most important parts of any website - but often one of the most neglected.

One of the best articles I've read on this topic, is also one of the most entertaining. David Gilberton at Hackernoon wrote a fantastic piece on what he learned making 'the fastest site in the world'. He opens with the first point, which I think is probably one of the most important:

If all you do is try to make a fast site, you will automatically get a faster site. You have to try non stop, but it's like being a jerk, it's actually pretty easy with a bit of practice. David Gilberton

For this article, I'm going to focus on improving the benchmarking afforded by the Google PageSpeed Insights. To do that, we need establish what our starting point is - well, here they are:

That's OK, I guess. If you want to settle for mediocrity. Let's see what I can do to improve it!

Optimising images

img.circle-of-alex {
    height: 350px;
    width: 350px;
    @include rounded(50%);

    @media only screen and (min-width: 600px) {
        height: 500px;
        width: 500px;
    }
}

Poop. We can't just shrink the image size - it's already at its maximum display size. No worries, let's not lose heart. This is where there are bunch of software pieces that can help you. I use the great Irfan View (and PlugIns). If I open my image in that, and click the "Save for Web", I'm given a bunch of optimisation changes which produce quite a size reduction

What about the other image on the homepage? That's logo.png. It's pretty small and can't get any smaller. Wrong. It can, and by quite a percentage. The image is currently the tiny 2.7kb as a transparent PNG, however, using the same technique as I used on the dashing mugshot, I can change the colour palatte to be only 16 colours and reduce the size down to only 0.7kb.

Leveraging Browser Caching

Now we've got better images, we need to do a lot better with our browser caching. Currently, we've just left our images, CSS and JavaScript etc to the default. Which is to get a fresh copy each time. Most of that stuff isn't going to change that often - so we just need to enable browser caching.

For me, I'm using ASP.NET Core 1.1 (currently), so I can do this via some middleware in the .NET Pipeline like so.

app.UseStaticFiles(new StaticFileOptions()
{
    OnPrepareResponse = (context) =>
    {
        var headers = context.Context.Response.GetTypedHeaders();
        headers.CacheControl = new CacheControlHeaderValue()
        {
            MaxAge = TimeSpan.FromDays(350),
 
        };
    }
});

What about if I change my logo? Or I suddenly decide that drinking alcohol isn't a respectable image to use? If we cache it, then it'll remain the same. That's where we just cheat a little. We add a QueryString to it, to make it cache it now, but then when we want to change it in the future - we can simply change the random string we suffixed.

<img src="/images/cool-alex.jpg?o1n3rgpoxl09291243" alt="The coolest." class="circle-of-alex" />

We can see this in action by using Google Dev Tools. Go to the Network tab and refresh your page. Make sure that you untick the "Disable Cache" box to see how it would normally behave. Then you'll see similar to this:

There are a number of files that still remain once you've done all the browser caching for your hosted files - and that's for files not hosted by you. E.g. Google Analytics. There isn't much you can do about it, without getting the sledgehammer out. One particularly dramatic approach is to copy the file frequently from where the script normally runs from, and then serving it from your website. The trick here is ensuring that you're never long out of date, as in theory, you could find that the 3rd party service fails for the entire time that it is out-of-date for.

The real win here is to look at all your third party implementations and decide: do I really need them..?

Eliminate render-blocking JavaScript and CSS

This requires a significant amount more thought and potential maintenance. I'll cover it briefly here, with some suggestions, but they are for a future blog article or homework for the reader. It is largely about ensuring that only the content that needs to, gets loaded before the page finishes rendering. Some common techniques to resolve this problem are:

• Use defer or async on scripts to either force them to wait until the end, or to start loading, but not to block rendering for them.
• Remove JavaScript or CSS that is not needed for that page. And this is where some of the major headaches come in for a large site and some trade-offs need to occur. It's viable to create separate CSS files for each major page/section of your site, with only the styles that are needed for that page/section. This would reduce the overall size of the CSS file, and the number of styles that need to be parsed before the page can be rendered.