The Failed Personal Website Redesign- Part 2: Hosting Woes

Having settled on Jekyll after a nasty yet naïve experience with Hugo, it was time to worry about hosting the site.

Issues With GitHub Pages

Up until now, I hosted my personal website on Github Pages since it was free and it supported custom domains, which I usually got for free somehow. It’s also easy to use. All I had to do was code an HTML or Jekyll Site, push it to Github and it would host it without issue.

Although Github Pages was simple to use, it had issues such as,

• No HTTPS for custom domains– you could get it with CloudFlare, but it would be nice if it was built in.
• Only Jekyll is supported- While it’s possible to compile the site using whatever static site generator you want beforehand, it’s a mess to manage. I did this a few times just to see if it would work, which it did.
• The Jekyll itself was greatly limited- GitHub Pages only supports Jekyll with limited plugins. Again, you could build the site beforehand, but that makes things harder to manage in source control. Then again, I just read an article where the author had good source control so ¯\(ツ)/¯.

I could have such with it, but there was another contender that caught my eye- Gitlab Pages.

Working With GitLab Pages

Made by GitLab, GitLab Pages addresses it’s rival’s shortcomings.

For one, it supports HTTPS on custom domains without the need for CloudFlare. Also, you can use virtually any static site generator you like with whatever extensions you like. You can even make your own static site generator and Gitlab would take it.

There is a catch, however. You need to do more work.

To add HTTPS on custom domains, you need to upload the TLS certificates to GitLab although you could use CloudFlare which, come to think of it, is actually a better deal. In my case, I took advantage of Let’s Encrypt and got myself a free TLS certificate. The process itself wasn’t that hard although my carelessness made it harder than necessary.

As for the ability to use any static site generator, you need to tell GitLab how to do this through a .gitlab-ci.yml which runs the commands through its very own Continuous Integration &Delivery (CI/CD) pipeline.

I didn’t know how to use it at first and I almost gave up until I noticed that GitLab was nice enough to offer templates that only deferred my lack of understanding to a later date. Coincidentally, an earlier draft of this post had me complaining about the complexity of Gitlab’s CI at which point I actually understood how it works. Funny that.

Anyway, just as I got the template, the build failed. Thankfully, it was an easy fix. Turns out I forgot to add the Gemfile needed to gather the site’s dependencies so I just added it in.

Once I got the actual pipeline working, I noticed just how slow Gitlab Pages was compared to Github. While it takes less than 10 seconds for a site on GitHub Pages to go live after a push, Gitlab takes over a minute to build a site. This could be because of the way Gitlab has to download and install the dependencies whenever the pipeline is run.

There are a few ways I could speed up the site. I could

• pre-build the site and change the gitlab-ci.yml script to just and mv command or
• download the plugins before pushing to Gitlab.

The problem with these optimizations, however, is that it kinda defeats the purpose of CI and switching to Github Pages. I then decided to just deal with it and turned my attention to the next task- tweeting new posts.