WordPress Performance Revealed

[Music]

Jakob: Hello and welcome everyone to Greyd Conversations. This is the first episode of a vodcast, so a comination of podcast and video, where we discuss WordPress topics and digital business in general with different international experts from various fields. So it will not only be me – each episode will feature different hosts from our team to share or different perspectives on things. So some episodes will be from a technical perspective like today. Some will be more business driven and others are more design-focused. And today I’m talking to Felix Arntz about WordPress performance. Felix, welcome to the very first episode of Greyd Conversations. Thank you very much for taking the time and joining us. Before we dive into the topic, could you briefly introduce yourself, tell us a little bit about yourself. Who is Felix?

Felix: First of all, hi and I’m really excited to be here, especially on the very first episode, that’s exciting. I’m a WordPress core contributor. I have been contributing to WordPress core since 2015. and I am a senior software engineer at Google. I have been working at Google for just over six years now and as part of my role at Google we are also contributing to WordPress with the specific focus on performance. So my team at Google is called Galaxy. That’s how we call ourselves internally. Doesn’t really matter externally, but Galaxy is supposed to stand for like we work in the CMS ecosystem, so we try to improve performance and adoption of web technologies in CMSs like WordPress. Of course WordPress is obviously the biggest or most widely used CMS, so that’s a big focus of us.

Jakob: So you are working for Google, but also kind of working on WordPress. Can you share a little bit about what does your team focus on, how does it work, why does Google have a team that works on WordPress?

Felix: I’ve been working in, I mean our team has gone through some permutations throughout the years, but I’ve basically been working on WordPress at Google my entire time at Google. And it’s always been about user experience and performance. So Google I think in a nutshell, Google cares about WordPress because WordPress makes up for a huge chunk of the web and Google cares about quality of content on the web. And when I say quality of content that’s not just, I don’t know, how nice the articles are and things like that, but also the user experience of consuming them. And because the user experience of consuming them, which includes performance, is what keeps people, what has people using the web. I want to say always there’s on the flip side more and more throughout the last I don’t know 15 years or so, the app ecosystem has been coming along. And the and apps are very much closed compared to the web, where typically content is public. So basically we want to improve the content, the quality of the web. And we do that by improving the quality of CMSs, because they make up for a large chunk of the web. And there are other teams in Google that do this similar kind of thing within other segments of technology style.

Jakob: So, really interesting, you mentioned performance is being part of user experience. I’m not sure if a lot of people are viewing it this way. Can you go to the details, why does Google or you view it as a part of user experience?

Felix: I think it’s best explained with an example. Like if you go to a website and it takes 5 seconds to load and then you have to click five popup banners away and another app banner away, that’s not great user experience. And that is related, is deeply related to performance. I mean the time this page takes to load, that’s obviously performance. So if you have to wait 5 seconds for a page to load, you may already have gone somewhere else. Of course when you think about five seconds – does it matter that much? But you visit so many websites and if every website takes, every web page takes 5 seconds to load, I mean that’s a lot of waste of time. So that’s one part of performance. But then also when you’re actually using a web page, this example of what I mentioned like lots of pop-up banners and cookie notices and ad banners and things like that, they make using the web and the website more tedious than it needs to be. Especially if they’re slow, if they’re slowly reacting, like if you click a button and it doesn’t immediately close, but only after one and a half seconds or something. You notice that. When I say these second numbers, it always sounds very little, but as a user you feel that way more than when I say one second. so yeah, and then all the other examples. If you click a button and the page is somehow kind of janky, you want to click a button, but just as you’re about to click it, the page shifts somewhere else and then you click on something else. I’m sure that has happened to you. That’s also part of performance, which directly leads to user experience.

Jakob: Really interesting. I think a lot of people, myself included sometimes, but especially clients or not necessarily WordPress professionals, think about performance as how fast is the page loading. But you mentioned it’s not only about how many seconds does it take to actually see something, but it also is about how does the site perform, how do I click a button, what happens afterwards, all these little indicators. So I guess performance is much more than just the light speed score.

