Static site migration – starting the optimisation, already

Now that I’ve got the static site up and running, it’s obviously time to switch over immediately, right? Not to fast. After QA’ing my deployment process in production, it was time to check how the two compared from a performance perspective. I like to use several different tests, starting with Pingdom, then using PageSpeed Insights for more details.

The Pingdom speed test gave it a thumbs up, but they’re not running the currently dominant search engine. Fortunately said search engine also offers performance check tooling. This wasn’t quite the thumbs up I had hoped for, though. While the mobile performance is similar – in other words, equally unimpressive – the desktop performance is pretty good for both sites. The WordPress site still has a slight advantages, but after some initial tweaks like disabling highlight.js (the static site uses the basic Hugo highlighter), the static site is pretty close.

PageSpeed Insight comparison of the static (Hugo) site vs the old WordPress site. Both are in the low 50s.
Mobile site comparison – static vs WordPress
Side by side comparison of the PageSpeed results for the new static site vs the existing WordPress site
PageSpeed insight for new static site vs WordPress (desktop)

Clearly, in both cases the static site needs work. Admittedly I have neglected the mobile performance for both sites somewhat. It’s not like anybody ever looks at sites like this on their phones or tablet, right? Oh, wait. Might want to do something about that.

I got to the numbers above after I made a few tweaks to the theme already – adding a canonical link and adding support for Google and Bing site verification. Neither should affect performance. The only performance tweaks so far were disabling the use of highlight.js. I use Hugo’s built in highlighter and overlooked at the theme’s default config.toml from its exampleSite also enables highlight.js

The PageSpeed analysis indicates to me that the two big issues are the font and JavaScript downloads, with the fonts being the larger and harder to fix issue. The servers – well, VMs – I am running these on are also not the same size and type. Unsurprisingly the WordPress VM has more cores and more RAM compared to the static site.

While I’m no front-end web developer by any stretch of the imagination, trying to improve this theme for my needs might prove a useful learning experience. I apologise in advance for more meta blogging posts.

Static site should be fixed now

Ah yes, the guy who used wear the “I don’t often test my code, but if I do, I do it in production” T-shirt in an ironic way followed his own advice, unironically.

The deployment script was ultra efficient and mainly removed the static site when updating it. Think about all the bandwidth this conserved!

Anyway, the static (beta) Hugo site should now be available and accessible. Feedback is still appreciated :).

Moving this blog to a static site – this time I’m serious (because org-mode)

I have been toying with the idea of migrating this blog to a static site to simplify its maintenance for some time. While WordPress is a great tool, this blog is a side project and any time I have to spend maintaining WordPress gets deducted from the time I have to write for the blog. Keep in mind that I’m self-hosting this blog and it’s actually running on a Linux VM that only handles the blog. That is yet another server that I need to administer, and it’s the odd one out, too, as all of the others are FreeBSD or OpenBSD servers.

Oh, and one of the big advantages of using a static site generator is that the whole site can be put in version control, archived there and also quickly re-generated from there should I manage to spectacularly mess up the host. A WordPress restore is a fair amount more work, as I found out about two years ago.

The only parts that don’t back up that well are the comments, especially if I use a self-hosted system for them.

Migration is fine, but what to?

For that reason, I had experimented with moving the blog to Jekyll for quite a while. In fact, I have maintained a parallel Jekyll blog for years now. For a smooth switch over, the devil was in the details though, and I was never happy enough to actually migrate and shutdown the WordPress site.

After another patchapalooza, I revisited the idea of converting the blog to a static site and looked at several other static site generators. I also decided to resurrect an experiment I had started with Hugo. My first attempt hadn’t been very successful, so I stuck with Jekyll. This second attempt however is a lot more successful as it addressed a couple of the issues that kept me from being happy with Jekyll:

  • Hugo builds the site much faster than Jekyll
  • I found a theme that I’m really happy with.
  • It looks like some of the details that I found hard to get right in Jekyll are already handled nicely in Hugo. This is mostly around the RSS feed generation – Hugo by default generates category feeds in addition to the regular “full” feed. It also looks like the category feeds are very similar path-wise to what WordPress uses, so hopefully the RSS feeds should continue working with the couple of aggregators that picked up this blog.

Fortunately, this time I succeeded in importing the site from Jekyll into Hugo. It took some work to clean up some of the artifacts that originated in the WP-to-Jekyll conversion, and then I had to convert the Liquid template code to Hugo shortcodes. The latter was pretty easy, but a bit tedious. Just not tedious enough to write a script to do it.

Hugo can render org-mode files (and so can Jekyll, apparently)

Another nice feature is that my workflow can still use org-mode for when I want to use it to write longer posts. Shorter posts I usually crank out in Markdown, but for the more complex posts it’s nice to have org-mode as an option. Especially if the post contains source code.

While the setup I described before with using org-mode to post to WordPress is mostly working, it’s a bit clunky especially if you’re using more than one computer to work on blog posts. Both Jekyll and Hugo can handle org-mode files directly – in fact, even though this file would be as effortless to write as Markdown, what you are currently reading is actually a processed org-mode file. Assuming that you’re reading this on the static site, that is.

What’s left to before the actual cutover?

