So it’s been about a year since I started using WordPress instead of Hugo to publish this blog, and it’s been quite a nice experience so far. I like the editing workflow, that I’m actually reminded to certain things like specifying tags and publish date when I do press the publish button, and that I can schedule posts so I can write when I feel like writing and still end up with a somewhat regular cadence of when the posts actually end up getting shown on the site.
The sligthly less rosy part of the whole thing has unfortunately been the performance, specifically the performance for anyone else than myself since the site gets hosted locally to me. Now there are some things I’ve already done to alleviate this, like using caching in WordPress so that the pages get rendered faster and using Cloudflare in front of the site as a CDN and cache to hopefully deliver the content from a location closer to the reader but it’s still quite slow because in the end speed of light is a thing and the caches don’t last forever. Also, only the assets and not the pages themselves ended up being cacheable with the free Cloudflare plan, so the main content of the site ended up being served rather slowly anyway.
Then, at some point, I remembered looking into Ghost, which is another publishing platform which remains more focused on just the publishing part than WordPress and while looking into it again I discovered a keyword which lead me on something of an adventure: headless CMS. What this specifically means is, that the CMS part is just there for managing the content and then provides an API which a frontend of your choosing can then use in order to render out the actual site—so a greater separation of duties in a sense. Classically in publishing systems, the CMS is responsible for both the whole content management part and the presentation part but this separation of the two means one can take a static site generator like Eleventy or Gridsome, query the API of the CMS for the actual content and still generate the site statically which allows it to be deployed more easily.
Since this site is mostly just me writing for the fun of it and the more interactive parts like comments haven’t really proved that used implementing this approach for the site was something I set about exploring, and what an exploration that was. It all ended up being somewhat more complicated than I expected, partially because the WordPress REST API isn’t necessarily set up for all the functions required for this sort of thing—ended up needing to install another plugin for authentication against the API so that things like site settings could be retrieved through it, normally only the session cookie based authentication is implemented—and another problem ended up being content management since I want to then also deploy the media I might embed in posts so that they don’t end up still being queried from the WordPress server and that use-case was surprisingly unsupported in many of the static site generators I looked at, not even through plugins. Now, of course, most of them support some form of filters or mapping or the like with which I could create this functionality myself without too much trouble, but I wanted something where someone else had (hopefully) figured out the edge-cases for me so that I didn’t have to go around thinking about file I/O and the like.
This lead me to settle on Eleventy which allowed me to reach my goals with the least amount of fuss—which is kind of what it bills itself with as well, “Eleventy is a simpler static site generator”.
Once that decision was made it was a relatively simple task of configuring Eleventy to query the WordPress API in order to fetch the posts and then display them in a near identical manner to the current site, with the biggest differences being the lack of comments because the site is now static as well as removal of some of the shall we say bloat that WordPress as well as JetPack include. It’s all well-intentioned and I could remove it if I liked so this isn’t a criticism of WordPress by any means—and in the case of JetPack I even chose to include that—but it’s still nice to see the site in a somewhat leaner form than it was before.
Getting the category-pages working however, was a bit more of a struggle—mostly because I’m somewhat stubborn however (and also not that familiar with Eleventy)—because I didn’t want to end up retrieving the pages from the API twice so I needed to figure out some way of providing two different collections while only retrieving that data asynchronously once. In the end however, I just ended up retrieving the data twice since that seemed to be the way Eleventy preferred handling this usecase, and in the end it’s just text so it shouldn’t lead to all that big of a transfer anyway.
After that, I simply needed to find a plugin for WordPress that triggers a webhook when a new post gets published so that the hosting for the static site knows to rebuild, and the process is essentially complete. For this I settled on Notification since it seemed on the surface the cleanest and simplest implementation and it looked like it would likely remain supported in the future as well—always a concern when adding a new plugin.
All in all, the process wasn’t perhaps quite as straightforward as I would’ve wanted but still easy enough to get everything going after I stopped being stubborn and just used the systems that actually provided the features I wanted (Eleventy, specifically referring to the local image support) instead of considering developing plugins of my own. From what I can tell the site also feels quite a bit snappier even for me so that’s a big plus as well, hopefully it ends up serving any potential readers better as well! Regardless, it was a fun journey.