Optimizing WooCommerce Performance & Code Quality

Marcel:
Well, hello everyone. Welcome to another episode of Woo DevChat. With me, as always, is Mike Andresen. Mike, how are you?

Mike:
I’m good, Marcel. How are you doing?

Marcel:
I’m doing great. Thank you so much. You have been busy this month. What have you been doing?

Mike:
We are putting the final touches on a database CLI audit tool that generates a big, beautiful report and trying to figure out how to make it digestible for the receiver, which is part of our job sometimes, balancing communication for people of all skill levels.

Marcel:
Tech. How is that report putting out information? Is it building an HTML file, or how is it?

Mike:
It’s Markdown. Notion Markdown.

Marcel:
Oh, Notion. Interesting. So are you connecting to Notion directly and delivering through Notion?

Mike:
We have an option to do that, yeah. We ran into some weird issues where you can have a page that’s too big—which we often forget in any document world—there’s a limit to how many characters you can put in. If you have thousands of orphaned entries in your options table, having the delete command is going to get very, very long. So we’ve had to split it up into four different pages.

Marcel:
That’s actually a very good idea—to deliver reports with Markdown through Notion, generated by a CLI command. That’s very interesting. I can think of a lot of use cases for that.

Mike:
What about your month?

Marcel:
Well, I’ve been busy with the block editor and building some stuff for Gutenberg. There’s HTML for the browser, and then there’s a completely new, different world that is HTML for email clients. So whenever you use Gmail or any other operating system out there that has an email client app, it just has its own HTML rules, and there’s a bunch of other different stuff that you cannot use in email that uses HTML to display the information.

What I’ve been doing is I’ve been trying to collect some of those rules into blocks that I can build on the block editor and just basically use it as a template designer for transactional emails or newsletters, for example. So you have the ability to use the block editor and still have all the tools that it provides for spacing, for images, for writing text and copy-pasting, and all of that, but trying to render it in a way that email clients can see properly on the screen.

Right. It’s very hurtful. I don’t recommend anybody to do that. It is very difficult to understand how it’s going to look on different email clients. There are a couple of websites out there where you can test those templates and see how they look. They are, I would say, 95% accurate, but at some point, you just don’t have to care for the other 5% and move on. It’s 2024, and email clients don’t run their emails in a way that is similar to browsers.

How weird is that? Why isn’t there, like, a WebKit instance of some sort in an email client that renders emails beautifully?

Mike:
That is beautiful. As long as those 5% that you can’t account for aren’t the kind that are opening your emails, I wouldn’t bother.

Marcel:
Yeah, I mean, I understand the security part of it. You don’t want to provide all the different methods for tricking people with spam emails and making them think it’s a website or something like that, but at the same time, by protecting us, we are hurting ourselves more than protecting in this case, I think. I don’t know. Anyways, it’s a challenge.

The less you try to put things into email, the easier it gets. So headings, texts, images, and links—that’s it. Don’t try anything else. I think it’s for the best. But with that, I’ve been seeing also a bunch of other different email templates that come from other newsletters I subscribe to, and there are some really cool things that people are doing to go around some of the difficulties using the old tables as we’ve seen them in HTML4 back in the day, or any other inline CSS tricks that you can come up with.

Yeah, there are a couple of cool tricks, and honestly, with that, you also learn a little bit of HTML for browsers as well. You’re always like, “Oh, there’s the style sheet and there’s HTML and PHP,” and you kind of forget the roots where we come from, building HTML and CSS by hand back in the day. So you go back and see, “Okay, why did we change this? This was working like 10 years ago. Why did we go in a more complicated route to do inline styling or to do styling at all?” Right?

Yeah. So I pretty much recommend nobody go through this route, but it’s very interesting. If I can publish this sometime in the future, I will. I would like to do a plugin around this. I think the block editor is so cool to edit stuff. It’s not only for pages.

It would be awesome for you—you have WooCommerce, you have all the different email templates from WooCommerce—and you could just simply edit them on the block editor. How awesome would that be?

Mike:
That would be very cool. Very convenient, for sure.

Marcel:
And if you’re talking about transactional emails, you can also talk about newsletters, because it’s just basically, at the end of the day, content that is sent through email. You can still use all the other systems that you use, but the HTML is built within the block editor. You can preview it in different ways, and you can send a link for people to preview it. I think it’s a missing part in our ecosystem, but that’s me.