Felix: Right, yeah I think a good way to summarize it, Google has introduced a while ago core web vitals, which is this sort of standardized way to measure performance. And core web vitals is basically three parts. They have very abstract names, so I’m just going to mention them: Largest content full paint (LCP), cumulative layout shift (that’s CLS) and then INP is interaction to next paint. So, largest contentful paint is essentially the one of those three chunks that’s related to how fast the page loads. But the other two are about other things. So even when you look at it from this perspective, this how fast the page loads, is only one third of what’s important for performance. So in other words speed is only one third and the other ones are broader topics. I mean the other parts somehow also relate to speed. However we want to define speed like for example, INP is about interactivity. So when you interact with dynamic elements on the page, like if you want to expand an accordion element and you know you click on the header. If it expands immediately that’s good INP. But if it takes a notable time, like if it takes like half a second or something, then then that is not good for INP as an example. And so that’s also still about speed, but more about the speed after the page has loaded, of things that you do on the page.

Jakob: So Google does not only track how much time it takes until the page is loaded, it tracks all these little interactions. Does Google actually click all the buttons? Can you, without going too deep into how the technology works –  Google measures all these things, right?

Felix: Right. I’m not exactly sure how, like how this happens from the Google search perspective, but I can say, Google Chrome for instance has a setting to opt-in, to send anonymous data for usage data. And  for users that enable this, it basically tracks the performance of sites that they visit. And this later goes into a highly aggregated and anonymous data set called the Chrome user experience report, called short Crux. So that’s a public data set that the Chrome part of Google makes available which includes the aggregated metric values for those three metrics for all sorts of websites. It’s just, that websites that are included in this data set, have to have a certain popularity, simply because of anonymization. Like if you have a website with 10 users a month,  that’s not sufficient, because otherwise it would be too granular essentially.

Jakob: So in general you would say, how would you, how Google defines website performance? So those are the three key indicators and this is what defines performance? Or is there more to it? How do you, how do you at Google define website performance?

Felix: I think  the performance on the web is basically how do people experience the page. And we you have these metrics to try to represent this in metrics of course. But at the end of the day, those metrics are only as useful as they indicate how performant the page is to the actual end users. And we have seen that, for instance, I can quickly go on a side story here. There used to be another core metric called FID –
first input delay – that used to be the third metric until earlier this year INP replaced it. And that was one of the things where at some point it became clear that this FID metric was not sufficient to accurately represent how well sites are doing in terms of interactivity. So that’s why a newer metric that has more granular, that goes into it more granularly, was introduced. And I can give the context, like this FID metric for WordPress sites and more or less the entire web, it had 95% passing rate or something like that. Of course it would be great if we all had amazing websites, but if the passing rate of the entire web is 95%, maybe the metric is too easy to pass. That kind of shows where FID was not good enough. But now INP is more representative. And yeah, one of the problems with FID was that it only looked at the very first few interactions on the page, whereas INP tries to capture also interactions that happen after 20 seconds or something, when they user was on the page for a while.

Jakob: Very interesting. So I understand it as performance is.. You try to measure the experience and that’s really an interesting thing. It’s not necessarily a metric that’s only a metric. It’s a metric that tries to calculate experience. And that is something I haven’t thought of in that way before to be honest.

Felix: I can give another example with the LCP metric. With largest contentful paint, which measures how fast the page loads, it actually measures how fast the visible part of the page loads. So you see the little screenshots. Yeah. I think probably many, many years ago, historically people would think of the performance as how fast the entire page loads, but really when you, I don’t know, when you have a long page with lots of, I don’t know like a block archive or something, you don’t care about the 9th and 10th article on the page, because you can’t see them. So it doesn’t really matter that much how long the entire page takes to load. What matters more for the user experience is how long the part that you can immediately see takes to load, so LCP. Let me share my screen real quick. I have a light speed test open right now. Let me share the screen, just so others can understand a little bit better what we’re talking about. So that is wordpress.org. It has failed some tests, but that’s not something we’re focusing on. So this pretty much is what you were referring to, right? So the time it takes to visually load things, right? Exactly, and this is a great example here to see that this is a mobile viewport. And you can see on top on this pagespeed insights tool you can change it to also load desktop. And that’s why this is important, because what you can see on a web page is different between different viewports and especially mobile and desktop. They have very different implications usually on how this website is displayed. That’s why it makes sense to break it down at least like that. So if obviously the time that the entire page takes to load should be more or less similar between mobile and desktop, other than of course that mobile devices also tend to be weaker than desktop devices on average. But because the viewport is different, the implications become even more different than just how good is the device.

Jakob: All right, let’s talk a little bit about WordPress. So we have talked about what page speed, performance, call it whatever you want, is. Let’s talk about what it does inside WordPress. So first of me as a user, a client or a professional, I want to upgrade my performance. So I stick in some caching plugins and make some quick fixes. Is this enough to ensure good performance?

