This weekend I wanted to ensure that lansley.com works well on all screens from standard web browsers to mobile and TV. After all I can hardly espouse about the internet of things if my own web site can’t work on them where applicable!
I used the Google PageSpeed web site tester, and all was well in terms of desktop and mobile page rendering. PageSpeed did highlight a couple of issues:
It discovered a rather large image file which I quickly compressed to 10% of its original size without causing any noticable picture degradation – something for me to look out for in future.
PageSpeed also didn’t like the fact that it had to keep stopping building the web page display in order to download and run JavaScript files, a process known as ‘render blocking’.
Render blocking is not something I had thought of before, but it makes sense. As the web browser reads through the HTML of the web page you have requested in order to display (‘render’) it, it has to stop every time it comes to a script tag in order to download and execute the JavaScript to see what it does. Doing this is important as the JavaScript may be making page adjustments itself – the browser just doesn’t know until it runs the script.
Often the JavaScript doesn’t actually have to be set running until after the page is fully loaded and rendered. This would save quite a lot of page-display time – both in downloading and executing the script. On a mobile phone this could make a huge difference to the time between requesting the page and it appearing on the screen. So how do we stop JavaScript from being (downloaded if from a different file, and) executed until after the page is shown to the user?
Most calls to download and execute JavaScript look like this:
<p>Hello
<script type="text/javascript" src="somejavascript.js"></script>
World!</p>..which would display “Hello World!’ in the web browser window (assuming the JavaScript did not try and change it).
In this contrived example, supposing the above HTML is half way down an incoming HTML page. The web browser sees the <p> paragraph tag followed by the text Hello, then spots the Script tag. The browser must pause trying to display the page and instead download somejavascript.js from the web site, then set it running. Once it’s done then it can continue the display rendering process with text World! and the </p> close-paragraph tag.
Now supposing we added the parameter async to the script tag like this:
<p>Hello
<script async type="text/javascript" src="somejavascript.js"></script>
World!</p>Now the web browser simply notes that it must download and run somejavascript.js but it doesn’t need to do so immediately. As a result, Hello World! appears far faster than it did before.
Now this web site is run on WordPress and going through the entire application adding async to any script call is going to be arduous and with an uncertain outcome – after all some JavaScript requests do need to be executed as part of the initial render – but which ones?
Fortunately there is a WordPress plugin called WP Deferred Javascripts that does all this work in a controlled manner, and you can download it from here: https://wordpress.org/support/view/plugin-reviews/wp-deferred-javascripts
Upload the plugin zip file to your own WordPress site, activate it and re-test using Google PageSpeed. I think you’ll be pleasantly surprised at the performance boost.