DE{CODE}: When to Choose Headless for Clients

When a client has performance and security requirements, when should an agency choose traditional WordPress or headless WordPress for the job?

Find out more in this DE{CODE} session, featuring a panel of agency experts who weigh in on the benefits, constraints, opportunities, and tradeoffs of going headless.

Session Slides

https://www.slideshare.net/wpengine/when-to-choose-headless-for-clientspdf

Full Text Transcript

HASHIM WARREN: Hello, welcome to our panel, When to Choose Headless WordPress for Clients. So my name is Hashim Warren, and I am the Product Marketing Manager for Headless WordPress, our solution for Headless WordPress. And one of the first questions I received from people when they are adopting, or want to adopt Headless WordPress, is when should I use traditional WordPress, all in one WordPress, and when should I use Headless WordPress. 

So if I have a client who has performance and security requirements, like what should I think about in terms of adopting, or choosing Headless or traditional WordPress. And also, if I choose Headless WordPress, what should I expect, what am I getting myself into here. So today we have an excellent panel with experience with both traditional WordPress projects and also Headless WordPress projects that will be able to answer some of the big questions that I know many of you have. 

So today with me we have, Jonathan Jeter, who’s the Director of Technical Production at Click Here Labs. We also have Stephen Brooks, the Director of Technology at Springbox. We also have James Squires, the Chief Technology Officer at space 150. And we also have Tayo Onabule, the Managing Director of drewl. 

So I just want to bring in the panel right now, so we can get started with this conversation. So let’s kick off the conversation this way. Just tell me what made you personally, or your agency, interested in Headless WordPress in the first place. And Jonathan can you start us off? 

JONATHAN JETER: Sure thing. So we’ve been interested in working in the Headless space for a while. And the main reason we were interested in it was because we wanted to create larger projects that would integrate data from multiple sources. And the WordPress API wasn’t quite there yet. So we were working on different ways to present the front end layer, still use the content from WordPress. And so, that’s basically what we’ve been doing up for about five to seven years now, trying to figure out what was the best way to do it. 

And now it’s much easier than it was, obviously there’s a lot more– there’s a breadth of options as far as how you’re going to do it. And so, we’ve seen the space grow, and we’re really excited about where it’s going. It 

HASHIM WARREN: Awesome. And Stephen, do you have a similar story? Like what made you or your agency interested in Headless WordPress? 

STEPHEN BROOKS: Yeah, so we’ve been in the Headless space since about 2015, dealing traditionally with jam-based CMS platforms. Over the past few years, it’s been challenging dealing with some marketing teams working inside of a jam system, just because of the paradigm shift in content entry, as opposed to a post and page type approach. 

We’ve also tried, just like Jonathan, to leverage the WordPress API. That’s a little bit cumbersome, doesn’t really get you exactly what you need all the time. Whenever WP Engine mentioned Headless WordPress and talked about the underlying technologies, it was chef’s kiss with what we’ve traditionally done in the jam space. 

So now it’s a real easy conversation with our clients, because almost all marketers have experience working inside of WordPress, but developers get the added benefit of a Headless solution. So you get security risk mitigation, as well as just some of the top of the line interactions with a React-based presentation layer. So that’s been our real driver here recently. 

HASHIM WARREN: That’s awesome. Tayo, can you tell us your story, and just to follow up with that, can you tell us about convincing publishers to adopt Headless WordPress? 

TAYO ONABULE: Yeah. So I mean I think that, in our case, we’ve had a slightly more recent and a bit of a different entry into the Headless WordPress space. One of the core drivers for us is one of our clients Android Authority, who’s got a fairly wide reach. Sort of at the current moment kind of hinting around the sort of 20 million monthly visitors mark. 

And their needs are quite simple in a way. They need really great SEO, like top tier. And they’ve got a lot of very competent competitors around them. So yeah, really great SEO, really great performance, and really great reading experience for all of the articles that they publish. 

So Headless was really– it really came about for us as part of the conversation just as we were trying to do whatever we could to find a way to make their existing WordPress sites serve all of those needs. Really to the maximum, basically. And Headless, first it was a case of me just doing some research and being like, oh, well maybe we could, maybe give this a go. 