Well, today I’m excited to introduce our guest, Brian Lee Jackson. He’s a seasoned entrepreneur, WordPress expert, and co-founder of Forge Media. With over 16 years of experience in WordPress development and content creation, Brian has a passion for optimizing websites and helping brands grow organically. He’s also a Bitcoin advocate, and he has built successful businesses, including his widely-used plugin, Perfmatters.

We’ll dive into his journey today. We have some lessons to learn from him, I’m pretty sure. And let’s see also if we can get some time and talk about what’s next for him. Brian, thank you for joining us.

Brian:
Yeah, thanks for having me.

Marcel:
Awesome. Brian, I think we can start by you telling us a little bit about what got you into WordPress in the first place, and then we can dive a little bit more into the WooCommerce part of it. But I would definitely be interested in how you got into WordPress.

Brian:
Yeah, I started my first WordPress site back in 2008, so that’s what, 12, 16 years ago? Yeah, 16, I think you mentioned. And I was in college. I think it was either late high school or early college, somewhere in there. At that time, it was still mainly just a blogging platform. People weren’t using it to build websites. I was doing websites as well, but your HTML site—you got your CSS—and you’re just using Notepad++ to code, everything like that.

So I was still doing that. And then WordPress kind of was this thing that people were just using for random blogs. So I launched one, and somehow, I was always doing web development and IT stuff, and I started blogging. I think it was IT tutorials because I always just found that really interesting—to share knowledge on the internet for free.

And that’s kind of just how it started. It went from there. I started flipping websites kind of through college, too, and then I started a hosting company in high school before I went off to college. So all this stuff’s kind of intermixed together, and WordPress is kind of just in there in the middle somewhere.

And then, yeah, once I hit college, I was really into the flipping thing. I went down the eBay rabbit hole too—I was selling computers on there. And then, once I realized I didn’t need to do all this physical stuff, I could just now flip websites, and pretty much all in the virtual world, I was like, “Oh, this is even better than flipping computers.”

So I got into that, and I don’t know. The whole thing of making money online always just fascinated me. You could just sit down at your computer with an idea and make money from the internet. I think I fell in love with that ever since I was a little kid, even, to be honest, when we first got our—

Marcel:
Computers.

Brian:
—first computer. It was grade school. I think I was in fifth grade or something. It had the five-and-a-half-inch floppies. That was our first computer in the house. So it was a typewriter, but it did have a DOS screen type of thing. But I did all my reports—I mean, this is fifth grade or something—on a five-and-a-half-inch floppy disk. And we were kind of lower middle income, so a lot of my friends actually had computers already, and I was still doing everything on this DOS typewriter thing.

It did have a backspace—that’s the best thing it had on it.

Marcel:
For younger listeners, a five-and-a-quarter floppy disk looks like a toasted bread slice, almost the same size. You can look it up on the internet.

Well, 2008, you said, right? That’s 16 years ago. That was version 2.5, 2.6, 2.7. WordPress brought a major revamp—the code name was “Coltrane.” I may sound very knowledgeable about all of this, but I’m actually reading off the internet, just so everybody knows.

It included the multi-file upload, it had an improved editor, it had the dashboard widgets, extended search—all of that that we take for granted today was what was brought in back in the day.

It’s actually very interesting to know that you come also from the hardware IT part of the computer science or computer-related businesses. I come from the same area. I’ve been working as a developer since 1998, but also throughout the following 10 years, I was selling computers, doing IT, and managing a lot of companies and email systems around my neighborhood and my city.

And it was for the same reason that I fell in love with WordPress and also for mobile development. And that’s the case—you can sit down on a computer, build something, and then distribute it worldwide almost instantaneously. That, for me, is very interesting to know and to observe.

What did you do, Mike, before becoming a developer?

Mike:
It’s funny. We all have this similar background. My first job that someone actually paid me money to do was I would go to these computer shows—fairs where companies could set up a booth and sell their hardware, software, or whatever it is.

We had to unpack the truck and set up the booth, and I had to field all these questions from other enthusiasts. And it was really fun. It was a really fun time.

But not having physical inventory has so many perks. So I totally understand, Brian, why the virtual world appeals in a totally different way—not having to worry about where to put these 50 boxes you got a really good deal on from the manufacturer or whatever.

Marcel:
And Brian, so we know you as a plugin developer, as a coder, but you had a marketing position at Kinsta at some point in your life, right?

Brian:
Yeah. So I was doing it kind of all the way up until I moved into WordPress. It was first at KeyCDN, which is a CDN provider. And then I was like, “I want to go into just WordPress.”

