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:

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.

For the visual progress, self hosted WordPress is fastest

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

Profile Picture for Alan Levine aka CogDog
An early 90s builder of the web and blogging Alan Levine barks at CogDogBlog.com on web storytelling (#ds106 #4life), photography, bending WordPress, and serendipity in the infinite internet river. He thinks it's weird to write about himself in the third person.

Comments

  1. Hi Alan,

    It’s good to see you are carrying the WordPress flame, between that and blogging you’re becoming an Atlas of the Web 2.0 years :) I flirt with the moves to Github and all that, but in the end the labor seems far more than the payoff, and if WordPress straight up seems hard, I wonder how self-authored Markdown will fly during our workshops to reclaim one’s domain :)

    That said, I have a list of sites I need to archive to HTML static sites for some of the reasons listed here, but that is mainly because they are museum pieces now. The discussion around safety and bloat in WordPress is persistent though, and Kin Lane has been talking about the headless CMS that has me interested, but I don’t see any practical alternatives to WordPress and what it can do. I am not afraid to go rogue from WordPress for awhile and see, and it may be good for my learning curve, but I still have a hard time taking the WordPress is bloated, slow, and passè arguments seriously. I guess that comes with the territory of predominance, and I’m sure WordPress (like everything else) will be replaced at some point. But pointing folks to Jekyl and Github seems to me the absolute wrong direction for wider adoption and ease of use.

  2. It’s good that you scratch this edge. My self-hosted WP site uses cache. The cache is rebuilt daily and on need, proactively. It uses a nginx redirection. This means it really acts as a static site, no php or database is harmed when you fetch a page. Details are added by dynamic scripts.

    What disturbs me the most with WordPress is the poor coding, the complexity and in fine the poor UX from editor point of view. Trying to align images, paragraphs properly, in a way it fits for mobile and desktop is a pain. The lack of competition caused WordPress to offer a very poor UX. It dominates the market not because it’s good but because you can’t beat the price and the ecosystem.

    Markdown is nice but it’s like limiting ourselves to make it easier. I tried github, ghost but I’m not happy with it.

    Your figures on static websites have to be triple checked. Modern websites delivery implies cache, inline image place holders, shared CDN, in-browser storage etc…

    Another criterion would be to see how to support scaling. Each page requires a php instance for as long as the page is delivered. A slow client causes a php instance to stale for a while. You can’t have so many php instances because it takes memory and database connections.

    1. Thanks Bruno. The speed issue is still questionable, I agree, and to me is not the critical part of my sloppy argument. The claim was made on a comparison of use hardly comparable. If all you use WordPress for is a crutch to write HTML through a visual editor, well dot dot dot.

      I’m not sure WordPress can be blamed for the challenges of multiple platform layout, it’s huge design challenge period. The problems start for most people when they try to control the layout from markup, or make it work perfectly on the device they are building upon, rather than going semantic and letting the style sheets do their work.

      I almost never use the WordPress visual editor, it drives me batty. And there are some layout elements that will be hard to work across multiple screen sizes.

      We just keep doing what we can…

  3. Good job, Alan.

    I would add something Ryan and the others who who pooh-pooh WP for teaching in favor of “markdown, jekyll, github, html, blah, blah…” don’t seem to deal with – most faculty.
    Sure Ryan & Co. can deal with all that and actually think it’s “easier”, but it’s really not practical for the 99% of faculty that teach and don’t have Ryan’s computer skills and coding background.

    I can set up a faculty member or a student to teach/blog with WP when they’ve only ever used MS Word & email to ever do anything on a computer. Using a rough templated site – or even better a SPLOT — we can have them writing & publishing on the Web and even have them benefitting from FWP connected courses setup, in an hour. Sometimes less for students.

    Getting them to learn markdown + GitHub + all that other crap? No way.

    So sure, Ryan can be some kind of purist and elitist. But I’m more interested in getting as many real faculty & students actually doing stuff as soon as possible

Leave a Reply

Your email address will not be published. Required fields are marked *