And we got further into it and further into it, and went through the process of convincing the team. But as we got further into the whole development of it, we started to realize that, yeah, it answered all of those main questions, like SEO performance and an experience, but it also gave us complete flexibility down the line as the years have gone on. 

We launched, I believe it was May of last year, so we’re coming up on the anniversary of that actually. , But yeah, since that launch we’ve managed to build a huge number of integrations into the site. All of which would have been considerably more difficult had we been on monolithic or all in one WordPress. That flexibility that it gives you is kind of one of the– it’s one of the things I was telling Android Authority we’d have, but I don’t think I quite realized the scale and the freedom that it provides, basically. 

HASHIM WARREN: That’s awesome. So, so far we heard about SEO performance, flexibility for developers, flexibility in terms of what type of project, also publishers being able to stick with a CMS that they know. Jimmy, does your experience match any of that, or do you have anything to add in terms of what made you or your agency attracted to Headless WordPress? 

JAMES SQUIRES: Yeah, I think a lot of those things we share in common, as well. The one thing I would probably add that maybe it will come across is a little bit selfish at first, but I’ll kind of get there and why it’s a good thing. But really for us, it was really developer satisfaction driven. 

We came mostly from a React and React-based framework background, kind of coming into WordPress. And our clients were demanding WordPress more and more, but our engineers are really just not that satisfied doing theme-based development for the most part. We still do that when there are still applications where that makes a lot of sense, but if you’re developers are satisfied with the product and what they’re building, I find that the output is oftentimes you get a stellar experience so that there is a real benefit for our clients, even though kind of our jump into it was really centered around something that our engineers wanted to do. 

HASHIM WARREN: That’s awesome. One of the things that many people who are watching this will have heard in the conferences, the difference between theme-based development for WordPress and component-based development. Can anyone speak to that? The benefits of adopting a component-based approach when building websites? 

TAYO ONABULE: Yeah, I’d really like to jump into that, actually. Just as, I’m sure that we’ve all got examples of this, but I think one of the most satisfying things that happens when you work with JavaScript libraries, like React’s, in our experience anyway, is yeah, as you say, access to this sort of component-based building style. 

And it means that for the one part, you get to break up an entire site design into these component parts that are far more flexible. So let’s say as an example, you might have a block on a page that has two different styles. One, where the image is on the left side and the text is on the right side, let’s say. Just as a sort of simple example. And React, that’s a case of you’ve got one block with a modifier, essentially, to just say, flip the text and image order around. 

When we’re talking monolithic, you’re essentially just, yes, maybe you start off on the same basis, but you very quickly have to just split the two apart, and you’ve got two separate things now. And changes, to some extent, have to be spread across two separate things. And it’s that kind of concept that means that as you get into larger and larger scale uses for Headless front ends, that flexibility and consistency that you can have running across a whole site, across all of the uses of a particular component, mean that development, as James said earlier, is so much more satisfying for developers. 

It’s a considerably nicer experience. You can really tell that React has been designed to sort of maximize the output of developers, and it’s and it’s that, once again as James says, all of that gets passed on to the client. Because I think that you can tell when something has been made with love and enjoyment in it, it kind of always results in a better output. 

STEPHEN BROOKS: Yeah, not just that, Tayo. But there’s also some other great benefits to it, too. I mean you really hit it on the head for the developer satisfaction piece, but if you take a look at traditional, template-based development, as opposed to a component-based development, unit testing, right. It’s really difficult to implement any kind of unit testing inside of a theme-based approach. With a component, boom, it’s right there for you. 

But I want to add a point to that, but it’s not necessarily for the developers, it’s more so for the business owners. Typically with a component-based approach, your level of effort decreases significantly against a given theme page, because your components, you’re going to be reusing those all over the place, right. And it doesn’t require an additional keyboarding time, typing, to go and add in that additional block wherever else it goes. You just build it once. Whenever you consume it, you hydrate your build. Boom, you’re done. It’s so beautiful, so fast. It’s wonderful. 

JONATHAN JETER: And we had to train our creative staff, right, because they’re so used to like, OK, this site is 5 templates, or this one is whatever. We’re like, no, no get away from that, right. And so we ended up with calling it. Just design the kitchen sink page, right, one page with everything on it, right, and we’ll build it from there. So yeah, it’s made development a lot easier, but we have had to train the staff across the board to make sure they understand what we’re doing and how we’re building it. 

