Improving Your Site’s Load Time With PageSpeed Insights

        
We love optimization at CodeClouds. Fast web pages are better web pages: they perform better on SEO, and they have a significantly higher customer retention and conversion rate. One of the fastest and easiest ways to audit your site speed is using Google Pagespeed Insights. Simply insert your site’s URL into the field, click ANALYZE and then …         
          

We’ve worked hard to get our number high, but you’ll notice it isn’t 100 and I feel it’s worth hammering in the following: it is okay to not hit 100. If you had a website with no images, text, or any content at all, it could score an easy 100, but you’d hardly call it a perfect site. It’s not the be-all and end-all either: there’s a strong correlation between PageSpeed score and side load speed, but it’s not 100% correlation—some sites can score relatively poorly and still load very quickly. 

“So why use PageSpeed Insights at all?” I hear you cry. Because it’s one part of a broader optimization toolkit that includes Pingdom, YSlow, and GTmetrix. It’s a great way to tell how well-optimized your site is, it’s just not the single definitive tool; nobody calls a screwdriver a bad tool because “it can’t do nails”.

Different tools will test for different things, and critically they’ll test from different places. A landline connection in rural Montana is going to load your website very differently from a fibre cable in Seoul, and each tool tests from somewhere different—most will have servers around the world to test from. 

A big problem arises when ‘around the world’ doesn’t give you a good picture of what’s actually going on locally; I’m in Wellington, New Zealand, and my closest Pingdom server is in Sydney, Australia. That’s 2000 miles away, in another country, with wildly different internet infrastructure. They have a server in Washington DC and you’re likely to get extremely accurate results if you’re in WA, but the further you get from their servers the less accurate the results are going to be. When I ran a speed test using GTmetrix this morning, it chose their server in Vancouver rather than their server in Sydney, and got even less accurate results. 

Of course, you might not want to test locally: if you’re a company primarily selling to clients overseas, then you might want to know how your actual customers are going to receive your data. I use Host Tracker for that—their interface is a little bit retro, but they’ve got a huge number of servers around the globe and they’ll let you do some fine-tuned location testing. 

All of these testers use different metrics and create different data profiles from different locations, so—obviously—they’re going to give different results. Some of them will give you an A+ and some of them will give you a C, and that’s just sort of the nature of the beast. You don’t even always get the same results from the same tests: I took that screenshot of our results late last week when I started writing this blog, and I ran another PageSpeed test this morning and it gave me a 90.

        
That’s a difference of three days and relatively few changes to the website.  I hear you asking: “if the results are this unreliable, why am I even testing?” 

Because, as mentioned, each test is a different tool in your toolbox. You’re not trying to ace just one of them, you’re trying to get consistently good results across all of them. Note I said good, not perfect—trying to attain perfection will drive you insane. The better rule is this: try to get decent results from as many tools as possible. If multiple tools are all throwing the same issues at you, then start giving those issues serious consideration. Speaking of: 

Now we get into the fun stuff. 

We’re going deeper into the technical side of things in this article, but if you want some simple fixes, we put together a guide to web speed optimization last year that covers the basics. While this article covers issues you’re going to see in your PageSpeed console, that guide hits a lot of broader and simpler issues—it’s good to check off to make sure you’ve got all your bases covered.

When your site goes to run any <script>, it pauses HTML loading while the script is downloading and executing. If PageSpeed Insights or GTmetrix tell you to “remove render-blocking resources”, this is one of the big ones. 

The easiest way to do this is using the defer attribute. This will allow HTML to continue loading during script download, and will execute it after the rest of the site has loaded. This is your fastest and most direct option, but it’s not always viable;  if the script needs to run before other elements have loaded, the best option is the async attribute.  Async will pause HTML loading during script execution, but will allow it to continue loading while the script downloads, and this can give you a significant speed boost. 

Adding JS (and CSS) inline can sometimes help in these circumstances, but only for very small sites—any sufficiently large site will hit a certain amount of JavaScript where making everything inline will only make load times worse. We don’t recommend this method unless you’re very light on JS (and CSS).  

If you’re on a CMS like WordPress where editing code directly can be difficult or cause issues, you might need to find a plugin that gives you that functionality. The plugin will vary from platform to platform and we’ll be here all day if we go through them all, but the keywords you’re searching are ‘async’ and ‘defer’.  

Your CRC is the path that a browser has to follow in order to load your site. Take a look at this chain from the CodeClouds main page:          
        
The page itself loads, then the first thing that happens is we send out an API request for the web font IBM Plex Sans, THEN the font loads, then we request Roboto Slab, then the font loads, and so on (as a sidenote: despite the higher number of requests, web fonts are great for reducing load times). Your CRC will execute in the order given, and if it contains large blocks of JS or CSS then they can hold things up. Defer and async are one way to handle this, but you can go a bit deeper and fine-tune here, pushing any larger (and/or noncritical) resources down the chain. 

When you put your site through PageSpeed Insights, if there are CRC issues then you’ll see this:

        
and if you fold it out you’ll see the offending chain and know what you need to tidy up. 

Outside of poorly-optimized images, JS and CSS are two of the biggest culprits of slow load times. Refactoring your code can be a lot of work under the hood, but can really help you squeeze out those crucial seconds. If you don’t want to do this manually, I suggest using cssnano for CSS and UglifyJS for JavaScript. There are a lot of tools out there to help with this, but those are the two recommended by the official PageSpeed documentation and they’ve served me well. 

3rd-party scripts like analytics and ads can be a major source of slow load times. I remember one blog I was asked to look at that was absolutely squeaky-clean under the hood but had a massive 14-second desktop load time. After a little more poking around I realized that the blog owner had installed dozens of 3rd-party buttons and scripts to give his site full social media integration. He had a very nice Twitter bar along the side of his site, but I think few people ever actually saw it because they closed the window before the page could load. 

That’s an extreme example, but it’s important to keep track of anything 3rd-party you’re running on your site.          
        
Our own report is interesting because the main thing blocking the thread is AMP, which actually speeds up our load time. Remember when I said you shouldn’t try for 100? This sort of thing is part of the reason why—a major hit to our score comes from something that speeds up load time and improves user experience. It’s important to read and analyze your PageSpeed report, rather than simply looking at the score and trying to get it as high as possible. 

That won’t always be the case, though: sometimes a poorly-built ad service will be holding up the entire CRC for so long that your users leave before the rest can load; sometimes an ancient Twitter sidebar will be adding seven seconds’ load time to every page on the site. 

Ask yourself, have I: 

And that’s it for now. It probably won’t get you to 100 on your PageSpeed report, but it’ll do something much more important—it’ll improve load speed and UX, and help your customers access your content more easily. 

        
Hey, you! Web developer! Are you looking for work? CodeClouds have great web developer jobs in the US and India. If you’re passionate about web page optimization and want to put your skills to the test, don’t be afraid to get in touch.