A few months back we moved away from Wordpress in favour of a more lightweight platform, namely Jekyll. At the same time we made front-end improvements from the point of view of design, markup and resources.
Speed Increase
The primary advantage of moving to a less complex system, that generates a static HTML site, is the speed improvement. The platform change has meant that we have been able to drastically reduce our time to first byte to around 80ms without any investment in the server.
Together with the front-end redevelopment, we have been able to reduce the number and size of resources. For the first load of an image-heavy page, like the home page, it can take anything up to two seconds; pretty fast. Once resources are cached, page load times reduce to around 300ms.
There are two dynamic portions of the page which we had to move slightly outside of the jekyll platform. The first is for the latest tweet block on the home page. This calls a local PHP script to read in the latest tweet. The second is the contact form which posts to a PHP script.
We have also made use of Amazon CloundFront as a CDN to optimise delivery to visitors around the world.
Drafting Posts
The biggest change for us internally is the way that posts on the site are composed. They are now written in markdown and committed to git before being deployed. This change has given us the freedom to re-think our writing approval process.
As site content is now in git, and we are a very technically focussed team, we decided to employ the git-flow model that we use for code development. Each time we draft a post, we create a new feature branch which can be pushed to the remote origin as the writer sees fit. While writing they can ask colleagues to check-out (pun intended) the feature branch. Once completed they can finish the feature and merge it back into develop. The post can then be tested in our staging area and sent for final approval before it is merged into the master branch.
This process is still being explored but we think it is an interesting idea.
The disadvantage of this is that new team members that do not have development experience will be unable to make changes to the site directly. This will likely have to go through a more traditional approval process and then provide content to a developer.
That aside, this has been a vast improvement on using an overkill, customised Wordpress installation.
The questions that I am hoping that this poses to others are:
- Do you really need that cumbersome CMS?
- What is your website change approval process? Is it as co-ordinated as your code review process?
- What can you do to your site on the front-end to make it more lightweight in terms of resources?
- Do you have a responsive site yet?