fidzu : WordPress

Karim:
Well, hello, welcome to Scaling Enterprise WordPress and Open Source Software. This is the Buyer's View. As you might remember from our last episode, we are going to be doing two podcasts a month: one that is closer to the buyer's view and helps the enterprise see how to engage and work with WordPress and open source software, and the other side will be more of a community-focused WordPress project podcast around how the project and WordPress can focus on the enterprise in certain areas. My name is Karim from the Scale Consortium. I'm also CEO of Crowd Favorite. With me is Tom Willmot. Tom?

Tom:
Hello. Great to be here. Excited to be kicking this off, what I hope becomes a regular thing for us. I'm also a founding member of the Scale Consortium and the CEO and co-founder of Human Made. Yeah, excited to get into this.

Karim:
Me too. Me too. So let's jump right in. We at the Scale Consortium figured that it was time to have a group that unified and had a singular voice around helping the enterprise navigate open source software and WordPress specifically and its options. Tom, how do you see how we do that?

Tom:
Yeah, I mean, good to probably just step back and talk about that a little bit. The challenge we have in the enterprise WordPress space, and I think the challenge buyers face is compared to the single vendor options that are out there where they can talk to the buyer with a unified message and simplified positioning. The strength of the WordPress ecosystem is it's really broad and deep and that brings lots of benefits. There's lots of choice and flexibility, but it does mean that as a buyer you can look at all of that and it can be a bit overwhelming. It can be a bit confusing. Where do you go? At Scale Consortium, we come together and we work together across vendors within the space to give that clear view.

Karim:
Well, one of the things I hear most is if an enterprise wants to approach WordPress, where do they go? Do they go to a host?

Tom:
Right? Who's the vendor? Maybe they turn up to a host, maybe they find an agency. But yeah, it's not so simple.

Karim:
And then on the community side, folks argue that if you go to one vendor or one host, you're going to get their flavor of WordPress. One of the things that I'm hoping that we're going to dive into is that really you can customize WordPress to do almost anything, but the point here is that there are no flavors of WordPress. There are flavors of Linux that are forks. This is all the same WordPress, right? It's just the special sauce that any one team might bring to it or the special sauce that any one host or any other one product might bring to it. But WordPress is not the same type of complex ecosystem that operating systems were for the last 40 years. So let's dive right into the introduction to why WordPress. Its current market share is 43% of the internet. So it has very strong strengths, right?

Tom:
Yes. Even amongst the kind of enterprise tier, it's pretty dominant depending on how you're talking about measuring it. It's certainly true that the vast majority of enterprises, the vast majority of businesses, have got WordPress somewhere, even if they're not using it as their primary CMS, they're using WordPress somewhere in their organization. And actually there's plenty that are using it as their primary, but I think that's secondary. The CMS kind of narrative is the WordPress history is quite relevant, I suppose, to how WordPress started to break into business and how that's evolved over time.

Karim:
But if it's a generalist platform and it's being used as that secondary system, is it just vanilla is the problem we run into all the time? We have a hard time explaining to folks that what ends up happening is this isn't just a generalist system that can't help you with your specific need because the WordPress project is so general, you can actually bring it and customize it for your specific needs without having to use the technical term fork, without having to fork the code, without having to move away from it. You can adapt it to your needs. It's so adaptable, which is what I think some of the successes out there are, right?

Tom:
Sure, yeah, a hundred percent. That means that the barrier to entry actually is quite low. It's quite easy to get going with WordPress and then you can customize it and it'll flex with you and scale with you. There's WordPress out of the box. Of course, if you're an enterprise user of WordPress, you do need some stuff on top of that, right? You have specific common needs across enterprise or workflows or governance or digital asset management or whatnot. And so there's this layer of stuff that exists in the ecosystem that does make WordPress meet the needs of enterprise. And then of course you get the vertical-specific needs too, whether that's higher education, financial institutions, or publishing.

Karim:
But I want to jump into this question of the first choice versus second choice, because I remember the way I approached WordPress when we first came into the space was automatically assuming it was going to be a first choice. One of our larger projects that we started now 14 years ago, it was the first choice. So I came to the WordPress larger enterprise community thinking, oh, let's do that. And then I was shocked to find out that more than one of the managed hosts, their marketing was all targeted towards WordPress as a secondary enterprise. They had one of those monolithic enterprise systems as their .com, and then the host was saying, we're never going to get that .com, so we're actually going to market as put your .com out there with this monolithic system and then after that, or proprietary system. And then after that, all these smaller sites that you don't want to invest so much time in those ones can actually be on WordPress. And that shocked me. I mean, how did you find that back then?

Tom:
Yeah, I mean, I think to some degree that reflects how WordPress usually comes to be used by an organization, which is usually bottom up. It's usually people in the organization who are on the front lines using these tools and they want to use WordPress. Maybe they're familiar with it, maybe they've used it somewhere else, and then they'll fight internally to get WordPress. And so maybe it comes into one specific team or one department rather than those large rollouts, which are usually top down run by IT or something. I think what we've seen over the last decade, it started out like that actually.

Now there are plenty of organizations where that the WordPress gets its foot in the door and then it works its way through the organization and unseats the primary CMS. And so I think that's great. WordPress is definitely validated as a great primary option. And if anything, I think that's the biggest gap now to close because we are, how do we make the jump from people inside organizations fighting the fight to get WordPress? How do we make that jump to the top down the IT rollouts or digital strategy rollouts?

Karim:
And that's interesting because I've always tried to address it specifically as how do we head to head compare ourselves to these monolithic proprietary systems and how do we show that we can feature for feature or more importantly business need by business need actually come up to that level? Because people still think of WordPress as this, oh, it's just a CMS. Oh, it's just to push pages and articles not necessarily can help me integrate data from many different sources or so forth or so on. So it's interesting to see that there's part of the market that is still thinking of it this way as second choice.

And then there's the other part of the market that's saying, how do we actually show that we can do this? And more and more case studies are coming up that way. You've worked on a giant major European bank as WordPress being the first open source. We've worked on one of the largest media companies with WordPress being the first choice, the .com, so to speak, of all their major sites. So it works that way. But how do we get that message out? And I guess that falls down to the enterprise needs. What do you think about that? What are the enterprise needs?

Tom:
I think that's the opportunity here, right? Because actually the enterprise needs, I think particularly these days, the trends that we're seeing in the industry actually I think pair very well with WordPress around total cost of ownership, the need for a lot of flexibility that just increases and increases. We've seen this kind of trend of all-in-one DXP, which feels like it's peaked and now, and actually we want to own more of our stack and be able to swap pieces out, and we need it to integrate with the long tail of things that we are using across the enterprise. And so actually that really starts to, WordPress actually been a particularly good fit for a lot of those needs. And again, it's like we've got to form clear messaging around that so that enterprises are aware and they're being told that they can discover that for themselves. It doesn't need to come up through this backdoor, secondary route.

Karim:
So the general WordPress project as an open source project needs to stay communicating that we can be all things to all people. And because most of the internet are smaller sites in the enterprise space, we're a very small subset of clients by volume. What ends up happening is it's a very small voice. So then it becomes up to the Scale Consortium podcasts like this one, the agencies, and products that want to work with the enterprise to try and communicate that. What we need to do is try to bring together some

sort of unified messaging because those needs aren't being met. If a particular host or product or an agency is saying, oh, well let me show you how I do it in this one exact example, they get pigeonholed right away. Most people are very surprised to find out that WordPress can be used as the central hub of an ERP system. There are large medium enterprises, not necessarily the Fortune 100, but right below that, that are using WordPress to manage content on what could be classified as an ERP system, not just a CMS or a marketing solution. You'd say, why would you do that? Why wouldn't you use one of those other applications? And I feel that the bottom line of the need of the enterprise is not what is the name of the package, what is the technology? What programming language am I going to use? What's going to solve the business need? And in this particular case, going back to quoting Matt Mullenweg from WordCamp San Francisco, 2010 or 2012, it takes five minutes to learn how to publish a page. Bottom line.

Tom:
That time to publish and the flexibility of that, again, it is something actually we can often take for granted. I think within the community, we often have this experience when we are demoing to clients and actually it's the stuff that we forget is actually quite groundbreaking already. The fact that you can log in and edit a page and publish it, have it live within five, 10 minutes, and those things are not actually true across the rest of the competitors.

Karim:
Exactly, exactly.

Tom:
Yeah. This kind of central hub piece, I wonder if that's something we certainly see a lot. I imagine it's similar in the work you are doing where actually customers are building DXPs, they do end up with a DXP, but they've put it together themselves with WordPress at the center and all of these other pieces. And so it's true that the world has the needs of enterprise that have evolved beyond just CMS. Absolutely. There's a bunch of other pieces now, but WordPress doesn't need to be all those things. What WordPress needs to do is integrate really well with them.

Karim:
That's the key. That's the key, right? Because both of us have done presentations on how you've built a DXP centered on WordPress and it's an amazing product, and we've done this composable direction, which we're going to talk about a little bit later, but this composable direction. But the key is integrating. The key is for all these folks, all the folks who might be listening who have been around the block a few times, old school, 1990s, system integration of middleware. If you think of it in those terms, WordPress is a great connector.

Tom:
Yeah. That's usually where we find clients end up in actually. They've got WordPress as that central hub.

Karim:
So how do you address when you end up going to an enterprise client and you have the technical team of the enterprise, the client goes, but it's WordPress, it's a blog. How do you address that?

Tom:
Yeah, I think that is something that's improved quite a lot, certainly over the last five years. I think the number one thing is just that the WordPress, there are so many examples now of WordPress being used really for the very biggest stuff on the internet across almost all verticals. And so you can usually rely on just a lot of direct evidence. Actually, that's not the case. So usually it's a mix of lots of case studies, lots of references, and lots of demos that you can show and demonstrate. And perhaps five or 10 years ago, you perhaps were on the cutting edge if you were trying to use work with the scale. Actually that's just completely normal now. And the concern is just out of date. And so you can just show all of the evidence. And actually there are many more examples. There are many more high scale WordPress sites than most of these other platforms actually.

Karim:
No, exactly. Exactly. So I think we've reached the part where it's time for a small break and when we come back, Tom, I think you're going to head us off with talking about the evolution of content management and how we got here. See everybody in a minute. Thank you.

Tom:
Okay, welcome back. So Karim, we touched a little bit in that previous section on the evolution of the enterprise CMS and the evolution of content management and how WordPress fits into them. And so I think that'd be good to just dive in on a bit and expand on. One of the things I often reflect on is that the narratives out in the industry, the buzzwords, the framing, the structure of how we think about enterprise CMS has actually historically mostly been set by the competitors to WordPress. So I think this is an opportunity, right, for WordPress to start actually putting its vision for enterprise CMS forward and more that maybe you can do as a bit of an explainer on that.

Karim:
Well, yeah, because if you look at the history, content management systems started out what we used to call OnPrem, right, on premises. And then with the evolution of SaaS and the evolution of not just software as a service, but just thinking of things being not within your own system but putting together lots of other systems. You ended up with just this expectation that it was out there in somebody else's system. But there's a lot of Fortune customers and there's a lot of mid-market enterprise companies that say, we need our data internally.

And one thing that's vastly overlooked is that if you're using open source and specifically WordPress as this hub that we were talking about, that lets you literally own your data and actually keep solid control over what's being shared outside. It's not about points of failure necessarily, although it can be. It's not about having things across 12 or 15 different SaaS's out there and different companies having access to your data. You solve all of those things if you are centralizing saying that your source of truth is your content management system. And that is an evolutionary piece that's been lost in the last 10 years of the MarTech stack explosion of SaaS products, I feel.

Tom:
Yeah, I couldn't agree more. A common occurrence for us, which I'm sure you'll run into too, it will be working with a new client who are wanting to move to WordPress and a driver of that move is that they have bought into a legacy CMS or a CMS that is now legacy in which the company behind it actually are no longer around or they're no longer supporting it. Maybe they've built a new product and the cost to move to that new product is the same as the cost to move to WordPress. Actually, that's a pretty dominant frame for the industry. A lot of enterprises make the decisions over a five to 10-year cycle because actually that's the cycle. That's the lifetime of a lot of these platforms that in five to 10 years they're going to be legacy and you're going to want to move to something new. A lot of the education we are doing as part of a WordPress installation is that's actually not true in open source. We've got a much longer time horizon ahead and you're not going to need to move off in five years because WordPress is still going to be around and innovating.

Karim:
I'm actually going to challenge that, Tom. I'm going to say I don't see clients that are spending in a total of five years on a platform before saying they want to move.

Tom:
Like you're seeing it come down.

Karim:
I'm seeing it come down because of their marketing so hard against each other. Sure. If you look at the market leaders in the DXP area, they're marketing so hard against each other that they're innovative and the others aren't.

Tom:
It's true.

Karim:
They're marketing so hard against each other about how they're better that CMOs and CIOs are saying, well, maybe it's worth the cost of migration and they're bouncing. Or if it is a longer-term thing, it's because they created a bespoke dead end of their own that the cost of owning it is so high that they're like, okay, now what do we do? And coming back to your point, doing something with a platform like WordPress that doesn't have major migrations,

Tom:
No, sure.

Karim:
It's not free. You actually need to maintain it, right? Which is another misconception.

Tom:
I mean it's actually a big difference even between WordPress and Drupal, which are the two open source platforms, but Drupal actually does have this cadence of major backwards compatibility breaking releases, which we see from the WordPress side whereas a user of Drupal seven, you've got to make the decision, okay, I'm going to spend a bunch of money moving to Drupal 10, or actually maybe I'll move to something else.

Karim:
And another nod to Matt and the way he's thought of the WordPress project, Matt Mullenweg, in the sense that he has been really steadfast about not breaking backwards compatibility sometimes even to the point where you and I are frustrated in thinking how can we move the platform forward? But it's really helped us in that long-term future. So as I've seen the SaaS companies market harder and clients have more and more choices and flip even more, the more I've seen the total cost of ownership come down for staying on something like WordPress, the more I've seen the cost of migration be not just money, but also the time aspect and the retraining of your employee base. So it's been very hard to understand exactly how to relate this back to customers because they've only seen the last 10 years of marketing that again, these marketing budgets on these major platforms are huge and all these individual companies that are trying to help enterprises with WordPress are going, we can't match that marketing of that major platform. That brings me to the one word that I

think has started to take over from just digital experience or digital transformation. There's a lot around the word composable these days, and I know a lot of people assume that means, oh, I'm just going to compose three or four SaaS platforms, I'm going to compose my own system. We've come to realize that when they do that, they end up with a mess of the poor marketing staff that has 18 tabs open in a browser and to get one workflow done for marketing tasks, they've got quite literally six to seven different interfaces with six to seven different products that are trying to swap information back into each other, sometimes in real-time, sometimes not. Is there a way that this general tool of WordPress helps? We feel it does. How does your team deal with that with the vertical of the enterprise? How does your team try to address how can we not have customers do this?

