The Challenges of Hosting Difficult WooCommerce Sites

Zach (00:00):
Everybody, and welcome to another episode of the Woo Dev Chats. As always, I’m one of your hosts, Zach Stepek, and I’m here with my co-host, Carl Alexander. Carl, how are you?

Carl (00:11):
I’m good. I’m into future now. I’m in Tokyo, so it’s Friday now.

Zach (00:16):
Nice. It’s always good to be in the future. Right? So what brings you to Tokyo this time? Just relaxing.

Carl (00:24):
I was here just for myself, but also I was working at Tokyo last weekend, so that was kind of fun. I got to meet a lot of the organizers for WordCamp Asia, the Taiwan community. And yeah, I mean, for those that didn’t know, I was shocked. But the Tokyo Work Camp used to have 1,100 attendees that’s even bigger than the Miami one, which I thought was the largest work camp since it’s actually an insanely large community. And their WordCamp ticket, it was mind boggling. Their WordCamp ticket was 2000 yen, which is about $16 us.

Zach (01:10):
Yeah, that’s really low.

Carl (01:11):
Yeah, they had 30 something sponsors. It was wild. It was wild. It was a lot of fun.

Zach (01:18):
That’s a lot of sponsors. Awesome to see that much community involvement and sponsorship in Tokyo. My understanding is that the community over there is great. So

Carl (01:31):
Yeah, they’re awesome. I had a great time.

Zach (01:33):
I’ve met a few people who have come over for us and they’ve all been very kind, very down to earth and very interested in having all of us come and visit them. So I think that’s awesome that you got a chance to do that. So today we have a couple of special guests with us. I know we never have special guests, do we? No,

Carl (01:57):
Never. I have never. It’s

Zach (01:58):
Always just Carl and I rambling on. Correct. So today we’ve chosen to focus on the topic of hosting difficult WooCommerce sites, and I couldn’t think of two better people to invite than Ben Gabler from Rocket.net and Tom Fanelli from Convesio. So why don’t we start out, Ben, with letting you introduce yourself.

Tom (02:29):
Yeah, thanks for having me. My name’s Ben Gabler. I’m the CEO and founder of Rocket.net. I’ve been in the hosting space about 21

Zach (02:35):
Years now,

Tom (02:36):
So going strong.

Zach (02:38):
That’s awesome. And Tom,

Tom (02:41):
Hello everyone. My name’s Tom. I’m the CEO and Co-founder of Convesio. And just hearing how long Ben has been in the hosting space is making me feel old. So I’m not going to say how long I’ve been in the space, but a long time.

Zach (02:54):
That’s awesome. And both of you have in recent years started hosts that have made a significant impact, in my opinion on the hosting space, do things a little differently. So I don’t want to spend a lot of time on sales pitches, of course, but why don’t we talk just briefly about the key differentiators that you feel each platform has. Tom, we’ll start with you first and then we’ll go to Ben.

Tom (03:25):
Yeah, so we are squarely focused in what I would call the mid-market of helping people scale hard to scale sites. This is e-Commerce. Our typical customer has somewhere between 2000 to 70 or 80,000 orders per month. They’re high growth stores, membership sites or LMSs online learning with lots of concurrent users. And so we have pretty much shaped our business and team around helping end users that have those sites and agencies that work with those sites. And we have a team of experts at scaling those type of sites and a platform that works for those sites to scale. And so that’s really what our focus is, is providing an amazing experience for that niche of people.

Zach (04:21):
Awesome. And Ben?

Ben (04:23):
So our approach was a little bit different. Some of the things that I noticed when I launched the business was everybody out there was touting the same thing, Google Cloud, Google Cloud, Google Cloud containers, this, that and the other. And Rocket broke into the market with an Edge first strategy. But ultimately part of that strategy was eliminating the bottleneck of the network on some of these resources and localizing a database server. And just kind of even going back to basics, similar to what I did when I relaunched all the hosting at GoDaddy, what we see with WooCommerce as an example is we have yet to see something actually need more than a single server for that. But really the bottleneck is coming down to what we see at the core fundamentals of how WooCommerce and WordPress are built to leverage MySQL. And to give you an example there, which I’m sure we’ll get into this during the call, but what we see is somebody will have a hundred checkouts a minute or a second or whatever it might be, but let’s say their merchant gateway is taking 30 seconds to process a payment and at that point they’re doing a lock on the database and it’s unable to process any other orders because of the inventory management.

(05:38):
So we’ve seen a lot of that. So we’ve just continued to kind of focus on how we can innovate in the space to alleviate some of those issues on the stack. We recently brought on Dave Costa as our CTO, and him and his brother created a little piece of software called cPanel. So I think we’re taking a really heavy SaaS approach to what we’re doing and looking at how we can solve some of these critical pain points when it comes to scaling.

Zach (06:08):
So here on the Woo DevChats, we tend to focus on the issues and things that developers deal with. We’ve talked a lot about scaling. We’ve talked a lot about things like high performance order storage and the future of WooCommerce in those spaces. We’ve talked about subscriptions and had somebody on that has a large subscription site that has all of the renewals happening on the same day. So we tend to talk about those pain points. And I wanted to give an opportunity for each of you to kind of share a story about one of those pain points that you’ve seen yourself with a WooCommerce site and how you resolved it.

