- Making WordPress headless offers advantages over other headless CMSs in terms of both cost and the ability to customize the administration panel
- Furthermore, the headless architecture addresses common concerns with WordPress, such as security and performance
Our company, Yohaku, will complete its fifth fiscal year at the end of November 2024 and enter its sixth year in December. For the past five years, we have neglected our website in a state unbecoming of a web production company, so we have finally decided to redesign it at this time
Since we had the opportunity, we decided to go with a modern configuration that still had few adoption examples, but also wanted a configuration that could be immediately used for client work rather than simply pursuing the latest technology. Based on this approach, we proceeded with technology selection and ultimately adopted the following configuration
- Front end: Astro
- CMS: WordPress (headless & GraphQL)
- CI/Hosting: Cloudflare Pages
We had decided to use Astro for the frontend pretty much from the beginning, but the problem was the CMS. We've already handled several headless CMS projects at our company, and while there are benefits to creating incredibly fast sites by combining them with Next.js and Astro, it's also true that there are several concerns
Concerns about headless CMS
Costs and security per user
Generally, SaaS-based headless CMSs charge a fee for each user who logs into the administration panel. If you try to keep costs down with a free or low-cost plan, you have no choice but to share accounts, but this raises security concerns. Also, with fixed-price plans, it is difficult to set permissions in detail, so it is easy for a user to accidentally change settings
Pay-per-use charges based on the amount of data delivered
Similarly, this is limited to SaaS-based CMSs, but while images registered in the CMS are delivered quickly via the service's CDN, this also comes at a considerable cost. You must avoid the risk of starting with a free service only to have a sudden spike in traffic result in monthly bills of several hundred dollars
Low customizability of the input screen
With the exception of a few services, the input screens for headless CMSs are built using the GUI provided by that service. Each service has its own quirks, and it's often the case that the desired structure cannot be created due to the specifications. Also, because it's a GUI, it's not compatible with version control and is not suitable for collaborative work by multiple people. You might be thinking, "Isn't building WordPress input screens also done with a GUI?" but that will be discussed later
A headless WordPress installation solved all my problems
Costs and security per user
WordPress is open source and free to use, so naturally, there are no costs for each user. Furthermore, it's easy to flexibly set permissions as needed, such as not allowing anyone other than administrators to see the settings screen or limiting who can publish articles
Pay-per-use charges based on the amount of data delivered
The data delivery limits on typical WordPress hosting services are significantly more lenient compared to SaaS services. Furthermore, this time, I used the WP Offload Media plugin to configure all images registered with WordPress to be delivered via Cloudfare R2. Although there is a very small fee for registering with R2, the delivery cost is zero, so it's safe to say that the cost here is practically zero. On top of that, R2 is incredibly fast
Low customizability of the input screen
WordPress has a history of over 20 years as a CMS. While it often sparks controversy, its accumulated experience as a tool for building administration panels is undeniable.Advanced Custom Fields Pro , Admin Columns Pro, Admin Menu Editor Pro, you can freely customize the administration panel. Furthermore, our company has an in-house framework that allows us to write ACF custom field settings in PHP, and the settings for input elements are managed using Git.
Furthermore, concerns about WordPress itself are also addressed
Up to this point, I've discussed the advantages of WordPress as a headless CMS, but in fact, by making WordPress headless, it even solves some of the concerns that are commonly heard about existing versions of WordPress
Security risks
While it's true that WordPress can be operated quite securely if security measures are taken properly, a headless WordPress configuration separates the front-end and CMS into separate servers, significantly reducing the risk of tampering and hijacking. In the case of this Yohaku Web, since the images are also hosted on R2, the WordPress URL is completely hidden from the front-end source code, making it virtually impossible to identify the CMS address. In fact, if it weren't publicly disclosed like this, it would be difficult to even determine that the CMS is WordPress
It's slow because it runs PHP every time
While this can also be made considerably faster by adjusting the server and using caching plugins correctly, there's no doubt that this headless approach, which outputs the front-end using an SSG and puts it on a CDN, is incredibly fast
Poor DX (Developer Experience)
Honestly, I think this is the biggest advantage of making WordPress headless. Personally, the most tedious part of WordPress development is when you have to port the front-end content drafted in HTML to PHP. Constantly switching between HTML and PHP for trial and error is incredibly inefficient. On the other hand, if you start writing with a theme that includes PHP from the beginning, the coding experience is so bad that it's stifling
In contrast, with a headless configuration, you can write the admin panel and WordPress settings in pure PHP, while using front-end frameworks like Astro or Next.js, which offer superior user experience and improve the quality of your trial and error process
Issues that need to be addressed at this time
Since this is an internal project, we prioritized launching the site while covering operational issues. However, there are several challenges that need to be addressed before proposing this system as client work, which are listed below. Note that these are not problems unique to headless WordPress, but operational challenges in headless CMS in general, so the main point of this article, "WordPress is the current correct answer for headless CMS," remains unchanged
Establishing a staging and preview environment
I think one of the great things about pure WordPress is that you can click the draft/preview button and immediately see the article in that state. To achieve a similar UX, it seems necessary to enable SSR only in the staging environment while also setting up a system that allows draft-level articles to be retrieved via API
Checking the build status
While it's understandable that a build process exists in a headless configuration, it would be nice to have a way to check the build status on the admin panel after clicking the publish button. Netlify makes this easy using build status badges, but Cloudflare Pages and Vercel seem to require setting up their own webhooks
summary
Finally, I mentioned some inconveniences, but these are the only drawbacks of a headless WordPress configuration. In terms of workload, as we accumulate more practical experience, it should be possible to proceed at a level equivalent to or even lower than a pure WordPress setup. As mentioned earlier, I would like to use this in client work in the future, so please feel free to contact me if you are interested
This first post after the renewal is quite long because I put a lot of effort into it, but I'll probably mention Astro in a future post soon
Bonus: Other CMSs I considered
Payload
Actually, this is the headless CMS I'm most excited about right now. It's a self-hosting type, and it largely addresses the concerns I had about headless CMSs mentioned above. However, the learning curve is steep, and the number of servers that can host the CMS itself is quite limited, which is a drawback. Also, it's still under development, and after comparing it with WordPress, I've concluded that it would be difficult to deploy it in client projects within the next six months. However, I definitely have high hopes for it, so I plan to keep a close eye on future updates and continue testing it
Sanity
It's my favorite headless CMS among SaaS solutions. While the style of building the admin panel yourself using code has a learning curve, it's very appealing because it's easy to manage with Git. We also have several successful projects using it. If WordPress is completely out of the question, then it's currently our top choice
However, the previous pricing plan was "start with the free plan and only pay for the excess amount (around a few dollars) if you exceed the limit," which made it easy to recommend for client work. But with the recent price revision, the overage fee for the free plan has been eliminated, and subscribing to a paid plan is now mandatory, which I think is a risk. That said, the basic data transfer limit has been significantly increased, so I don't think forced switches to paid plans will happen very often