JAMES SQUIRES: Yeah, even into operations. I mean, it’s changed how our proposals for clients are shaped when we’re doing this. We talk about quantities of blocks, and how we’re building those out, as opposed to templates. And that’s just such a paradigm shift, I think, for some, especially in the marketing side, to think about– you have endless pages of different block types. It’s really these core blocks and components, and what we’re building and scoping. 

TAYO ONABULE: And just one last bit on that. And I think that the mention of proposals is a really good point, because the Headless process massively changes kind of any estimates that you might have about what a feature is going to take or a new page layout is going to take. The fact is it does decrease very consistently over time. The wider your component library is, the less it takes to add an additional style or something, tweak a style across the whole site, add a new page layout. All of those things just become easier and easier. 

And I think that’s gratifying for everyone, to be honest. 

HASHIM WARREN: So, that’s really interesting. It’s not just Headless versus an all in one site, it’s template-based development versus component-based. And it looks like it touches on quoting, client work and client approval, testing, and QA work, development work, and design work. And it looks like there’s a shift. And it sounds like there’s a positive shift. Is there anything– 

So if you have a client come in, and they say, I have xyz requirements. What set of requirements would you hear that would make you say this is perfect for a Headless project? And Stephen, can you start us off? 

STEPHEN BROOKS: Yeah, sure. So the first thing that I personally look at is the security footprint that the organization needs, right. Is this an internal facing website or an external facing website? After that, then we start taking a look at, hey, is this CMS going to power multiple items, omni-channel delivery. If those first two boxes are checked off, boom, it’s an automatic Headless build. 

If only one of those gets checked off, then we need to talk a little bit deeper with our client to make sure that it’s in line with their operating footprint. And I want to say that 95% of the conversations I’ve had within the past eight months has all been cool. Everybody likes it. It’s a real paradigm shift from everything else. So, yeah. 

HASHIM WARREN: No, that’s awesome. And Jonathan, can you speak to that a little bit? What set of requirements would make you feel like, OK, this should be a Headless project? And also what trade-offs would you explain to a client about adopting Headless? 

JONATHAN JETER: Sure, so one of the main ones, kind of to the point earlier, is how many data sources are you using to aggregate the content for the site? And does the client want to use this as the central content repository, as opposed to this and the eight other sources they have for their mobile app or for their media, or for whatever else, right. 

So we have that conversation. If they’re like, oh yeah, we’re all in. And that’s an obvious choice. Also, so as an ad agency we have these creative types that are always designing these really crazy things, right. So if we know ahead of time like, oh, who the creative is, sometimes that prompts a conversation of, we know that this is going to be easier to develop as a React app than it is going to be to try to customize that theme in WordPress. 

But the trade offs. One is price. It’s more expensive, it’s maintenance, right. So now you’re not just maintaining WordPress, right, you’re maintaining two different stacks, two different applications. Which is why we went down that path, and we were using all AWS and Gatsby, and all this stuff to do it beforehand. And so, we were all in when Headless WordPress showed up. We were like, oh yeah, if we can do all this in one spot. 

Because for years, we’ve been talking to our WP Engine, where I was like, you guys need to do this because we’re doing it somewhere else, right. So let’s get it all together. So we were excited about that. Really, really happy with the process of building sites in Headless WordPress. But the trade off is basically the maintenance, which kind of goes away with Headless WordPress. The cost for the client, as far as hosting goes, as opposed to just a standard WordPress site. 

But sometimes, like I said before, that cost of developing the site goes down, the cost of maintaining the site goes down. So it’s a trade off. 

JAMES SQUIRES: I think one other really important thing that we consider when debating if it’s appropriate for a theme-based approach or Headless, is what does the handoff look like after a site build? Is the client expecting that they have internal resources that are taking this on? Or they looking at a long-term agency partner to kind of rely on? 

And that’s a really critical decision, because if you have a team that’s not familiar with say, React, Gatsby, or Next, whatever the Headless stack ends up being, then that could be a pretty big surprise if they’re not familiar with the Headless architecture, and how that’s going to be maintained. So that’s something really important, might seem obvious, but just to be explicit about, OK, once this thing launches, and we’re into maintenance mode, and hand-offs, what is the plan there? 

HASHIM WARREN: Awesome. 