Ben (07:02):
Sure. So I’ll jump in kind of tailing off of what I was talking about earlier. We had an enterprise customer and no matter what hardware, the hardware would be running at 5% utilization, 96 cores, you name it, NVME storage. And there was still this bottleneck on whenever a large sale had happened, and we finally threw some APM on there and figured out it was the merchant gateway in Brazil taking 30 seconds to process a payment. So what would happen is as soon as the first person clicked purchase a complete order, it would lock the inventory. So therefore, every other PHP process would just stack and stack and stack and stack because no matter what you do with MySQL, if that’s the way it’s built, there’s no getting around that. It doesn’t matter what you do. So our recommendation and what we’ve seen is incrementing and decrementing inventory in different ways.

(07:56):
So when somebody adds the cart, decrement the inventory right then and there, right? It’s an instantaneous call for the most part. And you can add some sort of time limit on it. So if that checkout doesn’t complete in 20 minutes, 10 minutes, whatever it might be, it’ll just add it back to the inventory. So there’s different ways to go down the rabbit hole to solve some of these things. But I think ultimately some of the conversations we’re having with Core, especially now with Dave on board, is, Hey, instead of SQL light being an option, why isn’t there just an ORN, right? Why can’t we use CockroachDB or something else to start scaling WordPress cross region and kind of keep up with different ways to handle asset compliance and things like that. And the biggest challenge I would say is you get into all these different stores.

(08:45):
There’s some customers we host that solve that problem already, but then they ran into different problems. There’s all kinds of little things and ways that you can even tweak what happens in a stock WooCommerce shop to even reduce some of those PHP calls to begin with. But the real challenge I think that’s happening and why we’re seeing a bleed to Shopify right now is sort of that MySQL dependency and how some of the default behavior works. Because I don’t know how many of the developers on WooCommerce and the contributors are working with large volume stores. If you’re solving for the local business selling T-shirts here and there, no big deal. That type of delay on inventory at checkout doesn’t really matter. It’s when you get into the high volume stuff. And that’s one of the pain points that we saw that ended up coming down to a fundamental way the software works.

Tom (09:43):
And I would say that the vast majority of core WooCommerce code is extremely performant. If you take, we’ve done, we do a lot of load testing in our world, and if you throw up a default WooCommerce store with no plugins and just everything set to default and a strike gateway, you would be shocked at the amount of orders you can process with very, very little CPU and memory overhead. And both Ben and I, our companies implement all of the latest, greatest, best practices with Redis and Relay and Object Cache Pro and edge caching and all this stuff. The problem is when you start having so many plugins needed and people have, usually what winds up happening is when people were small, everything works fine. And then when they start to scale, they’re like, what the heck is wrong? And it’s always like, it’s WooCommerce’s fault.

(10:50):
It’s not these hundred other plugins that I’ve got running. And I’ll give you just an example to your point on your question. We have a guy that’s got a large membership site, actually the biggest membership site in Africa in the French language, and he had a lot of growth and one plugin that we disabled, one of my favorite plugins, and it’s like that plugin, and I won’t fault the plugin people, but here’s the thing with this plugin here allows you to do things. It’s one of these, if this happens, do this type thing. And you can do some really, really bad inefficient things with that plugin. And you can tell it to say, Hey, I want to scan my entire post table to find anything like this and put a wild card search in it. And if you’re doing a lot of functions at once with that, your site’s going to come to a crawl disabling that one plugin took his load time from eight seconds to four seconds.

(11:52):
So that one example of how people customize with plugins or customized WooCommerce or their theme that is just bad for performance and you don’t notice it until you start getting scale. And that’s why it’s really hard, as Ben said, you can throw as many resources as you want, is this, you’re not fixing this with resource more resources. You have to dig into the code, use New Relic APM, look at what’s going on and make some decisions to cut some stuff or change things. But I thought that the traditional way to do this, from what I’ve been told by other hosts in the past is to throw more bare metal at it.

Ben (12:34):
Well, I mean, that’s where you start to get down to the root cause of the problem. So it doesn’t matter if you have a thousand GPUs running your WooCommerce or if you’re locking a table, there’s nothing you can do about it. And to Tom’s point, it’s not that uncanny is a bad plugin. I always like to say one of the best things about WordPress is there’s 10,000 million plugins. One of the worst things about WordPress is there’s 10,000 million plugins, and it’s not even necessarily, I’ve seen sites with 40 plugins that run fine. I’ve seen some with 17 that are super heavy. RP is another example of a plugin that just does these insane queries that are all these joins all over the place on unindexed tables and it

(13:25):
Works for a site with five pages and then you throw it on a site with 200,000 pages and it’s not going to work. So I think part of what we should be focusing on is we’ve seen a lot of our enterprise customers, and it’s not because of us, not because of Tom, they just get frustrated with it. They’re like, we’re just going to Shopify at this point. We’re wasting so much money on DevOps or developers or resources. Screw it. We’ll give the revenue to Shopify and be done with it. And some of them come back because they have different limitations over there, but some of them don’t. Some ’em just get frustrated and they’re over it. So I think that’s where I think it’s kind of time to look at this tech stack and really start from the ground up with the database. So Tom’s point, the code’s amazing. It’s always the database and the disc that’s going to be your bottleneck no matter what. But there’s modern systems out there that we could solve that with. It just may not be MySQL.

