Why we chose not to use WordPress for our new website

This week, we deployed our brand new website. When we set out on building the site, we considered many options for how to manage the design, content and additional features such as contact forms, email subscriptions and blog posts and commenting. The obvious choice was WordPress - it has a plethora of themes, tons of plugins, and because it is powered on the server side and backed by a database, it is powerful enough to support all the features you could want from a modern website.

We didn’t use WordPress, however. While WordPress offers great functionality, there are many drawbacks. For any serious WordPress website, you need a VPS at a minimum. This typically requires maintaining a server with OS level updates, managing security and not to mention keeping WordPress itself and all its plugins up to date. Because it is a server-side solution, its content is dynamic by default and served from a database. Although this has the benefit of being flexible and easy to update, it also causes performance problems and introduces the headache of caching to improve site performance. There are some good Wordpress-as-a-Service options out there (one of our clients uses Pagely and it’s great) but we just wanted something that was much simpler and still more flexible.

For building the site we chose to use a static site generator, specifically Jekyll, which is built with Ruby. This allows us to create our website layout using HTML, CSS and JavaScript but still benefit from features such as reusable templates and dynamic menus, blog archives and category pages - without needing a database back-end. We write our blog posts in Markdown, which Jekyll converts into HTML at build time. Our site visuals are built on Bootstrap, and it was a piece of cake to cut this into templates and layouts that are used across the site. When we need to change our footer or header, we change it in one place and the update is reflected across the site, like it would in a dynamic CMS like WordPress.

When it came to site deployment, we originally planned to store our site on Amazon Simple Storage Service (S3) and deploy it using Amazon CloudFront as a CDN and use Amazon Route 53 for DNS, but a few minor quibbles frustrated us along the way, such as the lack of elegance around the configuration of the site, the complete pain that CloudFront invalidation proves to be and some issues getting Route 53 to work consistently with this setup. While doing this, we stumbled across a fantastic static website host called Divshot. Labeled as static hosting for developers, it promised command line deployment, custom domains, SSL support and a CDN amongst many other features. We decided to give it a go, and it was a match made in heaven.

One of our favourite features of Divshot is its Command Line Interface (CLI), which makes deploying our site and performing actions such as purging the CDN cache accessible via a single command. In fact, we have set up a simple script that enables us to build our Jekyll site, deploy it to Divshot, purge our cache and commit our changes to a Git repository for backup all in one go. This allows us to spend our time worrying about more important things like how our site looks and functions, keeping the deployment and backup process as easy as pie.

Some common reasons for avoiding static site generators are:

  • Commenting system - this is easy, if you want comments, just use Disqus
  • Contact form mailer - a good static site host such as Divshot should provide a solution to this one. With Divshot, we have a JSON config file that allows us to set up form mailers quickly and painlessly.
  • Email subscriptions - you shouldn’t be using a CMS for this anyway. Instead use an awesome subscription email management service such as MailChimp. You get a ton of messages for free each month, it’s a complete no brainer.
  • Themes - there are a growing number of pure HTML themes available, particularly themes built on top of Bootstrap. The only drawback is you will need to get your hands dirty with the HTML to get this working, but for most WordPress themes you’ll need to do this for a lot of customisation anyway. Besides, to get things looking just right you’ll want to tweak the underling markup, styles and scripts.

Static site generators aren’t for everyone. Novices will struggle with the non graphical aspect of managing the site (although you could use a tool like Octopress for this). Some may have complex requirements that justify the need for a database at the back-end. If you want to build an e-Commerce site that accepts payments, a server-side element is pretty important. But for many, many cases - a static site generator and hosting such as Divshot is the best choice. Simplicity, flexibility, ultra fast performance and scalability make it a compelling alternative to the behemoth that is Wordpress.