One of the things that makes professional life better then that of my youth has been the complete lack of grading your work. I suppose we still are tested and graded, but it’s different then the stark, cold number or letter scribbled on a page that either justifies or diminishes your efforts. That being said, there isn’t anything like an arbitrary number grade that somehow motivates you to just do better.
Enter Google’s Page Speed Insights and HubSpots Website Grader. Just like that no nonsense teacher you always disliked in middle school, they grade your web site performance with no emotion and little care for the level of effort, complexity or love you poured into your project. It’s all about the numbers for them. You can imagine my disappointment when my partner sent me a nice little screen shot of our website showing an 84% on Website Grader. Lucky for me, she never looked at the dismal 50 we received from PageSpeed Insight. And so began my complex relationship between these two tools.
Let’s start by breaking down what these tools are and how they work.
PageSpeed Insights is a tool that developers can use to see their web pages look to Google in terms of best practice coding, technical performance and content delivery. It will judge your site based on desktop and mobile standards, that have different quantifiers. What’s interesting is that it will also look at UX best practices and factor them in to it’s overall score. It will look at redirects of your domain – if you have a “www” prefix or are redirecting to “https” protocol or maybe have two domains resolving to a single domain, you get dinged for it. For example, we have two domains, narwhal.digital and narwhal-digital.com with the .com redirecting to the .digital. When testing the .com address we receive a lower score then if we just put in the main domain of .digital — even though it’s the same code base.
PageSpeed Insights also looks at if you’re minifying your scripts and styles and if your images are optimized – not just compressed by actually optimized for the space they’re occupying.
Overall, Website Grader is much more fun with it’s cheeky tone and well designed graphics. It’s analysis is more geared toward SEO and less toward page performance, like Page Speed Insights. To factor your score, it will look at and assign points for Page Performance, Mobile, SEO and Security. If you’re lacking an SSL, you automatically lose 10 points. Like Google, it looks at number of requests and render blocking scripts. It will estimate the time it takes to load your site, but I have found this to vary widely from time of day and not to match up with what I see when using network performance monitors. Funny enough, unlike Google’s tool, it looks to see if you have page titles, meta data and headlines. Most of these metrics are easy to hit and net you a decent score. Of course it’s performance that will usually drag you down.
This is no easy task. If you run a preprocessor to compile your SASS or LESS like Grunt or Gulp, you can set it up to concatenate all your resources into a single CSS or JS file. Both Grunt and Gulp will also minify your files be default. This is the first step to lowering your page requests. If you’re using WordPress as a CMS, there is great little plugin called MinQueue that can also help with this.
Lowering your image count however, is a much harder task. If you’re using images in CSS, you can switch them to use Data URI’s as opposed to the standard image path. Doing this will basically write the code that renders the image directly into your page, eliminating a page request! If you have a static site, you could employ a sprite sheet, however for a CMS driven site, sprite sheets aren’t all that practical and you’ll have to work around the images your placing in your page. One nifty trick, which is most certainly a trick, is to make sure you are using source set when calling your images. Not only does it help to choose the correct image size for your screen, but Website Grader doesn’t recognize this a true image call. Or maybe it does and it just likes it more — who knows, but for now, using it will dramatically reduce your page requests. One last trick for for SVG images, which are basically XML data anyway, is to convert the uploaded image to a data string instead of calling out to the svg asset. This takes a little bit of code work, but will end up saving you another page request.
From Google’s perspective, we had a huge problem with our images. It was flagging nearly every one as being oversized. We are using retina sized images, which are basically 2x the size they need to be and then shrunken down to their final size. Needless to say, Google did not like this and wanted our page to serve up standard size images. It’s a known issue for page speed insights, but on the flip side, fixing it might dramatically decrease our page weight and increase our overall score. The answer to this one was simple. Since we use WordPress, it can generate various image sizes for a single asset upload. We just needed to make sure our sizes were correct — it’s good practice to do this anyway. Now this will only get us part of the way there. We’ll get our standard resolution images at their correct sizes, but we still need our retina images. Using a script like Retina.js or Picturefill.js are two great solutions, but with WordPress, we wanted it be more streamlined then maintaining two images. This is where a plug in like WP Retina 2x comes in handy. Basically if you upload retina sized images, this plug-in will generate and serve the sizes accordingly using a variety of methods. It’s dead simple and just works. Consider is running all your assets through a compressor tool such as Tiny PNG. This will compress all your images in a magical way and can even be added straight into your WordPress workflow.
If you’re using something like Google Tag Manager, you may have another issue where any third party scripts will be loaded into the header and cause render blocking. The solution to this largely out side of your control. However, most third party scripts are moving to load asynchronously — which is good for your page and good for them too.
My last bit of advice here is to get a CDN for your assets. There are so many out there, but we settle on CloudFlare. It’s not a traditional CDN that hosts your image assets for you, it’s more like a full on caching and security service. I’m not going to pretend I’m an expert on CDNs and how they work, but basically CloudFlare will take cached versions of your pages and distribute them to it’s data centers all over the world so when your site is requested, it’s pulled from a data center that is closer to the source of the original request. It also adds a shared SSL into the mix, which great for sites without one, and will minify not just your CSS and JS files but also your HTML files by default. There are also a bunch of other little things it does, like concatenate your javascipts, automatic image compression and optimized image size delivery based on device size. All of this makes your site faster, more optimized and more secure.
Every website is different, there is no “one-size-fits-all” approach for site optimizations and some site owners will be ok lower scores if the reason is justified. These techniques are the basics, and with them we were able to raise our Website Grader from an 84% to a 97% and our PageSpeed Insights from a 50 to an 88. We’re still working and optimizing every chance we get and we’re always ensuring clients have the best possible site they can get.