So I connected with Kinsta. At the time, it was kind of just like WP Engine, Pagely, and the three managed hosts that were kind of all competing. And Kinsta was a brand-new one at the time, and it was like six people on the team. I got in early, and they were looking for someone to do marketing, and it was a perfect fit.

They had seen what I was doing with marketing at KeyCDN, and I guess you could say they poached me, maybe. But yeah, it was a great fit. I started doing marketing there, and just the strategy of long-form SEO and quality content was kind of our strategy, and it worked out really, really well. It kind of just took off from there.

That’s where I really dove into the performance stuff, though. Fell in love with how to speed up every millisecond of a WordPress site.

Marcel:
Right. Do you think that the fact that you gained knowledge about how hosting works and what the elements of hosting are helped you see that there’s another side to performance, and that is the coding part—how you do all the coding?

Brian:
I would say I know that a lot more now than I did even when I joined, because at first, when I was at Kinsta—or even from the CDN side—that’s one perspective, just all CDN. And then at Kinsta, I was pushing, “Move to a brand-new host; that’ll fix all your problems.”

Then, diving deeper and gaining more knowledge—I don’t consider myself a fast coder, but I have coded for years—I started figuring out how that tied into performance. I’ve learned a lot more now about how a host can only do so much, but then it really is up to the code or the quality of the code to go from there.

There are kind of two different aspects to that. Some people think one is more powerful than the other. It’s like a perfect balance—you’ve got to get everything just right if you want it to be perfect.

Marcel:
That’s awesome. So, at a certain point in your life, you said, “That’s all well and good, and you had lots of success,” but then I want to build the path to how we got to Perfmatters. I’m kind of wanting to get there, so help me do that.

What did you do before Perfmatters came to life, and why did you create Perfmatters? Let’s talk a little bit about that.

Brian:
The reason it started was my brother—he’s the full-time coder. That’s all he does. He can just sit and code for 12 hours a day, and he’s completely happy. Me, I don’t like doing that. I like doing all sorts of different things.

But he was working at an agency at the time, just doing WordPress development—full-time coding. While I was at Kinsta, I kept seeing people’s sites over and over saying, “I need to fix this one other thing. This host is not helping me with this; the host can only do so much.”

At the time, it was pretty much just WP Rocket. WP Rocket was the only kind of optimization plugin. Maybe Autoptimize was another one out there, but those were kind of the only two players in the space at the time.

For me, I wanted to do things differently. I wanted to just disable all this crap that came with WordPress. So, I kind of got down the rabbit hole of, “How do I get rid of icons, emojis—all this stuff I’m not using at all? Why does it need to be loading if I’m not using it?”

I got kind of obsessed with that. My brother and I—he put together the first ZIP file that we were installing. Then, I started chatting with clients and said, “Hey, just try this little thing we put together.” I started handing it out for free, basically.

After a while, we saw it kept growing in popularity. So, we said, “What if we just threw this on EDD and charged $15 or $20? Let’s see what happens.” Nothing to lose. People started buying it, so we thought, “Maybe we have something here.”

Long story short, I kind of burned myself out again from working too many hours. It kind of got unhealthy. When I joined Kinsta, it was six people. By the time I left, it was over 100 people.

I went through the grind of the whole startup thing, and I’m never going to do a startup again. I don’t think I could take it mentally or physically. I’m a workaholic, so I’ll push myself too hard, if that makes sense.

Marcel:
Yeah, sure.

Brian:
Just working so many hours—we all were at the start there. It was just 18-hour days, not sleeping, drinking tons of caffeine. It takes a toll after a while. I don’t regret it, though, at all. It was probably the best job I’ve ever had, to be honest. It was super fun.

But that took a toll on me mentally. By the time we got to over 100 employees, I was being pushed into management roles instead of doing the nitty-gritty work, which is what I really like. I don’t like managing people; I find that quite boring.

I could have reworked things—they would have loved to keep me there. They offered many, many times, “Let’s just go back to writing if you want. You can do whatever you want.” But at that point, it was kind of too late. I was just mentally burned out.

So I chatted with my brother, and we decided to take a risk and do this Perfmatters thing full-time. He quit his job; I quit my job, both at the same time. It was risky. We figured, worst-case scenario, we’d just have to go get new jobs again at WordPress companies.