Carl (14:24):
I mean, e-commerce is always hard. Magento has struggles with the same issues. It’s what they call the eav, right? Entity attribute value. That’s the main thing. It makes it super flexible. That’s what basically post metas are.

Ben (14:43):
To be fair though, I mean if you look at Magento two, everybody that was at Magento, one user hates it. And the main reason is, number one, they’re trying to close the ecosystem and make it their hosted cloud or whatnot, sort of like a Shopify, but two, I mean now it’s like Adobe Commerce. I think they rebranded it so Adobe Commerce now, but there’s like 16 things you have to do. You cannot run it without Redis. You cannot run it without Elasticsearch. So on one hand you’re like, this is super annoying. I’m never going to go through this process. But on the other hand, they know that there are systems there that need to be in place for it to effectively scale. Shopify has got elastic, they’ve got Redis, they’ve got everything, and

Tom (15:22):
It’s just there. Right. Well, one thing I’ll mention too is I was having a conversation with some of the WooCommerce leadership at, we’re camp us and I like to stay close to the customer. So I had this lady who came to me and it was a good cause and she had lost her web developers and she was sort of half pregnant with this WooCommerce store. And I said, I’ll help you finish it. And I was like, I’m going to personally help you because I haven’t built a WooCommerce store in a while. And I was like, I’m stripping out plugins. I’m like, this thing’s going to be super light and super fast. And I got down to these are the five plugins she needs. And she’s like, okay, great. Now we need to add this and now we need to add this and now we need to add this.

(16:04):
And I’m like, what the hell? I’m like, none of this stuff is core functionality. Packing slips, for example, is not a core functionality in WooCommerce. And I’m like, why do I have to add a plugin for something simple like packing slips? So it’s like all of this stuff requires us to just pile up more and more and more plugins. And unfortunately that builds sort of this dependency on, I’ll just add plugins. And that site, which I had such high hopes for of being super lean now has a dozen shipping plugins because they have to do all sorts of different carriers and different weight classes and shipping. And it’s just become like we have dozens and dozens of plugins in it. And it’s like you cannot do this stuff in WooCommerce core. So one of the things I think we need to do is just start to embrace more out of the box features in core that lessens some of the dependencies on very common things that stores need to do

Zach (17:09):
Well. And I think it’s a matter of, it’s the Spider-Man dilemma, right? With great power comes great responsibility, and we have the ability to configure WooCommerce to do pretty much anything it could ever possibly do, but having that level of power means that we also need to be careful how we use that power. That’s really what it comes down to In almost every case where I have seen performance issues in a WooCommerce store, apart from inserting 50 order meta for every order, which is just part of core and they’re fixing, but apart from that, in almost every case, it’s decisions that make the site slow. It’s not WooCommerce itself. And so once even at large scale, hundreds of thousands of orders a month, WooCommerce can handle it as long as you can get around that one bottleneck of orders. Right?

Ben (18:18):
And to be fair there, I think one of the pieces of low hanging fruit is archiving orders, cold storage. So imagine just having a configuration that says when an order is 60 days old, put it in cold storage, and I don’t care if that search takes 10 seconds, no big deal, and keep my hot table nice and light. And that’s one of the most painful things whenever I log into one of these stores when they’re asking for help is it’s just like, man, it takes time to look up and order a page no matter what stack you’re on, just because it’s number one, are the tables indexed properly? Probably not. And number two is just, it’s a lot of data and a lot of joint, a lot of data all over the place, right?

Zach (19:03):
Yeah. It’s funny, one of the first optimizations that I saw made for WooCommerce was disabling the order count in the admin, right? Because that count took so long that it slowed down the entire admin. And so that was one of the first optimizations that I started to implement was removing the order count.

Ben (19:24):
Makes sense.

Zach (19:25):
So Carl, you’ve been relatively quiet. Our guests have lots of great information, but I have an opportunity here for you to ask a few questions as well.

Carl (19:35):
I mean, I’m just listening. I mean, I’m kind of in the same boat, right? I’m working with agencies trying to scale WooCommerce. It’s a hard problem because the use cases vary so much site per site. I mean, we’ve discussed it a bunch of times on other podcasts, but you can have a site with three products and they’re just going to do tons and tons of orders, or you can deal with sites where they have a million SKUs, completely different scaling problems. So I’m just really interested in hearing how everybody’s tackling. I think all three of us have different approaches to how we want to do it, but it’s just interesting to, I mean, I don’t really have that much more to say. It’s always the plugins they scale in weird ways. It’s not necessarily the developer’s fault. It’s hard to predict how your code’s going to behave at scale necessarily. So even in my case, it’s just tricky to just figure out what are the break points and how to fix them or optimize them.