Felix: This is a great question. I will say the answer is uh no, very blunk. But let’s go into it more deeply. Caching plugins only affect one part of the stack, which is essentially the server side response. It can definitely be a good idea to install a caching plugin. You should still always test how well it actually improves the response time of your page. But at the end of the day, the caching plugin only improves how fast your server response is to the user requests. And there’s actually a metric for that, too, which is called time to first bite – TTBF. TTBF is only a part of what contributes to this largest contentful paint metric LCP. So it’s definitely a good idea to have some kind of full page caching layer on your website, but it’s not enough, because the client side performance, so like the things that load in the browser like images, JavaScript CSS, those kinds of things are also impacting performance. So it’s also crucial to optimize those as well. And that you cannot do with a caching plugin.

Jakob: What other choices do impact the performance? Is the choice of my page builder, theme, does it have implication? I guess yes. Are there specific challenges you’ve observed?

Felix: I mean more or less any plugin can have an impact on performance. It’s very difficult to automatically being able to tell that for every plugin, because what plugins do is very undefined. They can do whatever they want more or less in WordPress. That makes it challenging to come up with some formula to say how good is a plugin in performance. But yeah, I think it’s always a good idea if you are able to try multiple plugins for a certain use case, compare the performance afterwards and maybe see what they do well or maybe don’t do well. And the tool that you just showed, page speed insights, that’s one good way to do it. Don’t focus too much on the exact performance numbers that you see there, because that’s only for that one specific request you made. But what’s good, what’s definitely helpful there, is it still shows trends. And it shows those recommendations and potential problems that your page has. And then if you do run this before you activate a plugin and after you activate the plugin, you may see a difference.

Jakob: So I go ahead, deactivate plugins, maybe switch a theme. Even a backend-focused plugin like a user management plugin, as far as I understand it can impact my website’s performance, right?

Felix: Right. If a plugin is purely backend, if it doesn’t load any JavaScript, any CSS, no images, nothing in the frontend, then it can only impact backend performance, which is still relevant, but then that part you could solve with the caching plugin.

Jakob: Ah right.

Felix: Usually at least. So if your website has a caching, a full page cache, it caches a page and it loads in I don’t know 150 milliseconds. If you didn’t have the cash maybe it loaded in, I don’t know 600 milliseconds. And then you add a plugin that makes it 700 milliseconds, but because it’s cashed that part wouldn’t matter so much, because it would still load maybe in the 150 milliseconds. All right, like as long as it’s only backend-focused I feel like that part you can solve with full page caching. But as soon as it adds something to the frontend, which many plugins do, then you have to consider the other aspects of performance.

Jakob: All right. So, you mentioned, I deactivate my plugin and I hit Google pagespeed insights. This is probably a go-to tool for many, myself included. Are there other tools that maybe you or your team or others out there, agencies, professionals can use aside from pagespeed insights, that you would maybe even recommend to measuring certain ties or diagnosing certain problems?

Felix: There’s definitely some other tools similar to Pagespeed insights like web page test and other tools from other companies that are also useful, but they’re all sort of trying to tackle the same problem or similar problem. There’s another way that you can monitor performance directly in your browser, at least as as long as you use certain browsers like I think most major browsers have some kind of performance panels integrated in their developer tools. So you can use those to gain more granular insights on certain aspects of your page and I think eventually
those kinds of use cases are useful if you want to debug some performance issue or like try to find out how does a certain plugin impact my performance. But eventually if you want to really measure performance and how well it affects your actual users, you need to basically collect something we call real user metrics – short RUM data. There is a way to collect anonymous performance data of your users kind of the same way that Google Chrome does for the users that opt-in to it. But you could do it on your own, like for example using your own analytics tool.

Jakob: How do I do it? How do I do that? On a high level maybe.

Felix: So, what we recommend is, there is an open-source JavaScript library which is very lightweight, called Web Vitals JS. You can get that on GitHub for example. It’s a small JavaScript module that you can add to your page and you can configure it to work with, to send the data anywhere you like. So it’s not tied to any particular analytics provider or anything. As a developer you have to do a little bit of configuration there when you add this to your page to hook it up to whatever analytics provider you use or wherever you want to send the data. But then it will gather the performance data in the encouraged way and send it there and then later you can basically look back over, maybe after you gathered a week or a month of data, you can look how your actual users view the page. And then you may find problems that you would not have found while testing it yourself, because let’s face it, we usually test on our amazing laptops and desktops, but depending on who your audience is or where your audience is, they may use less capable devices or they may do different things than you do when you test them. Again, especially talking about interactivity, that’s very hard to predict. That’s something when you use pagespeed insights or any of those tools, they can’t automatically click on things, so they will only know part of the interactivity performance that you, that the site will give actual users.

