After six years of WordPress, I’ve migrated to a static HTML site. I’ve tested the site to the best of my knowledge and cleaned everything up, but contact me if there are bugs or errors.

The rest of this post goes over the vision and reasons why I switched the site from WordPress. You don’t have to read it, but it might be interesting for those of you looking to create or work on your own site.

Site Vision

A year ago I had a brief conversation with Friend of the Site Kate about blogging and potential monetization. I made a decision then to hold this site to two principles:

  1. This site will be free to use.
  2. No ads, no monetization - this site is a labor of love and I use it.
  3. The site will use minimal resources and be fast-loading, as airport WiFi and mobile internet connections at airports are often terrible.

This worked quite well as a set of guiding principles. I was also invested in WordPress as a content platform as I have plenty of experience with it.

I was doing some research on Raspberry Pi projects a couple of months ago when I came across a project on a personal site. The first thought I had was, “That’s a clean site. I want that.” I reviewed the page source to find exceptionally clean HTML. I was wondering how someone would go to the trouble of coding HTML themselves in 2023. I emailed Matt and asked how he was able to get such a clean site; he replied with a link to his blog post outlining his process and tools. (Thank you Matt!)

As I had just completed another update cycle with WordPress, I thought about Matt’s post and converting my sites over to static HTML. I let that thought simmer for a few weeks until I recently chose to make the switch.

Aside: Concerns with WordPress

To be honest, I like WordPress and would recommend it … if you need it, or want something to work out of the box. WordPress is great for blogging: posts made in linear time, optionally with some static pages. It’s easy to implement a theme out of the box, and the editor is generally acceptable for most blog writing. The amount of customizations are endless; there is also a supportive community of people who can troubleshoot, optimize, and tune a WordPress blog. It’s why WordPress has been the number one content management system platform for a while!

This site isn’t a blog though. The only time-oriented content I have is change logs. Mailboxes at airports don’t change that often; if they did, the postal service would be on airport management asking why they are moving around so often. This site is based on evergreen content: data and information that doesn’t change often. There also isn’t that much to blog about when it comes to sending mail from an airport….

I was also getting annoyed by WordPress itself:

  1. The WordPress WSYIWYG blog post editor is pretty good but would lately try to format posts in ways I didn’t want it to.
  2. WordPress relies on PHP as its main language, which isn’t great from a security or learning-curve perspective.
  3. WordPress relies on a number of plugins to provide additional functionality. The more plugins in use, the greater the chances of plugins adversely affecting the site or other plugins. Sometimes there would be sketchy plugins on offer, or plugin authors would simply stop updating their plugin and cause issues at update time.
  4. Speaking of updates - I would get anxiety every time I would upgrade PHP, WordPress itself, or a plugin. I was never sure if or how the site would break once I pressed the “update” button. There isn’t a good way to make a test site that normal content writers could implement. Fortunately this site is lean enough to where upgrades wasn’t a significant issue.
  5. If I wanted to modify a theme (the code that makes a site look pretty), I would need to create a child theme. Child themes aren’t obvious to implement at all. With static HTML and CSS, I can make the site look the way I want based entirely on Internet standards.
  6. Some plugins like Jetpack (to help manage and optimize the site) were using cookies, which means I was unintentionally violating GDPR and/or California’s opt-out laws - even though I was only using it for visit-counting.

Essentially, WordPress was overkill for hosting a static site like this one - and I was tired of managing it.

The process to change a WordPress to a static site isn’t easy; I’ll leave the details to Matt’s excellent blog post. I don’t think I’d recommend this particular implementation to those who do not have programming experience. I’m not certain I would have made the switch if I just wanted to create content and display it on the Web.

I also recognize the site isn’t pretty - but it is functional, faster, and uses less resources to serve up and display in your browser. I also don’t have to worry about legal issues related to Web sites (for now). If you want a prettier site, let me know with suggestions and I’ll see what I can do.

Thanks for being a guest for the past six years, and I hope to serve you for at least another six years.

– Mike