Tom:
Yeah, I think we went through this phase with the kind of all-in-ones, whereas kind of this bundling phase and the dream there that was being sold was if everything's all in one place, you're not going to have to worry about it. You'll get everything you ever need here. And usually that doesn't work out right, because actually they're too limiting and the stuff you need to do, they can't innovate fast enough to keep up with the pace of change in the ecosystem. As then we've kind of swung the other way, okay, now it's completely composable all of your tools just talk to each other. You can swap any of them out at any time. But again, that brings a bunch of challenges, right? Actually it ends up with a pretty brittle system. How do you do governance across 20, 30 different SaaS tools that you lose track of what you are being billed for? The person who set that SaaS tool up is left now and you can no longer log in. A bunch of challenges there.

I feel like you go through those cycles and you come back to meet a little bit in the middle where actually this hybrid CMS that sits at the center that absolutely can plug in to the stuff you want to use externally but is still providing a significant portion of your functionality and acts as that hub. The compromise between composability and all-in-one, I think the fully composable platforms inevitably will need to trend in that direction where actually there ends up being some hub or the management platform that ends up needing to be developed to just manage all those different SaaS tools becomes that hub over time probably. And same thing, we're seeing the all-in-one DXPs trying to become as composable as possible as quickly as possible because realizing the limitations of all-in-one, and again, I think it's that trend just plays really nicely for WordPress.

Karim:
But can an all-in-one solution be the best tool for every job?

Tom:
No, I think that's the fundamental failure. Ultimately, they're attractive to begin with and I think we've just seen that play out in the market where the pitch is very attractive and very compelling, and then the reality doesn't deliver on that for a variety of reasons. And I think we just, we've seen that play out in the market. We're past the peak of that. There are now plenty of organizations who've bought into that and either they've been paying for a bunch of tools they haven't really got the value from, or they need to do stuff more quickly than the platform that they're bought into is innovating and they're starting to look around and want to use other stuff. And the bunch of those end up moving to something like WordPress. That's part of the inflow we see into the WordPress market.

Karim:
Absolutely. Exactly. Well, so I feel like episode zero, our first episode with Brad gave us the concept of what the entire show's about, and today we've laid out what the differences are between the two different shows and introduced the concepts of what we're going to talk about. And with that, we agree completely as you were saying in talking to our friend Remkus from this community. I'm sure that the upcoming episodes where we're going to talk about procurement, we're going to have to talk about how to approach customers, we're going to talk about how to service those customers. We're going to talk about what the solutions are for the enterprise.

It's going to be a little bit more of showing how we have a little bit of a different take on these things. But just from this conversation, I can see conversations around, like I said, speaking with a procurement specialist, speaking quite literally with somebody from some of these other monolithic platforms about what they feel they do best and having these conversations, talking about how to integrate well with SaaS and what that looks like, customized workflows. These are some of the topics that I feel like are coming down the pipeline in our next episodes that are really going to start asking and answering questions on how can we do better as a WordPress community in communicating this and give some information out to enterprise buyers on how they can approach any of the vendors who work with WordPress.

Tom:
It's a nerdy thing to say, but I think it's a pretty exciting time in the enterprise CMS space, right? There is actually a lot happening. There are some trends peaking. There are some new trends coming. There's a lot of players in the space scrambling to figure out what that is. The analysts have all got their takes. Are we agile CMS? Are we composable? Is it composable content? There's so many of these things. As a buyer, it's pretty confusing. And a lot of these platforms at the moment you're kind of like, okay, I'm going math, I'm all in on this, or I'm going with an all-in-one. And you're kind of all in on that. So they're pretty consequential decisions as well, I think, as a buyer. And so I think there's a ton of scope for us to get into all of that debate, all of that. What's the WordPress answer to a lot of these things? Again, that's not really discussed much.

Karim:
I'd like to invite literally an analyst from one of the companies to come on and ask them why, besides the fact that it's pay for play, why can't we get any attention?

Tom:
Yeah, I think that would be great.

Karim:
As an open source.

Tom:
Yeah, I would love to do an episode on analysts and their place. I think there's tons to say there. Yeah, well exciting stuff. Okay, good first episode and more to come.

Karim:
Absolutely. So Tom, tell us about Scaling Enterprise WordPress and Open Source.

Tom:
We are the buyer's view, but we'll be in the same feed as the sister cast that we're going to be doing with Brad Williams, which is, as Karim said, the Enterprise WordPress community-focused version. And so we'll be in the same feed. So you can listen to both of those. I think both are going to be interesting to everyone inside enterprise WordPress. If you're a buyer, maybe you're more interested in this buyer's view one, add us to your favorite podcast subscription. Come along on this journey. And I think most of all, we are just starting out and so we really want to hear from people. What are you seeing out in the space? What are the questions people have got? What would they hope to get from a show like this? I think we'll lead a lot on that as well as we go. Do people have questions that we can answer? Are there topics people would like us to cover? Are there people that it would be great to get on? Let us know and we'll endeavor to do so.

Karim:
So go over to Do the Woo and check on our feeds and whichever podcast platform you're using, and also feel free to go to scalecms.org and get in touch with us and ask us to do a particular topic or dive into something. We'd be happy to talk to you. We are really looking forward to bringing back some informative and useful information to help enterprises really understand how to better engage with WordPress and open source.

Tom:
Alright, a good place to finish. Thanks very much, Karim.

Karim:
Thank you Tom, it's been awesome. Talk to you soon.

BobWP:
So here's the deal. The other day I was thinking about the three Cs: community, commenting, and coding. Okay, I lied. I wasn't thinking about coding at all. Coding, I don't think about it much. It's never in my face. I know it's there. I know people do great stuff with it. I hear people talk about it. So the only reason I put that in there is it just sounded better. I really wanted to talk about community, commenting, and blogging, but it just didn't sound as good. But that is what has been on my mind lately. Well, actually I lied again because that wasn't on my mind lately. It's always on my mind. That's all I think about is this stuff. So I got to quit lying about things and just get to the point here that it's really something I am thinking about.

Like I said, a lot, those three things. And as a result, I got into some conversations. I had a conversation actually with Bryce from Metorik. I don't know if any of you know him, but he was on the podcast lately. We were talking about community, the builder community where they can connect and talk. We threw a few ideas around. Then it moved into another whole thing because of some stuff going on. And of course, I had to have a conversation with Ronald, one of our hosts here, Ronald Gijsel, and we always have great conversations and we started talking about this stuff and we thought, why don't we just take it live and talk about it? So, I twisted Ronald's arm and he's popping back in to actually, he called it, what did you call this? Do you remember what you called this?

Ronald:
Different ideas. I think my latest is almost like unpacking blogging with Bob or was there another reference to that? It'll come to me. But yeah, I'm really excited actually just to discuss it live and ask you a few questions, what the goals are and bring it back to me and be very lengthy. And maybe at the end of this call, or this recording, we will come up with a final solution, a way you'll have to give it direction and go for it.

BobWP:
Yeah. Yeah. I was actually looking back, you called it a BlogStorm.

Ronald:
BlogStorm. Yeah. We were doing a brainstorm about everything around blogging. It's a BlogStorm. Yeah.

BobWP:
So we're just going to go for it here. And I hope Ronald said we'll put some ideas together, thoughts, just what's on our mind. I'll set the stage. There was a point where I took the blog off because some part of my brain said, oh, I wanted to focus on audio and have everybody focus on the audio when they get there. And of course, I started to look at the site and thought it felt, I think I wrote this somewhere, it felt naked. It was like, where's a blog? This is conversational. This is community. This is what it's all about. So in turn, we're working on bringing back the blog to Do the Woo, and that's where this came because I had another idea. I had an idea about a newsletter and all this stuff kind of meshed together and Ronald deals with my crazy thinking and my train of thoughts and stuff. I brought up this newsletter idea and only because I keep hacking away at that thing. I've done that for so many years and never really progressed. What are your thoughts? I mean, you gave me some feedback. We won't go into a lot of the details there, but just give me a thought.

Ronald:
Yeah. The thought that came to mind is newsletters are great, but newsletters or anything, email notification of something that's bigger. And so if you write a newsletter with long form, I dunno what is long form these days, but something that gives you everything in the newsletter, you don't need to do anything other than read the newsletter. That's great if you're in the moment and in the moment of reading a particular topic, but also on a device that makes it pleasant to read it. And once it's buried in your inbox, it's kind of gone, difficult to get back and that moment when you send out hundreds of thousands of newsletters, what you see in the status within the first couple of minutes, you see a really high spike of the opening rate and then it sort of diminishes pretty quickly after that, even within the same 24 hours. Even if you have an intelligent system that sends the emails at the best time or thinks it's the best time with the highest opening rate, I do always wonder what the engagement rate is. So in other words, you send a newsletter, you think I have a huge post, but how engaged are people who read your newsletter? If it's a call to action to click through to something, that's really easy, but maybe it's like, oh, it's an email from Bob. Okay, great. It's quite long. I'm doing something else. I'm switching between 15 different tabs and different windows and other things are happening at the same time. Are you really absorbing the content and engaging it? It's really difficult to do that. And so it's great to have a notification, but maybe that notification should be, hey, there's much more content in the blog and here's your weekly reminder to explore and here are the things that have been happening, have been fed by our presenters and guests. And guess what? If you're interested in coding, here's a category, everything around coding, or here's a category, everything around community and thought. And that got me thinking like, hey, how much content? We're coming up to 500 podcasts now?

BobWP:
Yeah, yeah. This will probably be, I'm not exactly sure the number, but we're at around 500 in the 530 somethings.

Ronald:
Oh, so we passed that. Yeah. Amazing. So apart from me, all the other super interesting guests, some of them I've interviewed as well in the past, they all have really interesting things to say that it would be great to have quotes, snippets, or even get them to write something on your blog. Anyway, that got me really quite excited about the opportunity and bringing back blogging, which is the core of WordPress.

BobWP:
Yeah. And that's what I mean. Like I said, I have Ronald there to smack me alongside the head. Every once in a while I get these little ideas and I'm doing them for maybe one specific reason or I'm thinking, how can I make this part better? And then I realize I have things inside there that are already bubbling on the site. One of the things you brought up, I'm going to flip back here, is you had brought up what Matt Mullenweg said and on his, I think he said it on his blog post about WordPress turning 21. And then I said it again in his talk at WordCamp Europe just a couple of months ago, and let's say I pulled up the blog post and he gave 11 things that he's just been thinking about. He says people should be thinking about one of them was blogging, commenting, and ping backs need to be fun. Static websites are fine, but dynamic ones are better. Almost every site would be improved by having a blog or a great blog. So when I looked at that, it was like I thought, man, back what, 2010 or so when I was blogging, that was kind of the heyday of blogging and everybody was commenting and it keeps nagging at me, this thing he said, and it's not just what he said then, it was reaffirmation is what it was to me, what's been on my mind when we started the new site, when we did the redesign to do the Woo. When we launched that in March and then officially at WordCamp Europe, we decided to open up comments again. And of course, that's always a challenge. And I think there's this thing inside of me that just, I won't give up on it. Comments are there, there's got to be something happening. So I've been publishing ping backs and stuff and some different things and it is true. It's like there's so many ideas and thoughts going through my head.

Ronald:
Yeah, I think you touched on something really important and that referencing to Matt, but it just occurred to me that WordPress is 21 years old and WordPress, not everybody started 21 years ago, but for 15 years we've had a number of new publishing platforms, mostly social media come, I mean they're still here, they didn't go away, but your audience might have moved to different platforms over time and definitely many, many, many more. And when you think of the next 15 years, are any of them still going to be there and relevant? But your blog will always be there. So you build up your diary, your journaling in a way over all those years and that's owning that content as an asset is huge. So even if you don't blog for the sake of SEO, it's still within your own control that you can reuse on purpose and people can search for it and find different things. And I think that's something that really, the longer we do this stuff, the more valuable it is that you really own that.

BobWP:
Yeah, exactly. And for me, I think one of my challenges lately was my site BobWP.

Ronald:
That was huge by the way, wasn't it?

BobWP:
Yeah. And we were talking about that because I had my initial thoughts were kind of going back and forth between the two. So I would repurpose some of the content on Do the Woo over at BobWP.com, and as much as I thought that was a good strategy, it didn't really play out as I thought. And of course, Ronald, when we talked, he hinted maybe that content should be under Do the Woo.

Ronald:
Can you describe a little bit of your first thought of the content strategy when you were doing BobWP

? What were you publishing and how was engagement? I know some of it was testing plugins and so on, and probably old versions that are totally irrelevant. That's why you don't feel it's feasible anymore. But yeah, maybe you could share a little bit of it.

BobWP:
So the whole thing with BobWP, what it's always been, it's always been a piece of something. And back in the day I would do tutorials and stuff, and that's why a lot of this content no longer exists because it was really mostly about stuff that was at the time. And that stuff became outdated very quickly unless I went in and updated it, which I did. And when I actually separated the podcast that was originally started on BobWP, it was for that reason because I knew that I wanted to focus on Do the Woo. I wanted to build a brand more around that or build the buzz or get people directed to that. And so my strategy was always, I always had BobWP there and I did a little bit of blogging here and there, and then I came to the point where, like I said, I started thinking, well, should I start cross-promoting the two? Because a BobWP brand is known out there, which seemed like a good idea. My thought was that yeah, I could do a lot of back and forth because some people will go to BobWP and then I can send them over to Do the Woo, give them a snippet of that. Actually, it didn't work as I strategically planned because there wasn't as much traffic going to BobWP anymore because I let it mellow out, which was on purpose because I wanted my focus on Do the Woo. So that was how I kept looking at this and kept looking at this and I've actually made a decision going through all this. I'm at a point in life people can kind of say you're at a certain age or you're at a point in life where, okay, what's going to be the next thing? Well, mine is really Do the Woo. It's my focus. So I thought this is where I need to be all the time on Do the Woo because it's always going to be, even the experiences I can share doing my own thing over however many years can always fit somewhere there. And as a result, I just recently made the decision to take down BobWP as a site and use my Gravatar profile, BobWP, basically as my website now for BobWP.

Ronald:
Your business card.

BobWP:
And that was a long process and a lot of people have done that and I feel like that's going to be the best thing I can now focus directly on Do the Woo. I moved some of the content back over from BobWP over on Do the Woo because it fits there and stuff. I just done some of the old posts and stuff. So that was that whole thinking through process. And in the middle of that we talked about it and stuff and we had, oh, I'm drawing a blank, Ronnie from Gravita and listening to him even occurred to me, this is such a great thing because it's just I can send people where they want to go.

Ronald:
Yeah, it's like a massive signpost that's attached to on top of your head, isn't it? Are you business? You have a pleasure, are you sending money or are you just curious who I am? And then there you go. Just go wherever you need to go. Yeah, just one thing.
Nice. Do you question for you then is do you feel that BobWP might have served a different audience to where you are now with Woo? I know you've moved some of the content, so there's a little bit of an overlap, but I wonder if there's even a strategy where you say, Hey, there's some probably personal stuff that might not always be suitable for the Woo audience and even if I write this one blog post per year, it doesn't matter. It's just there. So I have a space that can run it that can publish and that's okay. And for everything else there is Do the Woo.