There are two fairly large items I have to tick off the todo list before I can cut over for good.

  • Migrate the comments. Now this blog doesn’t get a ton of comments, but I appreciate all of them and am trying to migrate them over to this blog. As I believe in self-hosting everything, I’m experimenting with isso, and I need to redo some of the experiments with Hugo as so far, they’ve been completely focussed on Jekyll. Hugo does have built in support for disqus, plus this theme has support for staticman, but neither of the two are my preferred alternatives.
  • QA the site, especially the RSS feeds so that they hopefully keep working as they do right now.
  • There are still some minor tweaks to be done, analytics integrated and all that, but those are probably going to happen slowly after the cutover.
  • Oh, and the last item is all of the draft posts that have accumulated on WordPress that I somehow never got around to finishing.

The beta of the static site is here if you want to have a look. Any feedback is welcome.

Postmortem of the unexpected blog outage

Straight from the “make work for yourself because there aren’t enough hours in the day already” files.

I’ve mentioned before that I am self-hosting this blog rather than using a hosted instance. I hosted the WordPress instance on FreeBSD and it’s been running quite well for a while, but during a double FreeBSD port upgrade to WordPress 5.0.1 and PHP 7.2 – after the php 7.0 port had been discontinued – broke the blog. php-fpm failed regularly with a signal 10, but I wasn’t able to figure out why in a hurry, so I started looking at alternatives.

Read More

Digg Reader shuts down, and thoughts on organising my blog reading

Farewell, Digg Reader

Unfortunately,  Digg announced that Digg Reader is shutting down tomorrow. While I never used Digg Reader as my main RSS feed reader – I’ve got a paid subscription to Feedly – I was very happy to use it as a backup reader for those feeds that weren’t always that great at adhering to the RSS feed standard (I’m looking at you, bringatrailer.com) as it was more forgiving when it parsed feeds. Unfortunately it appears to be another one of the “feed readers are dying” incidents that seems to have started when Google Reader was shut down. There weren’t really that many alternatives in the first place unless one wanted to self host.

Read More

Cleaning up UTF-8 character entities when exporting from WordPress to Jekyll

I’ve been experimenting with converting this blog to Jekyll or another static blog generator. I’m sticking with Jekyll at the moment due to its ease of use and its plugin environment. The main idea behind this is to reduce the resource consumption and hopefully also speed up the delivery of the blog. In fact, there is a static version of the blog available right now, even though it’s kinda pre-alpha and not always up to date. The Jekyll version also doesn’t have the comments set up yet nor does it have a theme I like, so it’s still very much work in slow progress.

To export the contents from WordPress to Jekyll I use the surprisingly named WordPress to Jekyll exporter plugin. This plugin dumps the whole WordPress data including pictures into a zip file in a format that is mostly markdown grokked by Jekyll. It doesn’t convert all the links to markdown, so the generated files need some manual cleanup. One problem I keep running into is that the exporter dumps out certain UTF-8 character entities as their numerical code. Unfortunately when processing the data with Jekyll afterwards, those UTF-8 entities get turned into strings that are displayed as is. Please note I’m not complaining about this functionality, I’d rather have this information preserved so I can rework it later on. So I wrote a script to help with this task.

Read More

Improving my blogging workflow using Emacs (of course)

I try not to post too many metablogging posts. Other people do it better and I’m trying to focus on journalling what I learn as a software engineer and manager, not what tools I use for blogging. However after losing another post to WordPress’s built-in editor I decided Something Must Be Done. I think this is only the second post I lost, but it’s a fairly regular occurrence for a journalist friend of mine and I really don’t have that much time to retype blog entries that ended up in Bit Nirvana.

My first attempt was to resurrect the weblogger-mode setup I used to have a while ago but after switching the admin interface on my WordPress install to https, I couldn’t quite get it to work again. Plus it was a bit of a half hearted attempt as I never quite warmed to this mode in the first place. It’s actually quite odd as I tend to use gnus semi-regularly and the interface is very similar, but it never quite clicked for me for writing blog posts.

If I would exclusively blog on Windows, I’d just use Windows Live Writer, but as I switch between Windows, OS X, Linux and FreeBSD depending on which machine I’m on, Windows only software just isn’t going to cut it.

As everybody raves about org-mode (which I admittedly have never used) I decided to give org2blog a chance. It’s probably not the smartest idea to try to learn too many new tools at the same time but at least Emacs doesn’t occasionally eat my scribblings. Plus, I’ve started using Jekyll for another one of my experimental blogs, so using org mode and having they ability to publish to a Jekyll blog is also very useful.

So far I’ve got the basics up and running and the main blog configured. I’m using visual-line-mode to do automatic line wrapping and now will have to set up flyspell on the machines that haven’t got it installed yet so I can have basic spell checking.

So far, the basic workflow I’m planning is:

  • Sketch the post(s) and write the drafts in Emacs in the comforts of my local machine
  • Publish them as drafts to my standalone WordPress install
  • Do the final editing and spill chucking in WordPress
  • Ignore or heed the recommendations from the WordPress SEO plugin. That’ll be mostly ignore, then
  • Schedule the final publishing on the WordPress admin console

Hopefully that should work better than the “log into WordPress and start typing” approach I’ve used so far.

Welcome back to the new blog, almost the same as the old blog

The move to the other side of the Atlantic from the UK is almost complete. I’m just waiting for my household items – and more importantly, my computer books etc – to turn up. So it’s time to start blogging again in the next few weeks with a new blog or at least a new URL.

Due to some server trouble in the UK, combined with the fact that I do like Serendipity as a blogging system but was never 100% happy with it, I’ve switched to using WordPress on a server here in the US. The old blog will stay up, at least as long as the server stays put, but I won’t add any new content to the old blog.

Enough meta-blogging though, I should be back to the usual 1-2 post per month soon, so if you kindly could subscribe to the RSS feed and you’ll see when all of this is up and running again.