At long last, the day has come! WordPress is dead to me, at least in the context of my personal site. I still work with WordPress for select clients, but I am no longer using it myself. WordPress was an absolute resource hog, it was a full time job keeping everything up to date, my hosting provider was costing me fortune, and WordPress’s plugin and theme marketplaces made me feel like I was walking into a thrift shop that doubled as a dump.

My WordPress DevOps Stack

I was hosting this blog on WordPress, using Digital Ocean’s managed Kubernetes Service. The way it would work is this:

WordPress Deployment

Step 1 - I would check any tweaks I made to the theme into Git, which would trigger a Kubernetes pipeline that would deploy the site Step 1a - In that Kubernetes pipeline, the core of WordPress and my theme would get baked into a container image, excluding the /uploads and /cache folders. Those would get mounted from Digital Ocean Spaces (Which is S3 compatible storage) Step 1b - The container image would get rolled out to my Kubernetes cluster Step 2 - CloudFlare API would get called to dump my cache Step 3 - I’d get a notification when the deploy finished

WordPress Persistent Data

I mentioned in Step 1a that I was excluding the /uploads and /cache folders that I was using. WordPress was designed in an era when “Cloud Native” applications were considered to be edge cases. Most of the files that make up the WordPress core can be treated as ephemeral. They shouldn’t change, they need to remain the same under normal runtime conditions. The only things that I would be changing would be media files attached to posts, and the posts themselves.

What about the Database?

I’m glad you asked. I run DO’s database as a service for MySQL so I don’t have to mess with the innards of maintaining a database, but if I did feel like foxing with it myself, I would likely have run that in Kubernetes as well. I treat my blog as a mission critical part of my online presence.

Some day I will write up the details of this stack I was running if you wanted to do something similar. I automated much of the process, but I must warn you, it is quite an expensive way to run a WordPress site. If I wasn’t doing DevOps consulting, I would probably have just put it on some commodity hosting and have called it a day, but I practice what I preach.

Is Kubernetes Overkill for WordPress?

In 75% of use cases, yes. The only use cases where it makes sense to run WordPress deployments in Kubernetes are:

• You generate real money with your site and uptime is important

• You do a ton of traffic every month, like over 8000 page views monthly

• You are The White House (Yes, whitehouse.gov as of 2021 is running on WordPress)

• You manage multiple WordPress sites, and want to get as much bang for your compute-power dollar as you can by densely packing your infrastructure.

Since, again, I do DevOps consulting for a living, I run the same stack that I sell my clients. My site fits in the 75% of use cases where WordPress in Kubernetes is overkill. As I was peeling back the layers of what made my site run, how much it was costing me per month to keep running, I knew that I needed to make some serious changes.

How much does it cost to host WordPress on Kubernetes?

This is a great question! I will likely write another article to cover this from end to end for those who are curious, but here was my cost breakdown…

3 Droplets with 2gb of RAM - $30/month
Kubernetes Control Plane - Covered by Digital Ocean
Managed MySQL Database - $15/month
Spaces (For storage) - $5/month for the first 250gb 
Load Balancer - $10/month
CloudFlare - Free

Excluding my time that I spent actually tinkering with my WordPress site, it cost me $60/month for the bare minimum best practices.

Deploying WordPress Changes And Updates To Kubernetes

This is the part where I address the WordPress Core, Plugin and Theme updates that stagger through. It is not as simple as just logging into the WordPress admin and clicking on the little update icons. If you do that, the updates will be executed relative to whatever instance of the container I would be dropped into by the load balancer, and it won’t feed it back to Git, which is the single source of truth for everything.

I basically had to spin up a special dev container that I built locally, make a branch in my Git repo, grab a fresh copy of my database, and spin everything up locally to execute the updates. Once those were done, I would check everything back into git, take an export of my database and diff it against the production database dump (Sometimes updates will touch the database, which is a different post completely), then I would merge my development branch back into master which would kick off my pipeline process and deploy the changes to production.

These updates round trip took anywhere from 2-3 hours, so I would often plan my updates to happen once a month, which to me is unacceptable since some of the security patches that needed to go up were for some serious security vulnerabilities. I practice what I preach, but my customers who actually pay me money come first, so my website got atention once a month. The time I was able to give to my website for actually writing content was 4 hours a month on average. Now that I have left WordPress for Hugo, I can now put all that time back into writing informative posts such as this one. In a shop where your WordPress site is tightly managed, and everyone sticks to the process, and it is a mission critical piece of the business, then it makes sense to adops a regular update strategy that revolves around a set schedule.