Jakob: Do you yourself or your team, do you use tools like that, or – that’s very interesting to me as a developer – how do you analyze performance? Because I can rely on tools that are out there. Do you measure things differently? For example to measure interactivity, I imagine this must be kind of hard to get that data in an anonymous way and in the entire web. How do you tackle this issue?

Felix: I guess there’s two aspects of it. One is, see how well the overall web is doing. For that we have those public data sets like CRUX that captures that from the opted in Chrome users and – just for context – it aggregates it for entire websites. So you can see for example, like wordpress.org is popular enough to be in that data set for instance. So you would have an entry for wordpress.org that shows what percentage of its page loads have good LCP, have good CLS, have good INP, and from there you could for example aggregate all sites that are WordPress sites that are in this data set and then we can see, okay, from all WordPress sites, like I don’t know 45% have good LCP and good CLS and good INP. Which if they do that, that means they have good core web vitals overall. So basically, we can aggregate those this data from this data set even further to get like the entire what we call Core Web Vitals passing rate for WordPress as an ecosystem. But when it comes to actually debugging problems on a specific site that’s a different challenge of course. So for that I would say, we use heavily the tools that I just mentioned like pagespeed insights, but also even more so maybe the built-in browser def tools. If you like, I can briefly share my screen to show something. Give me a second. Well, I have pagespeed insights open, but what I mean, I can show it here, I had this open before. The Greyd – you say Greyd, right?

Jakob: Greyd, yeah.

Felix: I only got the pun when you said Greyd Conversations, I never I thought, I was always like is it great or is it Greyd?

Jakob: No, no. But it’s not that obvious. The founder of the company, or the founding of the company comes from a German word “grau”, which means gray/grey. And then it was combined with the word great and kind of like a twist to have a nice title.

Felix: Yeah, makes sense. So what you can do, in Chrome for example there is this performance panel. I’m going to click this away. Here, what you can do to measure interactivity for instance is, you can hit this record button and then you actually do stuff on the page, like let me just reload it for now. I’m just going to stop that. I haven’t done anything interactive, but there’s still some things loading and that may cause the page to slow down or anything. So this is very detailed, so it’s may look overwhelming. I have to say I’m also overwhelmed by this myself. But you basically see here all the little things, all the little processes that happen in the browser to load the page from the very beginning of receiving the HTML response to paring every single piece of JavaScript and CSS and all the figuring out the layout of the page and all that. There is, which is good, I don’t see anything here that’s problematic. So I’m gonna look at this one. This is the New York Post, also a very very popular WordPress site. Let me just test it. So I need to record here and let me test this one. So here you see, if you compare this to this you may notice that there are some areas with red little triangles here. Those are problems. So those are what may want to look more deeply into if you debug interactivity for your own website. Those are what we call “long tasks”. A long task is one browser task that takes more than 50 milliseconds, which means, which could mean that the page is blocked for those more than 50 milliseconds, which can lead to problems. For the other things to load slower or for user interactions to not react until those milliseconds have passed, which will cause a delay. So whenever you do this performance analysis here, you will want to look for those red triangles and then from there you can go more deeply, like what is happening under them. I’m just going to click something randomly here, let’s see. Here it loads a script. I didn’t build this page, so I don’t know what this is. But you will see here that there is a certain script here that… Um, oh no, this was actually not a long task. Let me see. Here you see, there’s certain function that run here from a certain script that contributes to a long task. So potentially, whatever this script does, could be optimized. That leads to a problem. I mean, I see that it includes the word ads. Very common, so I assume this is a third-party provider of ads of some capacity. Often times the poor interactivity comes from ad scripts or analytic scripts that come from third-party providers. And the problem with that is you can’t optimize them, because you don’t control them. As much as you want to try to improve performance there, you  could only file a support request, you file that you found a performance problem, but then it’s like, is this going to be addressed? I don’t know. So yeah, but when you use this approach you may find problems that come from your own scripts, from things that you control. Things that either you coded yourself or maybe that is something from a plugin. And the plugin, you can adjust how that plugin behaves for instance. So those  would be things you might potentially be able to fix.