TAYO ONABULE: I think the one other thing that is, I think Jonathan mentioned it maybe, is kind of the fact that what, and this is in large part what we focus on as an agency is, what’s enabled by Headless is primarily an experience thing. In terms of what your users interact with. And so oftentimes, and this is a changing conversation for every company. Some companies just want to get the job done. Some companies want to be flashy about it. 

And in all those cases where it’s important for the client to have a really breakthrough experience, or something really bleeding edge in terms of performance, or they need something that’s considerably more engaging in the competition, then all of those things are much, much easier to do on Headless. And so the conversation in my mind, or at least the angle that we tend to start from, is just– is this, you need to get it done or is this, you need to get it done and impress people a lot with it. 

Because obviously WordPress has been getting it done for a long time, and it’s a solid place to build a site, but basically, how much “flashy flashy” do you want? And if you want a lot, then Headless is a really great way to 

HASHIM WARREN: That’s awesome. Jimmy, I want to talk about staffing in terms of an agency. When you think about Headless projects, do you want WordPress developers who have adopted JavaScript and, let’s say, something like React? Or would you rather have more of a JavaScript developer who doesn’t even use WordPress? Like how do you think about staffing when it comes to Headless WordPress projects? 

JAMES SQUIRES: Yeah, it’s a good question. Our agency, we look for React as kind of the core baseline, so obviously JavaScript and experience in the React framework. That’s kind of our mandatory, at all levels, really. WordPress is– we treat that as a “nice to have”. That’s something, especially in the Headless space, that we can train up relatively quickly. 

I mean, generally speaking, with Headless you’re spending your time in WordPress developing custom post types and just laying out the component framework from a backend standpoint, but you’re not touching a lot of the legacy, kind of theme-based aspects in a normal, Headless architecture. So we found that we really don’t need that really core, WordPress experience. 

Of course, we need some players on the team that have that for certain aspects, but by and large, we’ve been really successful pulling in say, a React engineer, who’s never touch WordPress before. Showing them how to make changes to fields, and they’re off and running. They already understand GraphQL, which is a core competency you need to be familiar with getting into Headless architectures. 

But beyond that, WordPress knowledge can be rather shallow, and you can get someone in and be very productive on a project. That’s the beauty with React components is any React developer can jump into the middle of a project, look at my components folder, and we assign them one, and they’re off to the races as long as they have their data structure already set. 

HASHIM WARREN: That’s really interesting, too, in terms of being able to separate work. You work on this component, and you can work on it separately from the project. That’s a really great example. 

Jonathan, how do you think about it when it comes to Headless WordPress projects? Would you rather have a WordPress developer whose skills– who adds React to that, or any JavaScript framework to their belt? Or a JavaScript developer who up-scales on WordPress, how do you think about it? 

JONATHAN JETER: So like Jimmy said, we need both, but we’re going to look for more now of the React, the View, the front end JavaScript developers. Well, everyone calls themselves Full Stack now, but the JavaScript developers who are going to be able to jump in. And I’ve had developers come in and say, oh, I’m not going to work in WordPress, like that’s not something I want to do. And once we get into it, we’re doing a Headless project, oh, it’s not that bad. 

Because they’re not dealing with all the work for the PHP and all that. But at the same time, we’ve actually moved some of our DevOps people to handle the backend WordPress, so we don’t necessarily need a backend developer to do it, so it works out really well. Go ahead. 

JAMES SQUIRES: I was going to add into that, at least from our experience, the number of Engineers you can get into a Headless project and be productive tends to be a lot higher. For example, we just launched a SvelteKit-based Headless– I think it’s the first one on Headless WordPress– last week. I don’t recommend SvelteKit quite yet to clients, but we like it quite a bit. 

But we had an excess of eight engineers simultaneously all working on components, and with theme-based development, we tend to struggle more getting a lot of Engineers and being productive. Just because things are a little bit more monolithic, in terms of how many things can you touch at once. I’m sure it’s possible, and you can coordinate it, but we find it’s much easier on Headless architectures. 

HASHIM WARREN: It’s a beautiful sight, by the way. I saw the launch. It’s a beautiful site. 

JAMES SQUIRES: Thanks. 