WordPress To Hugo Migration

I have used Hugo in the past for smaller projects where the clients were not doing any complex integrations or using shopping cart functionality. Hugo is a static site generator. Static sites, which are pure HTML/CSS mixed in with some Javascript are orders of magnitude faster, more reliable and cheaper to host than any other kind of website. Most WordPress caching plugins will essentially boil your most used pages into HTML so they can be accessed at filesystem speeds.

Basically, you feed your content into Hugo by way of markdown files, and it will in turn bake those into static HTML content. Because this process is repeatable and scriptable, it can be put into a CI/CD pipeline, so every time you check new content into Git, it will execute the Hugo pipeline, build and deploy your site.

Why are Static Site Generators Faster Than WordPress?

I don’t care how much money and resources you throw at hosting, caching, database tuning and custom development, WordPress will never be as fast or scale as well as a statically generated site. That probably sounds like a hot take, but lets break down what happens under the hood…

WordPress Site Gets A Hit

When you access a WordPress site, Apache/Caddy/Nginx gets the call, and looks for the index page, which is index.php. Index.php executes with the PHP interpreter which in turn executed a MySQL query against the database, which then returns the values from said query to build the page for the end user. This round trip process is repeated every time someone hits a page. The repetition problem is solved by implementing various caching layers. A best practices scalable WordPress site will use object caching like Redis, Page caching like Varnish (or one of the many WordPress page caching plugins), and edge caching like CloudFlare. These caching layers don’t really add speed so much as they add scale. No amount of caching will make slow and crappy WordPress code fast, it will simply allow it to serve more viewers in a slightly more efficient way. These are extra moving parts than can and do decide to not work properly, which is why I ran all these pieces in their own containers, so when Redis would decide to puke, Kubernetes would just kill it and recreate it before end users knew anything was wrong.

Hugo Site Gets A Hit

When you access a site that was generated by Hugo, Apache/Caddy/Nginx gets the call, looks for the page that you are requesting, in this case index.html - and presents it directly to the end user. Since this page is already built in a browser native format, it does not require the server to execute scripts to build the page. No database interaction, no need for a complicated caching layer. Nothing is faster than a filesystem, except maybe serving pages from RAM.

Hugo Has Less Moving Parts

Since Hugo has far fewer moving parts than a typical WordPress install, it is more reliable. This means when a server crashes, you can just pull the latest from Git and re-deploy it to a different server, change your DNS and you’re done. Since I host this site with Netlify, they handle all that for me. Since my site is essentially in one giant filesystem (They use Amazon’s S3) - I have virtually infinite scale, and no one server that would take my site down if, say, a hard drive parked for good. Less moving parts = more reliability.

Are Hugo Sites More Secure Than WordPress?

Yes. WordPress is known for having serious security holes. When those holes are not patched regularly, sites often get compromised by hackers on the internet. I could make a drinking game from how many WordPress sites I have had to clean up after getting hacked, but I don’t drink like I did when I was 20. Since Hugo sites are basically just a collection of files, post-hack cleanup is very easy, you just restore the known good files from your source control repository (In my case, Git) and you’re done. What’s more, S3 does not function like a native filesystem, it’s more of an object store, so nothing actually ‘executes’ in S3 - so filesystem directed attacks are virtually useless.

Hugo Sites Score Better Then WordPress On LightHouse And GTMetrics

I spent countless hours tweaking my old WordPress site so it would score as high as humanly possible on PageSpeed, LightHouse and GTMetrix. It took quite the combination of Apache tweaks, caching plugins and all order of changing the order of element loading orders to get an “A” In GT Metrix. I feel like every time I updated something, I’d have to spend an hour checking and tuning WordPress. This process was a breeze when I moved all my content over to Hugo. I’m still working on optimizing images, but I currently have an A on GTMetrx now, and it took less technical tom foolery to get there.

Should You Ditch WordPress in 2021?

If you run a blog, an informational site that you don’t update in real time, like a restaurant website with a menu and contact information, or you run a business that doesn’t have a client login area and you are just serving things like downloads and a contact form for generating leads - you should consider getting rid of WordPress, especially if you are looking for a ‘set it and forget it’ kind of website that you want to just work without issues. A good 75% of WordPress use cases function better on Hugo orders of magnitude better than WordPress can do.