BobWP:
Yeah, I thought about that and I want the BobWP brand now to be the gateway to Do the Woo. So that's why I kept thinking when I looked at the site, it's like I had people, you can go to do the Woo, you can see where I do this and all this stuff, but I felt like it was its own little piece there and honestly I started to realize that I was trying to force myself, it felt like the right move something in my gut and that's kind of how I've always done things and maybe sometimes I regretted or something, but for now I just feel like because I basically have some content somewhere still on my WordPress dot com blog and I can always revive that sometime.

Ronald:
Yeah, it probably makes a great archive that even 10 years looks like I did that is a photo of me and whatever and then it's still there. I think that becomes really a nice way your own tool of bringing back something that might be relevant even later, even if the minute on something. I also have another question then. When you think about the content for Do the Woo, how do you think about that? So do you want to write for your audience or how do you want them to engage and bring them in and get them to engage with to Do the Woo brand?

BobWP:
That is the fun part to think about, but the challenge I think for me, the site where I've moved my whole mindset is that blog becomes an arm of what Do the Woo stands for. And that is having hosts that have already shown interest come in and write guest posts and they can or having even a guest come in and do it. But as you and I talked about before and I think you alluded to a little bit is how that conversation can be carried from a audio podcast or somebody that talks about something in a podcast and says, I'm doing this five months later they do it. Do they want to come in and write a little bit about it

Ronald:
Or what came out of it? What's the outcome of that initial podcast?

BobWP:
It can tie in really easy and make this circle back and forth between the content and how to get people there and engaged. Aside from thinking of creating a forum or some membership or all the crazy stuff that's available to us that I don't even want to touch on It is it's all through that commenting and how to get people, how to drive them there. And that's through social, it's different ways. There's different things that I've discovered are Jetpack now that we've used that we're using that for a lot of our stuff that there are things I want to test with that and try to drive people back to leaving comments and having conversation. There's some stuff I even talked with somebody from Jetpack at WordCamp Europe and we can do a couple ideas back and forth and we're continue that conversation. So I'm thinking of some different things. I've had a few other people suggest things or actually ask for things that this might be an interesting way to leave a comment and how that can without giving any of a way, I don't want to say I'm going to do it and then I don't do it, but getting people to go between the podcasts and the blog and keeping that conversation flowing in some way and somehow interjecting the comments in all of that. And it's not going to be an easy task

Ronald:
Different ways, isn't it? Because you have on one hand you really want to engage with the podcast, you want to listen to every word that's being said, but there are times when you might also just want read the LDR of that podcast and I'd like to say, okay, that podcast probably is not for me, but I'm glad I've read the headline into it. Are you going to commit yourself to a soccer match for 90 minutes or almost two hours, which is probably a lot of kicking balls back and forth. Or you're going to say, no, give me the five minute highlight, that's enough and if the match absolutely fantastic with quality soccer football, I'm going to go in and watch the full thing. Or if it's a team or a category that you support, I'm definitely want to listen them know what the whole thing.
So I think the block is also a little bit of a bridge between the full commitment or just a really short version of that or if you have been intrigued by the podcast, a blog could be a way to express your gratitude, your follow up question, sharing it with somebody else because from there you have to learn the links to the podcast. I mean there's so many different ideas to really use the podcast as the center of it all that again, Gravatar, it's signposting to everything and everything around that particular topic and maybe write about references of other speakers or podcast made in the past, which you may not have discussed in the podcast itself. So I get really excited about this though.

BobWP:
You're right because when I go through any transcript and it's kind of what I was doing with BobWP a little bit is it's like one question is a post in itself. Somebody has given you a direct answer to one specific problem or one specific challenge, but within those transcripts there is tons of information that can be pulled out and be very in themselves are little nuggets I call 'em gathered throughout that are standalone because they really tell you something right there, maybe even something you can take action on or something. And by itself sometimes you miss those things because like you said, you're listening to this long podcast for 45 minutes and that little piece comes in there and then it's gone

Ronald:
And you want to maybe reference that to somebody else. It's like, oh, was that 23 minutes or 28 minutes and then it's kind of lost. You're going to listen to the whole thing, maybe busy, but if the highlights are set of reference, quote that into a blog post. Yeah, that's a good way to share that though. I was going to ask probably two questions. I know one of the biggest reservations to start

a blog is your time commitment and I think in our discussion I've touched a little bit on that's like don't commit yourself to a weekly or a daily something just whenever it's right, whenever you feel like it. And quite often a newsletter when you say, Hey, I have a weekly newsletter. That's pretty tough to always fill a newsletter with something inside for every single week to the point that people actually might even be turned off by it because it's the same stuff you read five times over everywhere you in the WordPress ecosystem. So on one hand you have the time commitment, which is really tough, especially if you have busy schedule and you have five recordings in one day. How can you commit yourself to writing these blog posts? Maybe there are hack tools and then the second part is publishing, and I know you alluded to that earlier. How do you get people then to read it and how do you get to publish it? I'm glad that you mentioned Jetpack. They have some publishing tools across many different networks.

BobWP:
And I think that is the challenge because nothing absolutely drives me more nuts than going to read a post and at the end of the post they say, we would love for you to leave a comment over on X and they give you a link about this post and I'm like, now you're making me go back over there. But everybody tends to do that because that's where they feel all the conversations. But also it's a huge mess of stuff that just goes by quickly. I mean you need to do it, but the commitment I think some people spend on social is way beyond. I mean even though they feel there's a lot of engagement, they're looking at their views, this is viewed by 10,000 people, this is great. Well how did that all play out? What did you really get out of those 10,000 views? What engagement was there?

Ronald:
When you publish something to Twitter to X to Facebook and Instagram, it would be nice to have a link to those particular posts but also a little counter of what the engagement is on those or whether like 15 comments or 200 comments, it could be quite intriguing to actually go and discover that or even have some of that be reposted into the comments section of the blog to sort of bridge that data. I dunno how easy that is, but that really good truth for thought, what you just shared

BobWP:
And somebody just shared recently a person that is using the Fediverse pulling in content and stuff, but on their site they're pulling in all basically their feed of everything they say out there and it's all living on their site as a one page is a long feed. I know that next time anybody's at a WordCamp and you want to have a nice lengthy conversation about all of this kind of social stuff, I'm find Robert Windish from side, he's thinking, how can we make WordPress a social platform and that means your blog and stuff like that. And he has a lot of really, I mean he will talk your ear off about it, but he has a lot of interesting ideas and he's kind of on the mission himself and that kind of brings it in, how do you tie this all together? How do you still make your site the place where people will go to? And I think we've gotten out of that habit, the

Ronald:
Data liberation project, probably not excelling as far as we want. It's not always about moving side to a different platform, but it's also pulling in information from other platform into your own side, whether it's private or in case of WooCommerce, it could be moving data from shipping platforms or accounting platforms but also public comments, relevant comment from social media into your own play. And I think again, what I said earlier that if everything you did or published is on WordPress that you can totally control with your own tools and what it looks like, how amazing is that? How many issues would would've prevent it? I think people will start to realize that as things mature, WordPress is always there and will always be there, even selling a hundred year plan. So I'm pretty confident that that's going to be the case

BobWP:
And I think is there's, even though some people really dedicate themselves to maybe a certain platform or feel that even though they still have a site that more and more people are starting to think just can't go on or continue this way, there's a bit of frustration I think on some people's level and a bit, I mean I've even cut down my time on social just because I feel like I'm just, yeah, it's, it's too much anymore. I still depend on RSS, that's how I keep up on everything is my R SS feed and that I go in and check all the time. That's the easiest way for me to do it and still the best way

Ronald:
Controlling what comes into your inbox, what you read, what newsletter you subscribed, which block do you want to get into your feed. It's super important that you take control over your own life. I noticed that with my own certain social media profile, how destructive it can be and we dunno quite what the result is going to be in 10, 20 years time and how their attention is going to be. But these are all challenges that we start to see the tip of the iceberg. I just want to go back because we brush over that creating the content, like writing the content and I know AI tools are big and they've been around for quite a few years and blogging you could almost just do it with a couple of prompts. What are your thoughts on that using AI tools in the broadest way?

BobWP:
For me personally, I don't use it to create any original content. I've sometimes asked for a few ideas and even then it, it's very rarely where I use it the most is repurposing content and that means existing content and I have exactly that through the transcripts. So when I mean my transcripts to give you an idea of my workflow with the transcripts, which makes sense, that leads into other content is when I get a transcript, I have it done through rev.com through their AI and I go through and I correct some of the names brands and then I take that same transcript and I run it through chat GPT and I tell it to just find any spelling errors or small grammatical errors. Sometimes you have to be careful with the prompt or it'll actually start eliminating parts of the transcript. So I try to keep it to just really small things, which that usually fixes quite well and from that I'll ask it to give me one or two paragraph intro to it and it's never written exactly like I want, so I use it as a basis to just do something and then I'll ask it for some key takeaways, which is where I think it is a lot better at and that's the best use of it is on existing content, not on creating original content.
And then I would go through and make sure it reads and take out the word delve, which AI seems to love so much. Everybody delves into everything and it just drives me. But that's where personally and I think where it works best, I'm at an advantage because I basically have original content through the audio. I just need to have that transcribed and then work with that content. But original stuff still for me personally has to come from my brain.

Ronald:
You could teach the LMS to be more like Bob and if you keep teaching it with your prompts probably can get much better in weeks and months to come, but that does take time. It needs to learn that as well. But that's really interesting. I mean even just a few years back I recall you would send off your recording to be transcribed by somebody and it would be quite an expensive server and compare that now with these A alarms it's an amazing value and so much faster and almost instant.

BobWP:
Oh yeah, and it's something, yeah, for years and years I paid Rev to do human transcripts and that budget became higher and higher as I did more content obviously and more podcasts.

Ronald:
Right. Then a little bit unpacking the part of publishing to where your audiences are, where your tribe is at, but I know in your case you have so many new audiences and communities across the globe speaking different languages. Do you track that? Do you analyze that or you don't even go that fast right here it is. There are a few ways to find it.

BobWP:
Yeah, I've tried to do it and there's never a rhyme or reason for whatever happens with any content. I mean a certain spike in listen and sometimes you try to track it and you think was there somebody that just happened to share? It's out there somewhere that you don't know about and there's no way you can track it because suddenly it's just out of the blue you'll have five, six times as many listens one day as you did for the last five days or something and you can go and look at that topic and often the topic doesn't make sense either what made this happen or was it shared internally somewhere? How do you

Ronald:
Feel about others writing on your blog or for you, is that something, I know you talked about a little bit, but what are your thoughts around that? How far do you want to extend it? You want to keep it only within co-host or anybody that's been on the podcast and even to the point where it's almost could monetize the way because of anybody that publish on your platform with the audience that this build up there is some value to that.

BobWP:
Yeah, one of the wonderful things I have is I have a group of co-hosts. If I have an idea and this is how the newsletter thing is exactly what I did with that and I can bounce an idea off and when I bounce the idea of bringing a blog back right away, several of them were like, oh, I'd love to guess both. Which it's not easy to get people to guess posts because it's tough enough for them to write content for themselves. So for sure the hosts to me a no-br

ainer, especially if they want to follow up or write about one of the shows they've recently done. The guests almost are a second no-brainer because the opportunity to give them to follow up on something or to add to the conversation say, wow, after the conversation I thought about this one piece or I thought maybe they want to elaborate on one thing they were asked, they answered it one minute, but they have a lot more to say. So those kinds of things, I think it's ideal. The podcast is run by the community. I mean I do all the grunt work, but I host you. I bring in guest hosts and all these guests and I want the blog to be that too as far as open guest spots, but I'm going to be very selective. I don't want tutorials, I don't want them writing about their product. It's not

Ronald:
The audience that you've built up. Yeah, yeah, absolutely. And get the feedback as well in the bottom of the blog have some sort of rating tool that's used for how would you rate this content? And so they kind of use that as a way of working where depending on the number of readers and the feedback that you get is better provide the content that readers are interested in. The other thing I saw that crossed my mind working with user levels within WordPress publisher and editor admin, whether certain speakers who might want to follow up on things or even add a supportive blog post, whether they have some sort of levels that they can add and own that piece of content.

BobWP:
Yeah, I guess I could say get in the groove of how I do this with the post and I still want it to be that community oriented piece and I want them to feel like they have a bit of control over that. So it's an interesting thing to think about because I think that's an important part.

Ronald:
Yeah, it's that community that you build up and it's also back to the comments and empowering some writers to control and manage the comments and the conversation and that's like bringing that back. It then becomes not quite a forum, but it is that engagement not just between the author and a few comments and that probably brings in more folks to then want to comment because they can get the audience with the speaker, with the writer and leave some nice words or ask for the question, what did you mean we did quote or does also apply to X, Y and Z. The other cool thing I found with the Jetpack tool, creating the social media images, so when you publish that something did you see that you add your featured image and a bit of text and within the post itself it generates a social media image that's formatted for the different platform. Again, it's one of those little hacks that just make so much easier to create a content, publish it and not be dragged down like, oh, I need to do this, I need to do that. And then weeks past you still haven't published it because having that threshold as lowest as possible direct from public I think is key to just keep going. It doesn't matter if it's not perfect, even if it's a light mistake, update it. Yours.

BobWP:
Exactly. And

Ronald:
Just going back on the newsletters, because we have to bring that back in because that was the original idea is like I'm going to start with a newsletter and now we, instead of really focusing on blog, blog block and all the advantages, there's still a place for newsletters. Where do you see that sort of fall into place?

BobWP:
When I visualize in my head for a newsletter and ideally what I like is I want to keep as much of this content on the site and drive people and have it as a teaser. And of course as it has been, or I guess you don't call it newsletter, but when people get notified of a post, I mean just knowing this is a content and you can go back through and listen to what you want to read, what you want, but also is how to have that content go out automatically but also be able to add a little custom content to it to make sure that people, this is how you can more easily comment or by doing this and make it a little bit more visible. Add little snippets of something in there that

Ronald:
Quotes from the community like, oh, Ron said this on X and that followed up in a comment here and that've got some great conversation going, get engaged in this if you care about this stuff or here's a quote, I got the community talking and it was relevant here and there. And yeah, it also a good way to introduce other platforms within the own ecosystem. If you have a guest speaker from a Woo ecosystem or from a third party developer, it's nice to be able to reference that in a newsletter I get.

BobWP:
And I think there's a lot of potential, but I don't want to make the newsletter, like you said, this is kind of more of a prompt the newsletter. And what I really want to do is when I get this all in place and things moving along, my next endeavor is to get Matt Mullenweg on. I'd love to just talk with him about blogging, comment and ping backs

Ronald:
And did you now who is also fantastic, I know if that he should bring in a guest Tim Ferris and I know he and Matt have shared so many ideas around blogging, like long form short form. Also Seth Godin and I've written to some podcasts around how easy it is to share something or not at all really the thought process behind blogging and I think Matt is pretty good at that. He can share something very short, one paragraph and it's out there or some really long bits of tech, but it's the short ones that I'm going to take way more time to think that through. Very easy to talk and write paragraphs and paragraphs. At some point people will disengage and you kind of lost them, but keeping it super short and to the point that's real.