Jakob: All right. So now you have a lot of data. You have a lot of metrics. And now your team works on improving WordPress core performance, your core contributing. Essentially you’re working on WordPress. You’re not working on Google essentially as far as I understand it correctly. So how do you, how does your team, how how do you achieve it? How do you start? How do you contribute to WordPress to enhance the performance on sites like – this could be a WordPress site, I’m not sure if this was a WordPress site. How do you start? What things do you do inside WordPress to improve the performance of it, like a huge chunk of the web?

Felix: I mean, obviously we do not control any sites, so we can’t fix, we can’t do what I just showed you for a site either. But we try to enhance WordPress so that it provides a better foundation for performance, for sites building on top of it. To do that first of all, I’m taking a step back. We co-founded the WordPress performance team about, was it, well it was almost three years ago now, or maybe pretty much three years ago. So that’s basically a team, an official team in the WordPress open source project, which was co-founded by contributors from various companies including us. So we now have a formal place in the WordPress project as a performance team. And in terms of what we do, we are heavily data-driven, so we try to look at the WordPress metrics and to see what we should focus on. For context, when you look at WordPress sites overall, what is the most problematic metric, is actually LCP, like how fast the pages load. But that’s talking about WordPress at scale. I’m going to say, if you, as a site owner, want to improve your own site, you need to look what are the problems on your own site. But speaking at scale, like all the WordPress sites that are available in the Crux data set, for them the on average the worst metric is LCP. So we are still very heavily focused on LCP. But additionally, especially because of this year’s shift to this INP metric, we’re also focusing on improving that metric, because as I mentioned before, this FID metric that used to exist was so good for all sites of the web, that basically the introduction of a better metric meant unfortunately that the metrics go worse for pretty much the entire web.

Jakob: That is one of the reasons why a client might see, ah my website was better a year ago, why is it worse? It doesn’t necessarily mean that my website went terribly bad, but maybe the metric has changed, right?

Felix: Right. And unfortunately it means often when the metric becomes better, the performance becomes worse. But to be fair, I want to say, at the end of the day, this all goes back to user experience. And the performance for the user was always similar. Let’s assume we didn’t make any change to the website, then it was always similar and the metric is just trying to capture that more accurately.

Jakob: You’re just compared to all the other websites out there, you’re not in the top 5% anymore, rather than top 10 or 20% right now, because the metric has changed and maybe the web has improved. This is how I understand it.

Felix: So we use that to define kind of our overall focus in terms of metrics, but then we also have to come up with concrete projects to work on. So for that we have also used things like pagespeed insights and there’s another public data set called HTTP archive that exposes data also based on the URLs that are in this Crux data set, but it’s a bit more manual, like it runs tools like Lighthouse and PHP insights, like basic PHP insights, against all those URLs and then it stores to makes those results available in my massive data set, so we can also try to query that data set to find out what are the most common issues on those sites that are flagged by Lighthouse.

Jakob: And these common issues, are there like common red flags? You mention external scripts like ads tracking and maybe caching is an issue. Is there something particular that you see on a lot of sites, like sort of repeated red flags or something?

Felix: I mean, one of the first things that we started focusing on back when the team was established, was modern image formats. You don’t really need to use Jpag anymore today for the web. So that’s one aspect of performance. There are more optimized image formats out there for the web, like webp or avif – avif is even better – that basically keep roughly the similar visual quality of the image, but the files  are a lot smaller, which means your end users of the site will have to download fewer image bites. And images are among the biggest resources that you could have on a web page, so they make up for a lot of potential problems. Whenever you use images, a lot can go wrong in performance essentially, which doesn’t mean you shouldn’t use images of course. You need to use images for your web page, but that’s always something to focus on. We created for instance a plugin called “modern image formats” which is a canonical, like a community plugin for WordPress that basically transforms jpegs or PNG files that you upload to webp or avif, whatever you configure it to do automatically, so that that the pages load faster for you and users. So that’s a plugin that helps you have a better practice, have a better output at the end of the day.

Jakob: I want to focus more on like beyond the plugins and tools, can you you share some of the insights of maybe what best practices are out there that agencies could potentially adopt to not only optimize the performance afterwards once the site is built, maybe some best practice that you could consider on the content level or structural level? Is there something that comes to mind?

