Optimising Pages the Hard Way
I recently came across an article by Dan Riti, “Breaking the PageSpeed Barrier with Bootstrap”, which examines ways to improve the performance score of pages analysed by Google’s PageSpeed Insights tool.
What interested me was not so much these original tips, but a comment noting that the
ngx_pagespeed modules could implement all of these optimisations – and achieve a PageSpeed score of 100 – with only a few lines of configuration. (Dan later updated the article to highlight this.)
These two modules are indeed great assets and huge time savers for any web developer looking to improve sluggish page load times. Just copy and paste a few PageSpeed configuration lines like this and your optimisation task is done!
Of course, as you may have guessed, I don’t think that’s the end of the story (otherwise, this post would be over now and you’d be free to get back to whatever it was you were doing). I think there are a couple of reasons that folks should read Dan’s article (and other articles on page optimisation) in detail.
1. Sometimes, you can’t touch the server.
A lot of the work I do is based on the Shopify eCommerce platform. I think it’s great, and there’s really very little restriction on what you can do with your store through the site templating system.
This also crops up in cases where not only do you not have access to server configurations, but you don’t even know where your page is going to be hosted! Designers want to build themes for sales to varied clients and developers want to build web apps that can work in a range of environments, without knowing in advance where they’re going to be running or having any control over them when they do.
In situations like these, if you want to make sure your site’s fast (and you should – it’s important), you need to take a more manual approach. This also leads into my second point, which is that…
2. All the time, it pays to know what you’re doing.
God forbid you think I’m now advocating we hand-craft every single line of our pages from scratch. I love being able to drop a plugin into a jQuery project, or nest my selectors in SASS. That said, I feel like I deal with the substrata underlying these tools often enough that I understand what’s happening if something goes wrong, or I need to restructure my site in order to take advantage of a new technique.
async, and when it needs to be synchronous. I can write a simple
asset_url filter to my Jekyll blog to generate cache-sensitive URLs for my static assets. These aren’t difficult or complex tasks, but they would become just that little bit harder for me if I’d always just had someone else do it for me.
So, hats off to the PageSpeed team at Google! They’re doing awesome stuff and the PageSpeed modules are certainly a great tool for web developers to have in their collective belt. My only hope is that we remember the principles underlying these powerful tools, so that we can still deliver for our users when we can’t bring them along.