We took a risk, went full-time on Perfmatters, and that’s what we’ve been doing ever since. That was almost five years ago now, I think.
Here’s the continuation and completion of the cleaned-up transcript:

Marcel:
Yeah, you were talking about the disable toggles that you have. Actually, right on your plugin, in the section that is called “General,” which basically represents the main features of the plugin, the first things you have are disable emojis, disable dash icons, and disable embeds.

This reminds me—this is an old thing that WordPress has. WordPress was intended to be something, and then it became something else. Although it never lost its first intention, which was blogging, it became an e-store or an e-commerce store. Then it became an application; then it became this and that.

We have so many plugins and themes where developers weren’t thinking about their products or their code being used for something else. So nobody was developing those with the mindset that, “Oh, maybe they don’t need emojis,” or, “Maybe the dash icons shouldn’t be enqueued,” or, “Maybe they don’t need short links or REST API, for example.”

It’s on for every single website or e-commerce WooCommerce website. You can browse the whole catalog through REST API requests and get information out of the products that you don’t have on the front end.

So all of these things—people forget about them, or they don’t pay too much attention. They are there for a specific reason. They are not there just to mess your website up.

That’s really clever. And you said another thing that also reminds me of our work, which is getting—not angry in a bad sense—but getting frustrated by something and taking that solution into your own hands, building something virtual that helps others as well to overcome this frustration of having too much stuff or having too little stuff. So that’s very relatable. Very cool.

How does Perfmatters connect into WooCommerce? What do you think are the main advantages of installing Perfmatters when it comes specifically to the WooCommerce environment?

Brian:
We do quite a bit of things that technically tie into it. We have features to disable WooCommerce scripts—some of the unpopular ones that many sites actually don’t need.

Then we have the disable cart fragments type thing, which I’m sure you guys—I know Mike—have gone down a lot with optimization.

Marcel:
Causes huge delays. Yeah.

Brian:
Huge delays. So we do this—there’s a cookie name, the WooCommerce cart hash cookie. If it exists, we will load it, and if it doesn’t exist, we won’t load it. So if nothing’s in the cart, it doesn’t necessarily need to be running, type of thing.

Because you have the carts that are up in the headers across the entire site, you have different scenarios to think about with stuff like that too.

All of our features—our delay JS feature, our remove unused CSS feature—all tie into performance. Delay JS, I know, sometimes gets a bad rap because people think it’s hacky, like you’re faking performance scores.

But I think of it more as, “If the JS isn’t needed, you shouldn’t be loading it.” That’s how I think about it. So, in my opinion, it’s not hacky. It’s fixing the actual problem—loading unnecessary code.

Marcel:
I agree. I agree. Yeah, that’s totally the case.

Brian:
With JavaScript, sometimes delaying it is the only way to handle it. It’s not like CSS, where you can scrape a page and take it apart. JS has dependencies, and you can’t just rip it apart like that. So with JS, it’s kind of like “delay or not.” Even Google says delay or defer—don’t load your unused JS.

Almost every one of our features ties into WooCommerce at some level, I guess.

Marcel:
Right. We don’t have unlimited bandwidth, and servers don’t have unlimited resources to serve all the different files. So there have to be strategies, and I agree with you. Delaying is definitely one of the many tools that we have available to help improve the LCP and the other metrics.

Building a plugin is something I’ve done in the past as well. I did sell a few plugins that I owned, and I get the whole thing about, “Oh, let’s build a plugin. This will solve this problem.” Then we go, and it’s successful, and we have a lot of people we’ve helped out, and we have great reviews and all of that.

But there’s the—I will call it the dark side of it—and that is support. How do you handle support tickets as a plugin owner? For me, if today somebody comes to me and says, “I want to build this plugin; I have this great idea,” before we discuss how great of an idea that is, the number one question I ask is, “How are you going to deal with support?”

“What do you mean, support?” they ask. “Support is a secondary thing. We’ll deal with that later; we just need to work on the features.”

I’m pretty sure you’ve been through multiple tickets. Would you like to tell us a little bit about how your experience has been providing support to all of those customers?

Brian:
Yeah, so there are a couple of things here. I think my time at Kinsta really helped prepare me for this.

When we launched Kinsta, Mark, who’s the CEO, had this whole theory of, “Let’s provide better support than the other competitors in the managed hosting space.” In the early stages, I think Kinsta did that really, really well. Nobody was offering support like we were.

I saw that and thought, “Oh wow, that works really well. People really want help, and if you just provide them with help, your churn rate goes way down.” That alone stuck with me the whole time I was at Kinsta.