JONATHAN JETER: The other thing I would say, too, is that I know we’re only talking about WordPress, right, but we deal with projects that aren’t WordPress, too, right. So those JavaScript developers can work across multiple backend systems, as opposed to if I hire a .net developer, they only work, for the most part, only work in .net, right. 

So we’ve got the people who are making sure the APIs work, aggregating the data, getting all that stuff together, right. And then we’ve got the front ends who can work on any one of those projects, as opposed to being specific to a specific language. 

TAYO ONABULE: And I think there’s kind of a few things here that we’re all kind of mentioning. I think, let’s say it how it is, like React, one– In our case, we tend to stick with React anyway. We do have a few View developers, but we tend to stick with React. But all of these front end frameworks, they have been designed specifically with kind of developer and process in mind. They are designed– I’d imagine that Mr. Facebook at some point was like, let’s make sure that this is as efficient for our team as possible. 

And so, that’s core to what React is, and it’s going to be much the same for View and Angular. In terms of the WordPress side of it, once again, call it how it is. Essentially, you could get by with just knowing how to navigate the WordPress backend and using ACF. And otherwise have no knowledge of WordPress and still manage to build a WordPress Headless site. 

And so the requirement on the WordPress side, unless you’re trying to do things that do start to get complicated, you could technically build a Headless WordPress site with basically knowledge of where the functions .php file is and nothing else. You can get by. And I think that the beauty of this is, as Jonathan said, once again, those JavaScript developers are going to be useful across all of your projects. And I think it’s pretty safe to say that for the foreseeable future the web is going to be JavaScript-focused, and so that’s very useful talent. 

How far down the line that that last switch, it’s likely to be a while. So it’s honestly, it’s not really a big commitment in a way. It’s one that makes sense that I’d imagine most cases. 

HASHIM WARREN: I just want to back up your story because in a previous life, I had to train two React developers on our new WordPress site. And it was a Headless WordPress site. And it was just an afternoon. I showed them ACF, they were really excited, they made the data models, and they were off. And even one of the developers actually connected the classic editor, and made it so that I can control some components on the front end. 

This is before Gutenberg, so we were using repeater fields and ACF, and controlling some of the components on the front end. It was amazing. But the two React developers immediately got it. It just took them afternoon, and they were off to the races. 

TAYO ONABULE: That’s the thing is that with these sort of front end developers, they’re quite used to plugging into back ends for their data, and having a data structure to stick to. That is a common component of their workflow, so WordPress doesn’t make much odds. 

JONATHAN JETER: With the prevalence of– sorry, the prevalence of SaaS, applications being available everywhere now, things that you used to do in WordPress, be it eCommerce, be it integration with the CRM, all that kind of stuff. Now that’s not done in– it doesn’t have to be done on WordPress anymore. You don’t have to install a Marketo plug-in or a Salesforce plugin, or something to try to connect these, right. 

Now you’re doing those connections yourself, which allows for a better experience, customized experience. That allows for speed, security, all of those things, as opposed to trying to get a PHP developer in there to figure out how to get these things working inside the WordPress. 

HASHIM WARREN: Awesome. Stephen, I would love to hear from you about the ecosystem, the JavaScript ecosystem. I know that WordPress developers are used to really awesome, robust ecosystem, in terms of plugins, also community. Can you talk about how it compares to maybe the ecosystem in the JavaScript world? Both in terms of technology and even community. 

STEPHEN BROOKS: Yeah, so with WordPress, it’s got the largest marketplace for plug-ins for traditional monolith build. But back to Jonathan’s point just a second ago, with leveraging NPM for all of your functionality that you need from the front end, it’s equivalent, if not greater, than the WordPress marketplace. Because not only do you have all those NPM packages that are available. There’s also numerous STKs that you can also pull in, as well, to really, rapidly create all of your data integration that you need. 

So I would almost say that it’s greater by about 20%. Just throwing an arbitrary number out there, but it is a lot faster for folks to move. And a lot of the NPM stuff is on point. You also really don’t have to worry about the WP core version and plug-in version mismatches that can happen. Once you pin your versions in your package manifest, I mean you’re done. You don’t really have to worry about updating them anymore if you don’t want to or anything like that. 

So again, it goes back to what everybody is saying, speed and flexibility are just paramount whenever using Headless solution as opposed to the traditional-headed WordPress approach. 

