A while back I did a Google PageSpeed audit on my website, and documented the process of how I went about fixing some of those issues that came up. 2 years later, and I'm back in the red it looks like. It comes with the territory. What was fast and amazing at one point, is slow and historic the next. If your website is in the red, feel free to follow along and maybe we can resolve some of those issues by the end of this post.
So maybe it's time to take a look at performance once again. Hopefully in a more detailed format for anyone out there with a website with similar issues. I don't foresee this being too much of a hassle, just because the normal issues usually have to do with file caching, minification and resource sizes. Most of which I already handle, but maybe I haven't been keeping up with it lately.
So hopefully by the end of this post, my 64 will turn into at least a solid 80. So let's begin first with what went right.
aiming for that 80
My UI is solid apparently. Awesome to see. Essentially, everything is set to take up the viewport on mobile. And anything that's too large or complex, I don't render for mobile. Buttons are spaced further apart and are made larger for easy clickability as well. That seems to be good enough to grant me a decent User Experience score.
As far as performance goes, the following criteria were met. And again, this mainly deals with file size and minification, which there are many different tools out there that you can use. I personally use my own, as it is built into my deployment process. Much of speed on websites has to do with how your website is set up and the kind of caching software that it is using.
These are mainly going to be for mobile users, as everything is mobile first nowadays. So this really depends on the type of traffic that you are driving to your website. If you're marketing towards a mobile market, then for sure having your site run efficiently on all of the many different devices is important.
Leverage browser caching
Let's start with browser caching, as this is the simplest of the issues to fix. Mainly because we just need to configure our servers to handle it for us. This is essentially all about Expires Headers. These little guys tell the client when to fetch a new copy of a resource, such as an image or a CSS file.
This is primarily for repeat visitors. Static content, like images, do not need to keep getting loaded from the server on each and every visit. Those rarely change, so for our repeat visitors, we want their browsers to do some of the dirty work.
I have a few files on my blog that have short expire times, and some are out of my control, such as the Google fonts. But the rest for sure I can do something about.
This one is going to depend on the type of server that you are using for your sites. I'm using IIS personally, so in order to set the expire ages for static content I'll need to make sure that the following directive is included in my web.config file.
<system.webServer>
<staticContent>
<clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="365.00:00:00" />
</staticContent>
</system.webServer>
By default, this is was set to 1 day on my site. But the longer the better I feel. I rarely change images on my website, and for performance reasons I've been minifying and inlining css and javascript, so the cache really isn't too impactful for these files.
And because I like to test everything incrementally, I'll be running the audit once more at this point to see what it has to say.
Excellent. It looks like everything, but the ones out of my control, have been cleared of that pesky warning. And we're slowly climbing to our 80 mark. It's sometimes that easy to improve performance on websites. But we're not finished just yet.
Render blocking?
So it looks like I have 2 CSS files getting loaded in my <head> section causing this warning. Because now, no one loads CSS in the head. You'd be crazy to do so. You minify and inline your entire CSS file. But because I have to resolve this issue, let's start with the Google Fonts. First off, am I using this font anywhere? I am. In one place in particular, and that's pretty much it. So goodbye to you Google font. That's a big part of performance too. Sometimes your websites get bogged down with files, scripts and resources from days long forgotten.
where would I load the font though...
If I were attached to said font however, and I needed to render it, where would be the appropriate place to load said font?
If you look at Google's documentation, they position their fonts right above in the head section, like any normal programming human would. But then if any above the fold content were to use said font, Google would ask you to correct it. Oh Google, how you jest.
Many people will tell you many different things. And you can spend weeks on the most "perfect" solution. Personally, I just want to use that font and not have it impact what Google thinks is a "fast" website, as later on that could effect SEO and such.
So for now, I'm going to be adding my font links down below to the bottom of the page. A few things to note however. If any content above the fold is indeed using that font, you will notice the font flicker from default to it's new one. It's a slight issue, and most people probably wouldn't even notice it. I notice it however, so I could also consider loading my content that uses that font, only after that font has fully loaded.
The exact same applies to my other resource files such as CSS and JavaScript. I'll be pushing those to the bottom of the page as well. And again, the site will have a particular flicker for now as it is loading the styles after the elements have rendered. For now, and for me mainly, this is perfectly acceptable.
Let's run it again
And there we are. That was a much shorter journey than I had hoped, but I'll take it. There are still some other areas that I can improve upon, but with a 94, I think I'll take the win while I'm ahead. So there you have it. With just a few slight changes to how you render your content and when you render content, you can improve performance on your website by a fair percentage.
Optimize Images
Because my website isn't particularly image heavy, or high res image heavy I should say, I'll leave this warning right where it is. However, if my website was a photo sharing or gallery-type site, then for sure I would want to make sure that they were as resource light as possible in order to reach a broader audience.
Is my website going to go viral now?
Probably not. While having a fast website is for sure something good for both you and your audience, it's not quite important enough to catapult your website to the top of search results rankings unfortunately. And while nobody (regular folk) knows just how important speed is to search results, it's always better to at least be somewhat competitive in that race than not.
Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.
Stay up to date
Sign up for my FREE newsletter. Get informed of the latest happenings in the programming world.