BobWP:
And I think that's kind of what I'm thinking about too is a lot of this and I think the site is ripe for that because there's a lot of content we can share that is short and to the point rather than just going on and on and giving 11 tips of whatever. I mean those have its place.

Ronald:
Yeah. Here's another thing, you're building up international communities and having the content of tribe or even the blog post, but having it with Google now, it's so easy to have your full page translated as well. It's almost instant. Well, it is instant. Which is a great way to repurpose content.

BobWP:
It is.

Ronald:
And both ways, if you have somebody writing in a lanugage that it also accessible to English speakers or to German speaker and yeah, that's probably something that's not talked about a lot, but super easy.

BobWP:
That would be really interesting, like to open that up. We've done that to some effect with the one podcast where we have the community come in and talk about their own WordPress community and their locale and in their native language, and so they're actually talking to their community. That's another whole piece of it. And I think it is, you're right, I know there's podcasts in the space that does the podcast in several different languages. They actually have somebody do it in four or five languages. A little bit of the news, WordPress news, and I think there's something there to be looked at for sure because we're a huge community.

Ronald:
I haven't checked the figures, but I would sort of maybe 60, 75% of Woo users don't live in a country where English is the first language. So maybe two thirds who don't have English foreign language, they speak English, but to truly engage with them anyway, I guess we've come to the conclusion that blogging is pretty cool. I think there is blogging for anybody for yourself, whether it's a personal diary that you have public and then you have your personal one that you keep private, whether it's for yourself or for your business, for your ecommerce site. I think blogging for the sake of SEO definitely has value, but I don't think that should be the prime goal to block call because then you end up in not very pretty or very well organized content to hit certain keywords and I think that puts people off. But write it for your, like you do with social media, keep it short to the point with a link to your product, to your podcast, wherever you want people to go to or the call to action. I think that probably has a good reason to consider it again.

BobWP:
Yeah, for sure. And definitely I think we've touched on enough different thing given our thoughts. Some of the direction Do the Woo might go. So if there is not a perfect post to come in and comment, anybody listening to this, this is a post because we've talked about a lot of things and I'm sure everybody that's listened to it has actually thought, well, yeah, that makes sense, or nope, this is the way I would do it or this is how it works for me.

Ronald:
And maybe that's the comment, call out what are the forms of blog posts or good examples of other forms of blog posts like rich content, whether it snippet the codes or a gallery photos or sound snippets or maybe a poll to get voting. That all can all be part of a blog pro. It doesn't always have to be just paragraph or words.

BobWP:
Right, exactly. So we're going to encourage everybody listening now to come and leave a comment.

Ronald:
I'm inspired now. I'm going to revisit my own site. I haven't touched since I started working at quite a few years now. It's all very well preaching about it, but maybe we should all get back to blogging. I think it's a good way.

BobWP:
Well this has been great and yeah, everybody hope you enjoyed it and let us know your thoughts. You'll go into the post, leave a comment.

Ronald:
It's been a great Blogstorm, Bob

. Yeah,

BobWP:
I'm sure you'll be right alongside there, at least in spirit one way or another.

Ronald:
Yeah, I need to write one of the first posts or co-write to see what.

BobWP:
Alright, Ronald, thanks everyone for listening and yeah, let us know what you think about all this stuff we were talking about. Alright, thank you all.

Ronald:
Thanks Bob.

Robert:
Hello, hello, hello, and welcome to another Do the Woo AgencyChat. It is my great pleasure to have Darko here from IntellRocket. Darko, welcome to the show.

Darko:
Hi Robert. Thank you for having me.

Robert:
Darko, tell us more about IntellRocket and yourself please.

Darko:
Yeah, thank you. So I am Darko Svetolikovic, which is hard to pronounce even in Serbian. I come from Serbia and I'm the founder of IntellRocket, which is a WordPress agency specializing in WordPress and WooCommerce development for more than a decade. Currently, we're certified web experts and have extensive experience in building custom WordPress websites and WooCommerce stores. I can say that we're trying to build beautiful websites, but that's not something you can be objective about. What's nice and what's beautiful is subjective. However, where you can be objective is that we build websites that are really fast. So, high-performance website projects where we guarantee that our custom builds will pass core web vitals. Why is that important? Because Core Web Vitals is a ranking signal. It means that your website is fast and produces a good user experience. Clients come to us asking for some crazy implementations, so we do that, create implementations from the technical side, and usually, those kinds of projects come with custom API integration.

Robert:
Don't spoil it yet, don't spoil it yet because we're going to get to it. Before we jump into the next sort of little bit here, I have to say there is a huge Serbian WordPress community and it's very impressive.

Darko:
Well, I see some people only at WordCamps. We live in the same city, but if there's no WordPress meetup or something like that, we don't see each other. And then I see them only at WordCamps, WordCamp Europe, or WordCamps across Europe. So yeah, there is a huge, huge community here. We hosted WordCamp 2018. I think it was WordCamp Europe in Belgrade, 2018 or 2019, I'm not sure.

Robert:
Yeah, so that's very impressive.

Darko:
We have a huge community here, and I suppose that is something that is driving WordPress. So it's not only the Serbian community; it's communities across the globe.

Robert:
I completely agree. It was actually really nice to see the Serbian community specifically having their little side meetups and things going on at WordCamps Europe. Nice group of folks. To get back to all the agency-important information, of course. You've mentioned performance as a key metric, not only for Core Web Vitals but for other, I guess, experience-related issues or experiences, period. What has IntellRocket done differently than other agencies around that performance question?

Darko:
Well, it's not that we're doing something different. We're focused on building websites that are fast and performant. We really dive deep into how WordPress operates, how everything functions, how everything works. So we try to optimize and make it better. And because of that, I can say those are performance-related things. I think I'm passionate about performance since I started my business and my agency work. I'm not a developer, so I don't have that experience related to technical things, but I can say I have some good people on my team who are willing to do what I ask them to do.

Robert:
So I want to dig into why that's important for you, but also why it's important for agencies as a whole to be looking at performance as a metric and specifically beyond hosting. Because every host is going to say they're the fastest, the best. We know the story. So why should agencies specifically be looking to target performance? How can they do that better?

Darko:
So about performance, of course, hosting is important, but if you have a well-coded website, then the hosting will be important but not that much. If you have a huge website that's not optimized well, you'll spend a fortune on hosting for that website to have good performance. So I would say everything is important: good code, good structure, good hosting. I'm passionate about performance. So because of that, I started working on performance. But 10 years ago, technologies were different. That's when that passion started. And then we started working on improving websites. So why should agencies care, or why should businesses care? Because that helps user experience. A fast website helps with conversion rates. Then that helps with revenue, that helps with profit margins. So I have a case where we worked on a client who was paying for Google Ads but didn't have an optimized website. So we started optimizing that website, and they were investing in PPC at that moment. Their website was, for example, let's say third in Google, first, second, third ad is like the third place. And then when we optimized the website for the same budget, this client had, let's say, a second position, and the cost per click reduced, for example, just for this case from $1 to 0.8. So they had 20% more traffic for the same budget. So that improved their Google Ads score. They got like 20% more clicks for the same money, but then that traffic landed on their website. And because the website was faster, they had a 20% better conversion rate. So 20% more traffic multiplied by 20% better conversion rate. They ended up increasing their profit by about 35%. That is why it's important. It's affecting your revenue in a short period. So it's easy to test. With SEO, it's harder because it takes more time to see what's affecting your website. I would say agencies that are doing SEO or marketing should care about performance. Even though I know what is happening in real life because it's not possible for most companies to achieve that. Of course, other work is important, but if you isolate all of this, I would say it can make a significant difference.

Robert:
That's a really interesting and good point about Google AdWords being affected by performance. When you tackle performance issues, are you tackling them at the front end, the backend? Where is that really making the biggest difference?

Darko:
We're trying everything. So, of course, we analyze the backend use. I don't know how the tools are called, but we analyze every query monitor, I think. So we analyze everything in the backend and how everything is working, but also we use code that is optimized. So even without caching, without anything, we tend to make fast websites. And then on top of that, we add caching, JavaScript, minification, all those things. But we make websites that are fast without any caching. We add caching in order to reduce resource spending and all of that. We try to make it fast from scratch. We try everything that we see from the backend, we will resolve it. Everything that puts me on the front end, we will try to resolve. Some things are possible, some things are hard, some things are not possible because you have some scripts you cannot handle. External scripts like Google Analytics and those kinds of things. And then those sometimes appear in the report. But we have also websites where we were adding 200 different Google events and those websites passed Core Web Vitals. So it's not about Google Analytics slowing down the website.

Robert:
And you mentioned building, I'll say it, custom front ends, and obviously you do a lot of work with WooCommerce. So I have to say it's something unique I haven't seen in any of our regular Do the Woo AgencyChats. Let's dive into what you're calling headless WooCommerce.

Darko:
So as I said, the passion about SEO, the passion about performance, and also API in the backend, all that was a solid foundation for starting something that is called headless WordPress or headless WooCommerce. How it explains headless, but in essence, that is JAMstack or headless, WordPress, headless website, headless WooCommerce, JAMstack e-commerce. Those are the terms. So it represents that you separate the front end from the backend. The backend is running on its own server. You use the API from the backend to send all the necessary information. And then the frontend is independently hosted. This simplifies the frontend and the backend because you don't have in the traditional stacks, you visit the website, the visitor comes to your website, you ask the backend, then it asks the database, it responds with something, and you get the front end. With a headless setup, you have most of the time everything pre-rendered, so the content is ready, and you instantly get the response of the page you're trying to get, which then reduces the time to get the information, and you get it much faster. So it just helps you build a super fast website, so you can have an instantly loading website across the globe. So it's not about your local market. It's possible to target a global market and have this instant website loading across the globe, which is good for international businesses. For example, startups, SaaS companies that don't know where they will sell. As a SaaS company, you don't know where your customers can come from. So you need to have a website that is loading fast in different markets. If you're targeting specifically, you can have a host server in that state or country. Of course, you can have CloudFlare on top, you can have caching, you can have everything with a traditional type, which will help you, but it won't help for the first visitor. So again, if you have different users from different markets, and for example, we're in Serbia, but our clients are in the US, and we host a website in Serbia, then our client from, let's say, California will get our website loading the first time slower than the second client or the second time he visits our website. He'll get it faster, but will he visit our website a second time if the first visit was like

ten seconds? Probably not. And then if you're targeting California, then the second visit is okay, but what if you have a visitor from Washington or New York? You cannot be ready for all that. And then on top of that caching, you should have some pinging servers, something like that. And you cannot be sure completely what is possible with a headless setup. It's possible to have instant loading across the globe. I can say we recently did some tests for our client, and we had the results. So they had a custom-coded website, so their website on 4G was loading something around three seconds, which is good on average, across five continents. So the website was on average loading within three seconds, something like 2.98. But then we tested on our other client that is using headless, and they have results which are 1.4 seconds average across the same locations.

Robert:
So twice as fast.

Darko:
Yeah. So 1.4 seconds is super fast.

Robert:
So my question is, and I've had this conversation about just regular, regular and both headless WordPress, I assume budgets are a little higher and time to develop is a little higher than just spinning up a regular WooCommerce. Would that be fair to say, or have you guys optimized it?

Darko:
There are challenges like that. If we are talking about standard e-commerce, standard WooCommerce, I don't think that costs too much. But usually, businesses that go to a headless setup have custom API integrations, have ERP in the backend, have CRM, and have several other marketing tools integrated into their setup currently, and they want to make a switch to headless. So they're like big businesses. They're not starting from scratch. Initially, you need a lot of things to be integrated and tailored to their needs, and that is why it usually costs a lot. But even with a traditional stack, that still costs a lot because you have a lot of different things that need to be connected, and that is something that affects the price. But what is positive about the headless is that if they go into a headless setup, they can save money on hosting, they can improve user experience, they can improve scalability. The flexibility is huge. You can adjust your website to do whatever you imagine it to do. So there are no limitations.

Robert:
And that website can be a mobile app as well.

Darko:
And yeah, you can use WooCommerce as a database, but usually in those setups, WooCommerce is not a database. ERP is a database, but you have WooCommerce to control the content. You can control that content, which can go to e-commerce. For example, we have a client who asked us to do something with categories in WooCommerce. They have a product page, and they want to have dynamically generated content. So they go and click some product filters, let's say it's a clothing e-commerce website. They go to categories, click outdoor, and then go to sneakers, and select under $100. They click all that in filters and get a dynamically generated page that says sneakers up to 100. Under that, they have "check our sneakers offering that is perfect for outdoor activities and less than $100." That can be the product page title and subtitle. When you change from outdoor to indoor, you get a different URL with sneakers for up to 100 for indoor activities. All those URLs for Google are indexable from one setup. You can have hundreds of pages that all get indexed in Google and get you real traffic. You're offering a great user experience to your users because they see the title, the description, it's in the meta description. So everything is done on an advanced level, which is not possible with a traditional stack. It's not about WordPress WooCommerce, it's not possible on any technology. With headless, you can do this. The time you save in content population or administrating those pages is where you save a lot of money, and your return on investment is bigger, the bigger the brand you are.

Robert:
I guess tying it to the original question, this isn't for everyone, it's not going to be for a freelancer selling their own t-shirts necessarily. It's really for, I'll use enterprise loosely, but a business where revenue and performance really do matter. Would that be fair to say?

Darko:
Yeah. In the e-commerce space, it's important for businesses that are across one country or one state that do business across one continent, I would say. They can have a bigger return on investment. Also, businesses that are entering the e-commerce space and want to compete with bigger players. Bigger players are hard to make that switch. It's expensive, it's time-consuming, and they don't know if that will work. But smaller players who want a piece of the cake can get that piece much faster if they go into some technology like this. They can win some positions in Google, they can win more clicks on Google ads for the same money. I would say it's important, but with smaller businesses, the budget can be smaller. You can build a good solution and then scale faster because it's scalable. You can add more. The backend can be independent of the front end, so you can add more things in the front end, but also you can scale your backend while the front end is the same.

Robert:
One point I want to make sure we don't miss is obviously we've mentioned performance, SEO, SEM, all the acronyms, security.

Darko:
Well, security with this setup is on another level. This is like, as I said, you have this decoupled architecture. Your front end and backend are completely separated, and because of that, you have a front end that is more secure by just, most of the time, having only read-only access. So you get the API and show the data and details. It's not possible to write something in. The front end is on a completely different server, and you pull the data from the API from some ERP, so everything is shown on the website. Because of this architecture, it's more secure. The backend can be hidden from users and accessed only by some security protocols. Because of that, users or malicious users cannot access your backend. This is just one layer on top. You still need to protect your WordPress and your WooCommerce, but this is one layer on top which prevents users from getting access to your backend.

Robert:
I've seen that in WordPress where you're drafting more static pages and obviously security is greatly improved by that, by having fewer vectors of attack.