When we did Perfmatters, support was our number one thing. Fast forward to today, I would say we’re like 50% a plugin company and 50% a “help you with whatever your performance problem is” company.

We’ll throw out advice like, “You need to move to a new host,” or “You need to compress these images,” none of which we do, but I have great recommendations and workflows to tell people what to do.

Brian:
If you reach out to us for one thing, I’ll kind of just throw the whole book at you and say, “Here’s what you need to do to fix all your problems.” That’s worked really well for us. I think we’ve gotten a reputation in the space for quality support, and that’s why people stick with us.

I don’t mind sharing how we do support. It’s just my brother and myself, and technically, we’re both developers on the plugin. We just use a shared Gmail inbox—that’s how we do support. Five years later, we’re still doing that. We have crazy labels and automation happening in this inbox, but the thing is, my brother and I know each other so well at this point that we know exactly which tickets belong to whom just by glancing at them.

We’re tagging things, completing things—it’s almost like we can complete each other’s sentences at this point. Since we’re also the ones who developed the plugin, that gives us another advantage. We see daily what we need to improve on or what feature we need to add. That feedback directly flows into our Trello board as we work through tickets daily.

That kind of workflow is something we had at Kinsta in the early days. It got a little harder to maintain once the company grew larger, but we’ve still maintained that tight loop for Perfmatters. I don’t want to lose that because I really like keeping the company small. We’re not trying to scale to be a hundred-person company.

I’d prefer to stay small forever, which might sound strange, but I just want to make enough money to have a good living, be happy, and not work 18-hour days. That’s where I’m happy.

Marcel:
And also be entertained and have some fun while doing it, right? That’s also super important. Everyone who’s scaled companies and built huge businesses—they don’t feel as happy as we small business owners do.

We have so much freedom, so much decision-making ability. We can do whatever we want to do within a certain point of our lives and businesses. As you grow a business that big, there’s only one or two paths forward, and it’s not as fun as staying small. So I don’t find it strange at all.

Mike:
I’m the same way. I have three people on my team, and I don’t want any more. I much prefer the personal approach. I know my clients well, and we all know what’s going on in the different projects.

If you’re not having fun, for me, what’s the point?

I also had a question for you, Brian, about that. How did you decide on the scope of support for Perfmatters? It sounds like I sometimes get clients who come to me after you’ve gone above and beyond for them, and they always sing your praises.

I know you care deeply about what you do—your documentation is so clear. But how do you find the boundary, time-wise and health-wise, to avoid overgiving to clients?

Brian:
That’s the tricky thing. The last year or so, it’s gotten even trickier. We keep growing, obviously, and it gets harder to manage as we get bigger.

I’ll give you a worst-case scenario: we had one client last year with 170 emails back and forth—170 emails for a single $20 license. Obviously, we lost money on that client long before 170 emails—probably somewhere around 20 emails.

So I kind of use email volume as an indicator. If I see the same name coming back repeatedly, and they’re not an unlimited-license client, I know it’s time to say, “We can only help so much.”

I always try to be upfront and say, “We’re happy to help, but there’s a limit to how much time we can give.” Honestly, 99.9% of people are completely understanding when I explain that.

For those who need more, I recommend external help. I’ll say, “Here’s someone on Codeable or another service who can provide more hands-on help.”

Marcel:
Do your clients accept that transition easily? Sometimes people get so reliant on your expertise that they don’t want to let go.

Brian:
Honestly, the hardest part was building trust in those recommendations myself. I didn’t want to refer someone I hadn’t personally worked with.

Mike, you’re an easy example because I’ve worked with you before. Same with Codeable—they have a rigorous vetting process. Most people might complain about the price, but they rarely complain about the quality.

Now, I have specific people I trust for specific needs, like Kyle from The Admin Bar or Vic from WP Boosters. Having those trusted partners makes it easier to transition clients when they need more specialized help.

Marcel:
That’s awesome. I want to thank you very much, Brian, for coming on the podcast today and talking to us about your wonderful work.

Do you still attend WordCamps?

Brian:
I’ve only been to one WordCamp in my life. I’m just not a big fan of traveling, honestly. If I ever go, it would probably be WordCamp Phoenix, just because it’s so close to me.

Marcel:
I totally get it. After COVID, the strength and will to travel have diminished quite a bit.

Thank you so much, Brian, and thank you to everyone listening. Until the next one!