Introduction

This blog used to be hosted on a WordPress installation. I did it that way because, while I had basic knowledge of HTML, CSS, PHP, and other website-building technologies, I couldn’t really be bothered to spend much time making my site better.

About six months ago, an acquaintance pointed out that the blog platform I chose was inconsistent with my principles, as stated on the blog itself. He said that, if I cared about software quality, especially security, I would not be using WordPress, which has a history of security vulnerabilities. It took me a few days to admit it, but not only was he right, it was pure hypocrisy.

Switching to Jekyll

He suggested that I use a static site generator, like Jekyll. I didn’t know Ruby at the time (and I still don’t know it well), but after looking at other options, I decided to use Jekyll because of its maturity.

The best side effect: I could use version control to track changes to my website. To be honest, even after I admitted my hypocrisy, this was the biggest reason I switched. I should have been better than that.

Anyway, I chose Jekyll, and I started learning.

Choosing a Theme

The first thing to do was to choose a theme. I chose Galada and began rebuilding my site.

When I chose Galada, I did not have any requirements for the theme except for looks, so I did not look too hard.

I should have looked harder.

Two months later, when I had put a link to a post on IRC, someone said that they could not access it because it required JavaScript. Oops.

Bloat

But that wasn’t even the worst part of Galada.

Around that time, I started reading some blog posts about web bloat, including these two. I decided to check the bloat of my home page with this calculator.

The result: 26.8. I was horrified, and I became determined to do something about it.

Reducing Theme Bloat

So I started looking for a theme that looked nice and was not as bloated. I eventually settled on Jekyll Clean. The decision came with a lot of hesitation, though; I like dark themes best, and I still missed some of the style from Galada. However, Jekyll Clean Dark was too bloated, and Galada was the worst of all.

Eventually, I decided on a compromise: I would create my own theme from Jekyll Clean, Jekyll Clean Dark, and Galada. The result is Jekyll Dark Color Blind.

If you are thinking that its name is stupid, you are correct. However, I am partially color blind, and I like themes with highly contrasting colors, which can sometimes look bad to normal people. I named it Jekyll Dark Color Blind so that people would know it was designed by someone who is partially color blind.

Once I had created my theme, I had made a lot of progress, but my bloat score was still bad: 2.68.

Purgecss

Because I had combined three themes, one of which used Bootstrap 3, and another of which used Bootstrap 4, there was a lot of extra material in the CSS. I wondered if it was possible to remove unused CSS.

I found out that it is possible, and I found some software to do it: Purgecss.

At first, I had a lot of trouble with Purgecss because it’s not perfect. I had to write a shell script to fix what it got wrong. I also had to make sure that all of the CSS files were combined into one file to give it the best chance of removing as much as possible.

The end result: I was barely below a bloat score of 1. Good enough.

Gzip

Except…Chrome dev tools has an “Audit” feature. I decided to follow its advice as much as possible while not spending too much time on the website.

One of the pieces of advice was removing unused CSS. That was where I got the idea for using Purgecss. The other big one was returning gzipped files.

I did not know this, but apparently, web servers and browsers are entirely capable of passing compressed files to each other. This is great news for performance, because CPU time is essentially free compared to the speed of any network, and this becomes even more true for worse-than-dialup 16 kbps satellite connections in Africa, for example.

Using Gzip was, therefore, a no-brainer. I even went the extra mile and used an open source implementation called Zopfli that was supposed to be even more aggressive than usual.

However, when I attempted to turn on Gzip, my then hosting provider, Bluehost, failed on me, and I could not turn it on. I had to switch providers.

Once I had switched to a provider that would allow me root access to my website’s Linux instance, I set up nginx after learning how to do it and by using nginxconfig.io.

And just like that, I had Gzip, and my bloat score went below 0.10.

Removing JavaScript

I let things sit for awhile, but one thing started bothering me: more than two-thirds of the loaded data was JavaScript from jQuery and Bootstrap when all that they do is show or hide the navbar menu on mobile when a button is pressed.

Today (29 Nov 2019), I decided to do something about it.

The first thing I had to do was find a way to do it with just CSS. Luckily, I found this page.

I had to adapt it because I wanted the menu to appear from the top, not the left, but it went mostly without any problems. I even accidentally changed the menu button in a way that I liked!

The end result is that my homepage went from 69.2 kb (including all assets) to 19.5 kb. Worth it.

Performance

On a standard connection in the USA, my website loads basically instantly. It is a nice experience.

However, I bet that if you asked Maciej Cegłowski and Dan Luu, the authors of the two blog posts about bloat linked above, they would say that my website is still bloated. The reason is that my site takes about 11 seconds to render, and 14 seconds to completely load, on a 16 kbps, 1000 ms latency, satellite connection from Ethiopia. And, on some level, they are right.

However, their websites do not look good, at least for me. Both websites are hard on my eyes, especially when reading their blog posts. I chose to make my site more bloated in order to make reading easier. (It would be understandable if I failed; I am, after all, partially color blind.)

And even though my site has much more CSS styling than theirs, I still managed to get it to render on a 16 kbps connection in under a quarter of a minute. I think that is an impressive feat.

On top of that, The vast majority of the data sent on the first load is cacheable, so every load after that takes only a few seconds, Thus, even on a terrible connection, my site is quick after the first load. (It renders in under 2 seconds and completely loads in under 4.)

Conclusion

I think the biggest takeaway from this post is that non-bloated websites are not only possible, they can still look great. If you have your own website and it is bloated, consider shrinking it. Your readers will have a better experience.