Tom (20:57):
I have a question for the group, if you don’t mind if I take over the host role for a second, Zach and Carl. So I’ll give you an example of something that just came out and we got friendly with MemberPress at WordCampUS, and those are great guys over there. And we happened to have a joint customer who had a really big scaling event for her client, and they were on another host and had crashed every year during this big sale day. And one of the big questions I want to ask the community, and I’m going to give this as the case study of how we should do it, but I guess I want to know who do we think should be, who’s the person most incentivized to solve this, right? Which is plugins have to test and optimize for these higher scale stores, but they’re not super motivated because it’s a very small group of people and there’s usually no monetary difference between a plugin selling their product to a store that’s doing 200,000 orders a month versus 20 orders a month.

(22:05):
So what we did with Member Press is we brought them into Slack. We have the agency in Slack, and we were winning this deal from another host. So we’re like, we’re going to load test this site. Tell us how much you traffic, you expect to get it used an insane amount of resources. We narrowed it down to one of the MemberPress plugins. It was an integration plugin between Beaver Builder and MemberPress. And the function of that plugin was to check every page when it loads if it had member restricted content on it. So every time a page was loaded, whether or not there was any, it was a public page. No matter what it was, this check was running, disable that plugin, the load cut in half, transaction time doubled. It was huge. We relay all of this in a nice little package to member press in less than 24 hours, it’s fixed. They’ve pushed a release, we’re ready for our customer’s big event. That is a great example of how plugin manufacturers and hosts should be working together. And I think it’s on us because quite frankly, we’re probably making a larger amount of money off of this than the actual plugin manufacturer is. But having those communication channels, having a plugin manufacturer who’s responsive, most of these people, you submit problems, they don’t do anything about it. They’re not even responsive to these issues or it’s

Ben (23:35):
Point the finger, right? No, it’s not us, it’s you. No, it’s you, not us,

Tom (23:39):
Right? Because it’s like, oh, well, maybe we’re used to dealing with a hosting company that pointed the finger at us in the past. So what can we do as the new age of hosting providers to get plugin manufacturers to partner with us, listen to us, give us time and energy and help us fix this? Because it will level up so many people because Ben, and I’ll probably both tell you, we see so many different use cases for sites. It’s crazy. We see many, many more times than what agencies see because we’re working with a larger pool of customers than a typical agency. And so there’s value in that, our perspective, but it’s like we got to get people to listen to us and take our feedback and input seriously.

Carl (24:23):
Yeah, I mean, I do similar things as you I communicate with, because my architecture is even more

Tom (24:32):
Right out of the box.

Carl (24:34):
It’s immutable. So some plugins, I have channels and I talk with them, but obviously some of it comes to scale. I’m not a significant scale to matter, but I think some of them are open some of the time I do the compatibility myself. So if they have the filters, I do, the compatibility changes myself. But it’s getting that kind of communication that I think is the proactive thing to do. I think that’s how we get everybody to have a better experience and a better,

Tom (25:17):
I think the challenge is how do you scale that, right?

Carl (25:19):
Yeah, I know. It’s insane. Yeah,

Tom (25:22):
We can’t do it, right? We’re about to hit 5 million in revenue at Rocket, right? So we can’t sit here and spend the time trying to with how many plugins there are. It’s very difficult. Now with that said, where I think it gets interesting is next week I have a call with Mark Westguard at WS Form. And I think with Tom talking about MemberPress, I think what needs to happen more than anything is I think some of these plugin contenders need to really start to get more of an open mind around partnering with a hosting company to give the solution to the end user. We’re not really seeing that mentality from plugin authors and companies. It’s wild.

Carl (26:14):
Yeah, I mean, for me, I’m just trying, I dunno for YouTube, but I’m just trying to find within a category, I will try to find one that I can just be like, okay, you’re trying to solve this specific problem. I can guarantee you that this plugin will work. You’re talking like WS Form, right? So if somebody is asking you for a form plugin can be, Ben can be, okay, we know WS Form works well, these things, but I mean, you need the license. I know what you mean. You need some way to just automatically get a license for a site. But I think just those types of partnerships and relationships are important because it minimizes our work. Because you have too many sites. I’m just one person. They’re all scaling problems. We can’t just do every plugin regardless of our size. It’s not realistic.

Zach (27:32):
Well, and I think this is an area where initiatives Guildenberg actually start to make sense. And for those of you who aren’t familiar, Jonathan Wold has started an organization called Guildenberg, which is a guild for WordPress product owners. I think the partnerships part of Guildenberg makes a lot of sense here because if you are a host that is a Guildenberg partner, you have a direct channel to all of the plugin companies that are part of Guildenberg, and it’s a marketplace of plugins that you can then verify all work on your platform and pre-approved as platform approved solutions. And there’s a way for everybody to make money. And I think that model moving forward makes a ton of sense because it opens those channels and it makes sure that there is a path to making sure that plugins do work on your stack and that they are optimized for your stack over time as well.

