It’s never been a better time to develop themes for WordPress. The advent of Gutenberg Full-Site Editing has simplified the process, removing (almost) the (entire) need to leverage PHP when creating robust web experiences. While there are tons of improvements ahead in the coming months and years, Gutenberg has already leveled-up the theme creation experience.
While Gutenberg has removed many pitfalls, not everyone is keen on adopting a new technology. Additionally, there are use-cases for clients that necessitate a fully-custom front-end experience that leverages tools that don’t always make sense to incorporate into a WordPress theme. Thankfully, a solution exists that allows for a decoupled (or headless) WordPress implementation.
Through the rest of this article, we’ll use the terms decoupled and headless interchangeably. Decoupled refers to the front-end and back-end experiences of the site being on separate hosts. Headless refers to accessing a WordPress site’s content without its front-end, which is how decoupled implementations are built.
The WordPress API
The WordPress REST API, fully integrated into WordPress with version 4.7, allows for content to be consumed separately from the web server itself. And while this doesn’t sound revolutionary if you’re familiar with RSS feeds and content syndication, the API provides much more depth, such as the ability to tap into all post properties, as well as site options as JSON. For ambitious use-cases, it’s even possible to write content to the source WordPress site from the external application.
Most often, the three primary aims when separating the content in your WordPress back-end from your front-end user experience are –
- Speed: separating the front-end and back-end into separate services improves the front-end performance, as load time is not impacted by database calls;
- Security: end-users are not provided direct access to the WordPress server. It’s also possible to create an implementation where the WordPress instance is not directly accessible at all, only to your front-end app through a firewall;
- Flexibility: developers can leverage modern tools such as React and Next.js to create highly-dynamic and performance-conscious applications, completely bypassing WordPress’s template hierarchy system.
Flexibility Breeds Complexity
While this all sounds great – and it is – the added flexibility provided comes at the cost of simplicity. Some functionalities inherent in WordPress no longer work (or no longer work the same) when decoupled –
- Plugins that add dynamic functionality on the front-end typically will not work. This can also impact server-specific plugins such as 301 redirect tools;
- Attachments uploaded will not be automatically accessible via direct URLs if your server is behind a firewall. For some clients, this necessitates reaching for third-party paid services such as Amazon S3 or Cloudinary to manage external asset hosting;
- Most decoupled WordPress installations require a lot of custom development work. This not only requires talented developers to implement, but also to maintain. This adds technical debt if there is developer turnover, either individually or when shifting to new teams or external agencies.
Alternatives To Decoupled
Headless WordPress sites aren’t for everyone. Most often, clients opt for these implementations to guard proprietary information that may exist on their servers. However, other options do exist.
Hybrid Themes
Similar in its goal of incorporating modern technologies into the front-end experience, many clients opt for the use of hybrid themes. They do not decouple the front-end and back-end, but are headless because they still communicate with the WordPress API directly from within the theme. This maintains plugin functionality as well.
The primary drawback when comparing this approach to decoupled is that it doesn’t include the automatic performance benefits or added security, while still adding some additional complexity.
Static Site Generation
On the other hand, static site generation doesn’t add complexity. Plugins and services exist that export your site as static HTML, CSS, and JavaScript. This can be deployed (or auto-deployed if you’re fancy) to a barebones external host, since almost anything can serve HTML, CSS, and JavaScript these days.
As the name implies, static sites are static – not dynamic. So, as with decoupled sites, many plugins aren’t able to function in a static deployment. This is either a dealbreaker, or requires reaching for more complexity in the static implementation to replace lost dynamic functionality – kind of defeating the purpose.
The Takeaway
Leveraging the WordPress REST API, application developers can create front-end experiences separate from the WordPress server instance. This adds flexibility and security, but also adds complexity and makes it difficult to use some popular WordPress plugins and features.
Alternatively, hybrid themes allow for the incorporation of modern development tools within standard WordPress themes, and static site generation exports a copy of your website that is easy to host independent of your WordPress server. All of these options come with their own advantages and drawbacks, and the best choice depends upon your use-case.