Moving from WordPress to Middleman

Note: In September 2017 this site was rebuilt with Hugo. The text below no longer describes my own site, but I would still use Middleman (or any other static generator) over WordPress.

Recently I’ve spent a few evenings removing WordPress and rebuilding this site on top of Middleman. The new site is still a work in progress and I have more features to add, but all of the previous content has been brought over. It should be safe to launch this.

So why did I do it? Over the past two years I’ve become increasingly frustrated with WordPress. Despite serving compressed pages, caching data, and reducing unnecessary scripts, page load times seemed to increase with each new version. Some of my more popular pages were averaging 5 seconds to load. That’s ridiculous.

Even when WordPress itself performed well, it required additional plugins just to have reasonable features (e.g., caching, contact forms, spam protection, SEO optimization, etc.). Each of these requires constant updates, and one can never be sure if updating one plugin is going to break other plugins, or worse, the entire site. Compatibility reports from other users are helpful, but are often incomplete. Logging in just to write a simple post became a chore: update this, double check that, fix this other thing that the previous update broke, and so on. Long story short, it got old.

On top of that, this site (and most blogs in general) really don’t need to be dynamic. Once published, the page content rarely changes. Involving a database and PHP scripts to deliver static content only adds unnecessary overhead. Under heavy load (thanks, Time!) I found WordPress achingly slow. During my largest traffic spike page performance suffered so much that my email exploded with inquiries about it (on the bright side, it did not go down). Nonetheless, WordPress was no longer a pest that lived only on my web server: its shortcomings were now invading my inbox.

The decision to switch to something else was a long time coming. Now that I had a few evenings to spare, I was able to do something about it.

So I set up Ruby, installed and configured Middleman, and re-developed everything from scratch.

The benefits have been immediate:

• Middleman is a roll-your-own beast. This site now does exactly what I want it to, no more, no less. No plugins to fuss with or break.
• Middleman uses the Sass CSS preprocessor and Compass framework. If you’re not already using Sass + Compass, I highly recommend them. They make rapidly deploying CSS designs incredibly painless by adding variables, mixins, and functions while removing the need to worry about vendor-specific prefixes.
• Since all of the ruby scripts, Middleman configs and templates, and page content is first generated on my local machine, my entire site can be versioned on github and served via Github Pages.

I’ve wanted to do this before, but have been a bit hesitant. My post on mapping sasquatch sightings generated a ton of discussion that I didn’t want to lose. Fortunately I could import all the comments to Disqus.

With that all done, the new site is up and chugging along. Stay tuned for more content, and if you notice anything wonky please let me know!

Some tips on Middleman + Github Pages

If you’re thinking of using Middleman with Github Pages, there are two ways to make it really easy. The first is to use the middleman-gh-pages extension. This adds rake tasks to deploy your site upon build.

The second method is to simply setup your config.rb file to use your Github Pages repo as the build destination by adding:

### Change build directory to Github Pages repo
set :build_dir, '../YOUR_GH_NAME.github.io'

This is the approach I use. It is much cleaner - no additional rake tasks, overrides, or issues to worry about. In addition, it uses completely separate repositories for the development and production versions of your site. This enables you to test things out, revert changes, and ensure everything is working in a test environment before pushing the changes live, even after a build.

Lastly, if you plan to use a custom 404 page, ensure your 404.html file is left as-is during the build operation. In config.rb add:

### Exlude 404.html from being placed in a directory
page "/404.html", :directory_index => false

That’s it! Just run $ bundle exec middleman build and commit the changes if you’re happy with how things work.

Update: Was developing a static site worth it?

The big question comes down to whether or not it was worth the effort to redevelop a new site. Despite already being happier with the more minimal and personal design, I wanted to compare page load times between the old and new sites. Here are the average page load times for one week before the switch, and one week after:

I would say a 1500% improvement speaks for itself.

---