Darko:
Yeah, the attack surface is reduced, so it's not impossible, but it's harder. Nothing is impossible. If someone invests a lot of time in something, they can do it from the application side or the hosting side. So nothing can be 100% sure and secure. Working on improvements all the time is important. For example, for all our backend activities, we have by default enabled two-factor authentication for all our users. We have two-factor authentication for every password that is shared. So we take care of security internally and even on the website level. Customers need to take care of their security too. Keep passwords in their password manager, have their users use two-factor authentication, force them to use a mobile app where they have two-factor authentication set up, not just in the password manager. But in the end, it's the responsibility of all parties involved.

Robert:
Without a doubt. As we all know, security is always more and more important because there's more money, there's more personally identifiable information, all the problems that occur, and that'll always improve at both ends. I'm more curious, of course, I have to say the AI word. What does the future of headless WooCommerce or WooCommerce in general with AI look like?

Darko:
Well, I think if you use it to do some things better, if you write… sometimes I play with AI, so sometimes…

Robert:
Oh, we all do, right?

Darko:
It's so annoying chatting with ChatGPT or anything. It's not AI yet, they're trying to sell us that as AI. But I think if you use it for some, there's some good applications, and it depends on how you set up your store to improve your operations. You can use it for data entry or some operational things, freeing up people to do more complex tasks. AI currently isn't capable of doing some super-advanced things, so we still need people. What's the future of WooCommerce with AI? This doesn't have too much to do with WooCommerce. Headless WooCommerce is the same. I would say that you can, for example, probably, the thing that I explained about product categories, you could generate content on those pages based on some filters. If you get personal details about users, it's more likely for them to like that content in order to click the product they want to buy, let's say something like that.

Robert:
No, that's fantastic. I know everyone's looking at figuring out how they can use AI. I like how you actually very much said LLMs are not AIs. That's a really good point. I think people forget that. I'm curious how upgrades in translations will affect especially multinational WooCommerce sites. I think that'll be interesting to see how that comes to pass, since I know that's sort of on Matt Mullenweg's WordPress timeline.

Darko:
I think if you reach some limits inside your WooCommerce, it's important to know that there is an option to go with headless because then you don't have those limitations. I haven't reached those limitations with the headless websites we've built so far.

Robert:
That's fantastic. Darko, how can folks connect with you and learn more about getting started with headless WordPress?

Darko:
For those interested in headless WordPress or headless WooCommerce, they can find our website at IntellRocket.com. They can find us on LinkedIn, they can find me on LinkedIn, and they can just reach out, ask what they're curious about, and we can provide them with a consultation or anything they need.

Robert:
Darko, thank you so much. It was great to learn about your perspectives, especially about headless WooCommerce.

Darko:
Thank you, Robert. Thank you for having me on this podcast, and I hope we'll see each other at some WordCamps.

Robert:
Absolutely. And that's another Do the Woo AgencyChat. Thank you. Thank you.

Mike:
Yeah, I think having adequate resources for the site is super important. So there's enough CPU and RAM, using fast SSD drives. There's room for growth. A lot of the time I see not enough resources being allocated for the database, for example. It's like having a big enough engine to power that database. Having access for developers like SSH analytics tools, being able to access the logs and scrape those properly for little nuggets of information. Having some sort of application performance monitor (APM) like New Relic is the one that I use the most. It's pretty popular because you want to be ideally alerted and proactive about performance issues rather than reactive. You don't want to find out customers are emailing you or blasting you on social media that, oh, you're trying to check out on this thing again and it's crashing or slow or whatever. It's better if you get an alert from your own systems that you have set up for monitoring, etc., to go out and put that fire out and be able to pinpoint the issue very, very quickly instead of trying to play detective with discovering all the clues instead of having the clues handed to you.

Having some sort of CDN integration I think is quite important as well. There are a lot of Cloudflare enterprise partners now with hosting companies, which I think is, if you wanted to build your own Cloudflare network, good luck. That's a lot of resources, a lot of money. So I think it's easier to just get a host that already leverages their network for the DDoS protection and the security because sometimes the performance issues I see on WooCommerce sites are actually security related. The site is constantly getting attacked on the login page or good old XML-RPC, which has been around since the dawn of computing and is used but can still be a very common attack vector. And fraudulent orders was one that I saw come up recently. This client had a bot network that was attacking them, making a bunch of fraudulent orders, just taking up resources from real people who are actually buying stuff. So yeah, those are the things I think off the top of my head.

Marcel:
And I obviously think that the very basic part of it, of the hosting, is if you have an audience or a market that is more US-based or European-based or whatever region you're selling to or providing your services to, that also plays a very important role in deciding which area of the world you're selling to and then choosing a hosting company that has good data centers or good resources in that specific area. The region of the world is, I guess, the number one thing we should look for when we're going to choose a hosting company because they all say they are very fast everywhere, but if you dig a little deeper, you will see that they are probably more US-based. So whenever you go to a hosting company and you search for their data centers and where they're located, some of them, even when you spin up a hosting service, they will ask which area do you want to cover.

I think some of them are more US-based, some of them are more European-based, and we have Asian ones. For example, if you want to go to the Asian market and sell in China, Japan, and other countries, it's far more challenging to choose the right hosting company than it would be to sell in Europe or in the US. So that would be probably my advice: choose a hosting company that has all the services you talked about and all the little details that they care about, specific for WooCommerce, but also where they are really strong when it comes to providing the fastest services in the region of the world you want to sell. Number two, I would say, is the theme. When we talk about the theme, do your clients go more with existing themes and then change that, or do they have custom themes?

Mike:
It depends on the size of the client. I work with a range of small businesses to enterprise clients. One of the Shark Tank clients I'm working with, they were using a very popular commercial theme that had a lot of extra bloat and unnecessary stuff they didn't need. I told them, you have the budget and the resources, go custom. It's hard to compete with the performance of a custom-built theme, and if you have resources available to maintain it going forward, absolutely it's the way to go. I generally find that smaller businesses, when they're just starting out, they don't know if what they're going to build and try is going to have legs, is it going to work, is it going to make money?

So they will tend to pick a theme that is pretty, has predefined templates that will work with WooCommerce, and has a bunch of features. As time goes on, they probably also use a page builder or two or three I'm sure we've all seen, and other components. That will tend to, of course, slow things down. I tell them during consultations that if you're using a certain combination of theme and a page builder, I would start with removing that and then if you're still not happy, we can look further at what's slowing things down. So I'd say it's a mixture. Whenever I see a custom-built theme with a cart, I'm like, oh good. This means that I don't have to have that difficult conversation of if they're really in love with their theme or the design that the theme provides, and you tell them, hey, you have to get rid of this. It's like taking a toy away from a child that they're very, very happy with. Then I tell them, no, no, no, you can have the same design and features, just rebuild it with lighter components.

Marcel:
And usually as a developer, when you have a client that is using an existing theme and they start having these ideas about, oh, what if we could change this page and make the image appear on the right side instead of the left side, or we need the description to have a bigger place now let's move it down, or now we need an extra tab for this or for that. And then you suddenly end up having so much customization on top of an existing theme that you start asking yourself or challenging the client, this is becoming so cumbersome to maintain all of these changes. It would make more sense to build a custom theme. I would say if you have the resources and if your client has the resources, a custom theme may seem like very hard work at the beginning because you have to do all of those standard pages, the 404s, the search page and all of that, but it will compensate in the end because if you have full control of everything that is being loaded on a theme and usually when you go with an existing theme, you don't need all of the features that they offer, you have a lot more control over performance.

So if you're starting out, fine, but if you want to invest in something that is very important to the performance, I would say the theme is the number one category where you should put some resources because we're talking about web performance and we're talking about key metrics that we can measure. The theme part is one of the most important components because it is responsible for the front-end part. When we talk about key metrics, we talk about LCP (Largest Contentful Paint), we talk about the First Input Delay (FID), we talk about Cumulative Layout Shift (CLS), which is when the page loads and things start moving up and down because the images are loading or different parts of the page are loading and they're shifting up and down, which makes it very confusing for a user to follow. That is all the theme, or mostly the theme's responsibility. From the key metrics, what is the most important one in your view?

Mike:
I think Largest Contentful Paint (LCP) is a big one. So related to conversion rates, time to first byte as well. I know it's not a core web vital, but…

Marcel:
I forgot to mention that. It's an important key metric as well.

Mike:
Everything else, the Largest Contentful Paint can only be as fast as the time to first byte. And there's also Interaction to Next Paint (INP), which you mentioned in the introduction, right? That I think replaced FID, the transition because when you click the button or whatever and you don't see something happening within a few milliseconds, we get confused or frustrated and keep clicking the button faster. That's a common human thing where we think clicking the button harder and more intensely will make it work. Maybe you press your mouse button extra hard or…

Marcel:
Multiple times.

Mike:
Yeah, like clicking the elevator button faster and faster…

Marcel:
It's not coming. Let's press again.

Mike:
I think that one is really important for stores because of the add-to-cart checkout flow. It's important to signal to the user that they're making progress towards their end goal and with their journey of trying to get this product or service that you're selling. That one is more difficult to measure in, not in the wild, but to pinpoint where the INP issue is coming from is not as difficult as Largest Contentful Paint, for example, which is well established for being very related to the revenue conversion rates. There's a cool calculator that Google put out a long time ago that they deprecated for some reason. I don't know why, but we took the code and put it on my website. I think I've sent you the link before too with this LCP Premier calculator.

Marcel:
And I would recommend everybody to take a look at that because it's very interesting how much you can estimate the increase in terms of conversions just by tweaking some of these key metrics in more performance.

Mike:
It can help a lot to put things into perspective for the clients. It's not based on a specific niche. It's aggregated data that people and Google Analytics opted in to allow Google to track. So it's from all niches across all different industries, and it gives us the best idea of if we can improve the LCP from X to Y, and if you know your average order value, the amount of customers that come

per month, and one other piece I can't remember, you can see how much more revenue you will get if you make that improvement in the LCP. It can help shortcut some of the conversations about price. If you're saying, oh, it's going to cost $10,000 or $20,000 to do this reworking of the site or whatever, and they can see, oh, that sounds expensive, but if you use the calculator they can see, oh, that's going to mean half a million extra in potential profit from a business perspective, it becomes a much easier decision.

Marcel:
And clients do have sort of the first impression that they get when we present them these numbers and we talk about this specific calculator you're talking about and they go, oh, that sounds too much or that sounds too good to be true and all of that. But you've done that. You actually have some cases on a website where you improve some clients' websites and it really turned into more profit. So that's something that clients will notice after you do performance tweaks and it's something that is absolutely incredible how they suddenly start believing in you and suddenly start seeing how important performance is to their funnel and to the sales and conversions and all of that. It sort of makes you feel a little bit like a magician or a special god of some sorts when you get to that point and then that client is hooked to you forever, I would say.

Mike:
Yeah, it's a very effective way to establish trust for the long-term because a lot of this stuff when it comes to performance is unknown for a client. We all know technology is unreliable, unpredictable, we can have the best intentions, we can make all these plans and then something that we didn't anticipate can mess things up. And so I think even if you have these case studies and you have lots of proof and stories, clients are still a little bit like, ah, but maybe that won't work for us. So when it does, I can see the struggle in their faces and that hesitation like, ah, they're taking that leap, jumping off the cliff and spending the money where things could not get any better. That's one of their main concerns, that it's not going to provide the return on investment. Fortunately, when you follow a specific methodology, and I'm sure this is true for anyone who's worked with performance, if the client is getting enough traffic, if the user experience of the site is otherwise good, their business model is sound. When you're improving the performance, it always makes sense within reason. Of course, once you get to a certain point, unless you're Amazon or Walmart or a very large client, spending an extra $500,000 to improve performance is not necessarily going to make sense. But for smaller clients, the initial performance tuning is pretty much always worth it.

Marcel:
I guess being aware that it is an important factor when you go online and do sell products is step one to admit regardless of your size. And I've seen other big brands in Portugal and the companies who were selling online who initially didn't give that much of a thought about performance and their websites were being slow and inconsistent and they were difficult to navigate. And since some time back, a couple of them have been actually working on their performance side and worrying about all these different key metrics we just talked about. And guess what? They're selling better. And you usually think big companies and big brands, oh, they must for sure know about this. And you probably also think, oh, my client has been online selling this product for more than 10 years now. He heard about performance, he's done everything that he can. Surprisingly, many people do not know about it in a way that affects immediately their conversion rate.

I wanted to talk also about plugins and the importance of plugins and especially the number of plugins that people install. They think they're essential and they're not. So my experience is more in terms of whenever I get hands on a website, it is performing very slowly. 30, 40 plus plugins are installed. Oh, when we start doing the audit and ask, do you need this plugin? What is this for? We certainly get rid of 10 immediately just by talking two minutes into the list of the plugins. And just that alone already cuts down the time considerably. And all the other plugins that are installed there are usually because there's something missing on the e-commerce out-of-the-box features that people don't have. And we've also seen WooCommerce iterating and adding some of those missing features into the core installation. But the number of plugins is also another thing that is very important to talk about, and that means also you need to update them and the more you have, the more security issues you have. You certainly also have multiple plugins that do the same function, or at least in their feature list they offer the same things and you just add things to the website that are absolutely not necessary.

So when it comes to choosing a plugin, it's also important to know about their performance and how they affect performance and if they are built in a way that shows the concern of the author of the plugin was performance or not. We usually use plugins to do image optimizations, maybe to do caching as well. We're going to talk about caching next. We use plugins basically to change features and to add features to WooCommerce. So plugins are very important. What is your experience with plugins? And you mentioned page builders. Page builders are plugins, but there are other nightmares that we can talk about when it comes to plugins and performance, right?

Mike:
Yeah, I mean my approach is similar to yours. It's remarkable how frequently you ask just simple questions, why do you have three forms plugins or what is this for? And they say, oh, well we haven't used that in six months or a year, or we don't use that plugin or feature anymore. And I tell them what you said, every plugin is a security liability and a performance liability. So as soon as you don't need it, treat your website like an F1 car. There's nothing on an F1 car that doesn't need to be there. If it has a specific purpose and provides some value in some way, it should be there, otherwise, there's no reason to have it. But otherwise, I would say the plugin quality is much more important than the plugin quantity. So I have seen websites that have 90 plugins and perform very, very well.

It's absolutely possible, but it's usually these heavier plugins that have lots of bundled features, 80% of which you don't use, and then you do that 10 times and you can see them in the profiling, code profiling, tools, plugins that are just finding out, do I need to run or running unnecessarily on pages. For example, a client I mentioned earlier, Bingbot. Bingbot was crawling a product archive page and it was triggering the membership plugin to see if the Bingbot had access to the particular pages of products on that product category page because the way the plugin was configured was to grant access based on categories and I was like, it's ridiculous. First of all, a bot isn't going to log in and take any courses or download any products, but there was literally no reason for the membership plugin to execute. So that was down to code quality in my experience and making sure that plugins, pretty much most plugins I see, do not have the logic to find out, do I need to execute here? Do I need to do anything here before it starts to process its own code? And I think that's why when people complain about WooCommerce being slow or WordPress being slow, it's not the core of WordPress being slow, it's all the other extra stuff that you added usually that is causing those kinds of experiences.

