In this conversation, Felix Arntz shares his journey from being a freelancer to becoming a WordPress software engineer at Google. He discusses the importance of WordPress in the web ecosystem, Google’s commitment to improving user experience through WordPress, and the establishment of a performance team focused on enhancing WordPress performance. The conversation also delves into the integration of AI in WordPress, the significance of block themes, and the need for standardization and canonical plugins within the WordPress ecosystem.
Transcript is AI-Generated and may include minor inaccuracies.
Brian (00:00)
So today I have Felix who is a senior software engineer at Google. Hey Felix, how are you doing today?
Felix Arntz (00:06)
Good, how are you?
Brian (00:08)
I’m excited to talk to you because I think it’s just fast. think it’s fascinating that you work at Google and you’re in WordPress. Like it seems like two completely different worlds of the internet. So I’m kind of, just kind of interested. Maybe you could give us like a background of like how you became a WordPress software engineer at Google.
Felix Arntz (00:28)
Yeah, yeah, first of all, thanks for having me here. I have been active in the WordPress space for longer than I have been active at Google. so I started contributing to WordPress core about nine years ago. And yeah, back then I was a freelancer and I was
Well, I was in the fortunate position that I was in college, and I had some extra free time at hand where I could spend contributing to WordPress Core. And yeah, so that’s where I kind of really got into contributing. I did that a lot, especially in that time. And eventually I became a WordPress Core committer. End of 2016, that was.
Brian (00:55)
Mm-hmm.
Mm-hmm.
Felix Arntz (01:18)
have been active in the WordPress community ever since. And then when Google, there was like early 2018, Google started, like there were public polls about them looking for WordPress people to establish a WordPress-focused team. And yeah, that’s how I eventually got to the position I’m currently in. And I’ve been at Google for…
Brian (01:21)
Mm-hmm.
Felix Arntz (01:41)
good six years now. And while the teams I’ve been part of, they have permuted a little bit, but I’ve always been focused on WordPress since I joined Google in one way or another.
Brian (01:49)
Mm-hmm.
So your team is, is everyone in there is focused specifically on WordPress or is it just like CMS is in general or like, is the, the, the, like the mission.
Felix Arntz (01:56)
And yeah.
Yeah, our team is, I would say our team is technically focused on CMS, CMSs. But since scale and adoption is an important part of what we’re doing, WordPress is by far the biggest player in the market. So I would say that a lot, like by far the majority of our work goes into WordPress.
And yeah, we’re also everyone on the team comes from the WordPress space. So yeah, we have a few other core committers and other core contributors in our team.
Brian (02:43)
What makes Google want to have people who are not just engaged with WordPress, but I mean, we can talk about some of the things that your team contributes heavily to, things that are important to core and stuff. What makes Google want to do that? What’s the incentive?
Felix Arntz (02:48)
Thank you.
I mean, Google wants the web to thrive and WordPress is one of the biggest, if not the biggest ecosystem that impacts the web. so our team is focused on improving user experience in the CMS space, again, most importantly in WordPress because of the large market share that it has.
Brian (03:13)
Mm-hmm.
Felix Arntz (03:27)
This is basically the one of the key pieces to try to improve user experience on the web. And there are other teams in Google that do this for other segments outside of CMSs.
So we are, like I would say, again, all the people on our team come from the WordPress ecosystem. So we care about WordPress deeply. And Google cares about a good user experience on the web so that the web continues to be relevant in comparison, for example, to all the closed markets and app stores and so on. So we want to.
Brian (03:50)
Mm-hmm.
Felix Arntz (04:05)
We were trying our best to keep the web relevant for the decades to come, so to say.
Brian (04:12)
Yeah, I guess that makes sense because Google’s kind of main, one of their main areas is search and search really is not about, know, search doesn’t work with closed platforms and it probably is not super helpful when it sends you to other competitors, but like when it keeps you as part of the open web and just websites in general, then I guess that it kind of makes sense that there’s this like symbiotic relationship between Google and search engine, you know.
relevance and then individual websites. And I think you guys work on the WordPress plugin, right? That like does your Google analytics and kind of like sets all that up.
Felix Arntz (04:47)
Yeah, mean, exactly. that was my initial project when I joined Google. So I worked for a good three years primarily on SiteGit. we built that from the ground up. But then maybe about two years ago, my focus pivoted a little bit towards more of the performance work. I continued contributing to WordPress Core.
during my entire time at Google, maybe like in late or mid-20… No, was it? No, it was late 2021 already, I think. I think that’s when we established the WordPress performance team. So there was a collaboration between Google and a few other contributors from other companies that we wanted to get this official WordPress performance team, make that a thing. And since then, we’ve been contributing to those efforts to try to…
improve performance of WordPress out of the box so that the sites that people create with WordPress have better, come with better defaults and have a better foundation to build performing websites.
Brian (05:50)
And I’ll just say if people don’t know what site kit is, it’s basically like a Google analytics integration, but it’s really slick. like really, it even gives like a lot of your insights inside of WordPress. So it’s really good for like clients that kind of, you know, they maybe are a little less afraid to go in to dig into their proper analytics or something. But if you set site kit up for them, they can log into WordPress. They can see like stats on posts and stuff like that. It’s super handy, but.
Felix Arntz (06:14)
Right. Yeah. And we also, we also, and it also has like the, other services integrated like Search Console, Ads, PageSpeed Insights. So I think one of the powerful things about Scikit is that it allows you to see those data from those services at a glance where if you go to the actual Google products, they’re, they have some integrations with each other, but generally they’re separate. and yeah. And to what you’re saying, like our, one of our key goals was to make it
Brian (06:21)
Hmm.
Felix Arntz (06:43)
seamless to set up. There’s copy or JavaScript snippet from there to here in that plugin. So we basically fetch everything through the APIs.
Brian (06:52)
I forgot about the search console integration. That’s another, it’s like one of those spots that you kind of forget to go to and stuff. So having it all in like one integrated place into WordPress. And then the performance, the performance team, which you said you’ve been focused on recently, that is when you say performance, do you mean like the performance of WordPress itself? Like maybe more of like a server side type of an idea of performance?
Or do you mean like the performance of the website to like a logged out visitor, like, that kind of like page performance or something like that. it all of that? Is it parts of that? How, like, what is the domain of performance, the performance team?
Felix Arntz (07:30)
That’s a great question. Yeah, it’s probably all of that to some capacity, but I would say our primary focus is on the page speed, the user experience of the visitors of your site. And of course, sometimes server-side backend performance, it can be part of that. But yeah, we’ve been primarily focused on areas that improve performance in the front end.
where the users, and when I say front end, I do not mean client side necessarily, but I the part that visitors see, so not WP admin. So, and we have been heavily focused on measuring the impact of our efforts. So that’s something where I feel performance is in a very great spot because the WordPress project overall is not very, doesn’t have a lot of metrics.
Brian (08:03)
Mm-hmm.
Felix Arntz (08:18)
on things. And performance is a great outlier there because you get metrics through other ways out of the box. There’s a public data set that Chrome makes available from all the users that opt into the anonymous tracking where basically it’s called Chrome User Experience Report.
Brian (08:36)
Hmm.
Felix Arntz (08:39)
and that basically gives us high level data on every popular WordPress origin, how the performance is every single month. And by that we can look at tendencies and how certain improvements that we make improve performance or decline, hopefully not, but we can basically see those changes.
Brian (09:01)
Uh-huh.
Felix Arntz (09:03)
There’s another public data called HTTP Archive, which that provides very granular insights for every month for every popular WordPress region. It basically has data on which feature does this site use and so on, which WordPress version is this site on, on lots of things. So we can combine the data from HTTP Archive in this crux report to, for example, say,
Brian (09:06)
Mm-hmm.
Felix Arntz (09:30)
I don’t know, we want to see the performance from all sites before they updated to WordPress 6.5 and then get the same for a month later for all the sites after they updated to WordPress 6.5. And we can see diffs and then we could, for example, this suggests that WordPress 6.5 improved the metric X by this percent or something.
Brian (09:39)
Mm-hmm.
So you can do like really widespread testing after each release, for example, and you can see, okay, this latest release, somebody introduced this feature that does this little tweak to image blocks or something. And then you see, no, like all the images are whatever loading with a weird delay. It’s like, there’s this weird things that happen in each release. So you can track that and kind of keep an eye on it and make sure that nobody’s adding like performance regressions and stuff as, as we kind of like continually.
build up WordPress core is that kind of the goal there.
Felix Arntz (10:26)
Yeah, yeah, exactly. I I have to say it is very difficult to tie those numbers like 100 % to a specific feature because those numbers are, those are performance metrics that are gathered throughout an entire month. So for example, going back to the example that I made, when does a site update to WordPress 6.5? We only have blocks of month.
Brian (10:35)
huh.
Felix Arntz (10:50)
data. So we don’t know if the site updates to WordPress 6.5 on like the 29th of the month. So that would mean that most of the data is actually for WordPress 6.4, for instance. So those kinds of, there are always, there will always be those kinds of nuances. But with, but the good thing is the data set of those, because WordPress is such a big platform, such a popular platform, the data set of Origins is so large that it kind of allows, it kind of
Brian (10:51)
Mm-hmm.
huh.
Felix Arntz (11:17)
reduces the noise a little bit when you look at such a large data set. yeah, and then for more granular insights, we can still look at areas which have less variance. For example, unlike the actual performance metrics, like the core white values metrics, we can look at, for example,
how accurately does WordPress identify the LCP image on a site? Because that depends only like that. You can tell from the HTML output itself. And it’s just right or wrong. Like there is no, it’s just a binary metric. And so for that, we could say, okay, after the site’s updated to this WordPress release, this detection became X percent more reliable.
Brian (11:43)
Mm-hmm.
Mm-hmm.
Felix Arntz (12:01)
That is a lot more of a granular insight to make and it doesn’t directly tie back to the performance impact on the metrics. if we know that doing this more reliably makes performance better, it’s also a good success criteria, for example.
Brian (12:17)
And when you’re looking at the sites, you, because there’s so many different types of WordPress sites. Obviously if they were like headless WordPress sites, they probably wouldn’t even show up as WordPress. You know, they show up as whatever a NextApp or something like that. But then if you have like say classic versus block theme sites in, might have these classic WordPress sites and they have these slider plugins and all this crazy stuff and everybody makes their own system however they want and they do everything differently. But then you have.
block-based websites that are much more consistently built and WordPress is much more responsible for compiling the front end of it. Does that affect anything? Do you try to filter out classic sites or how do you think about that?
Felix Arntz (12:58)
We measure across the whole spectrum. We sometimes do, we definitely for certain things, we do breakdowns, for example, we may work on a feature that only affects block themes and then it doesn’t matter too much what the overall number is because if classic themes wouldn’t be affected by it. But yeah, we try to look, because we want to impact performance across the web,
Brian (13:10)
Mm-hmm.
Felix Arntz (13:25)
We want to look at the whole picture, not just block themes or not just classic themes. We’d only do it if it’s relevant, but usually we put it all in one basket, essentially. I have to add, that right now, the overall, at scale, the adoption of block themes is still relatively low. So that’s also a reason why we need to continue. While that,
I’m completely, I’m big fan of, first of all, let me say I’m a big fan of block themes. But as of today, we also cannot just like forget that classic themes are still the most widely used themes out there. So we’re kind of trying to find a good balance, how to contribute to things that impact all of them, both of those kinds of themes. But it is worth adding that even from a performance perspective, block themes are
provide a lot stronger foundation. We have looked at all the various features that we track the performance numbers for. And we noticed from all the things that we track that sites that switch to a block theme, get the largest performance boost from anything that we track that they enable. And that makes sense because of all the
Brian (14:15)
Mm-hmm.
huh.
Felix Arntz (14:37)
best practices for performance that block themes have built in, whereas with classic themes, you would have to figure out that yourself. And some of those things aren’t even reasonably possible to do. then you also, at the very least, you need a lot of good plugins to do that.
Brian (14:54)
Yes, I know we’ve done, I remember back in the day doing like trying to do custom, like critical CSS tools for, you know, big sites and stuff like that. And a lot of that just happens with a block theme pretty naturally. But back then we would have to like, you know, take screenshots of pages and have some, you know, automated tool that continually checked for critical CSS, things like that. Yeah, it used to be a lot more work. I could imagine that people would get.
performance boost. And then there’s also, there’s a plugin where they can beta test like performance lab features.
Felix Arntz (15:28)
Right, exactly. That’s our main plugin from the performance team. It’s basically a collection of various performance features. And we have made them available in separate standalone plugins. So basically, Performance Lab is, I wouldn’t say the hub of all those performance features that we’re which ideally, each of these features should eventually become a core feature.
So the hope is that each of these plugins will eventually disappear.
Brian (15:57)
I usually use like the modern image formats and a few of the other ones and stuff. so hopefully at some point in time, it’ll be core, but does it help? it like, do you get testing data from people running it or bug reports or anything like that? If like, is there value to people who have maybe don’t mind running experimental features on certain projects or something, playing with those plugins.
Felix Arntz (16:21)
Yeah, mean, a good thing about these plugins is definitely user feedback from users that use it. The Performance Lab plugin itself, it does provide some monitoring features to users, but that we can also use, that can also be used for reporting on this CrUX dataset. So for the sites that use these plugins,
Brian (16:39)
Mm-hmm.
Felix Arntz (16:45)
A good thing is that we can also query for them among this cross data set. So then we could see, like sites that use modern image formats have this much better performance than the site before they activated it, for instance, or something like that. So it’s a good way to get metrics in advance of WordPress Core, because if you do it only once you’ve merged it into WordPress Core, it’s too late.
Brian (16:50)
Hmm.
Yeah, yeah.
Interesting.
Felix Arntz (17:10)
We do want to do that because you always need to validate once you have landed something, what is the actual performance impact to make sure you did the right thing. But of course, we always want to ideally get metrics before to even know whether we’re on the right track.
Brian (17:10)
Yeah.
so I was thinking also in addition to this other plugin, is your AI,
Felix Arntz (17:30)
AIs, AI services, yeah.
Brian (17:32)
AI services, yeah. This is to me, like one of the most fascinating places right now is really seeing like where AI is gonna be useful and where it’s not gonna be useful. it feels like places where you have a lot of data, a lot of content, a lot of repetitive tasks, know, those sorts of things, AI gets really useful. So it feels to me like there’s going to be some really strong use cases for AI in.
WordPress and in workflows like editorial workflows, things like that. WordPress, you know, AI is great at content images, these, you know, all sorts of things that deal with WordPress. So you built, I mean, maybe you should just explain it to me because I feel like I’ll do a bad job of explaining it, but like you built sort of almost like an underlying layer to, for developers to put AI into WordPress. Is that, am I close to describing it? How you would describe it?
Felix Arntz (18:26)
Yeah, basically what I saw is what I’ve seen is that, well, for once, I don’t see as many AI solutions in the WordPress space as I’ve seen elsewhere. So that then makes me think, okay, why is that? But then also, mean, there’s definitely a good bunch and more more coming AI solutions in the WordPress space too. So when I see those, I basically…
Brian (18:40)
Mm-hmm.
Felix Arntz (18:51)
I notice how all of them kind of implement support for usually one provider that may be OpenAI or Gemini or Anthropic or any of them. then I basically noticed that, OK, let’s think this a little bit further.
If there are more more AI solutions in the WordPress ecosystem, what is that going to lead to? It’s going to lead to that the end user of a site has 10 plugins installed with AI features that all of them implement support for one arbitrary provider, probably the one that the plugin author is most familiar with or likes the most or something. But the end user will be forced to, let’s say you have plugins that’s
One plugin just uses that provider, one plugin uses another provider, yet another provider, another plugin. eventually you would have to, as an end user, get subscriptions for all three services, for all five or 10 services to use the AI features. But a lot of those AI features could work on any provider. mean, there are definitely certain more complex AI products that maybe they have.
done a lot of prompt researching and found that ProviderX provides the best foundation for them or something like that. But I think that the majority of today’s use cases, we’re still only scratching the surface on what’s possible with AI. I think the majority of users that would already benefit WordPress users a lot could work on any of the popular services. so I kind of wanted to come up, that’s how I came up with this idea that I want to build
Brian (20:10)
Hmm.
Yeah.
Felix Arntz (20:31)
a foundation that abstracts around the APIs of the different services that it introduces basically an abstraction layer that you can talk to Google the same way that you talk to OpenAI or vice versa. And you can register your own custom service. So there are a few built-in ones that I put in this plugin for now, which I also intend to extend a bit further.
Brian (20:45)
Mm-hmm.
Felix Arntz (20:58)
Even if a specific service that you want to use is not there, you could register your own and build the abstraction for it, which of course, that’s a lot more effort to do. I think for the majority of users, for the majority of developers that want to build AI features in WordPress, they should be able to use one of the built-in ones and run with it. And you no longer need to build your own implementation of the provider, so you don’t need to worry as much about that part.
Brian (21:08)
Mm-hmm.
Mm-hmm.
Felix Arntz (21:27)
That’s another portion that I found as a big missing piece. Some of the services do not provide PHP SDKs. So then a lot of the plugins I see either they adopt some community maintained PHP SDK, which is probably a good idea in that situation. But then also a lot of them write their own little API client class for the service. And I feel that leads to…
Brian (21:37)
Yeah.
Felix Arntz (21:55)
I mean, that for once that leads to fragmentation, everybody reinventing the wheel, but also it probably leads to not super solid implementations because let’s be honest, if you want to build AI features, you don’t want to build the AI client. That’s boring. So you want to focus your time on actually building the feature. yeah, and I’m personally a lot, I have a…
Brian (22:05)
Mm-hmm.
Yeah.
Felix Arntz (22:20)
big interest on building APIs. That’s stuff that I like. And I thought, OK, I an API layer for WordPress.
Brian (22:24)
huh.
And, and so you can, like a developer could use your framework as a dependency. And then what they could do is say they wanted to build some plugin that does this or that to your content or something like that. by using your dependency, there’s already a setting screen for API keys and all of that’s handled. There’s an abstraction for interacting with any of the AI providers. So all they have to really write is the actual like logic of their plugin.
They just, it’s almost as if it’s almost as if, you know, in WordPress, I don’t have to think about registering a post type or, know, like that work is all done for me. The framework is there. And then not only that they can do it in PHP and they can do it in. it, do you have API endpoints to use it in JavaScript? you like integrated into Gutenberg’s data stores or is there like a JavaScripty way to, also do these interactions? Like if I was building a block and I wanted some, some
some clients I had AI thing to happen, you know, while they’re built, while they’re filling out their block or something like that.
Felix Arntz (23:29)
Yeah, exactly. it has APIs in both PHP and JavaScript. I built them to be relatively in parallel, like equivalent to each other. But the JavaScript API does use data stores, so it registers its own AI services store. And from there, you can use the selectors and actions to generate content using AI.
Brian (23:40)
Mm-hmm.
Felix Arntz (23:53)
So it also does support WPCLI. I feel like I did this more for an exploration, but you can also access them with WPCLI in the same way. yeah, I thought it was definitely crucial to me to build this for both PHP and JavaScript because I think a lot of the usage of AI will come in JavaScript, in UI, because of all the UI surfaces. Like you already said, content creation is going to be a big…
thing that can be validated by AI. So I think the Block Editor provides a lot of good surface area for that. I want to call out there is one early plugin that Linnea Huxford from Ali, she has been building a plugin based on that AI services plugin. So I was really excited to see that. also, she tried to build an SAO plugin that
Brian (24:21)
Mm-hmm.
Nice.
Felix Arntz (24:48)
that helps with certain meta description generation and things like that. I wrote a blog post as a proof of concept to build a plugin that generates image alt text. Yeah, and again, I think one of the most promising parts about having such an infrastructure is that you can build it agnostic of the service. So you can leave the choice to the end user, to the site owner of the site.
Brian (24:50)
Mm-hmm.
Felix Arntz (25:12)
to say, okay, I want to use Google or I want to use OpenAI or whatever. so that just gives the, that just leads to a better user experience in the end because they can choose whatever they like best. That said, if you, as a developer say, like, let’s say you optimize your AI use case only for one or two providers and not the others, you can still say, okay, I only want to use
Brian (25:12)
Mm-hmm.
Mm-hmm. Okay.
Felix Arntz (25:37)
one of those two if they are available, but otherwise my feature is not going to work. So you can still do that, but the foundation is Exactly. Exactly.
Brian (25:42)
Yeah, like, can you pick the model or something? Like you could say, like, I really needed to go through this model for what I’m trying to do.
well, what if, and I would say it would be cool as like there’s the other side of it too, is if some other LLM, you know, really popular model comes out, say like Microsoft or something came out with one, you, you know, you, or somebody in the community could build that integration into it. Then everybody who’s using the same framework would be able to then have that support kind of like automatically like, there’s a new really popular LLM.
it’s already integrated, now we can just add that as another option or something like that. Or maybe even people who wanna do self-host their own, know, model somewhere or something like that. it could become sort of like a hub for sort of these different directions.
Felix Arntz (26:24)
Exactly.
Right, exactly. one thing that the plugin also currently, it started supporting Chrome’s built-in AI. I’m not sure if you’re not familiar with it. It’s like basically Chrome is starting to build, have its own AI layer built into the browser, which runs on your own machine. So it’s a lot. This is good for, I would say, primarily two reasons. It’s good for privacy because you do not send data anywhere else.
Brian (26:47)
Mm-hmm.
Felix Arntz (26:57)
and it’s good for your wallet because you don’t have to pay for any cloud-based service API access to use it. So it’s just free. Obviously, do not… The devices that run on your device… No, sorry. The AI models that run on your device, they’re not as capable as some of the cloud-based ones because of all the computing power behind it, but they are…
Brian (27:00)
huh.
Mm-hmm.
Felix Arntz (27:23)
good enough for many use cases, definitely. I personally think this, I mean, basically this web AI approach where the AI model runs on people’s machine and you can access it through the browser or another way on device. I think this is super promising. I feel like that’s just starting. And I think most solutions out there currently rely on cloud-based AI services, but…
Brian (27:25)
Yeah.
Felix Arntz (27:50)
I think it’s super promising to have this emerge now with on-device AI because of the reasons I mentioned, but also because potentially that opens up a pathway to get something like this into WordPress Core. Because I think one of the current cavities with something that I built, as much as I would like it to be a universal infrastructure solution for AI, it’s a bit…
Brian (28:07)
Mm-hmm.
Felix Arntz (28:19)
It’s a bit tricky because WordPress Core typically doesn’t really adopt things that are tied to particular third-party services, even less so if they require payment. And I think if there more options available to use AI in a basically distributed way on end-users devices, that would alleviate those concerns.
Brian (28:26)
Mm-hmm.
Yeah.
And I’m glad you brought up the browser based one because I’ve heard Matt Moldweg say this and I kind of agree, which is that we’re gonna see it so baked into the browser and the operating system that it’ll become less critical to think about everybody. I think we’re gonna see it become as ubiquitous as any other internet protocol or something like that because it really is hitting that level of adoption and that level of like, you know.
like usability, but there’s a lot of issues with number one, people wanting to have the option to self-host for privacy reasons to keep their data out of the cloud to, know, maybe you’re dealing with something a little bit more sensitive and you just want to run stuff locally. And then second, like, as we’re, as you know, our local hardware is getting more and more powerful for the typical things we do. Like I use Mac whisper, which is like a local.
running like transcription or whatever. And it’s like, it’s fine. It’s, it’s, I don’t need to use a cloud transcription service to like transcribe some audio. just takes a little while it runs, you know, but it’s fine. It’s free. runs local. It’s good enough. I think we’re going to see a lot more of that, but I’m, I, I’m curious about your thought about like, like you said, not having something like this in WordPress core, you know, it feels like I would love to see more frameworks and integrations and WordPress core.
like your email newsletter service or your transactional email API or all these sorts of different things where you do always have to reach for plugins for, you’re always reaching for different plugins and they’re all using their own different systems and stuff like this. And like what you’ve built is something where if it were in core and everybody used it, it’d become so much more standardized and it always feels better when we have those sorts of things, but it’s such a hard decision and a trade-off.
Do you think that we will see anything in WordPress core like this or even something like related to it, like more of these sorts of frameworks or do you think it’s just not really doable?
Felix Arntz (30:45)
I mean, I would love to see more of that. I mean, again, for this particular example with AI, I think the cautious part there is that we’re still, as I mentioned, scratching the surface of AI. And maybe the web AI, on-device AI approach is going to make that more possible to have a framework in Core. But I think for many other reasons, I completely agree with you. It would be great if Core provided more
I don’t even know if I would call it frameworks. I would call it standards. Standards is to me one of the things that Core is missing. There are so many plugins that serve the same purpose. And it’s good. It’s good there is healthy competition, but it’s bad because they all implement, re-implement, they reinvent the wheel in their own implement the similar features in completely different ways.
Brian (31:14)
Hmm.
Mm-hmm.
Felix Arntz (31:37)
And because it’s so unpredictable and because there’s no standards, it eventually hurts the end users of WordPress because there’s serious vendor lock-in. That’s one of the biggest problems to me in the WordPress space. As soon as you start using one plugin, if you use it for a while, you’re not going to be able to migrate away from it without calling a developer, basically.
Brian (31:53)
Mm-hmm.
Yes.
Felix Arntz (32:04)
You can’t just migrate from one plugin to another unless it’s one of the very few plugins that have built specifically for another plugin and like migration service or something like that. But most plugins do not have that. I think that’s something that to me is one of the biggest pain points of the WordPress ecosystem. And more standards for certain use cases would help with that. Like obviously we cannot…
Brian (32:15)
Yeah, yeah.
Felix Arntz (32:32)
WordPress Core wouldn’t be able to cover everything. But yeah, I mean, some of the very common use cases, like certain e-commerce things, forum plugins, there’s so many things that there are tons of solutions for. And having some standardization would be great. Also, like I don’t. Sorry.
Brian (32:36)
Mm-hmm.
Yeah, even just as, I would say like a standard for like how plugins store your API keys or something, you know, like how you store these sorts of things. Every plugin does it differently. There’s no real right way to do it. There’s, I’ve seen some of the worst approaches to it. Just all of these like little things that every plugin does every, like a million different ways where maybe another CMS thing would have a specific spot to.
handle like global settings, site settings, that sort of stuff. Like it feels like we have it a little bit, but it’s still very Wild West, you know.
Felix Arntz (33:21)
Right, right. Yeah. Also, was thinking about one area where I think about this a lot is like payment providers. Like there’s so many different WordPress products that require some sort of payment, whether it’s e-commerce, whether it’s some membership platform, anything that requires a payment integration, these plugins all built their own payment endpoints, payment API endpoints for the different providers.
Brian (33:28)
Hmm.
You
Felix Arntz (33:49)
which is kind of similar to the problem that I’m trying to solve with AI services for the AI providers. Like everybody reinventing the wheel just because one product uses payments for like e-commerce, another plugin uses payments for membership. That doesn’t mean that the payment infrastructure needs to be different. It can still be the same. And I think so something like having your…
Brian (33:54)
Yeah.
Felix Arntz (34:13)
That would be one of the areas where I would love to see standard in WordPress Core. But then again, we get to a similar problem. Those are all third party services, which now that I think about it, makes me wonder, should this kind of thing be in WordPress Core just without any provider built in? know what I mean? Because maybe that way, would not make Core opinionated over any paid service, but it would provide the framework.
Brian (34:29)
Mm-hmm.
Yeah. And the payment provider one is tough too, because that’s also how a lot of developers fund is like through like revenue, revenue share programs with Stripe, right? So a developer has a Stripe connect integration in their plugin and they get, you know, Stripe will give them some tiny percentage of it. And so they want, they don’t want like, it’d be great if WordPress had its own just default Stripe integration and that revenue share went to fund core or something like that. But, you know, a lot of plugins start to depend on that as like.
a pretty important revenue stream so you can understand why they don’t want to share all these things. But it would be nice if at least the structure was there. you said, like Laravel is a good example where they have some preferred tools. Like say you want to add SMS notifications to your Laravel app. You go to their documentation. They have a couple of packages that they recommend. Some of them might be partners or something like that, but either way, there’s a couple like.
tried and true frameworks that everybody can rely on and stuff like that. And it plugs in, they all plug into the system in a pretty nice way where they play well together and stuff like that. And it’s a lot easier to take all the pieces and put them together. Whereas like you said in WordPress, when I try to add my this plugin to this, and then I need to switch to this other form plugin, it’s like everything just sort of like feels like it starts to fall apart a little bit.
Felix Arntz (35:56)
Yeah. I mean, canonical plugins could be an alternative solution to this. Although I have to say, so far, mean, the plugin that I’m building for AI, would love for this to be a canonical plugin. But realistically, I’ve noticed that it’s hard to get adoption for this kind of plugin because
Brian (36:11)
Mm-hmm.
Felix Arntz (36:21)
because it’s still not part of Core. I don’t know what exactly… I think it’s important. mean, developers have to be confident that this is a thing that is going to be around, obviously, in my plugin case, I’m the only developer so that I can understand how that feels fragile. But yeah, I would love to…
Brian (36:23)
Mm-hmm.
Mm-hmm.
Felix Arntz (36:43)
in general for that, but that’s a similar situation for many other plugins that could become canonical plugins. But I feel that many times an API is only getting adopted once it is actually in WordPress core. mean, like, don’t know, think about even the WordPress REST API, for instance, that was a big deal. Like before that was in WordPress core, some plugins adopted it, but not many like in
Brian (36:58)
Mm-hmm.
Yeah.
Felix Arntz (37:11)
And even that plugin did only have a couple thousand installs before it was in core. So you can’t compare the two. That’s where I feel… But now, mean, tons of plugins have REST API endpoints today. So I think only once it hit core, it really reaches a critical mass. So I like the idea of canonical plugins, in principle, but that part still, I don’t have a good answer for.
how we can solve that problem.
Brian (37:41)
Yeah, and I’ve like written about this because I really love the canonical plugins idea. And I would love people when they open the plugin screen in WordPress, there’s, you know, this list of like, you know, really just critical, important plugins. Here’s your performance plugin. Here’s a simple forms. Here’s a simple, you know, one like two factor authentication plugin, like all these plugins that sort of exist and half of them, you know, they’re out there and stuff, but.
I was actually trying to find like, what is the list of official canonical plugins? And you can find feature plugins where like features are being actively developed and you can find plugins where wordpress.org is a contributor to it in the directory, but it’s very hard to find like, here’s a list of like true trusted plugins in WordPress. And it would be great to see some of those gaps get filled. And yet on the other hand, like you said, things…
kind of just have to go into core a little early. That’s how Gutenberg went, right? It went into core definitely well before it was like great, but it increased the adoption at such a level that it never would have been able to before. And, you know, that’s just one way to do it too, I guess.
Felix Arntz (38:50)
Yeah, but I think especially when it comes to standards and APIs that are not immediately end user facing products, I think that the adoption problem becomes more severe. Like when you mentioned, if we had a standard form plugin, I don’t think it would face that problem because lots of people want to use forms. if we had, I don’t know.
Brian (38:57)
Mm-hmm.
Mm-hmm.
Felix Arntz (39:15)
standard payment API gateway provider, like the average end user would not install this. So like this is something that kind of the developer needs to build on top of. So I feel like that’s where I see that difference. And to me, canonical plugins for end user facing features work well, could work well. I mean, but I see it more of a struggle for things that are standards that developers need to build on top of.
Brian (39:27)
Yeah.
Yeah, that’s a good point. Like I think, like action scheduler is a good example. don’t, I don’t know that that would be considered a canonical plugin. think, I think it’s from WooCommerce maybe that actually maintains it maybe. But, again, it’s like, that’s a feature where a lot of developers and we’re just don’t even know it exists or that it’s, you know, something you can use in place of WP Cron. And then once they’d realize that and they feel like, wow. It feels like it’s something that’s supported.
and it’s clearly useful and solves the case and stuff like that, then it, you you can see the adoption grow a little bit, but yeah, it would be amazing if there was like, like you said, this, this developer centric little group of, like underlying framework type plugins and stuff like that, that, you know, once one person uses it as a dependency in their plugin, then it’s like, it’s there. It’s, it’s there once it’s not, you know, bundled and hidden in some directory of a plugin and never getting updated. It’s actually like the real.
maintained good version of it and stuff. Yeah, that would be great. Are you, I guess my kind of like closing question is if you could give me like something you’re excited for. Do you have anything that you’re like excited about in the near future in WordPress, something you’re working on or something you’re seeing people work on?
Felix Arntz (40:52)
I think other than what we talked about, I think I’m most excited just about more plugins embracing the block theme slash full-site editing paradigms. Again, going from a performance perspective, there is so much good in block themes and how they work. Unfortunately, today, it’s still that many plugins
are not built with block themes in mind. mean, of course, historically they’re not, but I think there’s lot of opportunity for more plugins to kind of provide their functionality as blocks or in ways that fully align with the paradigms. Because even today, a lot of plugins may already have blocks, but then maybe they still load a giant JavaScript file for all functionality for all the blocks in one go. But WordPress Core by now has way better mechanisms to do that.
Brian (41:18)
Hmm.
Mm-hmm.
Mm-hmm.
Felix Arntz (41:43)
So that kind of thing being adopted, would love to see those kind of features being, mechanisms being adopted by plugins. I would love to see that. then of course, yeah, I also am excited where the block editor is going. I hope that the outstanding issues will still be addressed soon so that more and more people and more more site owners can make the switch.
Because I truly believe it is the future of WordPress, but I would love to see it be adopted more.
Brian (42:17)
I’ve, I feel like this last year I’ve gotten more requests from people who are updating their plugins to have blocks than, than any years previous. Like there’s definitely a growing amount of developers who they’ll message me and say, Hey, I’m working on blocks for my plugin. Cause it it’s time. And they have a lot of questions about it and stuff, but it’s, think, like you said, if you’re really focused on performance and like front end performance of your user sites.
it’s actually easier to do that with a block than with a short code and moving your short codes to blocks you, yeah, like all of the asset loading stuff you’ll find is actually just so much easier and cleaner and you don’t have to ever think about it and you’re not doing all these weird tricks and conditionals to figure out how to load things and stuff. There’s a huge benefit to it I think the shift is coming.
Felix Arntz (43:10)
Yeah, exactly. good practices, best practices are built into blocks where I think with classic themes, you could still do it, but it would be a lot of work. It would be a lot of manual hacking around work.
Brian (43:26)
So there’s a few things we didn’t get to talk to, so I think we should do this again, because I want to talk about your MU plugins folder and some of the other stuff that I think is also useful. But in the meantime, where can people go if they want to follow you, read some of your recent blog posts about the AI services, and just connect to the online?
Felix Arntz (43:44)
Yeah, my website is felix-arnes.me. But then I’m also on all the usual socials. What is it now? X. LinkedIn. What is it? Blue Sky. I almost said Blue Host, but I meant Blue Sky.
Brian (44:00)
news guy.
By the time we release this, will be another new one that we all have to go to.
Felix Arntz (44:08)
Yeah, GitHub, of course, WordPress.org. Yeah, I’m everywhere under my full name Felix Arns, except on WordPress.org. My username is Flixos90, F-L-I-X-O-S-9-0, which used to be my nickname. And I tend to think it’s funny that that’s the only platform where I didn’t use my actual name because maybe I created my WordPress.org account so long ago that I was not yet a serious person.
Hahahaha
Brian (44:34)
that I would say that actually happened to me too. And I tried to look into changing my GitHub and my WordPress.org and I thought, it was definitely not easy. many of us are stuck with our younger names for our WordPress accounts. Thanks for jumping on and looking forward to chatting in in the future.
Felix Arntz (44:52)
Yeah, thanks for having me. This was fun.
Brian (00:00)
So today I have Felix who is a senior software engineer at Google. Hey Felix, how are you doing today?
Felix Arntz (00:06)
Good, how are you?
Brian (00:08)
I’m excited to talk to you because I think it’s just fast. think it’s fascinating that you work at Google and you’re in WordPress. Like it seems like two completely different worlds of the internet. So I’m kind of, just kind of interested. Maybe you could give us like a background of like how you became a WordPress software engineer at Google.
Felix Arntz (00:28)
Yeah, yeah, first of all, thanks for having me here. I have been active in the WordPress space for longer than I have been active at Google. so I started contributing to WordPress core about nine years ago. And yeah, back then I was a freelancer and I was
Well, I was in the fortunate position that I was in college, and I had some extra free time at hand where I could spend contributing to WordPress Core. And yeah, so that’s where I kind of really got into contributing. I did that a lot, especially in that time. And eventually I became a WordPress Core committer. End of 2016, that was.
Brian (00:55)
Mm-hmm.
Mm-hmm.
Felix Arntz (01:18)
have been active in the WordPress community ever since. And then when Google, there was like early 2018, Google started, like there were public polls about them looking for WordPress people to establish a WordPress-focused team. And yeah, that’s how I eventually got to the position I’m currently in. And I’ve been at Google for…
Brian (01:21)
Mm-hmm.
Felix Arntz (01:41)
good six years now. And while the teams I’ve been part of, they have permuted a little bit, but I’ve always been focused on WordPress since I joined Google in one way or another.
Brian (01:49)
Mm-hmm.
So your team is, is everyone in there is focused specifically on WordPress or is it just like CMS is in general or like, is the, the, the, like the mission.
Felix Arntz (01:56)
And yeah.
Yeah, our team is, I would say our team is technically focused on CMS, CMSs. But since scale and adoption is an important part of what we’re doing, WordPress is by far the biggest player in the market. So I would say that a lot, like by far the majority of our work goes into WordPress.
And yeah, we’re also everyone on the team comes from the WordPress space. So yeah, we have a few other core committers and other core contributors in our team.
Brian (02:43)
What makes Google want to have people who are not just engaged with WordPress, but I mean, we can talk about some of the things that your team contributes heavily to, things that are important to core and stuff. What makes Google want to do that? What’s the incentive?
Felix Arntz (02:48)
Thank you.
I mean, Google wants the web to thrive and WordPress is one of the biggest, if not the biggest ecosystem that impacts the web. so our team is focused on improving user experience in the CMS space, again, most importantly in WordPress because of the large market share that it has.
Brian (03:13)
Mm-hmm.
Felix Arntz (03:27)
This is basically the one of the key pieces to try to improve user experience on the web. And there are other teams in Google that do this for other segments outside of CMSs.
So we are, like I would say, again, all the people on our team come from the WordPress ecosystem. So we care about WordPress deeply. And Google cares about a good user experience on the web so that the web continues to be relevant in comparison, for example, to all the closed markets and app stores and so on. So we want to.
Brian (03:50)
Mm-hmm.
Felix Arntz (04:05)
We were trying our best to keep the web relevant for the decades to come, so to say.
Brian (04:12)
Yeah, I guess that makes sense because Google’s kind of main, one of their main areas is search and search really is not about, know, search doesn’t work with closed platforms and it probably is not super helpful when it sends you to other competitors, but like when it keeps you as part of the open web and just websites in general, then I guess that it kind of makes sense that there’s this like symbiotic relationship between Google and search engine, you know.
relevance and then individual websites. And I think you guys work on the WordPress plugin, right? That like does your Google analytics and kind of like sets all that up.
Felix Arntz (04:47)
Yeah, mean, exactly. that was my initial project when I joined Google. So I worked for a good three years primarily on SiteGit. we built that from the ground up. But then maybe about two years ago, my focus pivoted a little bit towards more of the performance work. I continued contributing to WordPress Core.
during my entire time at Google, maybe like in late or mid-20… No, was it? No, it was late 2021 already, I think. I think that’s when we established the WordPress performance team. So there was a collaboration between Google and a few other contributors from other companies that we wanted to get this official WordPress performance team, make that a thing. And since then, we’ve been contributing to those efforts to try to…
improve performance of WordPress out of the box so that the sites that people create with WordPress have better, come with better defaults and have a better foundation to build performing websites.
Brian (05:50)
And I’ll just say if people don’t know what site kit is, it’s basically like a Google analytics integration, but it’s really slick. like really, it even gives like a lot of your insights inside of WordPress. So it’s really good for like clients that kind of, you know, they maybe are a little less afraid to go in to dig into their proper analytics or something. But if you set site kit up for them, they can log into WordPress. They can see like stats on posts and stuff like that. It’s super handy, but.
Felix Arntz (06:14)
Right. Yeah. And we also, we also, and it also has like the, other services integrated like Search Console, Ads, PageSpeed Insights. So I think one of the powerful things about Scikit is that it allows you to see those data from those services at a glance where if you go to the actual Google products, they’re, they have some integrations with each other, but generally they’re separate. and yeah. And to what you’re saying, like our, one of our key goals was to make it
Brian (06:21)
Hmm.
Felix Arntz (06:43)
seamless to set up. There’s copy or JavaScript snippet from there to here in that plugin. So we basically fetch everything through the APIs.
Brian (06:52)
I forgot about the search console integration. That’s another, it’s like one of those spots that you kind of forget to go to and stuff. So having it all in like one integrated place into WordPress. And then the performance, the performance team, which you said you’ve been focused on recently, that is when you say performance, do you mean like the performance of WordPress itself? Like maybe more of like a server side type of an idea of performance?
Or do you mean like the performance of the website to like a logged out visitor, like, that kind of like page performance or something like that. it all of that? Is it parts of that? How, like, what is the domain of performance, the performance team?
Felix Arntz (07:30)
That’s a great question. Yeah, it’s probably all of that to some capacity, but I would say our primary focus is on the page speed, the user experience of the visitors of your site. And of course, sometimes server-side backend performance, it can be part of that. But yeah, we’ve been primarily focused on areas that improve performance in the front end.
where the users, and when I say front end, I do not mean client side necessarily, but I the part that visitors see, so not WP admin. So, and we have been heavily focused on measuring the impact of our efforts. So that’s something where I feel performance is in a very great spot because the WordPress project overall is not very, doesn’t have a lot of metrics.
Brian (08:03)
Mm-hmm.
Felix Arntz (08:18)
on things. And performance is a great outlier there because you get metrics through other ways out of the box. There’s a public data set that Chrome makes available from all the users that opt into the anonymous tracking where basically it’s called Chrome User Experience Report.
Brian (08:36)
Hmm.
Felix Arntz (08:39)
and that basically gives us high level data on every popular WordPress origin, how the performance is every single month. And by that we can look at tendencies and how certain improvements that we make improve performance or decline, hopefully not, but we can basically see those changes.
Brian (09:01)
Uh-huh.
Felix Arntz (09:03)
There’s another public data called HTTP Archive, which that provides very granular insights for every month for every popular WordPress region. It basically has data on which feature does this site use and so on, which WordPress version is this site on, on lots of things. So we can combine the data from HTTP Archive in this crux report to, for example, say,
Brian (09:06)
Mm-hmm.
Felix Arntz (09:30)
I don’t know, we want to see the performance from all sites before they updated to WordPress 6.5 and then get the same for a month later for all the sites after they updated to WordPress 6.5. And we can see diffs and then we could, for example, this suggests that WordPress 6.5 improved the metric X by this percent or something.
Brian (09:39)
Mm-hmm.
So you can do like really widespread testing after each release, for example, and you can see, okay, this latest release, somebody introduced this feature that does this little tweak to image blocks or something. And then you see, no, like all the images are whatever loading with a weird delay. It’s like, there’s this weird things that happen in each release. So you can track that and kind of keep an eye on it and make sure that nobody’s adding like performance regressions and stuff as, as we kind of like continually.
build up WordPress core is that kind of the goal there.
Felix Arntz (10:26)
Yeah, yeah, exactly. I I have to say it is very difficult to tie those numbers like 100 % to a specific feature because those numbers are, those are performance metrics that are gathered throughout an entire month. So for example, going back to the example that I made, when does a site update to WordPress 6.5? We only have blocks of month.
Brian (10:35)
huh.
Felix Arntz (10:50)
data. So we don’t know if the site updates to WordPress 6.5 on like the 29th of the month. So that would mean that most of the data is actually for WordPress 6.4, for instance. So those kinds of, there are always, there will always be those kinds of nuances. But with, but the good thing is the data set of those, because WordPress is such a big platform, such a popular platform, the data set of Origins is so large that it kind of allows, it kind of
Brian (10:51)
Mm-hmm.
huh.
Felix Arntz (11:17)
reduces the noise a little bit when you look at such a large data set. yeah, and then for more granular insights, we can still look at areas which have less variance. For example, unlike the actual performance metrics, like the core white values metrics, we can look at, for example,
how accurately does WordPress identify the LCP image on a site? Because that depends only like that. You can tell from the HTML output itself. And it’s just right or wrong. Like there is no, it’s just a binary metric. And so for that, we could say, okay, after the site’s updated to this WordPress release, this detection became X percent more reliable.
Brian (11:43)
Mm-hmm.
Mm-hmm.
Felix Arntz (12:01)
That is a lot more of a granular insight to make and it doesn’t directly tie back to the performance impact on the metrics. if we know that doing this more reliably makes performance better, it’s also a good success criteria, for example.
Brian (12:17)
And when you’re looking at the sites, you, because there’s so many different types of WordPress sites. Obviously if they were like headless WordPress sites, they probably wouldn’t even show up as WordPress. You know, they show up as whatever a NextApp or something like that. But then if you have like say classic versus block theme sites in, might have these classic WordPress sites and they have these slider plugins and all this crazy stuff and everybody makes their own system however they want and they do everything differently. But then you have.
block-based websites that are much more consistently built and WordPress is much more responsible for compiling the front end of it. Does that affect anything? Do you try to filter out classic sites or how do you think about that?
Felix Arntz (12:58)
We measure across the whole spectrum. We sometimes do, we definitely for certain things, we do breakdowns, for example, we may work on a feature that only affects block themes and then it doesn’t matter too much what the overall number is because if classic themes wouldn’t be affected by it. But yeah, we try to look, because we want to impact performance across the web,
Brian (13:10)
Mm-hmm.
Felix Arntz (13:25)
We want to look at the whole picture, not just block themes or not just classic themes. We’d only do it if it’s relevant, but usually we put it all in one basket, essentially. I have to add, that right now, the overall, at scale, the adoption of block themes is still relatively low. So that’s also a reason why we need to continue. While that,
I’m completely, I’m big fan of, first of all, let me say I’m a big fan of block themes. But as of today, we also cannot just like forget that classic themes are still the most widely used themes out there. So we’re kind of trying to find a good balance, how to contribute to things that impact all of them, both of those kinds of themes. But it is worth adding that even from a performance perspective, block themes are
provide a lot stronger foundation. We have looked at all the various features that we track the performance numbers for. And we noticed from all the things that we track that sites that switch to a block theme, get the largest performance boost from anything that we track that they enable. And that makes sense because of all the
Brian (14:15)
Mm-hmm.
huh.
Felix Arntz (14:37)
best practices for performance that block themes have built in, whereas with classic themes, you would have to figure out that yourself. And some of those things aren’t even reasonably possible to do. then you also, at the very least, you need a lot of good plugins to do that.
Brian (14:54)
Yes, I know we’ve done, I remember back in the day doing like trying to do custom, like critical CSS tools for, you know, big sites and stuff like that. And a lot of that just happens with a block theme pretty naturally. But back then we would have to like, you know, take screenshots of pages and have some, you know, automated tool that continually checked for critical CSS, things like that. Yeah, it used to be a lot more work. I could imagine that people would get.
performance boost. And then there’s also, there’s a plugin where they can beta test like performance lab features.
Felix Arntz (15:28)
Right, exactly. That’s our main plugin from the performance team. It’s basically a collection of various performance features. And we have made them available in separate standalone plugins. So basically, Performance Lab is, I wouldn’t say the hub of all those performance features that we’re which ideally, each of these features should eventually become a core feature.
So the hope is that each of these plugins will eventually disappear.
Brian (15:57)
I usually use like the modern image formats and a few of the other ones and stuff. so hopefully at some point in time, it’ll be core, but does it help? it like, do you get testing data from people running it or bug reports or anything like that? If like, is there value to people who have maybe don’t mind running experimental features on certain projects or something, playing with those plugins.
Felix Arntz (16:21)
Yeah, mean, a good thing about these plugins is definitely user feedback from users that use it. The Performance Lab plugin itself, it does provide some monitoring features to users, but that we can also use, that can also be used for reporting on this CrUX dataset. So for the sites that use these plugins,
Brian (16:39)
Mm-hmm.
Felix Arntz (16:45)
A good thing is that we can also query for them among this cross data set. So then we could see, like sites that use modern image formats have this much better performance than the site before they activated it, for instance, or something like that. So it’s a good way to get metrics in advance of WordPress Core, because if you do it only once you’ve merged it into WordPress Core, it’s too late.
Brian (16:50)
Hmm.
Yeah, yeah.
Interesting.
Felix Arntz (17:10)
We do want to do that because you always need to validate once you have landed something, what is the actual performance impact to make sure you did the right thing. But of course, we always want to ideally get metrics before to even know whether we’re on the right track.
Brian (17:10)
Yeah.
so I was thinking also in addition to this other plugin, is your AI,
Felix Arntz (17:30)
AIs, AI services, yeah.
Brian (17:32)
AI services, yeah. This is to me, like one of the most fascinating places right now is really seeing like where AI is gonna be useful and where it’s not gonna be useful. it feels like places where you have a lot of data, a lot of content, a lot of repetitive tasks, know, those sorts of things, AI gets really useful. So it feels to me like there’s going to be some really strong use cases for AI in.
WordPress and in workflows like editorial workflows, things like that. WordPress, you know, AI is great at content images, these, you know, all sorts of things that deal with WordPress. So you built, I mean, maybe you should just explain it to me because I feel like I’ll do a bad job of explaining it, but like you built sort of almost like an underlying layer to, for developers to put AI into WordPress. Is that, am I close to describing it? How you would describe it?
Felix Arntz (18:26)
Yeah, basically what I saw is what I’ve seen is that, well, for once, I don’t see as many AI solutions in the WordPress space as I’ve seen elsewhere. So that then makes me think, okay, why is that? But then also, mean, there’s definitely a good bunch and more more coming AI solutions in the WordPress space too. So when I see those, I basically…
Brian (18:40)
Mm-hmm.
Felix Arntz (18:51)
I notice how all of them kind of implement support for usually one provider that may be OpenAI or Gemini or Anthropic or any of them. then I basically noticed that, OK, let’s think this a little bit further.
If there are more more AI solutions in the WordPress ecosystem, what is that going to lead to? It’s going to lead to that the end user of a site has 10 plugins installed with AI features that all of them implement support for one arbitrary provider, probably the one that the plugin author is most familiar with or likes the most or something. But the end user will be forced to, let’s say you have plugins that’s
One plugin just uses that provider, one plugin uses another provider, yet another provider, another plugin. eventually you would have to, as an end user, get subscriptions for all three services, for all five or 10 services to use the AI features. But a lot of those AI features could work on any provider. mean, there are definitely certain more complex AI products that maybe they have.
done a lot of prompt researching and found that ProviderX provides the best foundation for them or something like that. But I think that the majority of today’s use cases, we’re still only scratching the surface on what’s possible with AI. I think the majority of users that would already benefit WordPress users a lot could work on any of the popular services. so I kind of wanted to come up, that’s how I came up with this idea that I want to build
Brian (20:10)
Hmm.
Yeah.
Felix Arntz (20:31)
a foundation that abstracts around the APIs of the different services that it introduces basically an abstraction layer that you can talk to Google the same way that you talk to OpenAI or vice versa. And you can register your own custom service. So there are a few built-in ones that I put in this plugin for now, which I also intend to extend a bit further.
Brian (20:45)
Mm-hmm.
Felix Arntz (20:58)
Even if a specific service that you want to use is not there, you could register your own and build the abstraction for it, which of course, that’s a lot more effort to do. I think for the majority of users, for the majority of developers that want to build AI features in WordPress, they should be able to use one of the built-in ones and run with it. And you no longer need to build your own implementation of the provider, so you don’t need to worry as much about that part.
Brian (21:08)
Mm-hmm.
Mm-hmm.
Felix Arntz (21:27)
That’s another portion that I found as a big missing piece. Some of the services do not provide PHP SDKs. So then a lot of the plugins I see either they adopt some community maintained PHP SDK, which is probably a good idea in that situation. But then also a lot of them write their own little API client class for the service. And I feel that leads to…
Brian (21:37)
Yeah.
Felix Arntz (21:55)
I mean, that for once that leads to fragmentation, everybody reinventing the wheel, but also it probably leads to not super solid implementations because let’s be honest, if you want to build AI features, you don’t want to build the AI client. That’s boring. So you want to focus your time on actually building the feature. yeah, and I’m personally a lot, I have a…
Brian (22:05)
Mm-hmm.
Yeah.
Felix Arntz (22:20)
big interest on building APIs. That’s stuff that I like. And I thought, OK, I an API layer for WordPress.
Brian (22:24)
huh.
And, and so you can, like a developer could use your framework as a dependency. And then what they could do is say they wanted to build some plugin that does this or that to your content or something like that. by using your dependency, there’s already a setting screen for API keys and all of that’s handled. There’s an abstraction for interacting with any of the AI providers. So all they have to really write is the actual like logic of their plugin.
They just, it’s almost as if it’s almost as if, you know, in WordPress, I don’t have to think about registering a post type or, know, like that work is all done for me. The framework is there. And then not only that they can do it in PHP and they can do it in. it, do you have API endpoints to use it in JavaScript? you like integrated into Gutenberg’s data stores or is there like a JavaScripty way to, also do these interactions? Like if I was building a block and I wanted some, some
some clients I had AI thing to happen, you know, while they’re built, while they’re filling out their block or something like that.
Felix Arntz (23:29)
Yeah, exactly. it has APIs in both PHP and JavaScript. I built them to be relatively in parallel, like equivalent to each other. But the JavaScript API does use data stores, so it registers its own AI services store. And from there, you can use the selectors and actions to generate content using AI.
Brian (23:40)
Mm-hmm.
Felix Arntz (23:53)
So it also does support WPCLI. I feel like I did this more for an exploration, but you can also access them with WPCLI in the same way. yeah, I thought it was definitely crucial to me to build this for both PHP and JavaScript because I think a lot of the usage of AI will come in JavaScript, in UI, because of all the UI surfaces. Like you already said, content creation is going to be a big…
thing that can be validated by AI. So I think the Block Editor provides a lot of good surface area for that. I want to call out there is one early plugin that Linnea Huxford from Ali, she has been building a plugin based on that AI services plugin. So I was really excited to see that. also, she tried to build an SAO plugin that
Brian (24:21)
Mm-hmm.
Nice.
Felix Arntz (24:48)
that helps with certain meta description generation and things like that. I wrote a blog post as a proof of concept to build a plugin that generates image alt text. Yeah, and again, I think one of the most promising parts about having such an infrastructure is that you can build it agnostic of the service. So you can leave the choice to the end user, to the site owner of the site.
Brian (24:50)
Mm-hmm.
Felix Arntz (25:12)
to say, okay, I want to use Google or I want to use OpenAI or whatever. so that just gives the, that just leads to a better user experience in the end because they can choose whatever they like best. That said, if you, as a developer say, like, let’s say you optimize your AI use case only for one or two providers and not the others, you can still say, okay, I only want to use
Brian (25:12)
Mm-hmm.
Mm-hmm. Okay.
Felix Arntz (25:37)
one of those two if they are available, but otherwise my feature is not going to work. So you can still do that, but the foundation is Exactly. Exactly.
Brian (25:42)
Yeah, like, can you pick the model or something? Like you could say, like, I really needed to go through this model for what I’m trying to do.
well, what if, and I would say it would be cool as like there’s the other side of it too, is if some other LLM, you know, really popular model comes out, say like Microsoft or something came out with one, you, you know, you, or somebody in the community could build that integration into it. Then everybody who’s using the same framework would be able to then have that support kind of like automatically like, there’s a new really popular LLM.
it’s already integrated, now we can just add that as another option or something like that. Or maybe even people who wanna do self-host their own, know, model somewhere or something like that. it could become sort of like a hub for sort of these different directions.
Felix Arntz (26:24)
Exactly.
Right, exactly. one thing that the plugin also currently, it started supporting Chrome’s built-in AI. I’m not sure if you’re not familiar with it. It’s like basically Chrome is starting to build, have its own AI layer built into the browser, which runs on your own machine. So it’s a lot. This is good for, I would say, primarily two reasons. It’s good for privacy because you do not send data anywhere else.
Brian (26:47)
Mm-hmm.
Felix Arntz (26:57)
and it’s good for your wallet because you don’t have to pay for any cloud-based service API access to use it. So it’s just free. Obviously, do not… The devices that run on your device… No, sorry. The AI models that run on your device, they’re not as capable as some of the cloud-based ones because of all the computing power behind it, but they are…
Brian (27:00)
huh.
Mm-hmm.
Felix Arntz (27:23)
good enough for many use cases, definitely. I personally think this, I mean, basically this web AI approach where the AI model runs on people’s machine and you can access it through the browser or another way on device. I think this is super promising. I feel like that’s just starting. And I think most solutions out there currently rely on cloud-based AI services, but…
Brian (27:25)
Yeah.
Felix Arntz (27:50)
I think it’s super promising to have this emerge now with on-device AI because of the reasons I mentioned, but also because potentially that opens up a pathway to get something like this into WordPress Core. Because I think one of the current cavities with something that I built, as much as I would like it to be a universal infrastructure solution for AI, it’s a bit…
Brian (28:07)
Mm-hmm.
Felix Arntz (28:19)
It’s a bit tricky because WordPress Core typically doesn’t really adopt things that are tied to particular third-party services, even less so if they require payment. And I think if there more options available to use AI in a basically distributed way on end-users devices, that would alleviate those concerns.
Brian (28:26)
Mm-hmm.
Yeah.
And I’m glad you brought up the browser based one because I’ve heard Matt Moldweg say this and I kind of agree, which is that we’re gonna see it so baked into the browser and the operating system that it’ll become less critical to think about everybody. I think we’re gonna see it become as ubiquitous as any other internet protocol or something like that because it really is hitting that level of adoption and that level of like, you know.
like usability, but there’s a lot of issues with number one, people wanting to have the option to self-host for privacy reasons to keep their data out of the cloud to, know, maybe you’re dealing with something a little bit more sensitive and you just want to run stuff locally. And then second, like, as we’re, as you know, our local hardware is getting more and more powerful for the typical things we do. Like I use Mac whisper, which is like a local.
running like transcription or whatever. And it’s like, it’s fine. It’s, it’s, I don’t need to use a cloud transcription service to like transcribe some audio. just takes a little while it runs, you know, but it’s fine. It’s free. runs local. It’s good enough. I think we’re going to see a lot more of that, but I’m, I, I’m curious about your thought about like, like you said, not having something like this in WordPress core, you know, it feels like I would love to see more frameworks and integrations and WordPress core.
like your email newsletter service or your transactional email API or all these sorts of different things where you do always have to reach for plugins for, you’re always reaching for different plugins and they’re all using their own different systems and stuff like this. And like what you’ve built is something where if it were in core and everybody used it, it’d become so much more standardized and it always feels better when we have those sorts of things, but it’s such a hard decision and a trade-off.
Do you think that we will see anything in WordPress core like this or even something like related to it, like more of these sorts of frameworks or do you think it’s just not really doable?
Felix Arntz (30:45)
I mean, I would love to see more of that. I mean, again, for this particular example with AI, I think the cautious part there is that we’re still, as I mentioned, scratching the surface of AI. And maybe the web AI, on-device AI approach is going to make that more possible to have a framework in Core. But I think for many other reasons, I completely agree with you. It would be great if Core provided more
I don’t even know if I would call it frameworks. I would call it standards. Standards is to me one of the things that Core is missing. There are so many plugins that serve the same purpose. And it’s good. It’s good there is healthy competition, but it’s bad because they all implement, re-implement, they reinvent the wheel in their own implement the similar features in completely different ways.
Brian (31:14)
Hmm.
Mm-hmm.
Felix Arntz (31:37)
And because it’s so unpredictable and because there’s no standards, it eventually hurts the end users of WordPress because there’s serious vendor lock-in. That’s one of the biggest problems to me in the WordPress space. As soon as you start using one plugin, if you use it for a while, you’re not going to be able to migrate away from it without calling a developer, basically.
Brian (31:53)
Mm-hmm.
Yes.
Felix Arntz (32:04)
You can’t just migrate from one plugin to another unless it’s one of the very few plugins that have built specifically for another plugin and like migration service or something like that. But most plugins do not have that. I think that’s something that to me is one of the biggest pain points of the WordPress ecosystem. And more standards for certain use cases would help with that. Like obviously we cannot…
Brian (32:15)
Yeah, yeah.
Felix Arntz (32:32)
WordPress Core wouldn’t be able to cover everything. But yeah, I mean, some of the very common use cases, like certain e-commerce things, forum plugins, there’s so many things that there are tons of solutions for. And having some standardization would be great. Also, like I don’t. Sorry.
Brian (32:36)
Mm-hmm.
Yeah, even just as, I would say like a standard for like how plugins store your API keys or something, you know, like how you store these sorts of things. Every plugin does it differently. There’s no real right way to do it. There’s, I’ve seen some of the worst approaches to it. Just all of these like little things that every plugin does every, like a million different ways where maybe another CMS thing would have a specific spot to.
handle like global settings, site settings, that sort of stuff. Like it feels like we have it a little bit, but it’s still very Wild West, you know.
Felix Arntz (33:21)
Right, right. Yeah. Also, was thinking about one area where I think about this a lot is like payment providers. Like there’s so many different WordPress products that require some sort of payment, whether it’s e-commerce, whether it’s some membership platform, anything that requires a payment integration, these plugins all built their own payment endpoints, payment API endpoints for the different providers.
Brian (33:28)
Hmm.
You
Felix Arntz (33:49)
which is kind of similar to the problem that I’m trying to solve with AI services for the AI providers. Like everybody reinventing the wheel just because one product uses payments for like e-commerce, another plugin uses payments for membership. That doesn’t mean that the payment infrastructure needs to be different. It can still be the same. And I think so something like having your…
Brian (33:54)
Yeah.
Felix Arntz (34:13)
That would be one of the areas where I would love to see standard in WordPress Core. But then again, we get to a similar problem. Those are all third party services, which now that I think about it, makes me wonder, should this kind of thing be in WordPress Core just without any provider built in? know what I mean? Because maybe that way, would not make Core opinionated over any paid service, but it would provide the framework.
Brian (34:29)
Mm-hmm.
Yeah. And the payment provider one is tough too, because that’s also how a lot of developers fund is like through like revenue, revenue share programs with Stripe, right? So a developer has a Stripe connect integration in their plugin and they get, you know, Stripe will give them some tiny percentage of it. And so they want, they don’t want like, it’d be great if WordPress had its own just default Stripe integration and that revenue share went to fund core or something like that. But, you know, a lot of plugins start to depend on that as like.
a pretty important revenue stream so you can understand why they don’t want to share all these things. But it would be nice if at least the structure was there. you said, like Laravel is a good example where they have some preferred tools. Like say you want to add SMS notifications to your Laravel app. You go to their documentation. They have a couple of packages that they recommend. Some of them might be partners or something like that, but either way, there’s a couple like.
tried and true frameworks that everybody can rely on and stuff like that. And it plugs in, they all plug into the system in a pretty nice way where they play well together and stuff like that. And it’s a lot easier to take all the pieces and put them together. Whereas like you said in WordPress, when I try to add my this plugin to this, and then I need to switch to this other form plugin, it’s like everything just sort of like feels like it starts to fall apart a little bit.
Felix Arntz (35:56)
Yeah. I mean, canonical plugins could be an alternative solution to this. Although I have to say, so far, mean, the plugin that I’m building for AI, would love for this to be a canonical plugin. But realistically, I’ve noticed that it’s hard to get adoption for this kind of plugin because
Brian (36:11)
Mm-hmm.
Felix Arntz (36:21)
because it’s still not part of Core. I don’t know what exactly… I think it’s important. mean, developers have to be confident that this is a thing that is going to be around, obviously, in my plugin case, I’m the only developer so that I can understand how that feels fragile. But yeah, I would love to…
Brian (36:23)
Mm-hmm.
Mm-hmm.
Felix Arntz (36:43)
in general for that, but that’s a similar situation for many other plugins that could become canonical plugins. But I feel that many times an API is only getting adopted once it is actually in WordPress core. mean, like, don’t know, think about even the WordPress REST API, for instance, that was a big deal. Like before that was in WordPress core, some plugins adopted it, but not many like in
Brian (36:58)
Mm-hmm.
Yeah.
Felix Arntz (37:11)
And even that plugin did only have a couple thousand installs before it was in core. So you can’t compare the two. That’s where I feel… But now, mean, tons of plugins have REST API endpoints today. So I think only once it hit core, it really reaches a critical mass. So I like the idea of canonical plugins, in principle, but that part still, I don’t have a good answer for.
how we can solve that problem.
Brian (37:41)
Yeah, and I’ve like written about this because I really love the canonical plugins idea. And I would love people when they open the plugin screen in WordPress, there’s, you know, this list of like, you know, really just critical, important plugins. Here’s your performance plugin. Here’s a simple forms. Here’s a simple, you know, one like two factor authentication plugin, like all these plugins that sort of exist and half of them, you know, they’re out there and stuff, but.
I was actually trying to find like, what is the list of official canonical plugins? And you can find feature plugins where like features are being actively developed and you can find plugins where wordpress.org is a contributor to it in the directory, but it’s very hard to find like, here’s a list of like true trusted plugins in WordPress. And it would be great to see some of those gaps get filled. And yet on the other hand, like you said, things…
kind of just have to go into core a little early. That’s how Gutenberg went, right? It went into core definitely well before it was like great, but it increased the adoption at such a level that it never would have been able to before. And, you know, that’s just one way to do it too, I guess.
Felix Arntz (38:50)
Yeah, but I think especially when it comes to standards and APIs that are not immediately end user facing products, I think that the adoption problem becomes more severe. Like when you mentioned, if we had a standard form plugin, I don’t think it would face that problem because lots of people want to use forms. if we had, I don’t know.
Brian (38:57)
Mm-hmm.
Mm-hmm.
Felix Arntz (39:15)
standard payment API gateway provider, like the average end user would not install this. So like this is something that kind of the developer needs to build on top of. So I feel like that’s where I see that difference. And to me, canonical plugins for end user facing features work well, could work well. I mean, but I see it more of a struggle for things that are standards that developers need to build on top of.
Brian (39:27)
Yeah.
Yeah, that’s a good point. Like I think, like action scheduler is a good example. don’t, I don’t know that that would be considered a canonical plugin. think, I think it’s from WooCommerce maybe that actually maintains it maybe. But, again, it’s like, that’s a feature where a lot of developers and we’re just don’t even know it exists or that it’s, you know, something you can use in place of WP Cron. And then once they’d realize that and they feel like, wow. It feels like it’s something that’s supported.
and it’s clearly useful and solves the case and stuff like that, then it, you you can see the adoption grow a little bit, but yeah, it would be amazing if there was like, like you said, this, this developer centric little group of, like underlying framework type plugins and stuff like that, that, you know, once one person uses it as a dependency in their plugin, then it’s like, it’s there. It’s, it’s there once it’s not, you know, bundled and hidden in some directory of a plugin and never getting updated. It’s actually like the real.
maintained good version of it and stuff. Yeah, that would be great. Are you, I guess my kind of like closing question is if you could give me like something you’re excited for. Do you have anything that you’re like excited about in the near future in WordPress, something you’re working on or something you’re seeing people work on?
Felix Arntz (40:52)
I think other than what we talked about, I think I’m most excited just about more plugins embracing the block theme slash full-site editing paradigms. Again, going from a performance perspective, there is so much good in block themes and how they work. Unfortunately, today, it’s still that many plugins
are not built with block themes in mind. mean, of course, historically they’re not, but I think there’s lot of opportunity for more plugins to kind of provide their functionality as blocks or in ways that fully align with the paradigms. Because even today, a lot of plugins may already have blocks, but then maybe they still load a giant JavaScript file for all functionality for all the blocks in one go. But WordPress Core by now has way better mechanisms to do that.
Brian (41:18)
Hmm.
Mm-hmm.
Mm-hmm.
Felix Arntz (41:43)
So that kind of thing being adopted, would love to see those kind of features being, mechanisms being adopted by plugins. I would love to see that. then of course, yeah, I also am excited where the block editor is going. I hope that the outstanding issues will still be addressed soon so that more and more people and more more site owners can make the switch.
Because I truly believe it is the future of WordPress, but I would love to see it be adopted more.
Brian (42:17)
I’ve, I feel like this last year I’ve gotten more requests from people who are updating their plugins to have blocks than, than any years previous. Like there’s definitely a growing amount of developers who they’ll message me and say, Hey, I’m working on blocks for my plugin. Cause it it’s time. And they have a lot of questions about it and stuff, but it’s, think, like you said, if you’re really focused on performance and like front end performance of your user sites.
it’s actually easier to do that with a block than with a short code and moving your short codes to blocks you, yeah, like all of the asset loading stuff you’ll find is actually just so much easier and cleaner and you don’t have to ever think about it and you’re not doing all these weird tricks and conditionals to figure out how to load things and stuff. There’s a huge benefit to it I think the shift is coming.
Felix Arntz (43:10)
Yeah, exactly. good practices, best practices are built into blocks where I think with classic themes, you could still do it, but it would be a lot of work. It would be a lot of manual hacking around work.
Brian (43:26)
So there’s a few things we didn’t get to talk to, so I think we should do this again, because I want to talk about your MU plugins folder and some of the other stuff that I think is also useful. But in the meantime, where can people go if they want to follow you, read some of your recent blog posts about the AI services, and just connect to the online?
Felix Arntz (43:44)
Yeah, my website is felix-arnes.me. But then I’m also on all the usual socials. What is it now? X. LinkedIn. What is it? Blue Sky. I almost said Blue Host, but I meant Blue Sky.
Brian (44:00)
news guy.
By the time we release this, will be another new one that we all have to go to.
Felix Arntz (44:08)
Yeah, GitHub, of course, WordPress.org. Yeah, I’m everywhere under my full name Felix Arns, except on WordPress.org. My username is Flixos90, F-L-I-X-O-S-9-0, which used to be my nickname. And I tend to think it’s funny that that’s the only platform where I didn’t use my actual name because maybe I created my WordPress.org account so long ago that I was not yet a serious person.
Hahahaha
Brian (44:34)
that I would say that actually happened to me too. And I tried to look into changing my GitHub and my WordPress.org and I thought, it was definitely not easy. many of us are stuck with our younger names for our WordPress accounts. Thanks for jumping on and looking forward to chatting in in the future.
Felix Arntz (44:52)
Yeah, thanks for having me. This was fun.