Sean's Blog

Blogging with Jekyll and AWS

I've yearned to have a blog for a while now, however I'm an extremely lazy person. Simply thinking about the effort involved in having to keep the hosting server secure, whatever framework I used updated, and moderating comments for spam always turned me off.

Someone mentioned Jekyll on Twitter one day and it sounded perfect for me. Essentially it's a script which takes the content of your articles/pages (in markdown, HTML, etc) and merges them with templates you create and spits out flat HTML files. No framework required — just a server to host the files. Lazy Sean approved.


Before even writing a single line of code, I made a mental note of what my priorities were for the site:

  1. It needs to be accessible
  2. It needs to be fast

I nearly put being fast as the first point, however I realised I'd rather have a slow site that is accessible over a fast one that isn't. Also, being fast improves the user experience and can have a positive effect on how high your site is ranked in search results.

How to be fast

I love reading about little tips and tricks people use to optimise their sites. Because this is "just a blog", I decided there would be:

  1. no JS unless absolutely neccessary
  2. no reset styles
  3. as few requests as possible
  4. optimised for a cold cache — I'm guessing that most of my articles will be read on a mobile/tablet, from random Twitter posts, not recurring visitors

Not adding analytics JS was an easy call. Lazy Sean rightly said that if I have analytics I will need to keep an eye on them. If my articles are popular then I may hear about it on Twitter. That's good enough for me, and hey that's another request avoided (not to mention the occasional delays caused by GA).

Reset styles are great when you're creating a complex interface, especially if there are forms involved. The styles needed to render a blog post are minimal so I don't see the point of resetting the world and then setting the 15 or so styles I'd need.

Putting all my styles in the head rather than linking to an external file was another thing I debated. I may change my mind later but for the moment due to the fact the styles are only 5KB, and that I'm optimising for someone with a cold cache (and possibly on a 3G/4G connection), I figure it's less expensive to send them down with the page content than to fire off another request for them. I'm not sure what the packet size is for mobile data but I doubt sending down 10KB instead of 5KB will slow things down more than adding another request. Another request avoided.

Web fonts are all the rage but I get so annoyed when trying to read an article and the page hangs while fetching fonts from Google/Typekit/whatever. Stock fonts, while looking kinda average, are still readable and will work fine. More requests avoided.

Testing is important

After a bit of testing on mobile I realised I'd need to add FastClick.js or cop a 300ms delay whenever a link is clicked. I'd love it if other browsers added something like the proprietary -ms-touch-action: none CSS property so JS wouldn't be needed, but until then FastClick will remain. Annoying but neccessary.

CDN all the things

I'd always thought a CDN would be expensive, but the pricing for services like Amazon CloudFront, Cloudflare, and Fastly are now much more affordable — at least when you're only hosting small html pages. I chose the Amazon stack mainly because I'm lazy and there are many well-written articles explaining how to set it up.

The results

After a lot of fiddling I'm really happy with how it's turned out. Lazy Sean is pretty chuffed that all he needs to do is create an HTML file and then run a script.

As of the writing of this post, posts are loading in around 6-20ms, with the Load event firing shortly afterwards at around 70ms. It also gets full marks for both Desktop and Mobile from Google PageSpeed Insights, and all A's on WebPageTest.

As someone who does most of their blog reading on an iPhone while commuting, I love with how articles look. It's nothing fancy and I'd love to hear any (constructive) criticism people have.