Moving away from wordpress to a JamStack

07 May 2020  Issa Nimaga  4 mins read.

The first build of my personal website was launched in 2017. At the time, I was looking to create a refined online presence and differentiate myself from other candidates during placement applications. The built personal website was to serve as my personal CV and a hub for all future side projects or Uni courseworks I might want to share with the world. I used Wordpress for the build, given its flexibility, and large resource base. Wordpress is a fantastic CMS and till this day, is my go-to when it comes to building great dynamic websites for organisations who require a CMS due to having multiple users. Nevertheless, I came to discover that, for my particular use-case of a hosted personal website with occasional blogging, a more apt tool was available. It was the JAMStack. I have since switched, and this blog entry is an explanation of the various benefits which led to me switching.

First, What is a JAMStack?

The JAM stands for JavaScript, APIs, and Markup and in its purest form, the idea of JAMstack is that a web application is pre-built into static pages, using content and code to generate the output. A site doesn’t have to include all attributes (JavaScript, APIs, and Markup) to qualify as a JAMStack and it might be built manually, or automatically (using a static site generator). An automatic build using a static site generator makes for a more fluid experience and the chosen generator for my stack is Jekyll.

About Jekyll

Jekyll is a simple, static site generator written in Ruby. It is currently the most popular static site generator, largely due to its adoption by GitHub. It is also the engine behind GitHub pages, a GitHub feature that allows users to freely host websites in their repositories.

Like other static site generators, Jekyll foregoes the use of databases, and instead, takes the content written in Markdown, passes it through your Liquid templates, then produces a complete static website, ready to be served by any web server. The generated files can be uploaded to one’s GitHub repository, with Github pages, conveniently serving the website. (Ex:

Why the JAMStack?

I migrated to a JAMStack, and specifically this setup for a couple of reasons:

  1. Better performance: While Wordpress is great for a lot of reasons, the installation of additional plugins to add features can quickly lead to a bloated setup, significantly impacting the performance of a website at scale. Furthermore, a Wordpress setup needs to be kept up to date and requires constant maintenance to prevent security breaches due to the vast majority of vulnerabilities affecting PHP or databases.
    In addition to eliminating the need for a database (and thus these security issues), Jekyll strips down everything to its bare minimum and will include absolutely no functionality or features that you aren’t using. When it comes to performance at scale, nothing beats static files served over a CDN.
  2. Great developer experience: Building and/or customising a theme or base template in Jekyll is relatively very easy (when compared to Wordpress). You have full and complete control over every single aspect of the website as it uses the liquid templating language from shopify, to process templates. It is also very convenient if you already use GitHub, as once you’ve made a desired change, simply making a push to the repository causes GitHub Pages to rebuild and serve your website while simultaneously handling version control.
  3. Cheap and easy scaling: With GitHub pages freely available to anyone with an internet connection, the deployed site can be freely served from anywhere in the world. Coupled with a free CDN like cloud-flare for scaling, the resulting combo is a super-fast and high-performing website for absolutely nothing. And hey, who doesn’t like free stuff?? 😉😆
    Running my website now costs me less than $10 per year in total, and this cost is solely for the domain name. Nevertheless, one always has the option to instead use the freely available subdomains from GitHub pages in the format: “https://{username}” bringing your total cost to $0.


  • Source Code: At the moment, the repository containing the source code for this website has been made private. However, I might consider making this public in the future. If you have any technical questions regarding how I built this site or aspects of it, then please feel to reach out.
  • Image Credits: Florian Olivo on Unsplash

Recent Articles