Felix: If you start from scratch with building a new site, then I think my biggest recommendation that may come controversial is use a block theme. The new WordPress theme paradigm of using block themes, I mean it’s now been around for, I don’t know, two years or so. Full Site Editing or do you mean the Block Editor? Yeah, a Full Site Editing theme, so a block theme. Of course they have all the various benefits that I feel like that we all know about probably, but they are also beneficial for performance. They do a lot of things by default in a more optimized way for performance than the classic theme paradigms did. Did your team work on that as well on the engine I can call it maybe behind the side editing themes? Yeah, we we definitely contributed to it. We didn’t drive how this was built, but we have been a lot on the consultation side and also contributing certain things to it. The way that that block themes for example load JavaScript and CSS is a lot more granular than classic themes would normally do. Like in a classic theme you can still do this kind of thing if you want to invest lots of hours of engineering time, like do it manually basically, but that would be really painful and it’s not realistic for most sites. But because block themes are entirely block-based and the natural, I can say like one of the benefits that it has, when you use one of these themes you know which blocks are used on a certain URL, and the JavaScript or CSS bits and pieces that you need, they are scoped to the blocks. So rather than loading like one big theme.js file that does all the interactions for all all the things that the theme can possibly do in one file, you have those granular JavaScript and CSS files for those blocks and you only load them when they are actually needed. And I think that one of the biggest hurdles or concerns with using, also what many plugins maybe do today, that it’s very hard outside of the block theme paradigm to know when a script is needed on a page for instance. So you sometimes will run into plugins that load their JavaScript in the entire frontend and maybe you only need it on one URL or something. That’s the kind of thing that you would as a as a developer need to manually optimize today. But going block themes that’s something that they do in a much better way. And then the more plugins also build for block themes, the more optimized this will be in the long run.

Jakob: I can only agree. We are a huge fan of the block editor, comes to no surprised to nobody. Do you think in general that solutions that are sticking much closer to this experience and this roadmap that WordPress is doing right now, will outperform or maybe do already outperform third-party plugins that maybe have their own entire engine to do all that kind of things?

Felix: I think by definition not necessarily, but so far from what I’ve seen I would say, yes. Because from all the pagebuilders and other tools that’s I’ve seen, the built-in block editor in WordPress pays most attention to performance, to doing things in a way that’s good for performance. And again,  you have to do that to consider that when building the entire architecture of how that works rather than trying to fix it later. And that’s where I think the block editor has done a really great job overall.

Jakob: Yeah, we are a huge fan. So let’s shake things up a little bit.  I want to ask you some quick questions. Some of them might be performance-related, some of them not so much. You can feel free to answer them however you like. A single word can be enough. You can also share an entire story behind the answer. I will just go through some quick questions and yeah, feel free to answer them however you like.

Felix: Clear.

Jakob: All right, let’s start: Morning person or night owl?

Felix: Morning person. Used to be night owl.

Jakob: What’s the first website you’ve ever built?

Felix: Well, this was a website that never went anywhere, but I wanted to build a Diablo 2 tip website, like of the video game what I played when I was, I don’t know 15 years old. It’s actually what got me into HTML. Maybe if I hadn’t played Diablo, I I would not be here today, so I’m very grateful.

Jakob: That’s a really good one. That’s a really good one. What’s one WordPress plugin that you cannot live without?

Felix: Oh, that’s a tough one. Honestly I would need to look in the list. I have a list of plugins that I usually use. I don’t think I have a good answer right now, like for one that I would use on every single project.

Jakob: If we are by one, then tell me what is what is ONE fix that if you could fix this one issue forever inside WordPress, what would it be?

Felix: I think one of the things that are for me missing the most in WordPress is standards, kind of how plugins of certain behavior should implement certain behaviors. We have like tons of, I don’t know plugins for one particular purpose, like let’s say you need a form plugin. I mean, how many form plugins are there, probably 100 plus? And all those plugins implement this in their own way. There’s probably some similarities that we can find between all of them, but there is no standard in WordPress how to implement forms. So then every plugin does it their own way, which means any plugin that wants to integrate with a form builder plugin doesn’t know how to do it unless they implement integrations for all hundreds of them, which they won’t do. So they’re going to just pick their preferred partners or something. So I think standardizations – and that’s just one example, this form six sector of WordPress plugins is just one example – I think having more encouraged standards for how we do certain things in WordPress, that would be great. It would also make it a lot easier to migrate from one plugin to another. But because it’s completely unpredictable, you know…

