Brand Breakout Summit/2021: Headless 101—Everything You Wanted to Know and More!
Why is headless so hot right now? Headless is a new pattern for building websites that introduces several new concepts to WordPress. According to a new study, 64% of enterprise organizations are currently using a headless approach, representing a nearly 25% increase from 2019.
Getting started with headless may feel overwhelming, but once you understand the playing field, your team will be building absurdly fast, decoupled websites in no time. In the session below, WP Engine and Click Here Labs team up to cover key terms, emerging trends, and cutting-edge best practices for Headless WordPress.
In this session, WP Engine Senior Product Marketing Manager Hashim Warren, and Click Here Labs Director of Digital Production Jonathan Jeter discuss:
- A basic introduction to headless concepts, including benefits, trade-offs, and advantages of using Headless WordPress on your next project.
- Real-world use cases for Headless WordPress projects, offering a closer look at the successes and the challenges headless can present.
Marketers and developers love this new architecture of Headless WordPress. And that’s for a few reasons. Number one is cutting-edge performance. The frameworks that I talked about aren’t just focused on accessibility and SEO. They are focused on making high performance websites easy to be created by developers.
WP Engine Senior Product Marketing Manager Hashim Warren
Full text transcript
HASHIM WARREN: Hello, there’s a lot of excitement and confusion when it comes to Headless WordPress. In this session, Headless 101, we will give you the trade-offs, case studies, and advantages of using Headless WordPress on your next project. My name is Hashim Warren and I am the Senior Product Marketing Manager for WP Engine, working on our Headless projects. And I am joined by Jonathan Jeter, the Director of Digital Development at Click Here Labs.
The first question that people ask before they’re doing a Headless WordPress project, is what is Headless WordPress, period? So you may have heard about Headless WordPress years ago when the WordPress REST API first came into core. Or you may have heard about it recently, as people have been talking about using an alternative front-end for Headless WordPress. So before we get started, I just want to level set and explain what Headless WordPress is and how it differs from traditional WordPress.
So Headless is a new approach to using WordPress. When you use Headless WordPress, you no longer make WordPress responsible for rendering the front-end of your website. Instead, you use WordPress strictly for managing content and also managing users on your project. So can use WordPress– WordPress’s API, this native REST API, or an alternative API like WPGraphQL to send data over to an alternative front-end or another device.
So on our website, developers.wpengine.com, Nate Archer, one of our writers, explains Headless WordPress this way: “Headless WordPress is when you use WordPress and a separate system for rendering content.” That is essentially what Headless WordPress is.
So what happens when you start using a separate system for rendering the front end of your website? Well, there are a few different systems and frameworks, and meta-frameworks that are popular with developers when using Headless WordPress. These frameworks usually use a JavaScript library like React or Vue to create and template pages. And then the frameworks add-in needed features like routing and creating pages and other features that you need in order to make websites.
So two of those popular choices are Next.js and Gatsby. And those meta-frameworks are based on React. And another popular choice is Next, which is based on Vue. So when you’re using a JavaScript framework, you have a few different problems that these meta-frameworks solve. One is speed. When you’re browsing the front end of a website and the marketing pages of a website, you do not want it to load as slowly as, let’s say the app version of a website where you log in. You want to load extremely fast. And these meta-frameworks, they solve that problem with speed.
You also want it to be accessible. Which out of the box sometimes JavaScript frameworks like React or Vue don’t have accessibility in mind. So these frameworks solve accessibility issues. And lastly, you want your website to be easily crawled by search spiders like Google and Bing. And that’s another problem that these frameworks solve. Instead of a search spider coming to a website where the content is hidden within JavaScript, these frameworks do special techniques like pre-rendering content so that search spiders can view your content and also rank it in search engines. So those are what meta- frameworks are that people use to render the front-end of their Headless WordPress site. And those are some of the advantages of it.
Now two of those meta-frameworks I mentioned are very popular, Next.js and Gatsby. And another question we receive when people are just starting their Headless WordPress journey, is which framework should I choose, Next.js or Gatsby? What is the difference between them? So there are many similarities between them. Like I said, they solve many SEO, accessibility, and speed issues. However, some of the things that make them special, I’ll go over right now. So, Gatsby, Gatsby is a system that is similar to WordPress in that it has a plugin architecture and 2,800 free open source plugins that allow you to add functionality to your website. Part of this functionality that’s really attractive to developers are plugins that grab content from WordPress or another system like Shopify or Drupal and makes that data easily available in your Gatsby project.
So if you’re using Gatsby, you can quickly spin up a website that meets the requirements of your team using Gatsby’s collection of 2,800 plugins. One thing that’s great about Next.js is that Next.js can generate dynamic and static pages. So with Gatsby, right now Gatsby can only generate static pages for your website. Meaning that when a visitor comes to your website, instead of the pages being created right there on the fly by a server, Gatsby has already pre-built your pages to make them fast and easily serveable to anyone in the world. However, sometimes if you want certain dynamic features, you don’t want to pre-build your pages. You want a dynamic website, that is where the pages are built based on the user need at the time. That enables things like personalization, and A/B testing, and other dynamic features.
Next.js, instead of choosing to be a dynamic site builder or a static site builder, Next.js you can build dynamic pages and static pages within the same site. This makes Next.js ideal for large sites because you do not have to have a long build time when you’re building a large site with many thousands of pages. Instead, you can build part of the site statically and also part of the site dynamically. Next.js is also great if you have several content updates a day. Because you’re not building your whole site statically, you can use Next.js to build one page on your site quickly and then have it statically rendered later. So those are some of the main differences between Gatsby and Next.js.
So marketers and developers love this new architecture of Headless WordPress. And that’s for a few reasons. Number one is cutting-edge performance. So the frameworks that I talked about, they are not just focused on accessibility and also on SEO. They are focused on making high-performance websites easy to be created by developers.
So any new feature that’s coming out in browsers or other systems that a developer could take advantage of to make your site faster, you’ll find those being adopted first in systems like Gatsby and Next.js. Some of the features that we’re really excited about is image optimization, pre-fetching of pages, PWA features on pages, where your website can become more like a web app or more like a native app on your phone, and more. So that’s one of the reasons why developers and marketers love these Headless WordPress. You can use these performance-focused front-end frameworks to have cutting-edge performance features.
The next thing that developers love is the modern developer experience that you can get when you decouple your website. So when a developer is using an all-in-one CMS like traditional WordPress, their workflow is tied to how that CMS works. But when they decouple the architecture where they’re using a different system to manage the front-end of the website, now they can use a modern CI/CD workflow in order to update the features on the website quickly.
They can also use React and component-based development architecture to create parts of the pages and parts of the site in a sharable way. So developers really love the modern developer experience of Headless WordPress because it enables them to use these new tools and these new ways of working.
The third thing that developers and marketers love is that this decoupled architecture is more secure by default. So when you separate your front-end from your back-end, you no longer are as susceptible to DDoS attacks or attacks on your database and other things that hackers can use to take down your site. I had an experience recently where I had my Headless WordPress site and I wanted to switch which host I was using for the back-end part, the WordPress install.
I was able to unplug my WordPress site from my front-end and switch it to a new host and plug it back into that front-end with zero downtime. So you can imagine if, let’s say my WordPress install was attacked. I can keep my front end up because the whole architecture is decoupled. So now I’d like to pass it to Jonathan and talk about Headless WordPress and speed and reliability.
JONATHAN JETER: Thanks, Hashim. Thanks for going through all those technical details on what Headless is and how it works. So now I can cover all the fun stuff of all the awesome things that Headless can do for a marketer. So I want to start with an example of– we did this couple of years ago for the Salvation Army. They have an annual report website and what it does is it basically gives what it says, the report of the financial donations and how the money was used and all the people that were helped throughout the year.
So this is a site that’s only updated once a year. And it was at the time a static site. So any time content needed to be updated at one time of year, people have to manually go in and change the HTML. And the people who are the marketers who are working on it would have to give it to a developer and we would have to make the changes. So there was this process that was in place.
So we decided at that point that we wanted a way to have the people who were the content editors go in and update the content and then export that site to a static site automatically. Eliminating the development changes that were going on and allowing the content editors or content producers themselves to go in and make those changes to the content and let us know when it’s ready.
So we, in this case, used Gatsby. And we use WordPress for the back-end. And it allowed us to give the marketers an interface that they were accustomed to. WordPress is easy for them to use. They would be able to go in there and create the content or edit the content once a year.
And we use a technology called GraphQL, which allows you to modify the way the data is presented out of the WordPress API. And then we used Gatsby to consume that data and generate a static site. So to your point earlier Hashim, a static site, what that allows you to do is there’s no database. There’s no other technology that the site is depending on. And so that’s going to be very reliable, it’s pretty stable and it’s very fast.
So that project went really well. Over the last couple of years, we continue to maintain it. And what we found is that one of the challenges with that is you’ve got to keep the Gatsby and the other technologies up to date even though you’re not adding content on the development site. There’s a little bit of maintenance that comes into it. But it really frees the marketers to be able to edit the content on their own without having to go through the development team every time they want to make a change on a website.
Another thing about speed and reliability and why it’s important is if you haven’t heard of Core Web Vitals, you will. You’ve probably heard it at this conference already. But what Google is doing with Core Web Vitals is saying that the user experience is really important and what is really important there is speed. How fast can someone see the site? And everyone’s heard the statistics of how quickly someone will bounce from your site if they don’t see content loading. Or if they don’t see something that grabs their attention.
So Google has come up with these ways to track how fast your site is loading. And sometimes if you’re using just straight WordPress or another CMS, there’s not a lot you can do with the front-end because it’s embedded with the themes and the core back-end code. What separating that front end with Headless allows you to do is to use a different front-end framework, you can be more flexible and you can customize the way you’re consuming that data in that content to make it faster and follow these guidelines that Google has put in front of us.
So we’ve done this on a couple of sites that we’re working on right now. And it just allows you to– for that front-end developer to actually go in and make those adjustments too. And you’ll see that if you go into the Core Web Vitals on the list. But modifying the code, only loading the CSS of JavaScript that’s actually needed for that page.
There’s all these different things, making sure that you’re loading the first thing as quickly as possible on that page and not loading a whole bunch of scripts. And then loading that hero image. Just so that the user has that best experience and that you see the content right away.
And a lot of these front-end frameworks, React and Vue and Angular, and these others will allow you to customize those kinds of things. For example, we’re taking the content for that page, we’re loading it up just the content that’s needed for that page. And then as
Hashim was saying earlier, preloading that as the content– we start loading the content for the rest of the site.
So when someone clicks the link to somewhere else on the site, it’s instant. That content’s already loaded and you just keep going page to page. And it really improves that user experience. So Headless allows you to do a lot of this. The pre-fetching of content, customizing what’s actually loaded into the browser and when. And that really helps the user experience. But ultimately, it also helps your search engine rankings in your search results and those kinds of things.
The other thing is that Headless gives you is flexibility. So what do I mean by that? Well, you’re not now tied into just the content management system. So you can use multiple sources of data, ingest those into WordPress to show what you’re going to present on your website. So one example is for a site that we’re working on now for a youth organization that has health clubs and those kinds of things. They have the class schedules and they have the volunteer information and they have the donation.
And these are all different services that they use to manage all those different aspects of their business. But we can now in WordPress, tie into all those systems, pull that data into WordPress so that it can then be edited in that one spot as opposed to going into all different systems and edit it. And then it can be taken and—we’ll see on the next slide– but then WordPress can then send that out to the front-end or to any other system that’s going to be ingesting that data.
So that flexibility of well, we’ve run into this before, we’re going to have to reprogram that content management system so that it’ll work with this piece. Or we’re going to have to make sure that we’ve said this a lot. Do they have a WordPress plugin? If you’re using WordPress and you’re wanted to tie in to say, CRM or Salesforce or HubSpot or something like you say, oh do they have a plugin that we can use to put that data in? And then a lot of times we’re like, well, no but if you put this form– the shortcode and there if you put this form that will then post. You can work around those things.
But what this allows you to do is take the data directly from those sources via the same way that you make the data available through an API. You ingest that data. You manipulate it or change it the way you need to, put it together in the chance that you choose to make it then available for the other sources. Just the same way that you can have multiple sources of data, the different pieces of data that are coming in. Maybe you have three or four different brands or you have multiple departments that are contributing to it and they all have their own system.
You can aggregate those together and put that data all to where you’re now managing it all in the same system. And you can configure the WordPress admin. You can go back and forth to where now you’re able to—let’s use CRM for example, a customer relationship management system—you’re now able to, instead of having to someone you’ve got to log in to this one and change this. And I have to log in to this system and change this. And I have to go into this other system– now what you can do is you can actually make the WordPress admin connect to all those data sources.
And you can actually not only receive the data but you can change data in those systems. So now it’s in one place for your markers to go to edit the content, see how it’s going on the CRM. It’s very flexible. And then on the other end, you have the ability to then output your content to multiple applications.
And what that means is that you have a data source available now for your desktop website and for your mobile site. And a lot of times it’s the same so now you have the ability to be able to say, you know what, for mobile, we’re going to actually do the content this way and for desktop, we’re going to do it this way for very specific reasons.
Oh, and for our native app, we’re going to actually use that same content management system and we’re going to ingest it into the app as well. And we’re going to format it a little bit differently because it’s going to require different pieces. And you can do that with WPGraphQL and some of those systems that allow you to change that data.
And if you have dynamic ads running somewhere, now you have basically endpoints or data that’s available for all of these different applications to pull in. Obviously with the authentication and all the different things that you’ll need you don’t want necessarily the data just going anywhere. But now you also have the ability to when someone says, hey, we really like your content or we want to promote your brand or whatever. Can we get a feed of your latest blog posts or something like that. You have now have multiple ways of providing that data.
The next thing is consistency. And I touched on this just a little bit. But it’s the ability to be able to use that one interface for your marketers to put in that data and to manipulate the data. And to make sure that everything content-wise is the way that it needs to be. So I remember asking a client once, who here has used WordPress before?
And everyone in the room, all the people in the room had used it at one point or another, whether it was for their own blog or for a website for the company. It’s just the known interface. It’s a very easy way to work. So that reduces training. You don’t have to say, OK, well we’re going to have to train you on this system and this system and this system to be able to get that content that you need to be able to be available for the site.
It also doesn’t require someone who’s specialized and trained in, again that CRM or that e-commerce system or whatever to be able to put the content in. And now it’s very straightforward. It’s very simple. You’re able to put that data in with very minimal training. It also helps with user management. So with their single sign-on that you can add to WordPress, there’s different ways to manage users.
But what it allows you to do then is that person– the employee who’s going to manage the content on the site just has one place to log into. You manage those users in that way and say your network user management system you tie that into WordPress, WordPress pulls that in. Now I can use my company credentials to log in to WordPress and now I have access to it. And I don’t have to be creating users in all these different places. I just give them access to this one system.
And then WordPress also, like many CMS, WordPress has a really good publishing workflow. So now you can do that by pulling the data from your systems. Have a specific person that goes in and decides what’s going to be done with that data. Either approve calendar events for example or pulling the data and write up a blog post and then get it to the next step for someone else to edit or approve it or and it goes through that approval process. And then you can either schedule or you can publish things automatically. And when that is published, the front-end now just sees it as more data. And it takes it and does what it needs to do with it.
And so again, with Headless you have the ability through all these things, the speed and reliability. I’ll go back to reliability a lot because I think it’s a really important thing for a lot of us. But what that allows you to do is now we’ve put the data in through here. We’re all comfortable. We know where it’s going to go. And like Hashim said earlier, you can have static and dynamic content on the same page.
So if I put this through either Gatsby or I have something else that I’m using, there could be a time when the database or WordPress or those pieces for some reason either it goes down or it’s not available or there’s a network problem. And my website is still up and running because I have that static content. And now we can just check for that and just give an error like, hey this content is not available right now. But your website is still up. The whole website didn’t go down. You just have certain sections that rely on that dynamic data that could just not be available while those things are gone.
So there are a lot of benefits to Headless and decoupling the front-end from the back-end. It allows you to do all those things. But there’s also some challenges. And I wouldn’t want to give just, hey it’s all bubblegum and roses or whatever. There are some things that you need to consider if you’re going to work with the Headless platform.
For example, whereas before you just had a WordPress site, now you’ve got a WordPress site plus some kind of front-end technology. Where are you going to host that? How are you going to manage the connection between the two? Who’s going to– we already have someone say who’s updating the plugins in WordPress. Who’s going to manage that? And so Gatsby updates those plugins to make sure that’s up to date.
Another challenge with Headless, and it’s a good challenge because now you’ve been given this flexibility of, hey we can now manage all of our content in one place. So what that means is now you really need to architect that data. It’s no longer just, hey, I’m going to put some pages together. And it’s just for the website so it doesn’t matter. I’m just going to put all this content in, make categories and tags and I’m good to go.
Now you have to really consider, hey this content that I’m putting into this section of the site, is it going to be reused in other places? Is this going to be pulled in by our native app or our multiple apps in different ways? Is it going to be used in some dynamic advertising that we’re running somewhere else? Is it going to pulled in through social? Where are all the uses of this content?
And you really need to plan for that ahead of time. So now you can structure that accordingly. And so now instead of just say, hey, look, we’ve got this content area for the web page. You may now have, here’s the content area for the page. And now here’s some additional tagging that happens for this one thing that’s pulling in the content here.
And there might be like, well here’s a shorter version that we use for say a blurb on another site or that this is what we use for our mobile app. So it just takes a little more thinking and planning. But it’s because you’re going to have all of these other possibilities and options for what you can do with that content.
And also, initially, the cost can be higher. Now you had a platform you were using. It’s open source, open source is really good. But you had a certain budget that you had for that maintenance. Well, now you’re adding another platform. You’re adding whatever it is that’s hosting or managing that front-end, the [INAUDIBLE] the Gatsby, or the next or the next. Where is all that and how do we maintain it?
So just again, initially those costs can be higher. But when you see the returns on well, now all the benefits we just talked about, which is– and now, hey everyone is putting the content in one place. Now we can use it in multiple places There’s all these benefits. Then you’re like, oh yeah, the return on that investment is great. Because now I don’t have to build the multiple platforms and do these things.
Another challenge, and this is a current challenge that’s being worked on. I’m confident that in the near future this will be either a thing of the past or will be handled very easily, is a content preview. Because currently in WordPress all you got to do is hit the Preview button and now you see the page. Well, that’s because it’s being rendered by WordPress in PHP. You see exactly what’s coming out. Well, now you’ve got a front-end framework somewhere that you’ve got to deal with. So you output the data now you’ve got to preview it somewhere else. I’ve got to preview it on React or preview in one of these other systems.
Now one really good thing about that is that WP Engine with their Atlas product, they’ve come up with a solution for that. And there are other solutions are coming out. There are plugins that are available. And so this is something that’s being addressed. But speaking of plugins, Hashim, WP Engine has a lot of experience with compatibility how they work on that work. And I think you can speak to compatible WordPress plugins and what the issue or the challenge might be with plugins and WordPress.
HASHIM WARREN: Definitely. Thank you, Jonathan. So one of the first things that the marketing team wants to know from the development team when they’re switching to Headless WordPress is, where are my plugins? Which plugins can I use? Which plugins can I not use? And often for your WordPress project, you’re relying on certain plug-ins in order to add functionality to your WordPress project. So I went through the top 100 plugins in the WordPress repo and found that actually, 33% of the plugins of the top 100 worked just as is with Headless WordPress. So the rule of thumb is, if your plugin does not touch the front-end of your website, then you can use it with Headless WordPress.
So certain plugins that are for user management or editorial workflow, you can use as-is with Headless WordPress. Now there’s another set of plugins, about another 20% of plugins are actually made obsolete by whatever front-end framework you’re using. So you do not need to use image optimization plugin for WordPress anymore if you’re using something like Gatsby or Next.js because those systems have awesome image optimization features that come with them. So there’s another set of plugins that you do not need to use like image optimization or caching with WordPress.
Now there are plugins that many people rely on that do touch the front-end that these frameworks do not replace by default. And the advice that I give there is, number one: if you’re using a system like Gatsby, Gatsby has thousands of plugins that can replace some of the plugins you might use for WordPress. One of my favorites is the Google Analytics plugin. The Google Analytics plugin for Gatsby has some features that are only available in the Advanced paid version of analytics plugins for WordPress.
So there’s a one-to-one plugin replacement. There’s also the wider React ecosystem and JavaScript ecosystem. You may be able to use a React library or JavaScript library to replace what a WordPress plugin was doing for your site when you were using traditional WordPress. And then there are plugins that work with both the editing system of WordPress and the front-end, like forms.
And there’s innovation happening there. But we’re still at the early stages. For example, you can use a form plugin like Gravity Forms plus a plugin like WPGraphQL, which gives you an alternative API for WordPress in order to create forms on the front end of your website to bring that data to the back-end into your Gravity Forms part of WordPress. This takes developer work and we’re still in the early stages of this.
But that’s one of the trade-offs that you have with plugins. So some plugins work as-is. Others are replaced by the front-end framework. Other plugins can be replaced by something like Gatsby plugins or React libraries or JavaScript libraries. And then there are other plugins where we’re at the early stages of having a really good solid replacement for it and they need development work.
So thank you so much for coming to our talk today. That is the nuts and bolts of Headless WordPress. And we are confident that you have the information on use cases, trade-offs, and advantages that you need in order to decide if Headless WordPress is right for your next project. Thank you so much, Jonathan. And thank you so much, Summit.
