Why I Went Static With Jekyll

by | Sep 16, 2019 | Opinion | 0 comments

Get posts like this one in your inbox by signing up for our newsletter.

Most of my writing nowadays goes onto the Medium platform. I write something, hit publish, and Medium does everything else from hosting and even bringing views to my posts. But, I’m currently working on a project that needed a website; something that Medium wouldn’t fit the requirements of. So, I needed to choose a platform to build my new site with.

At first, I thought of using a more traditional CMS like WordPress, which I’ve used many times in the past. It allows for easy customization by installing themes and plugins, and with some caching can perform very close to a pure static website. However, the reason I stopped using WordPress as my main blogging platform in the first place was because of the hassle it was to keep WordPress itself, along with all of the themes and plugins up to date. There’s also the fact that hosting WordPress requires a web host with PHP, MySQL, etc. Hosting WordPress on your own server is always an option, but then you also have to worry about keeping that up to date (which I do anyways, but it’s still something to consider if you don’t already have your own server). Then, I had an idea: why not try using Jekyll, a static site generator? Here’s why:

Speed & Scaling

Hosting a static website requires much less resources than a dynamic one. For example, in order to run something like WordPress, you need not only NGINX, but also PHP-FPM and MySQL/MariaDB, each of which uses a considerable amount of RAM. To host a static website, however, all you need is NGINX itself, which can serve static website extremely efficiently to hundreds or even thousands of concurrent requests with minimal resource usage. To be fair to WordPress, it can also be pretty fast if you’re using a page caching plugin, or even NGINX’s built-in fastcgi cache. However, it still requires that PHP and MySQL be installed on the server for at the very least the admin panel, but also to serve pages which haven’t already been cached. On top of that, if you’re using the built-in WordPress comments, you’ll need to refresh the page cache each time a comment is made, which can overwhelm the server if you receive a large surge of traffic.

Scaling a static website is much easier than scaling a dynamic PHP and MySQL site. To scale a dynamic, PHP and MySQL site, you’ll not only need a MySQL cluster, but you’ll also need to have the PHP files on each web server, along with a PHP interpreter. On the other hand, to scale a static website, all you need is web servers with the files, no interpreter or database cluster needed. Another thing to consider is how well you can utilize a CDN (Content Delivery Network) for your website. For a dynamic website, you typically only use a CDN for static assets like CSS, JavaScript, and media like images and videos. You can also cache the page HTML, but then you’ll need a way to refresh the CDN cache whenever a change is made to your website, such as a new comment. Compare this to a static website, where everything can be hosted on a CDN because it’s essentially all static assets. You’ll still need to refresh the cache whenever you update a page, but that occurs much less often with static sites (e.g. comments are handled by another service, widgets are done on the client side, etc.).

Ease of Use

Another thing you’ll want to consider when choosing between a static or dynamic website is how easy each one is to use and maintain.


Backing up a static website is super easy: just copy all of the files and call it a day. On the dynamic side of things, you need to back up not only all of the files, but also your database, which adds one more thing you can forget to do or mess up. When I had a WordPress site, I had a backup plugin which made backups of everything, including the database, every day just in case something happened. Well, something did happen one day and I wasn’t too concerned; I had the backup after all, and all I needed to do was restore it. However, it was then I realized the backup plugin wasn’t running as often as it should have. I know I should have checked it every now and then, but I had just assumed it worked. Anyways, even when I tried to restore the latest backup, the SQL dump file had countless errors in it, and wouldn’t restore. I had to manually go through all of the errors, and research a fix, then manually apply each and every one. If I had a static site, all I would have needed to do is copy back all of the files, and everything would have been just as I left it.

Posts and Pages

Static site generators, like Jekyll, typically have you write all of your posts and pages in a file with markdown. You can use whatever editor you want, since all you need is a text file, and everything just works. If you feel like adding in your own HTML, you’re free to do that. You even get all of the features something like WordPress offers, including categories and tags. When you’re done writing your post(s), you build the site, and copy the resulting static site to whatever hosting you use. For WordPress, you need to use their editor, which depending on your preferences, may be better or worse than using markdown and a text editor. But, if the editor fails to load for some reason, as happened to me many times, you’re pretty much stuck.

Bricking Your Site

I couldn’t count all of the times I broke my WordPress sites even if I wanted to as the number is so high. I’ll admit I didn’t take all of the precautions before editing functions.php, but just know that a single mistake in virtually any PHP file will brick your entire website. There are some ways around this, like using the Snippets plugin which detects any issues before applying the new code, but I’ve even bricked my site (accidentally) when using that plugin. When you break your website, no one will be able to visit it until you fix whatever broke. A static site generator, on the other hand, warns you of any errors with building the site, and the previous version of your site remains as it was until the error is fixed and the new version is built. It’s much harder to accidentally push a broken version of your website with a static site builder than it is to add a function in functions.php without realizing it makes all of your posts disappear or something.


Another factor you’ll likely want to consider before choosing to use a static or dynamic website is how much it will cost you to host the site. A dynamic website requires a web host with PHP and MySQL, which costs much more than what you’ll need for a static website. There are many reputable free services to host your static website, like GitHub pages. Or, you can opt to go the S3 route if you wanted to, which is still much cheaper than a WordPress compatible web host. On top of the fact that you get an entire year free, the pricing will be just a few cents per GB of storage (most of which is just text files), and around $0.10 per GB of data transfer (which can easily and cheaply be further reduced by using a CDN).


Static websites are faster, easier to maintain, cheaper to host, simple to back up, and are really hard to break.

Don’t get me wrong, platforms like WordPress do have a use case, as evident by the fact that a third of all websites use WordPress. But, if you can get by with a static site generator, that’s probably your best bet and that’s the route I ultimately chose.


Sign up here to be one of the first to know when we publish a post, as well as other exclusive blog updates.