Tom (28:47):
Yeah, I mean, one of the things that I have dreamt about having the time to do is it’s like Kevin Ohashi. All of the load testing that he does is awesome, but so everything changes when you have 50 or 60 or 80 or a hundred and plus plugins installed in a e-commerce site, and you’re slamming it with traffic. And so I almost envision a version of what Kevin Ohashi has for pre-built baked sites, plugins. Like I said, we do a lot of load testing. And so I’ve just been getting to the point where I’m like, I just want to publish the results of here’s a site with these plugins installed and this is what the load test showed, and just start to have a repository for that. And so maybe Denberg is the place to do that. Maybe there’s a load test verified stamp of approval for these plugins, and they’re the ones that as sites begin to scale.

(29:56):
Because at the end of the day, Ben said earlier, we are the last line of defense against Shopify, tell you right now, we don’t want to lose customers, especially people who are at the high end of the spectrum. We want to feel like I need to graduate to a Shopify solution. So we move heaven and Earth to try and keep those people on WooCommerce, but if they leave, they’re leaving those plugins too. So it’s an incentive for everybody to keep these people happy. I’m not sure that the plugin companies as a whole have been traditionally focused on this at all

Ben (30:33):
To that point. It just kind of gave me a random thought, right? Everybody’s so focused on core web vitals, not as much anymore, but they were, at what point is there some sort of core WordPress vital where a plugin has some sort of impact on an install? What if there was a way for, and granted, it could depend on a lot of things, but it’s like, Hey, this plugin is compatible with this version. It’s been tested up to a hundred thousand items in this database, whatever it might be. But I think the real problem is there’s no, everybody’s so focused on website performance on the front end. Nobody’s really focused on the backend and sitting there saying, how can we take that same methodology that the world went nuts over from Google and apply it to the actual core software stack? And know that, do you want to have a related, something as simple as related items?

(31:36):
Amazon does it, no problem, right? You go to, I bought Sonos speakers, and then one of the related items was the Sonos Arc, and then another one, another one. You do that and WooCommerce, that’s heavy depending on how many variations, this, that, the other, whatever it might be. So when you start to think about that, you can solve that quicker with what is it if you use Elasticsearch? But now again, you’re starting to get down into the weeds on how you’re deploying this thing, but at what point do we not sit and say, okay, packing slips makes a lot of sense. How do we build that in a very minimalistic way without any kind of crazy database queries and starting to figure out just the stack? And again, I get that it’s very difficult with half the internet running on this CMS, but at the end of the day, I think that’s really where the conversation needs to be is there is no standard or expectation of plugin development and code quality.

(32:39):
We started, Dave was contributing at contributor day, and the way that the test runner downloads, you have to install NPM just to run Docker from within JavaScript to run a test suite. And he’s like, this doesn’t make any sense. Why wouldn’t you just run Docker or something like that? And it was just, there’s a lot of things that have happened over time, and it’s expected after all these years. But at what point do we not start to say, yeah, I agree we should have relationships with plugins, but maybe there is a need for some sort of optimization effort on the actual code and what these plugins are doing.

Carl (33:16):
Well, that’s what Johnny’s working on and the performance team. So there’s some work going there. But yeah, I mean, I’m pretty bullish, honestly, on the whole thing. I was talking a lot about working at Tokyo, but a lot of what we’re talking about is because a lot of where we see the growth is these kind of WordPress applications. So when you were talking about core vitals is not as important, it’s because they’re applications like we’re talking LMSs, we’re talking WooCommerce, we’re talking buddy boss sites. We’re talking actual applications with logged in users that are CPU constrained. They’re not just put ACDN in front. So how do we optimize our code? How do we optimize our database? How do we offload tasks? You were talking about ElasticPress. How do we make WordPress? I mean, that’s where I’m super interested, but how do we make WordPress more of a cloud application? And that’s the challenge, but that’s also what we want because want it or not, Amazon and Shopify, they’re cloud applications. They’re not just a little CMS that’s running on a single server with a database. They’re distributed applications with microservices and the whole thing. So yeah, of course they have related products super easily. It’s all handled elsewhere.

Ben (34:52):
Right? No, I, and I agree with everything you just said, but I think that’s the evolution you’re seeing in web hosting being dead. I gave a talk 10 years ago about web hosting is dead, and what that means is web hosting, it has been dead for years, but having a website’s never been as alive as it is since Covid, right? And what it really means is, the reason Rocket’s so successful is we’ve built a solution on a platform and we have a platform that customers can adopt, and it’s a range of customers. So that’s why we’re starting to work towards more features that have to do with WooCommerce and different things. And we’re trying to leverage innovate in different ways. So we can have these skews that somebody comes and they have those items like Elasticsearch is done, and that’s an easy one. That’s low hanging fruit, Elasticsearch redness.

(35:42):
That stuff’s been around forever. But at the same time now, it’s not uncommon to see somebody start a brand new store with no budget and they want all the same features as Amazon, and then you start to get into a cost battle and as they should want those features. So it’s challenging. You could go build a thousand dollars a month solution, and some customers will easily adopt it. But I think where we see a lot of the struggle even is the, well, I want to start selling T-shirts online. Do I go to Shopify and just click a couple buttons and I’m taking orders? Or do I have to figure out this WordPress WooCommerce thing? And what does that even mean?

