MK Geek Night: Adventures with Google Page Speed
Last week I travelled up to Milton Keynes to participate in the fourth installment of Milton Keynes Geek Night. Richard and David were kind enough to invite me along to chat about something geeky so I decided to setp outside of my own personal comfort zone and share some of my recent experiences relating to Google Page Speed.
Over Christmas whilst working on the Back to Front Show web site I ran it through Google’s Page Speed assessment tool and was averaging around the mid 80’s. This piqued my interest and so I set about learning how to increase the score and ultimately managed to reach 97/100.
Along the way I learnt a fair bit about caching, both server and browser, CDN’s, httpd.conf files and the inconsistency of online testing tools.
As I said on the night I am still learning and I encourage you to check out the articles at the end of the post. As usual the time others spent documenting their own experiences and expertise helped me a great deal. Special thanks to Harry Roberts whose post “Front-end performance for web designers and front-end developers” I found particularly useful.
The slides won’t make much sense in isolation so here are the 11 main points along with some useful links to help you on your way:
- Make fewer HTTP requests – The fewer requests you make the quicker your page will be to download. Regardless of size every asset has a cost, whether it be a DNS lookup, bytes to download or a redirect to handle. The fewer the better.
- Minify and concatenate CSS and JS – As a rule of thumb aim for one CSS file and one JS file per page. I use Mixture to achieve this.
- Optimise images – Use tools like ImageOptim to squash your image file sizes.
- Only use what you need – Before including yet another JS library ask yourself the question, “do I really need it?”
- CSS at the top, JS at the bottom – Put simply JS stops the page rendering, by putting at the bottom the page renders quicker.
- HTTP Compression – GZip compression is probably the quickest win in terms of reducing the size of your files before they are sent down the wire to the browser. HTML5 Boilerplate provides the necessary code for your .htaccess file (search for # Gzip compression).
- Browser caching – Use far future expiry headers to keep assets cached in the browser. Again HTML5 Boilerplate provides the necessary code for your .htaccess file (search for # Expires headers).
- Enable keep-alive – Very simple to implement and will keep one connection open so that your browser doesn’t have to keep requesting new ones for each request. The relevant code is available on the HTML5 Boilerplate site (search for # Set Keep-Alive Header)
- Cache dynamic content – If you use WordPress I receommend WP Super Cache to cache your pages and posts. Additionally most frameworks have caching facilities built in. Investigate and use wisely.
- Use a CDN – Consider using a CDN to serve your static assets. Amazon CloudFront is very easy to implement and can grab assets from your web site automatically the first time they are requested.
- Beware of boilerplates – If you use a boilerplate ensure any referenced assets are in your site. Remember that every file referenced but not present will result in a 404 error page being requested and downloaded. Instead of a 1kb favicon you may well end up with a 1mb 404 page being pulled down in the background. (h/t to Andy Davies for this gotcha!)
- Front-end performance for web designers and front-end developers by Harry Roberts
- Let’s Do Simple Stuff to Make Our Websites Faster by Chris Coyier
- Speed is Essential for a Great Web Experience by Andy Davies
- High performance web sites blog by Steve Souders
- .htaccess made easy by Jeff Starr
- Google Page Speed
- Web Page Test
- Adventures with Google Page Speed on Soundcloud
Thanks again to Richard and David for having me along and being very hospitable hosts. If you get the chance to attend MK Geek Night I thoroughly recommend it.