[00:00:00] Speaker A: Welcome to Within WordPress, your favorite podcast. I hope. I hope. My God, should I still be saying this? I hope in this episode I welcome Felix Arns. Felix, welcome.
[00:00:21] Speaker B: Hey, thanks for having me.
[00:00:23] Speaker A: Yeah, I'm very happy to have you.
You are touching a topic in the world of WordPress that is very near and dear to my heart on, I would say, almost a daily basis. And you can correct me if that turns out to be once a week. But yeah. So please, for those who are not aware of who you are, what you do, can you please introduce yourself?
[00:00:49] Speaker B: Yeah. So I am Felix ahrens. I am WordPress Core committer. I have been contributing to WordPress Core for good nine years now and I am also a senior software engineer at Google. So I've been. I work at Google in a basically a WordPress focused team.
So we contribute directly to WordPress and related initiatives primarily to improve performance. And I've been at Google for about six years now and while the team has gone through some shifts, I've basically been working on WordPress my entire time at Google.
[00:01:31] Speaker A: Related initiatives, you say? What does that mean?
[00:01:35] Speaker B: I mean, I guess I said initially that I'm a WordPress core committer or core contributor.
But our team also works with other WordPress projects. So we don't only contribute to WordPress Core, we also work with other big like popular plugins. We partner with them or try to consult with them to land certain performance features in their plugins.
But we also occasionally work on other CMSs. So our team is generally, I would say a CMS focused team. But because scale and large scale performance improvements matter, WordPress is by far the most powerful lever in that regard because of its market share?
[00:02:23] Speaker A: Yeah, for sure.
Interesting.
When you say you're collaborating with other plugins, performance plugins out there, does that literally mean here's new features that are available to you either in the browser or as a tool, a mechanism, and you're not yet using it. How about we talk about how to integrate that? Is that the sort of collaboration I'm looking at or.
[00:02:54] Speaker B: Yeah, sometimes. I mean we sometimes advocate for new browser features that are good for performance to get those adopted in performance plugins, but we also sometimes work with other plugins that are not necessarily focused on performance, but every plugin more or less has some performance impact. And especially when we get to, when we talk about extremely popular plugins like those with over a million installs there, we have those plugins have a large impact on the web, not even only WordPress, but even the web.
So we Sometimes find opportunities to improve those plugins and then we reach out to the developers of them.
[00:03:45] Speaker A: I like how you frame that you find opportunities. I'm translating that as in you're looking at plugins that have a high impact on the web and if and when and where they can improve on in performance and they're not doing it just yet, you come with a friendly nudge.
[00:04:02] Speaker B: Yeah.
And sometimes plugins are already focusing on performance, on improving their performance, then that's great for us. So we can only be like, hey, here's this other feature that you could be looking at. Other times maybe the plugin developers have not been yet as focused on performance. So then it's a little more advocacy side for performance.
[00:04:27] Speaker A: Yeah, that's interesting. I didn't know that.
So what I know about the Google team is you have stewardship over the.
[00:04:40] Speaker B: What's the Performance Lab?
[00:04:43] Speaker A: Yeah, the Performance Lab. And you have the SiteKit plugin or is that even.
[00:04:51] Speaker B: Yeah, so we work, we have been working on that. So Site Kit was my personal primary project for my first three years at Google pretty much. And since then I've shifted gears a little bit more towards the performance work.
So it's been over three years now that we started establishing the WordPress performance team.
[00:05:14] Speaker A: It's been a good three years.
[00:05:16] Speaker B: Yeah.
I can't believe it's that long. Actually.
[00:05:20] Speaker A: No, I, I was, I was calculating in my head when you said I've been here for six years and I'm like, like, was it six years ago that we were actually colleagues at Yoast? Was that six years or was that seven years? Yeah, I'm lost in the math. Yeah, real fast one. But I didn't have six years in my head.
No. But interesting. So the, the, the two plugins out there currently sort of under the management of. Or I don't know, is it management. But the things that you focus on are the Performance Lab plugin and the sitekit. So Site Kit is a little bit less, I hear you say, for you personally, but I gather the team is still on that. As it, as it should.
Right. I'm mostly curious, as you know, my day to day tasks mostly focus around performance in one way or another.
I'm very curious on the things you do for the Performance Labs plugin. Can you, can you tell me a little bit more what the. Because that result is the result of the WordPress core performance team.
Did I say those words in the right sequence? I always.
[00:06:37] Speaker B: I don't know, sometimes it is the WordPress core performance team, sometimes it's just the WordPress performance team because we don't only focus on core, but.
[00:06:43] Speaker A: Yeah, so there's more people working on the Performance Labs plugin.
But I'm very curious like how do you find new ideas and focus of area of area of focus where you go like, so this is what we're going to build next and this is how we're not doing this and maybe later that. How does that work?
[00:07:08] Speaker B: Yeah, I mean just some additional context. Like I'm sure you're aware of that. But like the, the Performance Lab plugin is. We are heavily involved in it, but it is basically a WordPress community plugin.
So while the WordPress performance team, like our Google team, is a big part of it, we're not solely driving it. That's different for SiteKit, which is basically a Google product.
So yeah, for Performance Lab, I think the way we went about it in the beginning was to that we used those. There are those really big data sets out there of Word of websites and their performance data like those are. There is for example a Chrome user experience report for Crux which is based on data from Chrome users that opt into the anonymous tracking feature based based on that the Crux report makes aggregated data for popular websites available publicly. So like in terms of performance. So performance data, when for example you see, you get for you can look for any popular website, you can look up in the Crux report, how good is that site's LCP passing rate or INP passing rate? Yeah, and we use that. And based on that there's another data set called HTTP Archive, which is also a public data set which takes the domains from that Crux Report and then runs a bunch of automated testing over them. So we're talking like millions of URLs every month where they run, for example lighthouse, they run web page tests and those two alone, they give so much data about those domains. So for example, then you can query HTML response bodies, which features they use for instance, or it also runs, they also run HTTP archive, also runs weapalyzer, which is this technology detection framework so that by that we can discover, we can detect which sites are using WordPress and then we can connect it back to Crux data and say okay, now I want to get the performance only for WordPress sites.
That's basically the main data set that we as a team look at like the part of the Crux report that is WordPress sites. And then we try to validate the projects that we work on their impact also on more granularly for example, we can use HTTP Archive to even segment which sites use, I don't know, lazy loading or whatever feature. And going back to your initial question. Sorry, going back to your initial question, we did initially look at HTTP Archive to kind of to see what are the most commonly reported problems by Lighthouse across WordPress sites. And then from there we went to okay, how can we tackle those that gave us a sense of priority.
[00:10:22] Speaker A: I think that makes sense. So you're basically, you're combining two huge data collecting initiatives, CRUX and HTTP Archive, and sort of mixing them to produce the, you know, the valuable insight of which one does, does do a particular thing as well as not meet certain criteria. And what are things that we can do in Core to basically fix the delta between the two.
[00:10:51] Speaker B: Exactly, yeah. And it helps, so it helps find which are the largest problems at scale, but it also later helps. Once we have hopefully landed something in WordPress Core, for instance, it helps see how much does it actually improve the performance.
[00:11:10] Speaker A: That was my next question. Because once you've identified it, then found a fix for it, then implemented it and once it reaches implemented in the Performance Labs plugin and then promotes from there to WordPress core, I'm assuming, and I kind of know the answer to this already, but for those listening, I'm assuming there is a moment where you say, hey, look, we've implemented this and this is the actual effect of that on the web because you're running reports, right, for all the new versions of WordPress.
[00:11:44] Speaker B: Right? Right, yeah, we do it. Yeah, we do assess for every WordPress release. How?
Assess? Sorry?
[00:11:54] Speaker A: Oh, yeah, sorry. Yeah, that's so funny.
[00:11:58] Speaker B: We do assess for every WordPress version that gets out there.
How does it impact performance in the field? And but additionally we do it for certain high priority features that we worked on. We try to do it more granularly and that's always tricky because the CRUX report, it only gives one set of numbers for every month.
So this data is influenced by many things and you can't just boil it down to one feature before and after. That's impossible. But because the data set is so large, we can do our best to segment it based on certain feature detection HTTP archive in a way that we, we try to get as close as possible to some sort of, here's the sites that didn't have this feature in the last month and here's the same sites that have the feature enabled the month after and then we can compare them, for instance.
[00:13:00] Speaker A: So there is a limitation there because if you're only Looking at a month worth of data and it's a, let's say we have a high impact site on WordPress, millions and millions of page views per month. But the, you know, it, it lasts a little bit longer than a month before it's upgraded to a new major version of WordPress. Would you be missing that or.
Because, you know, if, if, if today, if, if December 1st, the new major release is done, you're measuring the whole of December, but it's 15th of January before updating to WordPress 6.7. Would you miss what the impact was on that site or is there a way to sort of still catch that?
[00:13:46] Speaker B: Yeah, it's tricky because I mean this, we do. The HTTP archive does have which version of WordPress the site uses, so that does detect. But to your point, we don't know when in the month the site updated.
[00:14:02] Speaker A: Yeah.
[00:14:04] Speaker B: I believe HTTP Archive usually runs its pipeline somewhere between the 20th and the 30th of each month.
So then if the site updated like a day before the pipeline run, it will show up as it is on the latest version or it might update a day later, which is not that different, speaking about the whole month length, but it would show up as the lower version.
And those kind of things are, those are the kind of inaccuracies that we can't avoid with those data sets.
But I think looking at the data at scale still gives a good idea because we look at so many URLs that it kind of. There is some noise, but.
[00:14:47] Speaker A: Yeah, exactly, that's the word I was going for. So how much noise is there? Or incomplete information when you're measuring like that? If it's in one month, it has a high impact.
There's a fix implemented yet the fix isn't measurable until five, six weeks later. Can you still actually accurately measure what you intended to fix?
This is probably a very niche way of looking at data sets. But as you were explaining, that's apparently where my head went.
[00:15:19] Speaker B: Yeah, that's also what we're trying to do. I mean, this is an, I want to say this is an endless challenge that we work. We've been trying to improve for years.
And so when I say this, this, the thing with those inaccuracies is fortunately they are. Well, fortunately they're only present in. When it comes to the actual performance metrics, which is in the end what we are after. We want to improve LCP and inp and cls of WordPress sites. So for that we have, for that we have the inaccuracies but we have for many features you can come up with a metric that's far more specific to that feature.
So let me make an example here. So WordPress Core has lazy loading and adds fetch priority high to what WordPress core thinks is the high priority image. But that approach is Limited because WordPress Core does this from the server side. So it can only kind of guess what is probably the most important image.
[00:16:20] Speaker A: Yep.
[00:16:21] Speaker B: So we're currently working on a plugin that kind of, that detects that on the client side and then optimizes subsequent responses.
And then for this kind of plugin, if this were to land in WordPress core or even right now with the plugin based on the plugin itself, we could look at to what percentage is the LCP image correctly detected?
And say, for example, WordPress Core detects it correctly in like 60% of cases. And then you install this plugin and now it's collected detected correctly in 95% of cases. Like, that would be a great outcome and that would be a reliable, it would be a reliable assessment that the feature works as we intend to. And then from there the LCP impact that actually brings from there, for that we can only go with the sort of approximate metric that we talked about. But at least still we know for sure, if we get this kind of metric, we know for sure the feature is doing what it's supposed to do.
[00:17:26] Speaker A: My assumption has always been that in some way you would be looking at it as data driven as humanly possible. But it's actually quite nice to hear that how the team approaches the problems that need to be solved and how they're measuring the efficacy of what, what it is you intended to solve.
Does your, you working at Google, does that help in this particular case? Or is it. You could have been working anywhere else and you'd have the same set of data or how does that work?
[00:18:01] Speaker B: I mean, it, I think it, I would say it mostly helps because I have a. Like, the people that work on this stuff are my colleagues, so I can easily ask them, I can easily find the right people to ask for how, how do I do this, how do I query that?
So that helps a lot. But the, the data sets themselves, they are public, so we don't, we don't query data that's not public, basically. So, yeah, but the other thing is, I mean if you, the thing is that those data sets are very big, so if you query them a lot and for very complex things, you unfortunately incur quite a bit of cost on your. Because it's using BigQuery. So it's a paid service but the data is public and anybody could query it.
[00:18:55] Speaker A: Yeah, BigQuery is a wonderful help in these types of things. For those listening, if you've never looked at what BigQuery can solve, it's, it's a.
Yeah, it's, it's a tool. Well, I think the name is exactly what it is. You throw a lot of data at like a lot, a lot of data and you have a whole tool set that allows you not to not only query but make reports and all types of wonderful things.
Not every project's going, not every web project is going to need it. But to have BigQuery, yeah, definitely check it out. But that's interesting to add.
[00:19:35] Speaker B: Yeah, I mean one thing I want to add is for even if you cannot or do not Want to query BigQuery yourself, the crux report, for example, there is a public, some like aggregation report that's called CWVTech, CWVTech Report. If you enter that in your browser, you basically see I would say a high level view of the types of things that we try to query. So it has, so this report has segmentation for all kinds of web technologies and how their performance is and how it has evolved over the years.
[00:20:09] Speaker A: Would you say it's the information that you have in there is better than built with?
[00:20:18] Speaker B: I mean I'm not quite sure at the moment.
I haven't looked at build within a long time to be fair. But I, I don't know. I can't, I can't really make up my opinion about an opinion about this right now. But I mean I want to say there is different.
There's also the other data set where like W3 text is the one that's very often referenced for WordPress adoption specifically. And I mean though the HTTP archive data set provides a slightly different adoption rate of CMSs than W3 text does.
[00:21:05] Speaker A: Yep.
[00:21:06] Speaker B: I don't know which one of them is truly more accurate.
One thing I can say is that HTTP archive, HTTP archive has I think only it has maybe like 17 million or 18 million websites in total. So obviously that's not the entire web. That's still only like, I don't know, my personal website is unfortunately not popular enough to be in there. So.
[00:21:34] Speaker A: Sadly.
[00:21:36] Speaker B: So it's not the entire web obviously.
I don't know if W3Tech somehow has a larger data set or if they, I mean the thing with that, it's also, it's not entirely public how they get to their data. So I, I can't I don't know, I can't make up. I can't see if that's better or more or less, more or less accurate than what HPR says.
[00:21:59] Speaker A: The reason I'm asking is, you know, the general curiosity of how we're measuring and how we're, we know what we say to be accurate is always the question in terms of looking at these types of performance things and the percentages that you think you should gain and what the actual impact has. Having worked with statistics myself a lot when, when I wore a younger man's clothes, there's always a curiosity, okay, how are we actually measuring? Right. So statistics is a wonderful field where you can deep dive just, just on statistics alone and what you can represent present and they don't necessarily have to correlate with the thing that you actually are showing. So.
Right. I've heard some stuff about Build with that. I go like, how accurate are we actually still with that tool? I think Yoast also on his CMS share, kind of moved away from it or might be remembering incorrectly. But anyway, so there's a whole bunch of features inside the Performance Labs plugin that are based off of things that you find.
How is the adaptation going from the Performance Labs plugin into Core? Because I've seen some things have landed in there, but if I look at the current version, which is what today is December 3rd, there's a lot of features in there currently, plus the little sub plugins that do even extra things that you'd expect to, I mean, I expected to have landed in Core way sooner than, you know, the, the current timeline. How does that go? How do, how do you decide which one goes and what, you know, what do you think of that?
[00:23:49] Speaker B: I mean, I think for once we always start with the features in the plugin to get some, well, first for once, user feedback, but also that we can measure the impact at least for the few sites in that HTTP archive and CRUX data set that use the respective plugins. There's obviously a lot less than WordPress. So it's not going to be entirely representative of the impact it will have in WordPress.
But yeah, in terms of landing it in Core, one of the things that is really key when it comes to, for example, new web features is that they're somehow adopted either across browser or standardized as part of the HTML spec. So that's a blocker for some of the things that are currently in Performance Lab plugin, but not in Core.
Other aspects, other aspects like.
Yeah, like this image prioritization engine That I briefly just mentioned, it's an extremely powerful feature, but there are also some. It's also quite complex. So I think that is a simple.
Well, it's not simple. It's a matter of.
It's a matter of getting enough core developers, well excited and on board about this. I think this is because it does certain things like it does certain things like run client side JavaScript to detect things and then send it to the REST API, which I'm going to say like it's trying. I think we're doing our best there to address any potential like security and security concerns and traffic concerns. But I want to say like when a core developer hears public endpoints, front end request, every. All alarm bells go off. And I think that's like, for that particular plugin, that's something that will require quite a bit of solid. And so yeah, thorough testing to make sure it's ready for Core if it. Yeah, like we hope eventually it will be. But I think it's still in a. That those plugins are still in a very early stage. And then there are other plugins like the modern Image formats plugin, which I think, I mean that we did, we did try to get into Core a while ago, but it was not. It ended up being rejected because of.
Primarily that. I think primarily back then. Yeah, primarily back then the problem was that those modern image formats are not enough supported outside of the web, which I, which, which I agree, honestly, like, I don't, I don't like to agree but like there's still, when you look at WebP and Avif, a lot of the stuff like when it works great on the web but then when you download it you get screwed in many places where you try to use it. And that's.
[00:26:59] Speaker A: Yeah, that's.
[00:27:02] Speaker B: I actually, yeah, I don't, I don't necessarily personally agree with that being the reason not to land it. But that's kind of where we ended up and yeah, so we kind of have to get back. We have. Right. At this point it's basically, at this point it's basically, I would say a canonical plugin to use modern image formats in WordPress. But if we wanted to land it in WordPress Core, we would need to come up with a solution for that problem. Like honestly, I think it should be. Part of me thinks this should be a browser thing that you can, if you right click an image and download it, that you don't get the modern image format but you just get a jpeg. Because honestly if you use offline images, it doesn't matter that it's fast or not. Like, I mean JPEG is fast enough.
[00:27:48] Speaker A: When you talk about offline the problem there. Indeed, if you're trying to solve these types of issues, right, you're either fully dependent on the browser functionality to do this on the fly as your download or as you're
[email protected], you go, let me download that. Then have that automatically saved as a jpeg. Not even asking, because if you're introducing a dialog, you're going to complicate it even more. You have to solve it on browser level, which is difficult in and of itself because if you got one, great. But there's a few more than one browsers. And then the other problem is if you don't want to solve it through the browser, your OS needs to support it. And that's probably even the more difficult route like Mac OS X needs to do it Windows, whatever version it is on Linux, probably the easier one.
[00:28:40] Speaker B: So there's, I mean either, either we can come up. I mean the good thing is in, in, in our position at least we being work, working at Google, people that work on Chrome are just around the corner so we can try to talk them into buildings exploring something like that, at least in Chrome. And, but would you say Chrome. Yeah. It is indeed difficult.
Well, I mean, on either, either side, I guess.
[00:29:08] Speaker A: I mean, because if you solve it in Chromium, you have a whole bunch of Chromium browsers now dependent on that. So.
[00:29:15] Speaker B: Yeah, yeah, I mean, I think it would be probably in Chromium because Chrome is built on top of it.
[00:29:22] Speaker A: Yeah. And so is Brave and Edge and you know, quite a few others. No, but that's, that certainly is a challenge. Like if you have.
And the question in my head is still like, should that be the reason why it's not being implemented?
You can argue that if you are implementing it, it's available and for those downloading finding themselves in like, hey, why doesn't this file work? That sort of creates the, the public demands it now. So hey, you could argue that WordPress has the obligation to have a positive effect on all things data consuming. Why not added in? So people are going to ask for a solution.
[00:30:09] Speaker B: This is the famous chicken and egg problem. We have that with a lot of things. Also when you talk about, I mean this is a whole. Even when you speak about the whole actual web technologies and web standards that already exist, there's often the question, okay, like browser X does not support this feature.
So someone says not land in WordPress because it's not supported in that browser. But then you could also argue we should land in WordPress because WordPress has such a big impact that then maybe the people work on the browser will be like, okay, we should support this.
[00:30:44] Speaker A: I find myself leaning in that direction most of the time because I think if you have an influence such as WordPress has, you're kind of.
Yeah, I think you have a responsibility to be the leading example. And this is a great thing because again, I see a whole bunch of features in the Performance Labs plugin and the auxiliary plugins to that of which I go, well, the support for it is big enough.
Why aren't we adding it? It's been in there for three, four months now. That's a long period. That's a full release.
And I get that certain features are very tough. Like they're multifaceted, they're very complicated. There are many, many edge cases. I get all of that. Again, I built software myself for various situations where you go like, oh, I thought it was working, but hey, I guess it wasn't because here's another scenario I hadn't thought of. I'm fully aware of that. But like I said, yeah, I think we have a responsibility there.
[00:31:49] Speaker B: I mean, I think for it's worth, I think WordPress has at least it has become better at that. I would say over the years that it does more of the progressive things. Like there are more. I feel like we have been landing more progressive enhancements in WordPress than we did 10 years ago. Like, I think the policy used to be a lot stricter and Gutenberg is also pushing the boundaries a lot I think of on certain. On your. Some modern technologies and so I think that it's a good development. But I completely agree with you that there should be even more.
[00:32:22] Speaker A: Yeah, let me be very clear on. Because the performance team, the impact you said it's been there for three years now, the impact that that has had on the actual performance of WordPress on so many different facets in terms of not just Performance Labs experiments, type of stu. But also like I just look at Johnny Harris's very thorough looking at queries and optimizing queries and having this new query class that is then made at use at all these various aspects of queries that we're doing. I'm sure other people worked on it as well, but I talked to him about this, so which is why I'm mention him specifically. But that type of focus on all things WordPress I think is, you know, three years may sound like oh wow, it's a long time already. But in hindsight that is way too short of a period to be focusing on, on performance.
Right, right. Years back there was somebody who did like the test that you are now doing from version 65 to 66 to 67, where you see how certain queries are being faster, load times are faster, you know, all these things. But somebody did. This is probably seven, eight years ago and I forgot who, but somebody did like the same thing for older versions of WordPress. And then going back like this is the download size and this is, these are the default theme and how fast it loads and all of these things. And you could see like an improvement and then you saw flattening and then you saw a dive. Like it got bloated. Bloated, wrong word probably. But it got slower.
And again this is the thing I think the responsibility that we have, and I couldn't be more of a fan of what you slash Google slash the performance team does in terms of just looking at the whole let's make this thing faster.
[00:34:28] Speaker B: Right. And I mean I want to add to that. It's also at least sometimes it's, let's not make it slower because sometimes, I mean there's always new features coming in and those features have a cost and sometimes if it's a really big thing that's needed, yes, it has a cost, then let's just at least try to keep the cost of this feature as low as possible. Maybe this release we will not improve performance, but we'll at least keep the status quo even though this big feature is being added. That's also a way to look at it. So I think that sometimes worth emphasizing when certain releases, even the ones where we were closely involved, they have slight regressions or they don't improve.
And I think that doesn't necessarily mean that performance actually degraded in bad ways. Sometimes it's just, okay, here's this big feature and it had a cost and that's it.
[00:35:27] Speaker A: It's a mix for sure.
I kind of want to add to that the.
There is a part of me that finds, I mean we're, we're over optimizing as much as we can. Right. So we were trying to find the things to do, which means scripts are loaded only where they are loaded. Scripts are being minimized as much as they can. Scripts are being loaded in a sequence, but you know, done smartly. Images, same thing. You optimized as much as you can, where you can, whenever you can. You lazy loads when you only load what you need to load and all of these things.
And once we've, once we've produced a website like that, and let's say I produced it and you visit that website, you get it in the most optimized version. Perfect. And that's the goal. And that should be the goal. But if you then go to YouTube and start watching a video, I go like okay, how many mbs was that? Like, so what did we actually say?
This is something I'm wrestling with every now and then. Yes, we want to optimize And I know YouTube as the example I've used optimizes the way video is being loaded and onto your machine and only that which you're actually are going to watch. I get all of that. But you know, watch YouTube for 30 minutes and you've had hundreds of megabytes download to your machine. Right. So it's sometimes a little bit difficult in my head like what are we actually solving if we're also seeing a huge increase in video across the board? YouTube is an example. But Instagram TikTok.
[00:37:11] Speaker B: Right. Yeah. I mean, tricky problem.
I mean this is a tricky, definitely tricky problem. I guess when you talk about, when you look at it from a sustainability perspective, then yeah, then I guess we shouldn't be watching videos on the web. We also probably also. But, but then, but from that perspective it's, it's very, I mean it's, it's hard to reason about it because at the same time then you could argue, well, we shouldn't be using images on websites because they're also by far the worst thing that is on website. I mean unless you have video on a website, which please don't, it's even worse.
But, but yeah, like I mean, I think at the end, I mean I think at the end what we're trying to do with performance is I suppose provide.
Find the most reasonable way to get sites performance given the resources that they want to display to their users.
And I think in the end the goal is to have, I mean, better. Yeah. Have faster experiences for, for the end users in.
But if your site, if your site is a video platform, you will have worse performance than a blog with some text. Like you can't fix that. Like you can't work around that.
[00:38:26] Speaker A: No, no, I mean like I said, it's a, it's a, it's a weird thing that every now and then pops up in my head like, great, I optimized this, I saved that and all. Great. And then the, the actual site that I worked on is linking to A lot of videos, it's embedding a lot of videos. I go, yeah, yeah, that's a bit.
[00:38:46] Speaker B: Yeah, it's a bit frustrating. I suppose that makes a lot of.
[00:38:49] Speaker A: Sense in a way, but I guess that's the chasm in which we have to work.
You build a lot of plugins or work on a lot of plugins for the performance side of things as you're working at Google. But you very recently released a plugin that sort of highlights a very different type of interest.
You have a plugin called AI Services, which I thought was a brilliant plugin. First thought I actually had when I saw it was like, wow, this should be in core for the simple reason, because it solves a problem from a foundational level. But maybe explain a little bit how you came to figure this plugin, figure this one out. Oh, I need to build this. And maybe kind of walk us a little bit along how you look at AI in the context of this particular plugin.
[00:39:56] Speaker B: Yeah, I mean, I mean, as many people I got curious about AI in recent years and I noticed, and I tried some WordPress plugins that do things with AI before I really got more into technically myself.
What I basically noticed. One thing that annoyed me is that more or less Every WordPress plugin adopts a certain cloud provider service. Like, I mean, whether it's Gemini, OpenAI or any other ones, like most plugins, they pick one and implement support for it. And what I really, I mean, that works, that's fine if you use like one AI plugin. And today maybe there aren't that many in the WordPress ecosystem, but I think there's obviously big, a lot of, lots of opportunities to use AI to help with content creation and even other things like maybe even performance, as I mentioned before. But what I want to say is imagine a future where you have 10 AI plugins on your WordPress site and one requires Anthropic and one requires Google and one requires OpenAI and one requires Replicate or whatever. And then you have to get subscriptions with all of those providers to use those features that you don't necessarily need to use. Exactly. That provider that the plugin author added support for. So it really puts the, it puts the burden on end users like both, I mean, both from a bad user experience perspective and financially because they would have to pay all the different providers just to use certain features that they could in theory also use with just one. All with one provider, for instance. Yeah, that's one of the things that bugged me a lot. And then I kind of thought about it further, like the reason, I think one of the reasons for that is that these providers have different APIs, they are not uniform. So it's a lot of work to implement support for multiple. What's even made worse because a lot of those providers do not provide php SDKs.
So you can't just use some code library in your plugin. You have to either find an open source community maintained one or build it yourself. And I've seen many plugins kind of currently do the latter, which then can lead to kind of poor quality solutions. Because as a plugin owner that builds AI based features, you do not want to build an AI client, you want to build AI features. So you want to get this done as fast as possible, basically.
And I think in the end, again, going back to.
Because it's so tedious today to adopt AI in a plugin, most plugin owners go with probably whatever provider they use the most and don't consider others. And that in the end puts the burden on the end user, let alone there's also the ui, the poor UI experience of having to paste API keys in tons of different plugin UIs.
Like if you use, I mean, let's say you have, if you have 10 plugins that use Gemini, for instance, you should just have to paste this in one place, your API key, not in every single plugin screen. The same API key.
[00:43:33] Speaker A: Exactly. Yeah.
[00:43:36] Speaker B: So I think that's why I came up with the idea that there should be some general infrastructure for AI. So basically, in a nutshell, the plugin I built is providing an abstraction layer around AI services. So then that you can talk to any AI service with one uniform API. So that as a plugin developer you do not have to pick and choose. You can just say, okay, my feature would work with any of those providers and then the end user can choose.
[00:44:10] Speaker A: I like that. I really like that principle of just solving a headache, basically. So first of all, I don't think anyone should ever have to copy paste API keys and secrets. I think you should want to build it in such a fashion that you can do that underwater. The Exchange, which is what we did for instance for our Scanfully plugin for the, for the SAS version of it. So the only thing you have to do is install the plugin and then hit one button and it, if you're logged into both, it just syncs. Right? That's how smooth things should work.
So I like that we've done that and I like seeing that in other projects as well where you want to say not only am I solving the problem of what you just said, like whichever AI you want to use shouldn't be relevant to how you solve the problem once you are inside WordPress, but also make it as frictionless as possible because I think we on the whole see way too many people just not fully understanding the basics of what they're actually needing to do.
And certainly we may think AI has seen a high adaptation already. But if you look at it on the whole, I think we're just starting like literally, I think we're just starting to wrap our heads around implementations of AI, versatility of how to use AI, on what level, in what degree, and all of those things. I think we're just trying, starting to see how those things could be implemented. Is there a particular implementation of AI inside of WordPress what you are especially excited about?
[00:46:08] Speaker B: I mean first, just. Yeah, just to add to this, I even feel, I mean we're definitely scratching the surface with what's possible with AI, but I think we also, I think specifically in WordPress there isn't even as much AI as in other industries. And I think partially that is owed to the difficulty that it is today to even get the foundation ready to use AI, which is that's not really using AI, that's just building an API client, which I have to say I love building APIs, so I love doing this kind of stuff, but I think a lot of people would find that boring and they rather want to build AI immediately. And that makes a lot of sense. You want to build features based on AI. But yeah, I'm going to your question.
I'm excited for definitely some assistance with content creation. I think there's a lot of opportunity with AI to suggest certain outlines of posts, for instance, or suggest categories based on the categories you have on the site which fit to the post that you just wrote or maybe even create new ones.
I think there's, I mean I personally like a lot the idea of alt text generation for images. I know there's definitely varying takes on the quality of the output, which makes sense, but I think there's a big opportunity there because I think, I mean if you're not like a lot of, I think a lot of administrators of WordPress, they're not necessarily where still not necessarily worried that you have to put alt text for good accessibility on images.
And my take is a little bit like if the, like, is it better to have like a slightly inaccurate text or not at all? I mean this is maybe a controversial question, but like I think It's a very valid question, but I think if the user would completely forget it, then I'd rather I think AI from what I. From what my early exploration is. I think it's at least reasonable enough. Like the output that I've seen in most cases.
[00:48:21] Speaker A: I think for me it's the Pareto principle. I very much see I've played with a few tools like that. 80% is great, 20% is.
And if we take the 8020 as a base, even 70, 30 would be fine for me to just have. Have something there versus not having anything there. Because the goal is to be informative. Right. For those who can't see the image and to then somewhat accurate to accurate display tell what the image is about that that's good enough for me.
[00:48:59] Speaker B: I like yeah go well and it's. And I feel like they don't.
I haven't come across many times where it said something completely different than what was in the image. That's obviously at that point it's really not helpful. So then maybe not having nothing would be better. But I mean, I don't know.
Definitely a human will not be replaceable with AI and I think we can all agree to that.
But I think in many cases it will do a better job than the.
[00:49:32] Speaker A: User not adding anything I have so this podcast will be transcribed in descript, which is an app that we're also recording this in. It's an app that does a whole bunch of optimizing what is being said.
There's too much to mention on the positive side of what this app can do. But one of the things that it now has, it has an AI integration called Underlord, which I absolutely love the name of. But the Underlord does a whole bunch of turning whatever we just said, turn it into a YouTube video description, including the markers for the chapters and all of that sort of stuff. If you don't like the title, you can ask it to propose a different title. If you don't like the output or whatever. There's. I can't recite by heart right now what the options are, but there's tons of options it does with its Underlord AI.
Those are exactly in the line of what I would love to see on the WordPress side of things. And I think I've only played with the generative side of AI inside of WordPress with Yoast SEO Pro Premium where you can have your meta descriptions be suggested in five different versions and you pick one of the five. So you hit use AI, you click it and it presents you five options.
Funnily enough, I 9 out of 10 times just pick number two. I don't know why that is, but number two usually is the one that is most accurate for what I intend to have as a meta description. But those sort of things to me are my favorites where it just makes sense for me not to do the manual labor side of things, if that makes sense. Generative short but this is summarizing, knowing what I actually want and then sort of play with it. In the case of Descript, there's, there's a little bit of extra prompt that I can add to it, that sort of stuff.
I see huge potential for AI on that side of things, but it can do so much more.
What do you see in terms of it doing for coding and maybe even templating stuff and things of that nature? Have you played with that?
[00:51:57] Speaker B: I mean, I mean I haven't built anything like that myself so far. But I wanted to say, for what you mentioned before, you bring up a great point with the whole picking options from something that AI generated. I find this, I mean this is super common. You would need to use this for, I don't know, rewriting paragraphs of what you just wrote or generating titles, generating meta descriptions, generating tags or anything like that. And that's something I've thought about a lot. I don't know, as a meta thing, I would love to see, I don't know, some JavaScript or web component that implements the picker kind of UI. Like I feel like that's such a common thing to have and I would love if there was. I mean, I know like modals are not necessarily beloved in many ways, but I feel like that's for that, for, for that kind of thing. Maybe it's a reasonable path. I think for now. Like I've seen. I recently saw a talk at some. There was a web AI summit that I went to recently where so there were two speakers that were working on a very big CMS in Japan. I don't recall the name, but they had built something like this for, for like, for like that CMS that helps that choose, propose different titles and proposes different other elements for the content. And, and I thought well this, this kind of thing should be. Could be like an abstract UI component because it's needed in so many, for so many content assistant scenarios where you have to pick. You need to be able to see three options next to each other, let's say, plus potentially the one you already populated if you want to have it revised by AI and then you. To Make a good decision. I mean definitely people can build this themselves, but I feel like this is such a recurring thing that it would be good to have a UI component for that.
[00:54:02] Speaker A: So what you're basically saying is there's you have the functionality of your AI services plugin, which in my opinion should be a core thing inside of WordPress and I really hope you work toward that end to get it in. I think you have some sway there.
[00:54:22] Speaker B: I mean my goal is definitely to make this should become an general infrastructure that at the very least economical plugin, I hope.
But ideally long term in core.
[00:54:38] Speaker A: I think that should be the goal, if I'm really honest. But then I also hear you say as we're building these types of things, we have decisions to make in the UI that present certain things as we're bound to have more and more.
I think that makes perfect sense.
Yeah. And like I said when I introduced this topic, this is one I'm very excited about because what I think it does, it makes WordPress shift from whatever trajectory we were on into let's try to make this thing we're using to create our content and manage our content and take the manage part very light here. I think there's a lot that we need to improve on that part as well. But if we start approaching all the things we're adding to it from a structural, let's do it foundational, smart in a way that other folks can just easily build on top of it.
I really like the approach to see that as the default approach for anything being added. So if we're adding this feature, great, but what is it part of what is the bigger thing here? And maybe we finish building that layer first before we actually do the implementation of that feature. Because we need that layer. And I know for instance on Project Gutenberg a lot of that stuff is already being done in that fashion, but I'd like to see it a lot outside of Gutenberg as well.
[00:56:09] Speaker B: Yeah, completely agree.
That's one of my favorite topics outside of performance. End of AI is like just standardization of certain things. Like it's boring as hell.
Yeah, I like it.
Blocks, blocks and I mean blocks are doing a good, have been doing a lot on that end to make certain things more standardized.
Like for instance how blocks use like assets like JavaScript and CSS and but, but, but. And full site editing of course emphasizes that even more because now blocks are used for pretty much everything. So that that makes it even better. But then there are still aspects of content management that are not part of blocks. And those are still, I feel lacking in WordPress and like for instance, I don't know. One of the things that always comes to mind for me is like form, form plugins.
There are tons of form plugins. Where do they send the data? How do they send the data? Like there's no core API that provide foundation to be like here is how you should accept form submissions to the back end and then pipe them through to an email notification or whatever, third party membership, whatever newsletter servers. Yeah, yeah.
[00:57:33] Speaker A: Every single form plugin that does any type of form needs this. They have it. They're such a shame that this is not a canonical thing again. No, I agree. I think we're on the same page here.
[00:57:49] Speaker B: But I mean, I want to go back to the question you asked me though before about the coding assistance.
I think one of the ideas that I've thought about a lot is.
Well, actually it goes back to standardization too because we don't have standards for many things in WordPress, core plugins do everything completely arbitrarily. Like many things, they have to build their own. So then form plugin A works completely different from form plugin B. SEO plugin A works completely different from SEO plugin B. And that goes for every niche.
And you cannot reasonably migrate from one plugin to another. WordPress has a serious vendor lock in problem, I think. And as soon as you start using one plugin and use it for a while, you cannot never get away from it unless you call a developer to do it for you.
And that also is a concern from us looking at performance because we sometimes we have been exploring ways to how can we assess performance of plugins and how can we recommend alternatives? Which is another great point for where I could be helpful.
But then the last thing that all of this always gets stuck is at is how do you even migrate? Like if, let's say we found this great plugin that you could replace this plugin with, how do you even migrate? Like you can't.
And there, I mean this is maybe a crazy idea, but I like, I thought about a lot. Like if you could give, if you could train an AI model with the code basis of tons of WordPress plugins.
[00:59:42] Speaker A: Maybe all in the same niche or all.
[00:59:46] Speaker B: Yeah, yeah, you would learn AI models, the AI model would kind of learn the database structure of WordPress. I mean that, that I'm sure it already has a lot of that even with the default models we use today. But then it would learn how each plugin kind of stores things in the WordPress database and then my dream here is that you could be like, okay, give me a plugin that migrate. Give me a code snippet that migrates my data from form plugin A to form plugin B, and AI generates the code because. And I think when I think about it, this is like, I mean, we're talking about gigantic amounts of data here that AI needs to consume to make it happen. But I think it's possible and it's also a task where I feel like AI is perfect for it because it's not difficult. Like as a developer, you can easily figure it out. It's just tedious. And you won't be able to do this for 60,000 plugin combinations.
[01:00:47] Speaker A: Exactly. It's time consuming.
As you were explaining this example, one other one, there's another one that I thought of.
If it has access to all the plugins and WordPress itself, including a proper full understanding of APIs, database schemes and all that stuff, you can actually ask it to say, look, what are the areas where we should standardize?
Like, what is everybody using?
[01:01:18] Speaker B: Right, yeah, that's a good point.
[01:01:22] Speaker A: So basically, to analyze all the different methods, you can ask it to analyze it proper and say, come with a recommendation, highlight the points of where there's no question, and then additionally highlight the elements of where we need further research and all that.
If you're adding all of this into an LLM, my word, there is a lot of opportunity there.
[01:01:49] Speaker B: Yep. I think we need some gigantic plugin code base AI model that would help with so many things.
But yeah, I mean, what you just said, maybe I don't know if that's what you're referring to. Like, for example, going back to form plugin, like, AI would be able to tell us X percent of form plugins store submissions in a custom post type X percent of form plugins store it in a database table. X percent do something else.
[01:02:19] Speaker A: Yeah, yeah, but also, then standardize. Hell, you can have the AI reach out to all the plugin builders and say, look, we're standardizing this way. This is the snippet you would need to add to migrate script and all that. I mean, heck, we can do. Oh man.
[01:02:34] Speaker B: Directly in the code editor, of course.
[01:02:36] Speaker A: Yeah, yeah. Also, yeah, I mean, we're just about an hour in in this conversation, but I think we just added the potential for what are we. What else can we start standardizing?
That's at least another hour.
Yeah, I mean, the future is bright no matter what's going on left and right, but I think the future is bright in Terms of all the opportunities that we have ahead of us to come with a more complete, more, more versatile, more standardized, more smarter cms.
I think, I think we're just touching the surface here with what we currently have available and an understanding of what AI can do for us.
One last question for you, if I may.
You like performance, you like AI? Do you see a bridge between the two at one point?
[01:03:42] Speaker B: I think definitely a few ideas there.
I think AI could be helpful in the future or well even today if someone just tried to build it.
But in terms of trying to find problems, performance problems on your own website. So you could have kind of an AI performance assistant.
I think there are definitely products out there that have started doing this kind of stuff.
But for instance, we've started playing around. Nothing serious really but we started exploring how.
How could we first of all use AI to enhance the output of tools like Lighthouse or PageSpeed Insights?
Because some of the explanations gives are. Well for once they are hard to explain if you're. They're hard to understand for non technical users. So that's where I could be helping with. But more, but even more important if you add these tools do not have WordPress context. So if you had a WordPress plugin running that runs those things and kind of combines WordPress specific insights with the tools, then AI could I think make a lot more sense of it and explain that towards the end user. Like I don't know, here's this render blocking script.
That itself is what the tools give you, but it's not necessarily very helpful. But then you could be like okay, this comes from this plugin here and maybe you could have like an end user mode and a developer mode. For the developer mode there would be like here's this code snippet to.
To fix this. So this is only enqueued when it's actually needed or whatever fix is appropriate for the situation and for the end user. I mean you can't necessarily fix that automatically for them, although you could even try doing that. But at the very least you could say hey, this plugin does this and this.
I always go very blunt and say complain to their support.
[01:05:49] Speaker A: That's a good start.
I think there's even an extra layer. So there's. There's a whole bunch of stuff that I happen to fix on many sites that I been asked to make faster or help scale or however you want to phrase it. There's a few default things that I just check for because those are things that slow the site down. Slow queries is A good example, um, but one that I still surprisingly see a lot is the, the license check for a premium plugin happening on every single page load doesn't really make a lot of sense if that page load is 100,000 requests per day and things like that are just too default to ignore in these types of settings. I think you can check which whichever outgoing call is being made.
If that's one that's on page load, you can measure that and you can then say, look, hey buddy, maybe you want to cache that a little bit here and there, transient maybe, or whatever solution you want to do, but it doesn't make a lot of sense to do that on every page load, especially if the, where you, the thing you're querying is slow in response.
There's a lot of stuff you could actually do.
[01:07:17] Speaker B: Yeah. And then the other thing about performance in AI goes immediately back to that idea of a massive plugin AI database with the code base awareness and stuff.
Like AI could, for example, I could then we could also, but then feed it the crux data and be like the. OR HTTP archive data and say that this behavior in this plugin likely contributes to this kind of metric in the field, like in a positive or negative way, and assess performance of plugins at scale. There's a lot of opportunity there.
[01:07:58] Speaker A: I think you just added a completely new project to your list of things to explore, Mr. Arns.
[01:08:07] Speaker B: I mean all of this stuff is kind of things that we've been thinking about, but there are also huge lifts to get started and they take a lot of work to get done. But I think there's definitely opportunity here.
[01:08:25] Speaker A: I think so too.
I think it's inevitable that we end up thinking about solving our problems in such a fashion where the actual solutions we're looking for are so huge or so diverse or whatever that you end up going, at what point are we, you know, should we mandate ourselves to force to use AI first to then have the mundane stuff done for us and then come up with a list of things to then actually start fixing?
I think it's inevitable that we end up that way. And as I say the word inevitable, I'm immediately reminded of the Matrix. I don't know if we should, but the sound of inevitability is the quote of no, but yeah, I agree with you.
There's a big task ahead of us that at one point we're going to start saying, yes, we're going to be serious about this, we need to move forward with this.
[01:09:33] Speaker B: And then, I mean, I don't want to, I don't want to, I don't want to open another topic but I'm still going to do it. Like just AI and open source. How you do all of this in an open sourcey way?
[01:09:43] Speaker A: Yeah, yeah, well there are open source, so you'd start there.
[01:09:47] Speaker B: Definitely, definitely. And but like, I mean I would love to see if someone built this or established this AI, trained an AI model with all this data. It would be great to have this, make this available open source somewhere so that then all those, I mean we probably talked about three different ideas on what to do with that now, but there are probably hundreds so everybody should be able to do this kind of thing.
Yeah, I'm in that sense also very excited about AI kind of becoming more available on device and on the web because that way it doesn't require a cloud based provider.
That's kind of something that's just starting right now. I feel like it's becoming a little more popular.
[01:10:39] Speaker A: Yep.
Like I said, and I'll repeat, the future is bright.
There's just a lot of stuff to do but I think we'll end up with.
This is going to sound very, very big and very corny, but I think we'll end up with a better world if we start thinking in terms of how do we create that better world with the tools that we have available to us to do the mundane stuff. I think that, you know, exactly. Just starting with that is probably the best thing we, we have ahead of us.
I want to thank you for a wonderful conversation. I think we touched two, at least two topics that I hold dear and as you as well.
[01:11:23] Speaker B: Yep.
[01:11:23] Speaker A: I think who, anybody who's listening to this and wants to really start paying attention to how we do AI and what we can do with it and maybe even has ideas. Felix, where can they find you?
[01:11:37] Speaker B: My website is Felix Arns me and otherwise you can find me in pretty much all the socials under my full name. Felix arns except on WordPress.org I am Flixos 90 F L I X O S 90 which I always say this is. I always say this is my.
This. I believe I only have this weird username because it was the oldest platform that I created an account for when I was not yet a serious person.
[01:12:05] Speaker A: Yeah, last thing to note on that and then I'll let you go. But I think WordPress.org should allow a change of username once because I know a lot of people with usernames like this Swiss, Spidey, Ocean90 just to name.
[01:12:36] Speaker B: A few but maybe it's also fun. Maybe it's also fun to keep those weird usernames around.
[01:12:43] Speaker A: Sure.
The pros and cons. Pros and cons.
Either way, thank you so much for a lovely conversation.
[01:12:54] Speaker B: Yeah, thanks for having me. This was fun.