Carl (36:25):
Yeah, I think it’s super dynamic right now because like I said, we’re competing, we’re trying to compete with Shopify. But I also talk with agencies and I mean with some of the agencies that are trying to do the scale consortium, but even on the WooCommerce side, I’m talking with agencies that are trying to compete with, we were talking about earlier, like Adobe Commerce, right? Because it is kind of the only option, right? Outside those kind of proprietary platform. You have BigCommerce and Adobe Commerce on one side, and then you have Shopify on the other, and then you have kind of WooCommerce that can kind of do both, but requires kind a more specialized kind of set. And it’s not always as easy, but there’s opportunities because they’re not proprietary.

Tom (37:19):
Well, I think there’s a really, really big difference between the people that are just getting started and want to build a store. And I think there’s a really, unfortunately, I think that it’s a harder sell for those people to not choose Shopify than to choose WooCommerce. But I think you have agencies, building stores for people who are building things in WooCommerce. I think, I mean, I don’t want to say whether I think one way or another because I don’t really, it’s kind of an opinion, but it’s like there’s a lot of great reasons. If you’re starting out and you’re a do-it-yourselfer, you want to get a store online. I think it’s easier on Shopify.

(38:14):
There are people extend and other groups that are trying to make it easy to try and get started, but it’s really hard to pick if you want to, got to get a hosting account, install WordPress, install Shop WooCommerce, it’s really difficult. But I think the other part of this is the agencies to build more on WordPress, I think, than Shopify. So agencies are out there implementing stores for businesses and then managing them. And then you’ve got this crew of people that have been on WooCommerce for a long, long time, and they’re the big stores that are growing. And there’s an interesting stat out there, and I forget what it is, but if you look at the GMV, the gross merchandise value of stores on Shopify versus WooCommerce, and I know we always talk about the number of installs. The GMV is like two XI think on Shopify versus WooCommerce, and that tells me that Shopify stores are selling more, and there’s a lot of people that may have installed WooCommerce and tried to get going and never really took off for them. I think just to be real, I think there’s something to be said that Shopify is attracting high value merchants and they’re attracting these people who are aging out of WooCommerce, moving there with their very large stores. So there’s very succinct different audience segments out there.

Zach (39:48):
One of the more high profile sites that was actually pursued by Shopify, they had their team go after it was Color Pop and Kylie Cosmetics, both the same brand technically, but that was a site that they actually went after. They intentionally pursued it and acquired it away from WooCommerce. And this was years ago at a time when it was much harder to build a performant WooCommerce store back in the days when the WooCommerce core team, their idea of dogfooding back then was the fact that WooCommerce dot com was built on WooCommerce. That was the largest site they had ever seen. Was WooCommerce dot com still a big site, but no longer the largest WooCommerce site out there. It’s been interesting seeing that the Shopify Plus team actively pursues sites on other platforms, and they make it really easy for them to move. And they do that because they know that big fish attract small fish, and the more big fish they land, the more small fish will come and hang out.

(41:12):
And so they’re willing to take a loss. A site like that doesn’t make Shopify as much money as you think. Infrastructure costs for a site that’s doing that many orders is higher than what they’re paying for, but they consider those larger brands to be a loss leader because they can make money off of all of the smaller brands that come over because they’re there. And we need to start being able to tell that story too. We need to be able to start telling that story on the WooCommerce side. And there are tons of brands doing tons of money on WooCommerce, and we don’t tell those stories well enough. And I think that’s part of why the attrition is where it is. I think we can do a better job of telling those stories. So that being said, you mentioned the need for something to test plugins and kind of provide these baseline performance scores. And do you feel maybe that’s something that the Tide project should start to investigate creating these core plugin vitals beyond just what they’re doing now more than just PHP compatibility and automated quality testing?

Ben (42:38):
I think that testing is a big thing that’s overlooked, right? Coming from some of the SaaS stuff that I did in between my hosting career, even our AP i@rock.net, it’s got 98% test coverage. We have test clients for every service we integrate with, and we have the same in our React portal. Our portal was built by the guy that built Visa checkout. So we have all of these varied modern testing practices for integration tests, Cyprus, things like that. And I think it’s something that you’ll start to see more and more, especially as PHP eight has surfaced, I think it’s starting to become more of a modern popular language again, because as much as everybody always hates on PHP, it’s been around forever and it’s a great powerful language. It’s so

Carl (43:30):
Good now. It’s so good.

Ben (43:33):
And you know what? Quite honestly, it’s always been good because it’s very versatile. You could do a lot of stuff with it, but at the same time, I think there’s a lot of different strategies. If you’re writing Golan or Node or whatever it might be, you come up in this environment that is a test-driven development strategy, and I think testing’s a big part of it, but I think I’d have to, if I put myself in the plugin developer’s shoes, I start to think about this awesome feature I want to deliver. Maybe I’m not really thinking about the performance because this is just such an awesome feature that I just want to enable for the world. And I think where we just have to imagine there just being an opportunity to almost like an APM test runner to be like, what is your plugin meant to run with? Okay, it’s meant to run with WooCommerce. It’s meant to do this. Let’s run it for a test suite of a hundred thousand hours in a, and let’s run your search algorithm, whatever it might be. And I think there could be some really creative stuff that you could somewhat standardize. There’s a way to get a score at the end of that, Hey, you’re using this old hook that was written 10, 12 years ago. There’s a new one that you could replace this with and get a performance gain.

