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.
All of the familiar suspects are in there – asset concatenation and minification, deferring “below-the-fold” content, ensuring browser caching is configured correctly, removing render-blocking Javascript, etc.
What interested me was not so much these original tips, but a comment noting that the mod_pagespeed and 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.
However, one thing you can’t do is get anywhere near the configuration files for the web servers. While the team over at Shopify certainly do their best to make sure they serve pages quickly, they’re limited by the lowest common denominator – they can’t alter server configurations to give a few stores the benefit of, say, automated Javascript deferral if there’s a chance it will negatively impact others. Obviously this is also the case for any other hosting platform over which you have no control.
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.
With the ever-increasing layers of abstraction and framework being piled on top of good ol’-fashioned HTML, CSS and Javascript, it’s easy to lose touch with the fundamentals. Every time we add jQuery, a CSS preprocessor, HAML, the Rails asset pipeline, or a tool like the PageSpeed modules to our workflows, we take one step back from the “real” web environment – the stuff that browsers and servers actually deal with – and make it harder for ourselves to fully conceptualise how our pages hang together.
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.
If ngx_pagespeed isn’t available, I know how and when I can defer my Javascript using 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.