A Case made for Static HTML over WordPress akin to Mashing Potatoes with a 1998 Ford F-150 (2024)

While it is possible to mash potatoes with my 1998 Ford F-150, I really would not compare it as a utensil to my plastic kitchen masher. It’s quite capable of mashing potatoes but is really meant for more.

Obviously.

I read Ryan Cordell’s Profhacker column yesterday, Build a Speedy, Dynamic Class Website Using Markdown, RStudio, and GitHub Pages. He shares his approach on creating course web sites based on Aleszu Bajak’s approach.

Ryan contends this approach is better than his previous use of WordPress for a “dynamic, menu-driven, flat HTML course website”.

I am a bit of a WordPress zealot, having being using it for (yikes) 12 years for most of my own work and for my projects. But I’m hardly a WordPress hammer seeing everything as a WP labeled nail. I’ve been doing a lot of web projects the last few years sans WordPress, using HTML5up themes (my calling card https://cog.dog/), presentation sites like for MLA15, Skidmore College Storytelling, Domains 2017. I set up a bunch of interactive tool sites as static HTML running in GitHub Pages like CC IP-SUM, We Make The Road By Annotating, Words With No English Translation, and Flickr CC Attribution Helper.

None of those sites used WordPress.

I spent a lot of time last year developing a publishing flow rooted in GitHUb Markdown, that would seamlessly work there, in WordPress, and the Hugo Learn Static site generator (sort of Jekyll-like).

I certainly think Ryan’s approach for making a set of web pages for a course, syllabus, course information, works well as static HTML. I have some questions about his claims on comparison to wordpress (addressed below) but more so, I don’t think his use case makes for a strong extrapolation to the use of WordPress. A menu driven set of HTML pages is hardly the limits of WordPress can do.

Let’s take on the issues Ryan outlines as problems for WordPress.

Bloat. As WordPress has become more and more prominent—by many accounts, 25% of the web runs on WordPress today—the number of plugins required to keep it safe and functional have ballooned. I increasingly felt I was wasting too much time just keeping the application and all of its plugins up-to-date.

I’m not sure I’m comfortable with a claim that WordPress is bloated, but that’s not even how Ryan framed it; his claim suggests the overhead of maintaining WordPress and plugins updates. As of version 3.7, WordPress and plugins can be enabled to automatically update with no intervention. If anybody remembers what it took like 8 years ago to manually install WordPress, edit config files, create databases, you have no idea how streamlined it is in 2017.

I’m not sure how many content management systems have a facility close to this, or to the breadth of community development.

Now he can make a case that because of the high use of WordPress (it is actually now 29%) it’s more of a target by hackers. This does call for consideration of plugins and other measures to keep your site secure.

But this is hardly “bloat”.

Next argument of Ryan’s was a suggestion that WordPress was slower than static.

Speed. While the phrase flat HTML might recall the early days of the World Wide Web, such sites, generated by methods such as the one I’m discussing today or through systems like Jekyll, which I will discuss more in the near future, are simply much speedier than WordPress-driven sites. They load almost instantly and respond nimbly. By contrast my WordPress pages feel sluggish.

A platform that does a lot of tasks, an admin interface, a database connection may make one thing that of course a bunch of static files would be naturally faster. But do more than a gut feeling if you are making a claim.

And there are more issues to consider for speed than the platform; there is the host, it’s backbone connection to the internet, and all the squirrels sitting on the wires between your browser and the server.

I decided to do some testing with a recently WordPress blog post that was originally published on a WordPress.com blog then automatically republished on my own blog via Feed WordPress Syndication (which, FWIW, is something WordPress can do that a static site cannot do).

I saved that blog post from my blog as stand alone web page so it would all be self contained static HTML (using Save As… in Chrome). This post has embedded images, a YouTube video, even a Github GIST file.

I should add it took me a bit of fiddling because I had to also include the CSS for the parent WordPress theme, but it’s all available at http://cogdogblog.com/stuff/on-transformations/— although on the sam domain, that is all separate from WordPress- here is a screenshot of the directory files, which weigh in at 5.1 Mb

I think it’s important if you are going to compare a WordPress site to a static HTML one, you ought to compare them on the same web host.

Again these are the three sites tested:

• WordPress.com https://cogdogroo.wordpress.com/2017/11/28/on-transformations/
• Self hosted WordPress on CogDogBlog.com http://cogdogblog.com/2017/11/on-transformations/
• Static HTML on CogDogBlog.com http://cogdogblog.com/stuff/on-transformations/

I ran a simultaneous load test of three sites on WebPageTest, where the results are available in a number of formats, here is a comparison video:

WordPress.com is kind of a slow nag, eh?

Or you can see the charts and graphs.

And also the timings for various elements, for the most part, self-hosted WordPress is a winner

How can this be? Well, I run a caching plugin on my WordPress site. But also, WordPress is really damned optimized.

This test is hardly conclusive, but I like to do more than go by a feel in my browser.

Ryan’s third point is whether WordPress is appropriate for his need:

Need. Frankly, I realized that few of my sites required the infrastructure of WordPress. Only a handful took real advantage of WordPress’ advanced user roles, and few of them included enough resources to make a full database architecture really necessary.

This I totally agree. His need is an outline series of web pages, something with a table of contents structure, a menu to navigate. I’d hardly reach for WordPress to do this task. The “interactivity” and “dynamic” features he cites is really just generating menus from a .yaml file. Heck, I was doing that with PHP or Javascript in the 1990s. It’s just a bunch of static pages.

But it’s not argument that WordPress is not a good platform.

Ryan’s points 4 and 5 are the same, Simplicity, and again I mostly agree.

Simplicity. I am increasingly convinced by arguments for minimal computing in the digital humanities, at least when such choices are possible. If I can make my course and project sites more amenable to access from less resourced computing environments, that seems like something I should do.

This too is valid. With static HTML you can actually develop completely on your desktop (though I do as well with WordPress and Varying Vagrant Vagrants), but moving static files is simple file transfer.

Simplicity. One reason I liked WordPress Multisite was the ease with which I could create a new version of an old class site, so it just needed to be updated rather than recreated. But doing this is perhaps even simpler in the flat site formats I will discuss in the next few posts. Whenever I next teach Reading and Writing in the Digital Age, all I will need to do is create a new branch of its GitHub repository or, were I using a different host, duplicate the folder containing all the site’s files. Either way the duplication will take seconds, and all that will be left is to update the new files to reflect any changes made to the course between semesters.

I am not sure how this is valid. If you are using Multisite, you can simply install a plugin like NSCloner to internally clone sites in seconds. I just did this for a multisite I used for a speaking/presentation tour. I made template sites for wordpress and my “SPLOTpoint” presentations, and made about 12 clones as needed.

There’s a lot to be said for simple static sites. I’m doing more and more of them, and there are some really slick things one can do. I will do that as a first approach. Going without the overhead of database and server setup is key.

But it hardly makes for a valid comparison for a static site of fixed pages to compare it to WordPress and all the things it can do and manage. If you are going to mash potatoes, go for the masher, not the pickup truck.

Featured Image: That’s my own photo of my Ford F-150: Big Red flickr photo by cogdogblog shared under a Creative Commons (BY) license. Ironically I found it search Google Images (results for open licensed results) for f-150 tire with results found in Wikimedia Commons. The potatoes edited in are from a pixabay image by Capri23auto shared into the public domain using Creative Commons CC0