WordPress & the gross inefficiencies

Underjord is a tiny, wholesome team doing Elixir consulting and contract work. If you like the writing you should really try the code. See our services for more information.

My recent work with WordPress revived a frustration I built up while working with software from that era of the 2000's. Drupal, WordPress, Joomla and friends. Whenever you visit a page, the system will generate it from scratch.

Note: WordPress gets to take the brunt of the focus here. But it just happens to be what I recently used that re-ignited these frustrations. I believe this approach remains the standard for Drupal, Joomla, Mediawiki and many, many others. It is bad for all of them but the popularity and traditional use-cases around WordPress make it particularly relevant in my opinion.

This gives a lot of flexibility by sacrificing performance, something I definitely touched on in a previous blogpost. It gives a lot of power, simplicity and developer convenience as part of that flexibility. But the end result is that for an extraordinary number of use-cases this is incredibly inefficient.

Generating a page at the time of request is only really meaningful if the content is either very time-sensitive (as in seconds, rather than minutes) or if the content is markedly different for every request (often the case for logged in pages or pages generated by the user's actions, mostly the realm of web applications, rather than web sites). In other cases you can generate the content before-hand and just serve that repeatedly with great efficiency.

As a blog-engine you can argue for time-sensitivity, but usually to-the-second updates are not very relevant on a blog. And the stream of comments is often not that dense. Log-in and accounts is the second bit which some use, some don't.

An incredibly number of WordPress sites are mostly static content. The conventional wisdom is to put these behind Varnish or any of the many WordPress caching plugins. This mitigates a lot of the load for an active site and reduces load times for popular pages. Or one step further, use a WordPress plugin that generates a static version of your site to serve. These static generation plugins are among the best approaches for WordPress in my eyes. But they are usually also somewhat kludgy, a hack around the dynamic nature of the CMS. And you lose one of the great strengths of WordPress, its expansive ecosystem of plugins to do anything your heart desires.

Is this trade-off insurmountable? I don't think so. I think you can make most of a site static and still make parts dynamic. This has always been possible with the web platform overall. Just serve files if you have them and generates responses dynamically if you don't. But beyond this we now have the idea of the JAMstack (Javascript, APIs, Markup) that tries to provide mostly static pages with the power of dynamic parts. LiveView can potentially fill a similar role in the Elixir and Phoenix world. I hope to experiment with this sometime soon.

So it can be done. I think it made sense for WordPress to do things the way they did when they did them. It was basically the blessing of PHP to just be able to generate everything easily on-demand. It requires less knowledge from extension developers, less consideration. You can mix static content, dynamic blocks, everything is up to date with whatever is in the database. I wrote recently about some of my troubles with WordPress' over-reliance on the database.

But this is resource-heavy. A static site that generates in 100-300 ms on WordPress can easily be fetched in 30ms using some CDN. Requiring small orgs that want an information website that non-techies can edit to figure out good caching (one of the hard things in computer science) or to understand the trade-offs in making your WordPress static is not a fair shake. That stuff takes a bunch of experience in web dev, some people just want a website. A lot of people fitting this profile choose WordPress and similar sites, not knowing that their site could be blazingly fast, basically free to host and significantly more stable, secure and efficient if it was built differently.

This frustrates me if you couldn't tell. It wastes resources in the form of CPU cycles, RAM and power. It lowers the general quality of the web as an experience for users, platform for development and place of doing business. People pay for server performance they really shouldn't need, their sites use CPU and IO where the entire website would probably fit on a very small RAM disk and could be served straight out of memory. Or from a CDN where it can be provided as close to the end user as practically possible and be heavily optimized for fast delivery.

The trust and status of WordPress as a platform teaches developer after developer that this is fine, reasonable and even good. "I mean, if its good enough for the biggest and most beloved CMS on the planet, who am I to argue." That's what I picked up. I put trust in these tools and figured the problems were something unavoidable or my fault.

But honestly, I think it kinda sucks. I applaud the WordPress project for their hard work on accessibility, maintaining a complex legacy and successfully providing a strong competitor to proprietary solutions. But I don't think its technically healthy, I don't find it a sustainable way of working. And, aargh, the inefficiencies really get to me!

Do I have a solution to propose? Yeah. Sort of. Maybe. This is too long to get into that but the general ideas are in my writing here. I'm mostly presenting the case against the status quo here. I have my thoughts about what the we could be doing instead. But that will have to wait. Also, this blog is not exclusively dedicated to WordPress and frustrations. I just had some things to say on the topic.

Thanks for reading. If you have anything to share or want to argue about this with me, feel free to get in touch at lars@underjord.io or poke me on Twitter where I'm @lawik. Have a lovely day.

Underjord is a 4 people team doing Elixir consulting and contract work. If you like the writing you should really try the code. See our services for more information.

Note: Or try the videos on the YouTube channel.