Marcel:
And when it comes to choosing a particular plugin that has a particular feature, you obviously have a bunch of different plugins out there, and usually what I tell people is, well, you could hire a developer to make a more informed decision about how the code quality is and how the plugin works and how it performs, but if you don't have the resources to hire an expert when you buy these plugins, basically, I guess looking at the plugin's reviews and seeing what other people are saying or maybe just trying to get a feel of if you see a plugin that is promoting bundled features that are 30, 40, 50 and they are expanding way beyond whatever the core function of the plugin is, it usually means that they are bloated and they're not very specifically oriented to the feature that they were talking about. When we did plugins for other companies here at our agency, some of them wanted to expand to other areas that were not the core focus of their plugin initially.

So for a developer, it's very hard to keep consistency and keep the code in a shape that is solely focused on the core feature it was intended to be in the first place. So if you start doing other features and start adding other elements to the plugin, for the developer or developer team who is responsible for making it perform well, it's going to be very hard for them to just focus on that particular feature, so that is very important. Next on the list is caching. We talked about caching. There are three main techniques of caching I think we can say. There is page caching, which are static versions of pages that are stored usually on the hosting side. We have object caching, which caches database queries so that they do not need to be executed every time somebody gets into a page. And we also have browser caching, which is telling the browser to store certain resources locally and not have them transmitted all over again. Caching is probably one of the hardest things to manage and to talk about because most of the hosting companies already say, we have the best caching solution and technique, just come with your website and host with us, and you're going to have the latest caching technology. Then when you dive in and want to control some aspect of the caching, you usually have no idea what they're doing behind the scenes and they don't tell you what resources and what techniques they're using behind the

scenes. So this is a very important topic. It's a very difficult topic as well from a developer's perspective because usually people think, oh, we just throw in a bunch of plugins like WPRocket or WP Total Cache or whatever other plugins there are, and the site will be faster, and then you hire a developer and the developer goes in and starts thinking about what is going on. We have all this caching going on, and what do you think about caching? Is it up in earliest as an important part? And also it's important to talk about the different pages that we have within WooCommerce. We have the checkout, the cart, we have a catalog, we have the first page, so not all of these pages are treated equally when it comes to caching. Right?

Mike:
There's also two other little pieces of caching too. There's fragment caching, which is rarely used but handy to cache partial pieces of the page and CDN caching, edge caching, I would argue. Yeah, but I know that those are typically not considered under the umbrella in the same way. It's not the ones that pop up first in mind, and I think with object caching too, you can also cache the results of API calls. I think we've done that before for clients with really slow calls that need to fetch something from some API that takes a couple of minutes, and instead of doing that every page load, we store it in a transient. But yes, caching is very, very important. I think in terms of the order that we discuss things, the hosting, the theme, plugins, caching, they're all really, really the first points of call when it comes to doing audits and making sure things are running well. I think page caching is probably the most important one to get right because everything else will, like you said, the LCP will depend on your time to first byte, which is tremendously improved once you get page caching working, and if you again can leverage edge caching on top of that, you can save usually another 100, 200, 300 milliseconds, which can speed up the other components.

Marcel:
Especially the initial page. The homepage is probably one of the easiest pages to cache, and because it is the point of entry to the website, it just gives you the first impression that we're looking for it to be fast and clicky and all of the links that go from the first page to specific products and maybe category pages and all of that, those are very easily cacheable pages, right?

Mike:
Yeah, yeah, exactly. Like the pieces where there aren't dynamic components that need to do post requests or fetch something from the database particular to that visitor, that kind of stuff. I certainly encourage people to build their homepages like that so that they're very cache-friendly and we don't have to worry about users seeing something they're not supposed to or those kinds of things compared to if you have product category pages where you have something with facets where you can filter and drill down, you're fetching a lot of information straight from the database, which I noticed…

Marcel:
Even with those pages, you can still cache them. Usually filtering options that you have on the website, in the cases where the number of combinations are not in the millions, if they're in the hundreds, it's not difficult to cache all the different variations when it comes to filtering and having fast filtering is one of the biggest challenges in a WooCommerce store. But if you're small and if you have the knowledge and if you can hire a developer to do that, we developers have the resources to cache those filtered pages as well, right?

Mike:
Yeah, absolutely. Yeah. I think you even built something for, I forgot the name of it, but you built a filter plugin for a client that is actually selling it.

Marcel:
Well, in that particular version we did a little, the client had this awesome idea to just provide the browser with the initial results of the filtered products, but it wasn't directly related to the caching part, but here's the deal, it benefits greatly from page caching because the information that comes with the page source is already enough for people to feel the filtering to be very fast. It's the perceived part that we talked about at the beginning, but it's not caching everything, but it's caching just enough for people to think this is super fast. And yes, that was one of the techniques that they used, but even if you don't have that, even if you have a page caching system where the first customer goes in is the one who generates the HTML for that particular cache, and then the second one that does the same, the same filtering options will be served the cached version of it, and that's…

Mike:
Possible, and I think with filtering too, you get, so you can do both page caching and basically object caching is what I would call it when you are storing them in the database or if you can cache the query string, get parameters from, if that's how the facet plugin is working, then you get to leverage Varnish or Nginx or whatever other caching plugin you might be using, and that's one cool way to do it. But then if that isn't cached, it fetches it straight from a transient inside the database is the next best thing. So I know some people don't like having layers of cache because you can have stale cache and you don't want the user to be delivered expired data, but I think if you get things configured correctly, everything helps boost one another. It's the same thing with page caching locally on the host and page cache on the edge with Cloudflare or a similar solution.

It's always better if Cloudflare wants to cache your homepage that when you deliver the page to Cloudflare, if you can give a cached version that's way faster than taking two to three seconds for time to first byte to then deliver it to Cloudflare. So I think it's important to consider these aspects in the performance strategy and get things, there might be some little fine-tuning or issues to iron out as you're rolling out caching, and a lot of planning is usually a good idea with clients asking them what's the typical user journey? What different types of users and avatars do we have on the site? How do they navigate through the site so that we can make sure we're considering all types of users? Also for employees, the customers are the ones giving money to the WooCommerce store, but the people who need to work on the backend processing orders, support tickets, that kind of stuff, I think it's important they have a good experience as well, and you won't be able to use page caching as much for them, but there's certain object caching and similar techniques you can use for their tasks daily that can make it a better experience.

They get more productive, store owners are happier and all of that stuff.

Marcel:
And then you have the cart pages and the checkout pages, which obviously cannot be page cached. Maybe parts of it can be object cached because there are elements in there that are repetitive for all customers, but then it goes back to what we were saying before about hosting, right? For those pages, you need to rely on the quality of the CPU, memory, SSD and all of that to render those pages fast enough because it's not just enough to do a fast homepage and category pages and product pages. If people get to the cart and then to the checkout and the page takes 10 seconds to load, you just basically lost the client right there.

Mike:
Yeah, yeah, exactly. And it's something to really get nailed down. I think it's okay for the final checkout when people press after they've added their billing details, credit card number, all of that, pressing that final button, it needs to communicate with the payment gateway or API calls back and forth. I think people accept and understand that that could take a bit of time…

Marcel:
Like that everywhere in every single site,

Mike:
But getting to that stage shouldn't take long. I think especially with mobile browsers nowadays, you can autofill pretty much all of the fields and WooCommerce is so popular and widespread that unless you've done a lot of customization to the fields or whatever like the Google Chrome Safari or whatever, I think we'll be able to figure it out. We can't cache those pages, but it's still, so maybe you might be able to do some fragment caching if you still have the menu in there and it's a mega menu, super complicated. We could cache that, so that's not taking up unnecessary time. I don't think that many users are going into the menu at…

Marcel:
That point. Yeah,

Mike:
Or you might have a footer, I've seen this before. We have a footer widget or some piece that is contacting Instagram or doing something else blocking the right page and the user isn't even going to see it, but it still is preventing the checkout flow from progressing…

Marcel:
Quickly. Yeah, I was going to take the last minutes that we have for this episode. Just to sum quickly, so we have chosen our hosting company, we have chosen our theme and we have a set of plugins that we chose. We learned about caching and what the different caching versions are, and now we've installed everything and we run the website and it's slow. The website is not moving at all. Then we need to talk about, and we've already talked about core web vitals, so we have different diagnosing tools that we can use to understand why the site is slow, because if we followed all of the advice that we're given, we've chosen the right hosting, the theme is not big, the number of plugins is reduced, and we only have the ones that we really need. We've tweaked, we spent hours tweaking the caching and the site is still taking two seconds to load the homepage. For example, core web vitals are the first thing to go to and to measure. How do you do that? How do you measure core web vitals?

Mike:
Yeah, there's definitely using a front-end tool like Google PageSpeed Insights, GTmetrix, WebPageTest. We've seen those at the perf now

conference…

Marcel:
PerfNow Conference. Yes,

Mike:
They all run some piece of Lighthouse nowadays. You used to have to use Google PageSpeed Insights, it's called I think something else now. Anyway, web.dev/measure. So they all just have different ways of running Lighthouse and then presenting the data to you differently. So I like WebPageTest the most. It's the geekiest, so it could be quite overwhelming for people. I think GTmetrix does a really good job of presenting the data in a more digestible way that isn't overwhelming and it gives you a good amount of insights and Google PageSpeed. I think because it's the official Google tool, people like to use that and it feels like it's more credible, trustworthy…

Marcel:
And it will tell you also about SEO because you want to appear on Google results and at the top eventually, and that particular tool will give you more information about that specific part of the performance.

Mike:
It tells you if you're failing the core web vitals for that particular page or for your entire website, depending on how much traffic you're getting. I believe WebPageTest does that as well. It has the crux Google Chrome user experience metrics, but that's only Chrome data, which is important to remember. It's the same thing on PageSpeed Insights that it's not collecting that information from other non-Google Chrome browsers. But yeah, those tools, I mean we can do a whole workshop on those. There's a bunch of courses on them, so advanced and rich in what they can do. But yeah, that's why a lot of people, they come to me and they say, Hey, I ran this and it's slow. I don't understand this report. Sometimes those reports are oversimplified where there's a lot of pieces that they miss or that they say, oh, the LCP element is this, and it's like, well, why is it taking eight seconds? Usually it's JavaScript related or something else, but it could also be the time the first byte was six seconds, so that takes someone who has experience and to decrypt, I think, or understand things more.

Marcel:
Do you have a favorite tool?

Mike:
Well, no, it's basically just the ones that you talked about, but what I think is the most important one, I don't want to say there's a most important one, but I do feel like the Google's tool is a good starting point for people to understand a little bit what's going on because they also give, I don't want to say simple instructions on how to fix those because they're not, probably not simple when they say to reduce image sizes or when they say to lazy load some scripts and all of that stuff. Usually as a store owner, you don't really know what to do, and even as a developer, you suddenly think, oh, so if I just lazy load all this stuff and I just delay all the loading of the JavaScript, that will fix it. But then I start thinking, oh, how do I determine which ones are not necessary and how do I determine which ones the clients need if they change something on a homepage? Suddenly it's the script that does this funny animation or has this slider going on. So it's very hard for people to understand, and I think Google's tool is the one that gives you a starting point to start figuring out what's going on. They do this coloring with red, yellow, and I think that's all the colors, the important colors they use to pinpoint all the most important parts of it, and if you manage to figure out some of those points, you're already in a good starting point and then you can use all the other tools you mentioned to just fine tune specific parts of it. But once you have the results and once you have some indications on the website specifically what's going on, being it a section of the website, an image problem, JavaScript problem, whatever it is, then it basically comes back to the theme setup and how to properly set up the theme.

Usually if you go with an existing theme, there are options that you can turn on and off and by those on and off, you will then obviously maybe not load some of the scripts if the theme is done properly, if they have taken care of just not loading scripts they don't need for that particular page. This is where page builders come in very handy, and that's why I'm a huge, huge fan of Gutenberg and all the Gutenberg experience because it's very performance-focused. But then again, you will optimize the heavy scripts, the styles, you will disable some theme features. As we talked about, mobile performance is also something that you will fine tune and then you suddenly… Let's move on to the story and end with this. Then suddenly you realize, okay, I've fixed all of these problems. I have a faster website. I have fixed most of the problems they were told to me to fix. How do you keep record of the website's performance and how do you go about making sure that this first initial tweak that you did is going to keep up with your website and you're going to maintain all of that performance throughout the whole existence of the website? What is your tip as a final tip on how developers or clients can diagnose the performance throughout the whole time that it exists?

Mike:
Yeah, I'll make it short. I think it's important to focus on both lab tests, which are these synthetic tests you run through GTmetrix and other tools, and then also look at the real user metrics, which is what actual people are experiencing, and then diagnose as much as you can using those tools and having some kind of performance budget in mind in terms of what kind of space do we have for, what are we going to allow for the LCP to be? What are we going to allow for the time to first byte to be? How much JavaScript, what's the overall payload for the entire front page that we're going to allow to be not larger than 500 kilobytes, for example, would be great. Sometimes it might be way larger and sort of tracking with a spreadsheet or screenshots or whatever you can, and sort of dating those to make sure that things are staying within your thresholds that you've defined, I think is a good starting point unless you have a whole performance team dedicated.

What we've seen at the conference, these big companies like IKEA, they have dedicated performance teams whose job is to make sure everything is running smoothly and they interface with the departments. I don't think that's realistic for a lot of companies, but we can still take some of the ideas and sort of track things. I think that most importantly is don't just assume that once you've made a change performance-wise or whatever, that it's going to persist indefinitely forever because the website is usually a living, breathing thing. You do updates to the plugins, etc. People tend to add more features and sometimes a plugin update can introduce a new performance bottleneck and it's important to match that…

Marcel:
Or changing the homepage, or you have a different hero section, you have something different in your homepage and you suddenly think it looks way better. I'm going to sell a lot more, and then it suddenly affects one of the key metrics, for example.

Mike:
Yeah, exactly. If someone has hired a designer to implement something and you're like, oh, this is beautiful, but the page has increased to five megabytes and all your metrics are way, way off, now aesthetically it might be better, but you're going to end up losing money. In my experience, so I think having it in your workflow, whatever size company you are, to do some kind of testing to make sure that the performance is still good after you've made major changes or even minor ones. I think it's important because people, business owners, will always check the money side of things and when they notice all of a sudden that conversion rates are down or have been trending downwards over a few months and they feel it in their wallet, that's a very frustrating position to be in and it's nicer to catch…

Marcel:
And they usually probably think, oh, it's something with my marketing or advertisement, or there's something with the products or reviews and they usually don't think it might be the performance part of the website that is damaging their sales.

Mike:
Yeah, exactly.

Marcel:
So regularly monitoring the site performance is our advice as a last piece of advice for today's episode. New Relic, it doesn't store information that much, but it is a tool that you can use to just analyze regularly your website's performance. Google PageSpeed Insights is something that some of the hosting providers have embedded in their system and some of them can also give you some notifications if you reach certain values that are not recommended. And I think GTmetrix, I'm not sure, is the one that you can also buy a subscription and have it regularly measure and analyze your website and send you insights to your inbox for you to be aware of…