Jakob: That’s basically a really, really good point. So let me put a question ahead that I actually initially didn’t have: Isn’t the block editor kind of a solution for that, could be the solution for that? Isn’t the block editor one default way to do things (just for frontends and blocks building)?

Felix: I think to some degree, yes. It does tackle part of the problem, but then again, as of today, too few plugins already embrace it fully, so a lot of plugins are still focusing very much on the classic theme way, which is fair because classic themes see more usage still as of today, but I hope the future will just shape it more into that direction. But then even beyond the block editor there will always be a need for other things that WordPress sites do, that at least today aren’t part of the block editor, like certain custom content type moderation in the backend and certain things you may be more on the CMS side of it, content management side of it. I wonder if maybe the block editor is gonna go in that direction to cover more of that at some point, but I mean today, like building a forms plugin on top of the block editor is certainly possible, but you still have to handle how are the submissions handled? Where do they go? For that part there’s no standard for instance.

Jakob: Okay, back to the quick questions. We have four left. The first one: Tabs or spaces?

Felix: Tabs.

Jakob: What’s the most unusual place you’ve ever worked from?

Felix: Hm. Oh, yeah. Well, I don’t know if I want to say that, but, I, this is even better maybe. I at some point launched a new Google sidekit plugin release, which launched literally with click the button, so please don’t worry that anything went wrong there. Which it didn’t. But I clicked the button to launch the sidekit plugin from one of these Tuk Tuks when I was in India.

Jakob: Oh, that’s great!

Felix: I clicked the button to publish the version. Going 50 miles per hour and launching it. I don’t even remember why that needed to happen in that moment, but yeah.

Jakob: What’s your favorite non-technical hobby that keeps you creative?

Felix: Well, I want to say it’s almost technical, but I like to do music production. So I’m still sitting in front of the computer, but it’s still a very different technical hobby I want to say.

Jakob: As the last part of this vodcast I want to talk a little bit about the bigger picture, so a little bit about the future. How do you see the future of the WordPress core, specifically evolving to address those certain things you me mentioned, to address performance challenges natively? How do you see it evolving?

Felix: I think, for me, I still have high hopes on the the block editor. I think a lot needs, more needs to happen in core to make it more feasible to use for more and more use cases, for more websites, that they consider switching existing sites, but also new sites. I think for new sites build it’s already quite popular to use the block editor or Full Site Editing specifically, but for existing sites to switch of course this is a big investment. So I think for that I would love to get to a place where we, where WordPress core and the Full Site Editing paradigm is convincing enough to have more sites switch towards it. I think that once more sites switch to it, it will make performance of WordPress sites overall better. I can just share, just like last week I was looking at… There are certain WordPress features that we kind of track using those HTTP archive data sets and Crux data sets. And I noticed, when I looked at all the features that we track, the one that has the biggest impact after sites enable it, is basically when sites switch to a block theme. From all things that we tracked, it has the biggest performance benefit. I mean you can add like certain performance best practices. They all had good benefits as well, but the one biggest thing that had the biggest performance impact in the metrics at least, was the switch to block theme. Which again is also easier said than done. It’s much harder to make that switch if you have an existing site, but maybe it’s worth it. And the other part somewhat related to block, to Full Site Editing, to block themes, but not necessarily:  There is a relatively new JavaScript API in WordPress core called the interactivity API. That’s something that I’m a huge fan of. And I think it’s going to – the more that this API gets adopted – it will drastically improve the performance implications of JavaScript. It will make the actual interactivity faster, but it will also reduce the JavaScript bundle sizes that you need, that any user needs to download. So that would contribute to pageload speed. So if you haven’t looked into the interactivity API as a developer, I would strongly recommend that looking into it. It allows basically to build interactions in a standardized way. And it’s the first time that WordPress core ever had a JavaScript API that’s intended for the frontend, so this is not used this like all the other JavaScript things that are made for the block editor, it’s actually you’re supposed to use that in the frontend of your website. The last thing I want to say related to that, please do not use jquery anymore.

Jakob: That’s one take I really like. We actually have used the interactivity API for the last couple of projects that we built, or blocks that we built essentially for the frontend. We couldn’t use it for each and every feature that we want to include, because it still had some limitations when we started developing these blocks, but yeah, I really love the it, I really love the concept. It takes some time to get used to to be honest, because it’s different how WordPress, or other libraries for that matter, are doing things, but once you get the hang of it, it’s a really awesome experience.

