• Home
  • 5 Reasons We Left WordPress for Hugo in 2021

WordPress is built for the web architecture of yesterday, and it does not look like it will change much from that paradigm in the next few years.

blog-thumb

WordPress powers a huge swath of websites on the internet today. Here are some quick stats from Creative Minds to illustrate just how ubiquitous of a platform WordPress is in 2021:

  • 39.6% of the internet is WordPress websites
  • 400,000,000 people visit WordPress sites monthly
  • WordPress is available in 57+ languages

There are some perfectly valid reasons for such a massive amount of adoption when it comes to WordPress’s ubiquity. WordPress is very easy to use, it comes pre-loaded on most commodity hosting plans available, and there is a huge ecosystem that has built itself up around WordPress.

Why Did We Leave WordPress?

To better understand how we arrived at this current point in time, we first need to understand the journey that actionspec.com has taken over the years…

Our First Site - 2014

ActionSpec’s web presence has had a rather interesting journey over the years, but that journey began with WordPress. When the company was started, we needed to get a web presence up and online fairly quickly, because at the time, the founder was the only person that was working on the site, and he only had so much time to go around. He knew WordPress, so it made perfect business sense to stand up a site using WordPress.

WordPress to HubSpot

A few years after our first website went up, we decided to move from WordPress to HubSpot. Hubspot is a great platform for marketing automation. We adopted inbound marketing as a growth strategy in 2018, and at the time it made sense to re-brand while we were moving over to HubSpot. This is how we arrived at the branding that you see on this site now. We switched from a blue and white design to a punchy orange and black-like brand. All our content was rewritten, re-branded and re-platformed. It was a pretty easy lift because HubSpot is a very DevOps-friendly platform, so we were able to stage changes before we rolled them live. What was nice about HubSpot is that we didn’t have to worry about scaling or hosting any of the functionality that the platform brought to us, that was all handled by HubSpot.

By and large, the biggest drawback to HubSpot was the cost. We were paying somewhere in the ballpark of $800/month for the platform. It was quite steep for a small tech business like ours. It was delivering some value, but not enough to justify the cost.

Business changes, Back To WordPress

ActionSpec underwent some serious business changes in 2019. We switched our core focus to delivering strategic consulting services for companies that were making digital transformations. The founder was also part and parcel of a DevOps PaaS startup that commanded much of his time. As such, we went back to a basic web presence on WordPress, since we were not producing all that much content or engaging with inbound leads. A lot of focus during this time was being paid to making sure that the WordPress site we did stand up was performant, secure, and would score the highest marks on GTmetrix and others. The best score we were able to get was a B after we implemented all the functionality and visuals we wanted on our site.

We were having some familiar issues with WordPress that were plaguing many of our customers that use that platform. Those issues were:

  • Doesn’t scale well at all - WordPress does not scale well at all, which we will explain later.
  • Two CI/CD Pipelines - YOu want to keep your technical tooling as simple as possible. Too many things can go wrong, which is why you want to minimize your exposure as much as possible. We needed two pipelines to handle changes to our WordPress presence, they were:
    • Pipeline for actual code - The code for our themes and plugins were source controlled in GitHub. Any time we wanted to tweak something in CSS, or anything with the theme or plugins we were using, we had to track that in source control and deploy accordingly. This, however, didn’t help us much with the next item, which was…
    • Pipeline for content changes - Since WordPress relies heavily on MySQL/MariaDB, we had to maintain a separate pipeline to control our content that was going out… Also, some visual and functional things were database-bound but functionally needed to be tracked in source control, so we had to version control our database too, which was a huge headache and didn’t make business sense given our size and workload.
  • Security nightmares - We were constantly updating plugins, the theme, and WordPress core. We had at least 3 streams of updates coming in. Of the dozens of weekly updates that we would do, a respectable number of those would break stuff on the site, regardless of how simple we kept everything.

All in all, there is a lot of overhead with WordPress if you want to run it as a critical piece of your business.

JAMStack For The Win!

ActionSpec went through a very weird period during the pandemic. Once we got back on our feet, we spend some time rethinking our web presence again.

We wanted to get back into inbound marketing so we could grow our client base again, but we didn’t want to pay for HubSpot, and we have adopted a policy of ruthless efficiency in every aspect of the business - so we didn’t want to spend a bunch of money either. Over the last few years, many people are switching their web architectures to something called the JAMstack. The JAMstack is an absolute dream for projects of all sizes that need cost efficiency, performance, and scale. In short, your entire site, and content live in source control like GitHub or BitBucket, then using incredibly simple CI/CD pipelines, any time you commit a change to your main branch, a static site generator compiles your site and deploys it to where you are hosting your site. Since you are deploying HTML and Javascript, you can get away with super cheap or free hosting. Most importantly, static sites are extremely performant. After making some tweaks to our template that runs our site, we are scoring A’s on GTMetrix, and we are in the 90’s on Lighthouse. We write our content, commit it to our repository, then it deploys to Cloudflare pages. If we break something, we can roll it back very easily. All our deployments for our site are zero downtime deployments.

The 5 Reasons We Got Rid Of WordPress

So, to boil this list down, here are the 5 business reasons that we left WordPress and will likely never go back:

Security

This is number 1. There are stories about WordPress zero-day vulnerabilities that have cost businesses lots of time and money to resolve. We have gone in and cleaned up a number of these compromised WordPress sites. Because the platform is so widely used, there are a ton of people who hack WordPress for fun and profit. This is why there is a cottage industry of specialized hosting solutions for WordPress. If you host it on a shared server like that of what could use at a commodity hosting provider, if someone else’s WordPress site gets popped, your site is in danger. Security is a full-time job with WordPress, which is why many people outsource the management and development of their sites.

WordPress Is Not DevOps Friendly

This is huge. We wrote a post called 3 Things You Need To Know About WordPress and DevOps which details a few key reasons that WordPress is now very DevOps Friendly. The main reason is one that was mentioned previously. The architecture of WordPress was designed when hosting your website on a single server was sufficient for the vast majority of use cases. This was also before people were using source control as part of their site lifecycle. Modern development teams rely on automation. WordPress deployments, especially ones that involve database changes (changes to content or changes to settings). You lose the benefits of WordPress’s click-and-go simplicity when you try to automate the deployment of changes using modern pipeline tools. WordPress is built for the web architecture of yesterday, and it does not look like it will change much from that paradigm in the next few years.

WordPress Is Not Highly Available Out Of The Box

Trying to run WordPress in an HA (high availability) environment, that also conforms to modern DevOps paradigms, is quite the undertaking, and it comes with a cost. We run customer sites in HA configurations because the nature of online presence for a business is mission-critical - which means that if a customer site goes down, that can and does mean lost revenue. We eat the food we make, so that means that we were hosting our site in the same HA configuration that we are utilizing for many of our customers. To make that work, we needed to run our WordPress site like this:

  • A small Kubernetes Cluster - All our clients are either moving to containerized workloads or are currently already running containerized. Our cluster was a provider-managed cluster running in Digital Ocean, so we abstracted away much of the Kubernetes management for simplicity.
  • Database Instance With a Read Slave - We had an HA instance of MySQL that we ran using DO’s RDBMS since we wanted to leave the daily management of MySQL to the provider.
  • CloudFlare for Caching - We use CloudFlare for all our edge caching needs, and are quite happy with the performance gains.
  • Compute node for Jenkins - We run our CI/CD pipeline outside of the cluster so we can separate the moving parts of our supply chain from the cluster itself. We view the cluster as a compostable resource as we do with everything in our service delivery stack. All parts must be interchangeable.
  • GitHub - This is where all our code lives.

When we moved everything to Hugo, the static site generator - we now only require GitHub and Cloudflare. The cost involved with running our WordPress stack was quite steep for one single site, we were paying somewhere around $370/month. To say nothing of the time value in time to make sure that everything was running correctly.

WordPress itself is not smart enough to know that it is running on multiple nodes, either. You need to store the ‘'’…/uploads/''' directory either in S3 (in Digital Ocean Spaces in our case), or mount an NFS share into the containers at runtime (the easier solution because it behaves as a real filesystem, not like an object store). If you don’t have a single instance of storage for the user-changeable data in WordPress, those changes will not appear on the other HA nodes. So user A might see the changes, but user B does not. This also applies to the database, which comes with its headaches, cost, and time overhead.

Time Overhead When Dealing With User Generated Content In A WordPress Deployment Pipeline

We are sort of an edge case when it comes to WordPress. We track database changes as well as code changes, which added some time overhead for creating and editing posts, pages and uploading other kinds of content. This was a huge hassle and is one of the reasons why we didn’t take the time to be more prudent with website content updates. We knew that to sit down and write 3 posts, it was going to take 20 minutes of ‘tweakery’ to make sure everything was compliant with our internal process - that’s not including the time it took to write the posts themselves. It created a point of resistance for us, a real blocker for us. Changes to anything on your website need to be revertable, performant, and secure. actionspec.com is no exception to this rule.

WordPress Performance Penalties And Bloat

Without caching, every time someone hits a WordPress site, it needs to ‘build’ the page. Depending on the size, type, and disposition of your site and its content, this requires computing resources. If you have a ton of traffic, this can crash your site. Many WordPress users will implement a caching plugin that will generate static pages to save round-trips to the database, and many more will use caching at the edge like Cloudflare. The more layers you add to your stack, the more time you add to how long it takes for a page view to be delivered. This impacts SEO and user experience. Caching does not make WordPress faster* - it simply means that you can handle more page views simultaneously. The less compute resources you need, the more cost-effective it is to host your site. The faster your site is, the happier your users will be. Again, you want as few moving parts as possible in your stack.

Conclusion

The vast majority of WordPress sites out there would be better served running on something like Hugo. 2/3 of WordPress sites are “here is my business, come patronize my services” websites, and can do without the bloat that comes with running WordPress at any scale, big or small. ActionSpec falls into the aforementioned use case. We write blog content, have a contact form, and a mailing list signup. WordPress in general, and how we were hosting it in particular, was simply overkill for us. Since we have moved to Hugo, our site loads so much faster, scores a full letter grade higher on GTmetrix, and is so much simpler to run and maintain.

We recommend Hugo to all our customers that have simple website use cases.