Mike:
Yeah, GTmetrix actually even lets you, if you pay them a subscription, you can have it alert you if certain metrics have exceeded. If you say, I don't want LCP larger than 2.5 for your product category page or whatever, it will actually send you an email and alert. And that goes back to the proactivity aspect, right? Where it's better to find that out and do something about it immediately rather than finding out three months later. And revenue is down, morale…

Marcel:
And it also provides actionable recommendations as well. All right, so we talked about a bunch of stuff today. CDN, database optimization, image optimization, lazy loading, plugins, themes, performance key metrics, all of that could be potentially a bunch of other episodes that we'll talk about. And actually it would be cool to bring somebody else as a guest to talk specifically about some of these key aspects. As a last recommendation, I think we can also talk about the PerfNow conference that happens in November in Amsterdam. You've been going to the conference before and you've recommended that conference to me last year and I went there last year with you. And

although within WordPress and WooCommerce we're only used to go to the WordCamps and the different versions of those, PerfNow has… I haven't seen the word WordPress ever in their website, but it has so much to do with our work and it has so much to do with the development work we do for WordPress. So I definitely recommend people checking out PerfNow. It happens in Amsterdam in November, it's a conference that is not as big as any WordCamp, Europe or US or Asia that we've seen. And you get out of there with the will to just go back to your clients and say, hey, I'm going to make your website a lot faster now because I understand performance there. Would you recommend PerfNow as well?

Mike:
Oh, absolutely. The people who build the tools that we use and they're pioneers of front-end performance and are sharing these incredible stories, a lot of them work for big companies and they give you real case studies where we're talking millions of dollars at stake from making certain changes. And it always reinvigorates me every time I go where I'm like, oh, I need to build this now and we're going to introduce this to clients and make everything better for them. If you're a real performance enthusiast and love this stuff. I haven't found a conference that's more exhilarating than PerfNow and the people are super friendly. The vibe is really, really cool there. When we were there last…

Marcel:
And just being able to talk to the people who built all of these tools, they actually have something to say about what's coming next and give advice on the evolution of all of this. So it seems also like you go to that conference and you're in the future for the next one or two years and see what's going to happen, what's important. And the fact that you as a developer can offer that to the client and make money out of it and sort of turn yourself into their magician and do stuff that nobody else can do, that is super important.

Mike:
Yeah. It sets you apart for sure.

Marcel:
All right, this is it for our episode. Thank you so much for listening in and I hope to meet you guys in the next one.

Jonathan:
Welcome to another episode of Do the Woo. I'm your co-host, Jonathan Wold, and with me today is your other co-host, Tammie Lister. Tammie, how are you?

Tammie:
I'm good, thank you. How are you?

Jonathan:
I am excellent. Excited to be doing the Woo once again. We are joined today by Nate Stewart. He is the VP of Platform Strategy at BigCommerce. Nate, welcome.

Nate:
Hi. Happy to be here.

Jonathan:
And where in the world are you joining us from today?

Nate:
In Puerto Rico.

Jonathan:
How is the climate in Puerto Rico this time of year?

Nate:
It's great. You know, we just had a hurricane pass through and push a little bit of the humidity out. Now it's back to normal, everything's fine here. Other than that, it's nice and beautiful.

Jonathan:
Excellent. So Nate, you are not a stranger to the show. It's just over four years ago, episode 64, you were a guest on Do the Woo. A lot has happened since. What are you working on at BigCommerce these days?

Nate:
I'm working on, believe it or not, some of the same things we talked about, just in more elevated forms. Like, I think a lot of what we talked about last time was more of an ambition to support openness and bring open into the core of BigCommerce. Around that time, we talked a lot about how we're open SaaS, like we want to be the open SaaS commerce platform, the leader. And that was more of a future-focused vision of where we wanted to sit in the market, what we wanted to support. Now, a lot of that is reality. We've invested multiple years into making that true and that changes a lot, I think, in a good way, of how we work with the WordPress ecosystem, how we work with pretty much everybody's way of working. We want to feel like you enjoy and love and cherish a lot of different platforms and technologies and ways of working. And we want to be the platform that makes you feel at home because we trust that you have good taste and you like what you like because it has value. So yeah, all that has kind of become true. I'm really just making sure we get the most value ourselves and everyone else with that strategy.

Jonathan:
I recall. It's been great to watch over the years too, that you were talking about that then and there were some hints of it, but BigCommerce's public position, because you're of course a public company, that's a whole other game to be talking publicly about this open SaaS strategy. It takes time to carry this out. So it's interesting to see that it's like we had that four years ago, you were talking about it. Now you have a lot more evidence that you can point to. Your investment in the WordPress ecosystem is how many, like, is it five plus years now that you've been in this space? Before we had you on the show, you'd already been at it for a while.

Nate:
Yeah, I think definitely in terms of when the first couple of WordCamps, big and small, we were doing research and meeting the community. That was like six, seven years ago. It took some time to build the plugin, but a lot of that was just coming from, at the time, we had hundreds and hundreds of merchants that already had WordPress running alongside their BigCommerce store. It was like, wait a minute, where does this data take us if we keep going? So that led us into the community. And then, I mean, myself, I kind of fell in love with just how it felt almost like what it felt like as I learned the web and grew into the person I am. I was like, oh, this feels true to who I am as well. And I think that's just part of why I really fight to stick in any ecosystem where there's that truth there and that it resonates with people. It's not just a bunch of corporate marketing. There's value beyond it. So yeah, that's like six, seven years ago. It feels like a totally different world than six, seven years ago. But a lot of what stayed the same is kind of what I'm talking about, you know, at work and in the communities I'm focused on.

Jonathan:
This is a WooCommerce-focused podcast, right? And one of the things that I've liked about BigCommerce from the beginning is that you didn't have this anti-WooCommerce stance, but perception and reality are two different things. And I think early on, a lot of folks, like you had a product, your first plugin, for instance, was focused on more of this small business use case where BigCommerce… Well, let's start with this. How do you think about the WooCommerce ecosystem? Because you have competitors in the space. You compete with Shopify and other proprietary platforms, but with this open SaaS strategy, how is it that you think about WooCommerce?

Nate:
Yeah, I think about it as a major part of the journey for decision merchants looking to easily make their vision a reality. You don't start by coming onto a platform like BigCommerce and using every feature. You start many times with your marketing presence, with what you know. Some people are already blogging in WordPress and want to create a business, and it makes perfect sense to start there. So Woo is the first place that I feel most people should look because it's so well supported. It's just the default for that space. But then it's a journey, right? So at which part of the journey does either WordPress or WooCommerce hit a little bit of a snag, where at that point you're like, wait a minute, I need to get out of WordPress, get out of Woo. I don't think that's a positive decision. It shouldn't be binary. It should be, hey, what part is it working and how do you retain everything you put into it and add on for the next level of your growth? That's kind of the way I feel about Woo. I have a lot of respect for Woo. I feel a lot of really smart agencies and developers are creating really cool experiences in Woo. I like seeing that. I like seeing innovation in the space because it's open source, you can do that.

Jonathan:
And I think the key for me lies in that open SaaS strategy because we're no strangers to proprietary platforms that work within our space, like Jetpack and other products like it are proprietary and there's the SaaS component, but they're all in on the WordPress ecosystem. Whereas other platforms, like Shopify, it's zero-sum, right? They want everything there. It's like you're choosing Shopify, you're also doing the CMS and everything. And that's what stood out to me the most about the approach you guys have taken, embracing the choice. You want to use WordPress, you want to use WooCommerce, that's fantastic. We're here to support you. What's made it clearer, and you tell me Nate, is, as the years have gone on, your emphasis on the enterprise has made a lot more straightforward. Whereas early on, it was more of an overlay because you started out as a small business-focused platform. That enterprise shift has taken a number of years to get to this point.

Nate:
Yeah, I mean, I believe we're on the 15th year of BigCommerce being the name of the company. The backstory is a couple of years before that it was actually like you got the code and you ran it yourself back in the day. And it evolved into a SaaS platform, right? That was because early days, e-comm, it was much harder to scale and support by, you know, much greater, like, let's say 10X. I don't know the exact thing, but it just, you wanted, people were reaching out, going, I love this, but I want it hosted for me. And now hosting and other tech has made it to where it's less of a, it's more fuzzy between open and SaaS. And I think it's part of our journey. So we went from the code to SaaS. It was SMB only because in the beginning, e-comm days, we didn't have all the advanced features we have now. You built a cart, you built a catalog, you built all those pieces. But over the years, you get to where the people that need the most help with their architecture and functionality, they need way more complex features. You naturally get into mid-market and then enterprise. So we've kind of been on that journey, and because we've invested in the open strategy a while ago, it bodes well for enterprise, really well. Typically, that's what you see in any software platform landscape. The more enterprise, the more APIs they have, the more ecosystem. Whether you want to get locked into, I would almost say, closed suite versus open suite, you see a lot of those strategies in different ways play out. We are more of the open suite, you know, we want to make it easy to package. And that includes you want to use WordPress and you want to use WooCommerce in a different part of our product catalog, if you will, like our suite. We want to open up pathways to that for the enterprise, and even before that to where it's not a binary decision. It's what's best for you as you are growing.

Jonathan:
And I think a good example of that to me, and we can touch on it more later, is you have products that people don't know about, like Feedonomics, that have WooCommerce support built into it. It's a product that's focused on your product feeds out to various endpoints. And you could use WooCommerce in that. It's a BigCommerce

product. The last question I have for you on this topic before we switch gears: WooCommerce has a mission to democratize commerce, which is connected to the WordPress mission to democratize publishing, right? I'd love to hear your thoughts on what role you see BigCommerce playing in supporting that mission. How do you think about that mission?

Nate:
Yeah, one that kind of echoes six, seven years ago when I was kind of indoctrinated in the community, the whole 51% I think is maybe the clearest way we help to get to 51% of the web, which much of that is commerce. When you actually look at the longstanding site, I think right now what happens, the trend I've seen is when you start in WordPress, you layer on WooCommerce, and then when you hit that decision point of, well, maybe it's not as fast as I wanted, or it's getting complex for the different plugins and the agencies I'm working with are quoting that I should migrate off to something else. It's at that point where if we make it easier to just uplevel the pieces of your WordPress stack to keep you on WordPress as you evolve, then both WordPress and many times Woo benefit from that. That's how you get to the 51% and more. You find those strategies in the WordPress community where there are partners like us that go, hey, let's keep that stat. Let's keep building it together. I want to see a world where WordPress goes beyond 51% and we are a part of that journey and celebrating together, knowing that we're talking about a journey here, not a one-off decision you make when you have a new problem.

Tammie:
I'd really like to move us from that. You mentioned the toolkit, the suite, and we looked at how we have this kind of blue. I want to consider the space for commerce and builders. You mentioned this suite. What has been the most exciting thing to explore and experiment with product-wise lately? You mentioned layers and complexities, but what does that feel like building in, and how have you been exploring and building in that? What have you been exploring and building in that even? That's a big question.

Nate:
Yeah. One of the things that I mentioned earlier, we had hundreds of merchants back in the day, which led us in the direction that were using WordPress on the side, meaning they had their site and then a shop dot. Now because of the plugin, but also because of things like headless and composability, it's more nuanced than that. And now with the Gutenberg editor, it's been this way for a while. You have blocks and whatnot. You can go, wait, if you already have your marketing site up there and you want to layer on commerce and you're already closer to the mid-market enterprise, right? Because you maybe have a big B2B business and you're going to B2C. So you're already at scale with complexity. Well, I've been plugging with a team a little bit around how would we integrate Gutenberg and existing stuff that you have, you made a decision like your theme and your blocks, into our open-source storefront framework that we built called Catalyst. That way, you get to retain what you built on WordPress and via the Gutenberg kind of standard blocks. So to me, one of the interesting things here is how, and this is an area I'd like to work more with people to solve. Blocks are almost there. The API, it feels in any like the WP GraphQL and REST, you can get to the point where it feels like it should work 100%, but you run into issues in actual live implementations where, okay, there's not really a standard where you can go from WordPress React into static or into now with like Next.js and the newest app router, React server components, how you transition from, I get this block, it's a form plugin, I have this type of React running on my headless instance. How do I make it work to where on the front end of the editor it works and then WordPress? I want that to look and feel the same way. That actually gets very complex very quickly. And I think whoever works in solving that problem where we can get there together will radically improve how people are using Gutenberg, how we work through these migration strategies that don't push you off of WordPress and off of Woo, but go, hey, this block works well for you here, this block is not performant, should we go headless? Should we just replace that block? Anyway, I've been plugging away with the team about that, working with several different agencies in this space to go, what's your opinion? And yeah, there's a lot there. I think Gutenberg is really cool, and personally, even on the weekend I'm hacking around occasionally, you might see me going like, what's the new thing? But it's funny how, I mean, it's been years since it was released and some of those pain points are still there, right? We have to ask ourselves why. If they're migrating out because we don't know how to use blocks, that's not even a core commerce thing. That's just in general, I think that more could be done there.

Tammie:
I like how you're kind of touching on it by what you are saying, which is you never, you don't find those, I always call them stress cases, not edge cases because they cause you stress when you hit them rather than them being edge cases because they might only be for one person, but it could be really important that that one person hits them by the experimentation. So I think one of the answers, and it's one of many, is people haven't maybe explored some of these combinations. So that's what really, for me personally, and I think a lot of people, is curious about these experiments that you're doing. But I'd love, in what you've been creating in your own experiments, how have you discovered this to be uniquely different to building this space? Because it is a little bit uniquely different, these stacks, like you've shared about the complexities and the layers, but it kind of is shifting sands a little bit in places. What are some of the other differences that you've thought about as you are creating these spaces?

Nate:
I think one that, again, this is more of a background thought the whole time. One decision we made early on was to do it 100% the WordPress way. And we, everything being in the community and the research and all the agencies and builders we talked to, they're like, there's the WordPress way, you build the template, it's PHP, all of that. Gutenberg was happening as that. But no one really, it's almost like people didn't want it to succeed. It was a very weird feeling, but we got over that hump overall as a community. But during that early, you're talking like six years ago plus, that WordPress way kind of limited us in terms of what Gutenberg was really trying to accomplish, which is being more modular, being more JavaScript-forward, React-forward. So now I have this, again, it's a background thought of instead of, you know, the plugin being like the WordPress way templates, being more components by default, it's really just React as the page loads reading out from an API. And yes, there's a downside to, you know, you don't have things in the table in the options table and other aspects. There's maybe a loading artifact a little bit there where the page loads and then it reads the data. But the benefit is you are fully compatible with the static hosting trend that's happening in the WordPress space and overall web development in general. It actually forces you to polish your API on your other end a lot better, making sure that caching and just performance in general is better at the API level. So I feel as a platform that is integrating that mode makes your product better for everyone by integrating that way. So I've had that thought come up a lot. The downside is there's effort there to change, and there's also feedback from the community where there are millions of people that love the WordPress way. And there's the thought there, and what does the WordPress way even mean anymore? I've had this thought of it, isn't it Gutenberg? Isn't it blocks? So yeah, all that.