Felix: For any things that you found that didn’t work, it would be great to open issues or something, that the people that maintain it can try to address them. That would be super helpful. And the other thing related to the interactivity API is I see some promise there to actually make the building of interactive features easier in the long run, because the way… I won’t go into it too deeply. The interactivity API is based on annotating HTML elements with what they should do when a user interacts with them in certain ways. So rather than writing all of this in JavaScript like you would maybe traditionally have done, you write only the actual logic in JavaScript, but you trigger it and hook it up with actual HTML elements in HTML itself. And I think there is a a big opportunity there especially for common things that happen a lot like toggling an element or opening an accordion or this kind of things that so many websites do. I see a lot of opportunity to have this kind of thing implemented in a central place like in core itself for instance using the interactivity API. And then for example as a theme developer you would need to only write HTML using that to get interactive features on your website or into your theme. And I think that would eventually reduce the barrier of entry, because you wouldn’t need to really write JavaScript anymore to get some certain interactive features.

Jakob: The way it is built, it seems really to be integrated seamlessly into the block, because at the end of the day your block writes HTML, so you can write for the interactivity API using blocks. You mentioned what is evolving on the core site, so is there anything, any trends or changes that you can maybe recommend to agencies, professionals, clients out there to prepare for? Do you have any  advice for them for the next couple of years?

Felix: I think nothing in particular comes to my mind other than what I just mentioned, like block themes and the interactivity API. I think that’s the biggest pieces for me. I would say the agencies should focus on and see what can be done, but I also understand that this is heavily tied to how many plugins or for which purposes plugins are available that embrace.

Jakob: Do you see, maybe for example we’ve been to a couple of conferences this year and AI is everywhere. So, is maybe AI for instance, might this predict performance bottlenecks during development, building sites? Is this something that you could see? Having them an impact on performance?

Felix: AI can definitely be helpful in that. We’ve been internally doing some experiments with that trying to build for example run a page speed insights report on the site and try AI to make more sense of it and explain it to users. Like that’s just a very basic way I want to say, but for example explain what comes out of the pagespeed insights report in a more user-friendly way, in a less technical way for instance. Imagine you could run this as a non-technical end user or administrator of a WordPress site and it would tell you, I mean maybe this is a little bit blunt, but maybe it would tell you this is what you should complain to your plugin vendors about or something. But just tell what the potential performance issues are in a way that they understand more than you the technical output of the tool.

Jakob: That’s interesting.

Felix: But also AI can be very I think promising in the long run if, I don’t know, maybe with data sets like HTPR on Crux, maybe it can help identify performance patterns or it could even, I don’t know, like if someone could build a performance plugin that uses AI that they kind of assess how good a performance change was or gather the data in a central database at scale somehow and then make sense of about, okay when this problem happened in 80% of these cases, this one fix fixed it, so maybe that’s a good recommendation, like that kind of assessment. So if anybody out there wants to build that, feel free to do so.

Jakob: Super easy.

Felix: Sounds super easy to do.

Jakob: No, jokes aside, sounds really interesting.

Felix: I think there are definitely big opportunities with AI obviously and and I’m not sure yet when any of this could be in WordPress core for instance. I mean, we’re still very early in the age of AI, but curious what’s going to happen there in the long term.

Jakob: Yeah, curious as well. So, those are really good closing remarks I would say. This has been a very, very interesting and insightful discussion, Felix. Thank you, thank you very, very much for joining us. Yes, appreciate it. It was a blast. I learned a lot to be honest. I think you have a really good way to approach things and the perspective you have is really valuable, for me essentially and I think for a lot of our listeners as well. So, thank you, thank you very, very much. Any closing closing words? Or say goodbye to the listeners.

Felix: I was excited to be here and happy I could share more about the performance efforts that we’re doing and I hope you took something from this. Start looking into if you haven’t already started looking into some things that I mentioned. +

Jakob: I’m very sure. At least I learned a lot. So thank you very much. For our listeners: In our next episode we will discuss profitably speeding up your page building process together with Thomas and Mark Szymanski. So don’t forget to subscribe to our YouTube channel and to stay up-to-date. That was it for today. I hope you learned a lot. And again, Felix, thank you very much and see you again. Bye.

[Music]