WordPress & the gross inefficiencies

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.

Latest Posts

Video - Livebook, trying it out

Last friday I did my second live stream. A lot of nice people stopped by and I spent the time showing and getting more familiar with the newly released Livebook....

Read More

Lumen - Statically compiled Erlang for x86

The Lumen Project is an ambitious compiler development effort to create a complimentary set of compilers and tools that allow developers to get the power of the Erlang VM, The BEAM, in places it does not traditionally fit. Such as the browser. Currently the project is at an early released stage as covered in Luke's ElixirConf talk. It does not yet implement all of Erlang OTP and as such won't handle most Erlang/Elixir you could throw at it. I want to show something that it does do. And while the project is a complicated compiler project you do not need to know that stuff to try it out. This should be achievable for most developers and to ensure that I wasn't talking out of my rear I had my assistant developer follow the instructions without my input and it worked out well....

Read More

A Telegram Bot in Elixir feat. LiveView

I asked my network about noting ideas quickly and got a lot of good responses. One mentioned saving them in Telegram. I don't think I want to do specifically that but I do want a minimum friction way of noting ideas for later review and refinement. And sending them to a Telegram chat would be quite nice. So I started on the path of something like a note-taking system using Telegram for ingesting quick notes. And I want to share the satisfaction I felt with seeing the near real-time way that it works....

Read More
Read All Posts →