Tammie:
I think it's fascinating that the WordPress way, maybe it should be adapting. Maybe the whole point about the WordPress way is that it isn't a fixed way, and we maybe thought it was like chiseled, and it wasn't chiseled. I think this is such a fascinating discussion. I want to skip back a couple of steps to something you were saying because you very clearly have an understanding of builders and you very clearly have an understanding both from your own tinkering, I love that word, and exploring. So that translates into what is being created. And I think that is incredibly important when you are creating these suites and trying to also create tools. Can you explain a little bit more how that translates into the products that you are offering as well? Because I think there's something in there as well that we've been talking about and getting super excited about the API and the experiments. But how does that then translate into the products?

Nate:
So I think we're really in this multi-product territory now. You can't be truly open if the only way to get value is to combine everything the same way every time. That's not open. That becomes closed in general, like entering the walled garden. And so I think what we've evolved over the years is formally, we've made acquisitions as a company. You mentioned Feedonomics, they're doing very well outside of the BC ecosystem as well as in. They actively support all of our competitors, all our commerce competitors. When you go to feedonomics.com, it's very hard to find any mention of BigCommerce. It's very much its own product offering. Because we're underneath the same umbrella, we work under the same constraints of, okay, when we need to ship a

feature and it's using their technology, we build like a partner would, right? We don't have internal things that are cheating. That helps everyone and helps us keep an honest open strategy. That's why Woo fits into their strategy in a big way. They have many large WooCommerce customers and they have kept them on Woo and WordPress, and that's okay because that product still grows their business. Let's be honest, it's easier to keep people happy if you don't go into their house and say everything's terrible. You can make comments, you know, they might not like the couch, but you don't tell them to move. They like their community, right? Another example of this is Makeswift. They're a recent acquisition, again, an independent company still like Feedonomics. They are a visual editor for Catalyst and our next-gen storefront. However, if you want to use Makeswift with WordPress, with WooCommerce, with any of our commerce competitors, they don't become a competitor. If you like Makeswift, you're not ready for BigCommerce, you've invested a lot in your current stack, that's fine. There are interesting things with Makeswift because it is composable by nature. It is built from the ground up to support the latest in React and React server components, all that where Gutenberg is more of the default. It is React and the new way, but its APIs and all aren't in the same ecosystem. You could technically use the Gutenberg API in the Makeswift visual editor and get the development flow you want while still retaining WordPress. It's almost like WordPress as I know Jonathan you said in the past as the operating system. It has the API. There are all these interesting things that can happen when we're multi-product. We're not single platform where you buy it as a product. I think that's one of the ways that we enable builders in a different way, and each of those separate products have different APIs and ways you can utilize them.

Jonathan:
One of the big switches over the past couple of years has been this increasing emphasis on enterprise, right? That's the transition that you've been making. Multi-product is a good example of how you carry out that promise. You're giving flexibility, especially in the enterprise, where that flexibility matters. They may have policies for using this or that, or they want just a piece of it. That's a good example. Let's talk about enterprise more and start with this: how do you define enterprise? What is that definition within the BigCommerce context?

Nate:
Yeah, for us, the way we define enterprise, it's more like the size of their annual revenue, their employee count, it's a blend, and they're opting into being a part of our enterprise plan. It's nuanced because typically you have a lot of platforms like products out there that are like, we're enterprise or not. They come in and it's like, okay, they have to be at a hundred million in annual revenue, they have to be XYZ. What we've found is you could have someone with a tremendous amount of revenue and they are very efficient because of the type of product they sell. There are DIYs and a lot of owner-operators, if you will. I believe there are a lot of those in the WordPress ecosystem. It's known for that. People say, I'll do it myself and I actually know how to code, design, and operate it. But that means why should they always pay the price for all the complexity of enterprise when they can handle a lot themselves? They might pay us a little bit less, where they're not super enterprise, but they're paying more in other ways that other people might not be able to pay, which means they're putting in the blood, sweat, and tears to code and design themselves. But that persona, while they might appear more mid-market in terms of how they're using it, they are an enterprise in revenue. We like to make it a real conversation with the brands we serve and everyone involved, where do you want the complexity to be? At the upper level, we handle a lot. Once you get to enterprise and you're on an enterprise plan, we handhold a lot more, we're a lot more with you building, helping you build, up to the point where you have dedicated people at certain levels of building your business. Some people might look at that and say, yeah, I know I'm generating a lot of revenue, but I don't need that level. My personal opinion is everybody needs help and it's going to make you sleep better at night when you have someone in your corner. But that openness goes into, well, let's have a conversation. It's a fuzzy line for mid-market and enterprise. High level, you're talking like 50 million GMV, 25, around that territory, very clearly enterprise. It's very rare for someone to opt out of that.

Jonathan:
This is where I get excited, looking at this through the WooCommerce lens. One of the risks we've seen over the past couple of years is people grow in WooCommerce, they like WooCommerce, they like WordPress, and then they start to hit the edges. There have been some great agencies, many of them coming onto the show, who've pushed the edges of WooCommerce and have innovated and figured out ways to make it scale further. And there's also this feeling like it wasn't designed for that. It's an SMB-focused tool. While there's a lot of room for growth, one of the things I've been intrigued about and been hoping to see more of is what it looks like to bring that enterprise capability from other players into the WooCommerce space. I think Feedonomics is a good example of that and would love to hear more about how you think about that. How can we, in the WooCommerce space, more successfully bring in enterprise capability? My hypothesis is that we can't do it by just changing the core product because we have millions of store owners that count on that SMB approach that WooCommerce has taken. That's the question. Right now, when people hit a certain point on WooCommerce and start to feel the edges, I think there's a churn risk where people feel like they just have to leave entirely. My hypothesis is that doesn't have to be the case. That's where I see this opportunity with partners like BigCommerce being able to augment. How do you think about that? What would that look like practically?

Nate:
Practically, this is one case where being multi-product and having these independent companies that think about each ecosystem, they understand the APIs and aren't filtering it through the BigCommerce lens. It means the Feedonomics team, the product knows how WooCommerce works, has a dedicated integration with them, and has been through this process day in and day out. Someone calls up going, hey, my sync, I have these plugins that are for my sales channels or advertising channels, and I'm getting to the point where it's slowing down my site, or I don't know how to support adding any more. I want to add five more channels. Keep in mind Feedonomics supports like 300 plus, maybe 400 plus, hundreds of sales channels. When things happen, like Target has a marketplace, you'll hear our competitors make big announcements about it. But the reality is because Feedonomics is wholly dedicated to that, they're working with Target and other marketplaces as the alpha of when they release functionality. There's a huge benefit to going, all right, I don't need to change WooCommerce at all. I'm already selling on sales channels. Let me get an easier-to-maintain site and way more sales channels. But again, you have to make that choice yourself, or an agency or developer working with a merchant. There is a cost, of course. It's an open SaaS platform, but it is a SaaS platform. It's a transition from a free plugin that I just have to pay someone to maintain or keep up with updates. It's that cost transitioning to dollar cost, but you get the time back and peace of mind. It's really that type of process. That's why enterprise comes in. People coming in from, let's say, they have half a million, a million in GMV, annual revenue, that's probably not something that Feedonomics power is necessary for. You can just optimize Woo and the sales channels. But if you have questions like, I have 3 million in revenue, I'm growing faster than I can update, I have ideas and ambition to go into 10 more channels. Even if your site is working, if you can't rapidly add 5, 10, 50 advertising, sales, and whatnot channels, and that's your ambition, that's when the right time is to talk. Again, it's the journey. We talk a lot about the right journey and the merchant journey, having the right time, right place, rather than going, there's one solution that fits everyone.

Tammie:
I'm going to pivot towards the end and imagine we're kind of dreaming a little bit. We spoke about the past four years, but it's panning away from products. There's so much going on in this space, so many emerging trends, technologies. Let's think initially for commerce builders, what should you be keeping an eye on if you're building in this space now and in the next year? Then we can kind of get a bit dreamy after that.

Nate:
I've actually seen a lot of different podcasts and articles about this topic in this space recently. Static, and again, I talked about how does Gutenberg in the WordPress ecosystem play with that. Not static as just the end goal because why not? It's fast and we should do it more. I think that will improve WordPress as a platform and other platforms integrating with it. If you think about the right separation of concerns and how the technology enables both approaches cleanly. As a builder, going, I'm building in a way that works for WordPress and its out-of-the-box state and WooCommerce's out-of-the-box state. What happens next? Someone wants to go static, they want to use

Next.js, what do you do? Is what you built cleanly able to support that? As we think about our architecture and design of APIs, supporting both is better for everyone. It'll create more opportunity for you as a builder, better for the end user. They're more likely to stay in the WordPress ecosystem with what they built before because it can be translated into what's next. A lot of what I'm talking about, we think deeply about composability and it's almost a part of everything strategically that we've worked on recently and will work on in the future because of that reason.

Tammie:
I definitely align to that. All too often, before it was generally just like commerce, what does the front look like, and how do the transactions happen there? But now it's kind of flipped in that sense. I'm going to flip that question though as well, segue. What buzzwords or tech should commerce creators avoid? Because I think there's so much, as you were saying, there's like podcasts and it can be really easy to be distracted or pile your feature set too high so that you then get problems. What makes your eye roll when you hear about someone adding and you're like, you don't need to add that, it's not going to work, it's not going to help someone?

Nate:
Yeah, I definitely think my eye rolls a bit when it's AI without purpose. I think that's kind of a softball question because a lot of people might say that. But what I mean with AI without purpose is if you're chasing a perceptual win where it's like, hey, I can have a chat interface here or look, you could ask it to do a theme and it does it. I feel like that's removing research and analysis and understanding of the user from it. That's just trying to achieve an end goal. Almost like what I said about static, don't do static just because you hear a podcast about static. Do it because you understand the value of being able to transfer from one type of architecture to another. That changes how you build your thing. AI that has a purpose, like, okay, we've researched exactly how people are using our themes or integrating different APIs and we have a focused use of AI that's tailor-made to accomplish that task or series of tasks faster. That's awesome. I see a lot of people just layering it on. Especially in business, a merchant layering on random AI chat stuff, is it better than ChatGPT? Are you just trying to get a brand for yourself as a builder? I'm not discounting, some people that's great early in your career, write up something and create and be like, hey, look at me. I know how to hit APIs for AI. But the reality is, does it make someone's life better? And if it's just a cool toy but it doesn't make it better. That's the difference. I'm not saying I know the answer perfectly. I had to look in the mirror and eye roll myself if I'm heading down. But if we just layered AI on top of that, we're all capable of running into that peril of all I need to do is layer x feature or tech and it will solve my entire business.

Tammie:
I would plus one that so much. I think it is so easy to AI, is it a workflow or is it AI as well as also that thing? Does it get a hurdle? Okay, the last question I'm going to ask here though is kind of, it kind of segues the end of this. Four years from now, you come back on the podcast, what do you hope you have seen? It feels an inevitable one if we're talking about the future to give my last question. If we're talking about the future, I would say there are a million viewers or listeners of this podcast and you invite me back for some tropical villa special edition thing. I know that has nothing to do with technology. I'm just trying to put out some optimism and let the universe make it happen.

Jonathan:
I think Bob's been talking about that, starting to take the hosts and putting us up. I think we're going to get there.

Tammie:
Thank you, Bob. If you do it a year, Bob, I'd like some puppies if we're doing that, that's fine.

Nate:
I am trying to think about four. I feel kind of echo back on being able to celebrate together, getting WordPress. I don't want to say modernize WordPress because I think WordPress is, people don't give enough credit for modernizing as it goes. I actually think a lot of people have learned from Gutenberg without admitting it in other ecosystems. Modernize is the wrong word. It's more perceptual. I think switching what people feel in the community and an internal perception of, hey, we have modernized, we've been through the pain of bleeding edge, trying to learn this stuff and into the rest of the planet by default going, okay, WordPress is in your stack, that's great for these areas. Having a real conversation around it. Leveling the playing field with headless CMS where a lot of people had for years been using WordPress as a headless CMS. We're not talking about the full journey, it's like, which way are you using it with other parts of technology to get the most out of WordPress, out of WooCommerce at that stage. If in four years we're having real conversations around that and we've done the technology work, everyone is better. That's how you get to over 51% and beyond. It almost becomes like we're, it's not like WordPress, it could be, and again, I'm ripping off Jonathan, the WordPress as an OS. You think about Windows, Mac, iOS, all those different things. It's close there now, but these things have to be solved to know how you interoperate and have all the standards where it doesn't have to be like every use case is in WordPress. WordPress has to win at every stage of the journey. It has to be where you can hook in and out and get the most out of WordPress. It almost becomes a utility like an operating system long term. In four years, that's happening. There will be so many more people using WordPress actively that we probably will be on a tropical villa for that episode because there will be so many new ideas and innovation there. I hope to be a little bit part of that journey.

Jonathan:
It's interesting because we've been on this trajectory for a long time. Gutenberg, it is interesting to look back now. At the time, there was a lot of, I would argue that the work that Tammie and many others have done on that transition was in fact the WordPress way. What we see today with themes, we added all this complexity to themes in the WordPress space and now we're getting back to how it was originally and things are getting simpler again. It takes a long time though. This vision of WordPress as an operating system for creating on the open web, I think we're seeing it play out more and more. E-commerce is a great example of people building and saying, hey, I can create on the web, I want to add business into this context. I really appreciate the work that you guys have been doing at BigCommerce to recognize and be a part of that. That open SaaS strategy fits really well into that. What we see in the future is WordPress just being a ubiquitous part of a stack and a foundation that people can feel like, hey, I own this. It takes a long time though to catch up and bring that parity, features, and ways of doing things that builders need to be able to create confidently on it. Right now, it's the people who really believe that are making it happen. That includes folks like yourselves investing into the space. Thank you for that. I look forward to seeing what the next four years bring. Nate, if anyone wants to connect with you further or learn more about what you guys are working on, what's the best way to get in touch?

Nate:
On LinkedIn, Nate Stewart, search for that. Also Nate.stewart@bigcommerce.com. Feel free to email me. I'm not really on Instagram randomly taking pictures. I missed that whole thing. Definitely missed TikTok. I have an account on now X but I probably won't actively respond. So LinkedIn and email. We also have our developer community. If you are a builder and you go in there and ping me, it's a private community that anybody's free to join. You go to developer.bigcommerce.com and go to the community section. We actually have a WordPress channel there that you could join in. I would love to see more people talking about how they're using WordPress in our community. Or you could just reach out personally. Like I said, we're working with a couple of agencies and leaders in the space just to think about what the future is here. The more voices we have that are stress testing that, the better it is.

Jonathan:
Excellent. We'll also look forward to seeing you at future WordCamps as well. Nate, thanks for coming on and talk to you soon.

Tammie:
Thank you.

Nate:
Thank you.