Welcome to a new website with a new philosophy
You may have noticed that things have changed around here - I built a new website, following the ethos that it should be as clear, lightweight, and fast as possible while respecting visitors’ privacy by keeping outside scripts and tracking to a minimum. In this post I take you through the process of designing and building the new site, from the initial inspiration to the end product you see today.
I read a lot of books during the COVID-19 lockdown. These ranged from one of the best novels I’ve ever read (South of the Border, West of the Sun by Haruki Murakami) to some more relaxing non-fiction (Blood, Sweat, and Pixels by Jason Schreier). But the pick of the bunch, and the one that has inspired me the most, is Chaos Monkeys: Mayhem and Mania Inside the Silicon Valley Machine, which charts Antonio Garcia Martinez’s journey from Goldman Sachs to start-up founder to Facebook.
The value of this book goes beyond what is physically held within its pages. Martinez referenced so many Googlable concepts, companies, people, and blogs that the thing took me about twice as long to read as any other book (perhaps the best among these was Paul Graham’s blog post How to Start a Startup, which Martinez described as “a crack-like gateway drug to the startup addiction”).
Without a doubt the most valuable outcome of reading Martinez’s memoir, however, was that it reconnected me with Hacker News. Hacker News is a website run by the start-up accelerator Y Combinator. It functions something like Reddit, with hackers (read: people who like to code and make stuff, not hoodie-wearing, basement-dwelling script kiddies) posting links and upvoting useful content.
By proxy, reconnecting with Hacker News meant reconnecting with the wonderful world of personal blogs run by techy people. I always try to pick up on these because they offer more inspiration and insight than commercial websites, but on the regular internet links to them are few and far between - something I’m acutely aware of with my own blog, which occasionally receives thousands of views in a short space of time thanks to Reddit posts, but does not do too well via search.
Another big influence on the project was a series of blog posts I read on the concept of web bloat, including the transcript of Maciej Ceglowski’s talk The Website Obesity Crisis, which laments all the unnecessary additions to web pages that slow everything down and reduce compatibility without tangible benefit to the user. This leads to short news article pages that have bigger file sizes than the full text of War and Peace, and misguided initiatives like Google’s Accelerated Mobile Pages (AMP) that speed up page loads but are still bloated and only serve to tighten big tech’s stranglehold on the internet.
I had been mulling a change of platform - or rather a change away from my previous platform - for quite some time. After all, I am a cyber security professional, and for all its merits WordPress (or at least its plethora of poorly-coded plug-ins) sprouts as many vulnerabilities each month as the most detested corporate software out there. Add to that the overhead of dynamically generating every page as it is requested, which isn’t strictly necessary for a blog that is updated at most once per month, and it was clear that there was a better, more efficient way to do things.
With that, I decided to take some inspiration from these small hacker blogs and build something new. But before I started, I needed to think carefully about exacly what I wanted to achieve and how I would do it. The following is a summary of what I came up with, embellished with the wisdom of hindsight:
The site should serve lightweight, static pages. In the interest of speed and efficiency, it was time to say goodbye to dynamically generated pages like those served by WordPress. They just take too long when good old HTML and CSS could do just as good a job by themselves.
The site should give me control. I’m a (fairly) competent person. I don’t need to be restricted by WordPress themes to avoid breaking my website. If I want to add new page elements or try out new features I should have the freedom to do so without worrying about how they fit into a content management system’s ecosystem.
The site should scale back user tracking. At various points in the past I’ve used Google Analytics and Jetpack to count visits. I’m still interested in how many people read my blog posts, but those solutions gave me more analytics than I would ever need, and stripping that bloat away could also negate the need for an ugly, annoying EU cookie notice.
The site should save me money. I’d been stuck with the same web hosting provider since 2012. To be fair they were relatively cheap, but when I needed support it was often sub-par and I frequently had to nag them to implement basic things like PHP updates. For the new website I’d be keeping an eye out for a new host, potentially even with a free platform that would support such a basic site.
With those broad goals in mind, I grabbed a pen and paper and spent some of my early time in lockdown sketching out what such a website might look like and listing ideas for how to satisfy my self-imposed requirements. After a little thinking and a bit of research, I had a plan.
Building the site
My initial idea to scratch my minimalist itch was to develop a series of Python scripts that would take data from text files, format them according to some HTML templates, and publish them to my web server. Then I discovered Jekyll, which already did all of that - and it’s much better, and has many more features, than what I would have developed. What’s not to love about open source?
So I downloaded it, got it running on Linux for Windows, and built the website you’re now reading. While it is a little more complicated than this makes it sound (Jekyll lets you store common elements in separate files and call them, and uses WordPress-style loops for posts, categories, and page content), the page you’re reading now is pure HTML and CSS, lovingly crafted from the ground up with the goal of staying as minimalist as possible. After running some page load tests, I think I’ve succeeded there.
There are some cool features in here that I’m quite proud of. For a start, the site is responsive and looks great on mobile (the way the homepage achieves this is slightly hacky, but I’ll probably revisit that later). It also respects your preference for light or dark mode and displays the site in the appropriate colours (I use dark mode myself, so if there are light mode bugs I haven’t spotted, please let me know).
Is it perfect? No. Every so often I spot a styling bug, the meta side of things could probably do with a once over, and there are definitely some messy elements to the code that I’d like to come up with more elegant solutions for in future. But in the spirit of moving fast and breaking things, the minimum viable product you see before you functions perfectly well in displaying information provided by me to you, the reader.
One other area where I could be more efficient is my use of Jekyll. Being new to the whole thing, I learnt how it functions as I built the site, which is fine, but means there are probably a lot of things I would do differently now I’m more experienced. The great thing about Jekyll, however, is that because it builds static HTML pages, the output is all that matters for the most part, and poor input isn’t going to introduce any security vulnerabilities to the website because… well, there’s nothing to hack.
Hosting the site
Now that I had something to share with the world, I needed somewhere to share it from. A bunch of HTML pages could be hosted anywhere, and the easiest thing to do would have been to stick with my previous hosting provider. But by chance I came across a discussion about GitHub Pages - a free platform for personal and project sites - and thought it sounded like a great solution to my problem.
With GitHub Pages, I could save some money while taking a bet that Microsoft-owned servers would be faster and more reliable than my previous provider’s. I could use my own domain, and the transition even gave me a security boost as my domain and my site files are now behind separate 2FA-enabled logins.
Setup, I’ll admit, was a little fiddly. GitHub Pages is not terribly well documented besides some basic instructions, and it seems to take a while to propagate once you turn it on. Eventually I got there, however, and the pain of the initial configuration is likely to be worth the ease with which I can publish new blog posts and other changes - simply by committing changes to a GitHub repository.
Adapting my content
One slightly time-consuming task was updating all my WordPress content to fit the new Jekyll site. The Jekyll Exporter plug-in was invaluable in this, saving me a lot of time manually copying posts into markdown by exporting all my WordPress posts into a Jekyll-friendly format… mostly.
The work that remained was still tedious. WordPress had automatically replaced all images in the body text of my posts with source addresses on its content delivery network, so I needed to replace them with the URLs of the images on my web server. Also, I’d been using a plug-in to highlight code on my WordPress site, so I needed to go through all my programming posts and wrap the code in the Jekyll tags that would apply the right formatting. This wasn’t a difficult task, but it was long-winded.
My internet minimalism didn’t stop at the design, however. I’m also more conscious than ever that I want every page on my website to offer value to readers. This doesn’t mean the Off-Topic category is going anywhere - value isn’t limited by subject. But at some points in the past I’ve been very determined to write a blog post every two weeks, or every month, and when inspiration didn’t strike this led to some bland posts. I removed these, keeping only what I see as the higher-value posts, and I will endeavour to ensure all future posts are based around either an interesting take or useful technical content.
Tracking the site
Over a period of weeks a few different analytics start-ups flaunted their offerings on Hacker News, but they were all aimed at enterprises and priced accordingly, meaning that an analytics implementation would set me back the money I was saving on hosting (and then some). It was looking like I’d need to bite the bullet and go back to Google if I wanted any insight into which of my posts visitors enjoyed.
All in all, this has worked out pretty well. The site loads quickly, and the process for creating a new post is both more straightforward and more flexible than it was under WordPress. It looks something like this:
1. Write post in Markdown format
2. Run Jekyll to generate HTML pages
3. Copy HTML to GitHub repository folder
4. Push update to GitHub to publish
The additional benefit of no paid hosting only sweetens the deal, and means that all I need to pay for is my domain. And I don’t even need to remember to back up my website anymore, because: a) it’s stored on GitHub, a more reliable platform than my previous provider; and b) the latest HTML files generated by Jekyll will always be on my hard drive, where they will be automatically picked up by my usual backups.
It’s taken a lot of work, and probably would have taken a lot longer if it wasn’t for the extra time afforded by the COVID-19 lockdown, but overall I think I can call the project a success. I now have a light, fast-loading website that respects users’ privacy and better reflects who I am.
There are changes to be made and features I want to add, but the beauty of the Jekyll/GitHub setup is that I can continue to develop at my own pace and the site will still function. I’m also interested in any feedback visitors might have about the change, so if you have any thoughts, ideas, or suggestions for updates, please do use the links below to get in touch.