(44:52):
Everybody’s always talking about AI and all this stuff. Well, if it’s so smart and so great, why can’t we use some of that to analyze some of these plugins and figure out, hey, there’s actually a better hook or there’s a better function that you can use that’ll increase speed or improve it. So I think, I don’t know. I mean, that’s just me thinking from a performance perspective. You never really hear anybody talk about that, right? It’s always page speed. Page speed. What about plugin speed? What does the plug and blow, what does this do to the database? Am I getting myself into type of deal by doing this?

Carl (45:29):
And I think this is kind of a new thing because we’re shifting towards these kind of WordPress application things because before web vitals made sense, right? Because you do the critical CSS, you put the CDN, you do this, you get your cool web vitals, but if we shift more towards applications, it’s kind of what you’re saying, Ben, we want code scaling tests. You called it plugin vitals. I think I liked it anyways, I liked the idea. It’s like, how does your plugin behave? If you have a hundred thousand posts or a million posts, it’s not necessarily going to behave well. So that could be a badge or a thing. Yeah, maybe that’s okay. But at least you could be, or at least you tested up to this or something like that.

Tom (46:27):
I mean, even if you could just know before you install a plugin, how much is it going to alter your database? What is it going to do? How many records is because people have a really bad habit of just like, I’m going to try 10 different plugins to solve this thing in my production site, and it’s a constant activate, deactivate, uninstall, install, activate de, and it’s like, what are you doing every time you do that? Hopefully nothing because it’s cleaning itself up. But we know that’s not true,

Carl (47:03):
But it doesn’t, most plugins don’t, right? Most plugins don’t actually do the uninstall hook cleanup thing, right? But that’s true.

Tom (47:13):
Yeah, I think that’s a really good point. And in the hosting space, it’s really difficult to provide a single solution that works for everyone, given that everyone is now millions of permutations.

Zach (47:28):
It was easier before when there were a core set of plugins that a lot of people used and not many others. But the ecosystem has grown so much that now we have plugins that have their own ecosystems. And that’s insane to me. By the way, plugins like WooCommerce and Easy Digital Downloads and MemberPress and Lifter LMS and Gravity forms, all of these plugins that are ecosystem plugins that have their own ecosystems behind them that have add-ons that other people develop and have created entire subsets of the WordPress ecosystem. It’s really cool to see, but it’s kind of crazy to think about.

Carol (48:19):
Yeah, it’s insane actually. And people can do a very successful business with multiple employees and they’re just like an Ecosystem plugin.

Tom (48:30):
It’s crazy.

Zach (48:32):
Yeah, it really is. I mean, even give wp, that’s another one where there’s an ecosystem behind it. There’s just a ton of these tinier ecosystems building around other plugins. Who becomes the arbiter though, of how that ecosystem performs? Is it the core plugin that’s responsible? Is it the individual plugin developers that are responsible? Is it the hosts that are responsible? Obviously, it’s not just any one group of people. It’s all of us that become responsible. The developers of the plugin, of course, share the weight of being the developer, but at the same time, we all have some responsibility in surfacing these things. And that’s kind of where this conversation started was.

Carl (49:25):
And I think also, we didn’t talk too much about it, but I think that’s why there’s a bit of a pressure too, to have these kind of packaged hosting solutions. Okay, you maybe WooCommerce by itself can’t compete with Shopify, but what if you had a nice prepackaged WooCommerce platform with the customer doesn’t even need to know it’s WooCommerce, right? It’s just you packaged it, you, you found the play and you optimized it, and you did all the work, and then it’s like a pop-up store thing. That’s why there’s a bit of a pressure to do those kind of things as well for then it’s a lot less pressure on the customer to figure all this stuff out.

Tom (50:12):
Well, it also reduces churn. There is a big acquisition funnel of new customers going to Shopify, going to Wix, going to all these places. And it’s like if hosting providers, like the blue hosts of the world and the Godad of the world can figure out a turnkey, get you started method where you’re not going to churn, that’s an incentive for them. We’ve shied away from that though, because it’s like none of our customers, our customers already have all that figured out because they’re more mature stores. So it’s really helpful for the ones getting started so they don’t have to go shop around and get distracted trying to find plugins to do basic functionality. But it’s probably not something more mature stores are going to adopt because they’ve already figured that all out.

Zach (50:58):
Yeah, I think that’s kind of the area though, where solutions like Woo Express, they’re trying to fill a gap here. Woo Express is from WooCommerce, and it’s their way to try and stop the initial attrition to an easier to use platform by making WooCommerce as easy to start as possible. And hopefully a lot of those learnings that they’re coming up with from running Woo Express come out to the rest of us over time through improvements to core, first of all, but through also just sharing best practices that they’re learning. And I think that it’s a remarkable opportunity the first time that WooCommerce has actually had their hand in the game of trying to host WooCommerce and host it well. So I’m excited to see what that means for the core team as they learn more about what happens when stores start to scale up. And that’s where the disconnect, I think has been for a long time. We’ve finally passed the tipping point, and there was a tipping point that the WooCommerce leadership and I had talked about years ago, and that was that we had to reach a tipping point where there were enough people that were running large WooCommerce sites to make the large WooCommerce site market make sense to invest in.