JAMES SQUIRES: Not to throw any shade at the businesses that are making a lot of money off their WordPress plugins, but that’s another area as you just tend in a headless architecture to have less licensing costs, where in a typical theme-based, there’s some really great plugins out there that we always find ourselves baking into proposals to purchase and utilize. For the most part, everything in NPM is free, open-source software. 

There’s certainly some that may have a service model associated with them. But generally speaking, you can find the most popular solution, and it’s open source license. So it’s easy to move quickly that way and not slow it down with client approvals on licensing costs and things like that. 

HASHIM WARREN: Jimmy, I have another example that’s like that. So I was building a Gatsby website, and I was adding Google Analytics to it. Gatsby has a plugin ecosystem, all the plug-ins are open source. Their packages are on NPM, they’re easy to just install. So I’m adding Google Analytics, and it had all these options that, with the most popular Google Analytics plugin for WordPress, some of those options go into the premium version. So I was very excited as someone who is happy to pay for this WordPress plug-in to have the same functionality with this package that was also a Gatsby plugin. So really excited about how those ecosystems kind of match. 

TAYO ONABULE: I think it was just very quickly on the whole subject of NPM, as well. I think that just the tiniest thing, and it’s probably inconsequential, but me for me. I much prefer the fact that when you’re developing something in React, you want something, you download it through CLI. And you don’t have to go into WordPress, or any kind of gooey, it’s just there in your space. You don’t have to leave the studio, and it’s all there. And it’s a much less clunky process than doing some research, finding a plug-in, getting it installed, et cetera. I’ve never been a fan of that. 

HASHIM WARREN: Awesome. Jonathan, I want to ask you, we talked about requirements that would make you say this is perfect for Headless WordPress. What kind of project would make you feel that it’s, OK, this should be a traditional, WordPress project. 

JONATHAN JETER: So we do a lot of those too, right. Sometimes it’s budget. They come in and say, we have this much. We’re like, there’s no choice, right. This is what we’re doing, right. And because, then we have things that we use. That process and that system is already in place. Like Jimmy was saying like, we have plug-ins that we bake into every one of those proposals because we know it’s very straightforward. 

So a typical, small brand site. Typical– Like Tayo was saying earlier, it doesn’t have to be flashy, right. There’s nothing outrageously creative about this site, right. And they just went, hey, we’ve had them before, like we know we need a website, so make us one. Right. And if that’s the case, then, yeah, absolutely, based on your budget and the requirements, a standard WordPress site will do. 

We even gotten to the point where using Genesis, and Genesis Pro, and Smart Plugin Manager, and all those kinds of things, we have sites that we build that developers don’t even touch. It just goes through the process, and the creative process, the studio edits the files, and they basically put the content in. We have some editors that proof it, and put the content in, and the site is done without a developer ever touching it. 

And that’s kind of the way you have to do it, right, to make money on those projects, because with those types of budgets, you can’t get 20 hours of dev on the back end of one of those sites. So that’s typically how we decide, unless it’s a huge site, but they’re like no, no, no, we don’t want anything fancy. We just want this to be a regular site. We’ve done that, just a lot of content, blogs, those kinds of things. 

SEO-wise, WordPress is still great. If that’s what they’re looking for, it’s like we don’t care how it looks. We just want the function. We want it to be fast. We want to have content and rank well. A traditional WordPress site works well. 

HASHIM WARREN: Awesome. Stephen, can speak to that? When would you say, OK, this needs to be a traditional site or traditional WordPress site? 

STEPHEN BROOKS: It really follows along with Jonathan. Cost is going to be the first one, and then the second one after that is going to be time to market. If somebody needs something out pretty quick, even with the accelerator as John’s talking about in terms of Genesis blocks, and just having a block catalog that you can do 0 dev from, it’s still really incumbent on getting that stuff out as quickly as possible for those clients. Also to spin outs is a pretty big one for us. To where, hey, we need some sort of marketing presence for our investors. This is going live in two weeks. What could you do for me. 

HASHIM WARREN: Awesome Thank you so much to our panel for your participation today. If you are interested in Headless WordPress, you can get a free Headless WordPress Sandbox account at WPEngine.com/Atlas. And compare for yourself. You can use an all-in-one WordPress site, and compare it right against a Headless WordPress site, to compare everything that we talked about today. Thank you so much for joining us.