Published 28 December 2016
Having recently decided it was time to revamp and simplify my blog, what better way to improve it's speed and security than getting rid of the dynamic element completely.

Prior to this blog post going live, my website was built using WordPress on my own VPS, where I am responsible for maintaining PHP and MySQL. Due to using a fancy WordPress theme, my blog list took up to 10 seconds to load “fresh” and is almost 2Mb in size. With the move to Jekyll, pages are ready for use within a second or two (just the Twitter iFrame and things take the extra time) and an initial load of the blog index is under 700Kb in size.

What is Jekyll?

Jekyll is a blog-aware static site generator that takes a bunch of raw text files (including markdown files for the content) and spits out a bunch of HTML and CSS that you upload to your server. Instead of doing a whole bunch of database requests whenever you load a page, all of the hard work occurs when the site is generated - so the end user just loads some HTML and images stored on your server. This makes your site incredibly fast and lightweight, at the cost of losing access to “most” interatice features.

While the idea behind WordPress was lovely - I could have full conversations with my users in the comment sections and add/remove plugins whenever I wanted some fancy new feature, it recently dawned on me that only one thing really matters about my blog - and that’s the content / projects that I’m sharing. Now, Jekyll has some basic support for interactive features - there is a search plugin someone has built using Javascript and index files and you can use Disquss to add comments to your pages, even if they are stored elsewhere / done through Javascript.

Don’t get my wrong - you can still do a bunch of fancy things at “generation” time for your site - including generating thumbnails for images and creating a RSS feed for your blog posts. Jekyll supports content in “collections” (blog posts, projects, podcast episodes) and each can have their own templates and handlers.

Migration Logistics

I don’t want to go into too much detail, otherwise this post would be huge. However, a lot of the work was the usual “migration” work that comes with changing platform - trying to retain link structure, removing temporary WordPress thumbnails, redirecting links, etc. I won’t focus on that, but I will focus on the Jekyll specific plugins and features I used.

Jekyll: Jekyll is written in Ruby and is easy to setup on macOS / Linux. I’m using macOS and Homebrew (I don’t know if the latter is necessary) and the Jekyll install instructions worked great. Once up and running, you can run Jekyll in ‘serve’ mode, which will immediately regenerate any changed files and serve them on localhost:4000.

WordPress to Jekyll Exporter: This WordPress Plugin did a pretty good job of exporting my pages and posts into Markdown files for Jekyll. It didn’t get everything right (a few pages were missing), but for the most part - it did the job.

Jekyll Plugins: I found the following Jekyll plugins useful in my endeavour.

  • Jekyll Feed: Quick and easy RSS feed for your blog posts.
  • Octopress Paginate: Makes it possible to paginate your blog index.
  • Jekyll Archives: Create ‘category’ and ‘tag’ pages for your blog.
  • Jekyll Redirect From: Very easy way to make Google-friendly redirects for moved pages.
  • RMagick: I ended up writing my own thumbnail generator plugin to generate thumbnails at build time.

_config.yml: I added special entries to my config file to setup blog permalinks and jekyll-archives how I wanted. In this file I also added a ‘collection’ for my projects, so that they act a bit like blog posts instead of raw pages. In this file, I also excluded copying my download directory from source to _site (as it was very big).

Jekyll Pros

  • In WordPress, a 300Kb image was taking up nearly 2Mb of space due to all of the different thumbnails that were created by my theme. Now I only create thumbnails that are actually needed and used.
  • Page loading time on desktop is dramatically faster, and it’s probably even more noticable on mobile.
  • As your site content is all text files, you can get great version control with Git.
  • The resulting site can be hosted practically anywhere - it’s just HTML, CSS and content files.
  • It’s much easier to edit HTML/CSS to customise pages on your blog.
  • No need for server backups: Assuming your site source is in Git and/or Dropbox, you can regenerate the site whenever you need.
  • You can build your site offline, edit it and test it and choose when you upload (which requires having 2 versions of your site with WordPress).

Jekyll Cons

  • I had to write my own Ruby plugin for generating thumbnails how I wanted them to be generated.
  • If you use the disquss commenting system, you don’t get ownership over the written comments.
  • Killing links to the wp-uploads folder was mostly manual work, although, I guess unecessary if you don’t mind old content being bloated.
  • There isn’t always a nice alternative to your WordPress plugins.
  • Fewer themes exist for Jekyll - you might have to get your hands dirty with HTML/CSS.
  • It’s harder to do ‘emergency fixes’ like removing a blog post from your phone while on the move. You could setup an post-commit hook Git though or use GitHub pages.

Conclusion

Overall, I’m pretty happy that I changed my website to Jekyll. I feel it will be less effort to maintain and it’s been really nice to be able to get my hands dirty and edit CSS and page layouts for certain pages without hacking through WordPress template code. If you don’t need any super fancy features and find a good template that you’re happy with (or you’re happy to get your hands dirty) - I can recommend moving to Jekyll.