(52:40):
And it took a long time to get there, but I think we’re finally there where we’ve crossed that tipping point. We’re seeing high performance order storage because of that. We’re seeing products like Woo Express because of that. And I think that that’s really a good thing to see. I mean, we’re building hosting businesses now off of the fact that there are mid-market and larger WooCommerce stores, and there are large WordPress sites that just in general that are bigger than the platform is seen in a number of ways, whether they be learning management system sites or membership sites, and there’s a lot of opportunity there. So we’re getting close to time here where I just wanted to open the floor for everybody to just share one more thing that they’d like to share with the community. This is your chance to address the WooCommerce development community in a way that most people don’t get to. So let’s go ahead and start with Tom. Do you have anything you want to share?

Ben (53:53):
Yeah, I mean, if anyone’s struggling with scaling issues, and especially if you’re a plugin developer, we would love to replicate and test your plugin. So if there’s any interest in working with us, you can email me@tomconvesio.com. Again, we’d love to have better relationships with plugin developers and of course end developers working on WooCommerce sites as well. Yeah, from my end, I think I just want to, we’ve done a lot of, I don’t know, critiquing and maybe nitpicking slash, I don’t want to say bashing, but we’ve definitely thrown out a lot of shade in many ways and just kind of pointing fingers at different things throughout the stack. But with all that said, from my perspective, and I know everybody on this call is I truly appreciate every line of code that everybody in this ecosystem writes, right? So WooCommerce, this was not me complaining about WooCommerce thinking it sucks or WordPress.

(54:58):
I have been a huge fan since day one, and we even have some of our team at RI is contributing to core, and I’m just really grateful for all the hard work, even separating the orders out and just the focus that has been done. It’s not that this is going ignored or anything like that. So from my end, just a huge thank you to everybody that makes WooCommerce possible every single day. And if there’s anybody that would ever like to talk about testing or code, when I say testing, I mean code strategies and stuff. Maybe our CTO could lend a hand on from some of his experience or just some of our ideas on how there might be a way to improve performance in the backend of WooCommerce from a software perspective. But again, just want to make it known. Really appreciate everybody’s hard work, and we are huge fans of everything that you do, and we all just want to work together to make it as good as a solution as we can for the customer. For sure. I echo the same sentiment.

Zach (56:06):
That’s awesome. Now, well, and in the interest of full disclosure, I didn’t do this at the beginning. I intended to, I do work at Convesio with Tom, so I want to make sure that all of you know that we try to be as possible, but I do work at Convesio, but I also recommend Rocket constantly. So Carl, as always, it’s been fun. Do you have any final thoughts for us on the topic today?

Carl (56:38):
Well, I mean, I want to echo a bit of what Ben said Because when I was at WordCamp Tokyo, I was saying how excited I was for the next decade of WooCommerce. I dunno, I’m really passionate about solving a lot of these problems. Basically, that’s what YMIR is about mostly. And there’s a couple of people after I was talking that were really hyped actually about it because I think there’s a lot of opportunity and we’re just, I think this is what this conversation was about. It was just like we’re three people that are basically at the edge trying to tackle these issues where we see the potential. WooCommerce is at such a nice intersection of things because if you’re looking to not go proprietary for various reasons, because we haven’t even discussed things like Gray market and things like that, but there’s a lot of opportunity with open source software and there’s a lot of strength to it. And WooCommerce is really the best open source e-commerce platform I think.

(58:00):
So as much as we critique out of love and not out of bitterness, and it’s just because we think at least I think we’re all on this call, we can all agree, but I think it’s the best open source e-commerce platform, and we just want it to be as competitive as we feel it should be, and it deserves to be. And I think that’s why we want to solve these infrastructure scaling issues that come from code that come from just scaling, compute, scaling, separating problems and things like that. So I dunno, I’m super pumped always. So that’s why I love working on it. So I just wanted, those were my closing remarks essentially.

Zach (58:51):
Well, thank you both for being here with us. I really appreciate it. I’m sure we could go another hour if we wanted to, but we all have things to do. So I’m going to ask quickly, Ben, where can people find you on the internet?

Ben (59:09):
I’m on Twitter, Ben Gabler, and LinkedIn as well. Feel free to add me up anytime, ben@rocket.net works as well. I’m always around, it’s a gift and a curse, So just reach out. Always happy to talk shop.

Zach (59:24):
And Tom, same question.

Tom (59:26):
Yeah, and same for me. Twitter, LinkedIn, email tom@conveo.com. And yeah, I’m always around as well.

Zach (59:35):
Awesome. Well, as always, this has been an episode of the Do the podcast. If you have any suggestions for future episodes, please feel free to share them with us through the do the woo.io website or by simply messaging Bob on your platform of choice. And we look forward to seeing you all again for the next one.