[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress, the people, the events, the plugins, the blocks, the themes, and in this case, how speculative loading is speeding up your WordPress website.

If you'd like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you'd like us to feature on the podcast, I'm keen to hear from you and hopefully get you, or your idea, featured. On the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today we have Felix Arntz. Felix is a Senior Software Engineer at Google, and a WordPress Core contributor from Germany, currently residing in San Francisco, California. He helped establish the WordPress Core performance team, and has been heavily contributing to its efforts. He has been using WordPress for a decade and contributing back to the project since 2015. More recently, he has stepped into the role of the inaugural performance lead for the WordPress 6.2 release, and subsequently of the 6.3 and 6.8 releases. In the latter release, he spearheaded development, and launch, of the new speculative loading feature, which is the focus of the podcast today.

Speculative loading is one of the most important, and yet, almost invisible performance enhancements of recent times. If you're on WordPress 6.8, this new feature is already active on your site, working quietly in the background to make page navigation faster, but you might never know from the WordPress UI. There's no menu, no toggle, and no obvious indicator to show it's there.

Felix explains exactly what speculative loading is and why it feels almost like browser magic. The Ability for WordPress, using the browser's new Speculation Rules API to load the next page just as the user is about to visit it. It's a clever use of browser signals like mouse clicks, and hovers, to anticipate navigation, shaving off precious milliseconds, sometimes even providing what feels like an instant page load.

Felix clarifies the difference between conservative and more aggressive approaches to speculative loading. And why the WordPress core team opted for the safest, least wasteful, option by default, while still giving developers or advanced users the hooks and tools to customize, or even disable it, as needed.

Felix discusses the origins of the feature as a plugin, the testing and data collection undertaking with tens of thousands of sites, and how this real world data gave the team confidence to ship speculative loading to all WordPress users. We talk about what those performance wins mean at scale, how a 2% improvement on 43% of the internet translates into saving users untold hours of waiting collectively.

We also get into the weeds on measurement and methodology, how the team uses data from the Chrome user Experience Report and HTTP Archive to track web performance, prioritize features, and validate real world impact. Felix offers insights into how these global, anonymized data, sets allow the performance team to make truly data-driven decisions.

Beyond the tech, Felix addresses practical considerations such as how to opt out or fine tune speculative loading if you have specific needs. How environmental concerns are balanced by default configurations. And how plugins or agencies might build on this foundation in the future.

If you've ever wondered how large scale browser level improvements make their way into WordPress Core, or simply want to know if there's a way to make your own WordPress site that much faster, this episode is for you.

If you're interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you'll find all the other episodes as well.

And so without further delay, I bring you Felix Arntz. I am joined on the podcast by Felix Arntz. Hello, Felix.

[00:04:46] Felix Arntz: Hey. Happy to be here.

[00:04:47] Nathan Wrigley: Yeah, thank you. I appreciate you joining us. Felix is joining us all the way from California. I'm in the UK so there's a big time gap. And I appreciate you getting up early and talking to me. That's fantastic.

Felix is going to be talking to us today about something which is now in WordPress, and you may not even know that it's in there because there's nothing to see here. But the endeavor of what Felix has built is to make all WordPress websites basically immediately better. More performant, so that the end users of your websites will be able to access your content more quickly.

It is something that's really fascinating. But before we begin digging into all that, I know it's a dreadfully banal question, Felix, but would you just tell us who you are so that people understand your credentials in the WordPress space?

[00:05:32] Felix Arntz: Sure. Thank you. I have been contributing to WordPress now for 10 years. So I started as a freelancer building websites using WordPress, and eventually got into contributing to WordPress Core after I went to my first WordCamp, which was a great way to get started.

Yeah, ever since then I've been contributing to WordPress Core, and eventually became a Core Committer. And now, for over six years, I've been working at Google, the team where we focus on CMS projects for the most part. So I've been, especially in the last good three years or so, I've been sponsored by Google to contribute to WordPress with a specific focus on improving performance.

So our team essentially co-founded the WordPress performance team, which is an official part of the wordpress.org project. And ever since that was founded in late 2021, we've been contributing to that effort, and the speculative loading feature is a big part of that.

[00:06:25] Nathan Wrigley: That's what we're going to talk about today. Can I just rewind a little bit though, and talk about Google for a minute. So, are you employed by Google to commit to WordPress Core? Do you spend a hundred percent of your time working on WordPressy things, or do you have a proportion of your time which is devoted to more, and I'm doing air quotes, Google things?

[00:06:46] Felix Arntz: Yeah, I mean, I wouldn't say that I contribute a hundred percent of my time, but a good chunk, probably 70, 80 or something. Our focus is, when it's not on WordPress, it's still on other somewhat related open source projects. So we have been contributing, we've been also working with other CMSs here and there.

[00:07:02] Nathan Wrigley: Yeah, that's interesting because I know that Google have a big presence. If you go to the flagship WordPress events, you know, WordCamp Asia, WordCamp US, and so on, then Google very often have a huge advertising booth. You know, they're a global partner if you like.

But drawing the line between Google and Open Source CMS is a little bit hard to do. It's almost like a philanthropic thing. Because I guess their job is to just try and make the internet better and part of it, if they can make 43% of the internet better by seconding somebody like you to commit to the project, that's just good for everybody.

So yeah, bravo to Google. I appreciate the fact that they're sponsoring you and helping the project in that way.

Also bravo to you and the team, the Performance Team. It is just a relentless good news story coming out of the Performance Team. So, I don't know, when did you say, 2019 it was founded?

[00:07:54] Felix Arntz: Late 2021, but things really kicked off like mid 2022 I feel.

[00:07:58] Nathan Wrigley: Yeah, and I am habitual about the WordPress news, and it just never stops. The Performance Team do something profound, help everybody out, it just ships into Core. Most people don't even know that things have happened because, you know, they're not in the baseball in the same way that you and I probably are.

A profound thanks. Maybe there was just this massive backlog of things that needed to be tackled. Maybe not. But it did seem that the minute the doors opened to the Performance Team, lots of dominoes fell really quickly.

So thank you on behalf of me and everybody who uses WordPress for the work that, I don't know whether you feel that you get the credit that's due to you, but I'm giving you some credit now, so thank you.

[00:08:37] Felix Arntz: Thank you. I appreciate it. That's definitely great to hear.

[00:08:39] Nathan Wrigley: I'm pleased you know, that there's people as capable as you who are doing this kind of work and that you're willing to do it in the background. And a big piece of that is what we're going to talk about today.

Landed in WordPress 6.8, but has a history prior to that as a plugin. It's called speculative loading. It sounds impressive. But it also, I guess it is impressive and it's a bit like voodoo. It's kind of doing things that you wouldn't imagine were possible. Do you want to just tell us what it is? What is speculative loading?

[00:09:08] Felix Arntz: So essentially, speculative loading, the idea is that when you navigate to a new URL, when you are browsing through a website and you go to a URL, the moment that you land on the URL, it starts loading. And we probably know that the performance aspect of that is very important to the user experience.

So if a page takes, I don't know, three seconds to load, that's not great. If it takes eight seconds to load, it's probably horrible of a user experience. And so one of the performance team's goals is to make that time that it takes a load shorter. So what then speculative loading does is load the URL, the idea is that it loads the URL before you even get there.

[00:09:47] Nathan Wrigley: Yeah, that's the bit that's voodoo. That's the bit that just sounds like you've basically hopped into Back to the Future and you've gone back in time a moment or something. It's very counterintuitive. So you are going to have to explain, how on earth does it do that?

[00:09:59] Felix Arntz: Right, right. Essentially, there are browser, there are heuristics which can be relied upon to hopefully assume correctly that a URL will be visited. So when you are on a page on the website, there is of course links to other pages on the website. So if you hover over the link with your mouse, if you're on a computer for instance, and you hover over the link with your mouse, maybe you'll click it. That's like one level of signal. It's not the strongest signal.

But then an even stronger signal is when you actually click the link. When you click a link, you want to go to that URL. I think that's a fair assumption in like 99 plus percent of cases. So when you click on the link, that's technically still before you're at the other URL though. We're talking about milliseconds. You probably think when you click, you are already on the other URL, but that's not the reality. There is like maybe, I don't know, 200, 300, 500, however long it takes, there are some milliseconds in between the time you actually click and that the other URL opens.

So by loading, for instance, by loading a URL, when you click on the link, you still gain those, whatever, maybe 500 milliseconds. I'm just going to make that up now, and reduce the actual load time by that.

[00:11:07] Nathan Wrigley: Let me just prize that apart. So we are now going to talk about a tiny fraction of time. For the next few minutes, we're going to be talking about literal milliseconds. So let me imagine that I'm on my computer, desktop computer, let's start there. I'm on a webpage and there's a bunch of links, buttons, what have you.

I'm holding my mouse, my mouse approaches the button and it begins to slow down, you know, because at some point we have to rest on the button. So there's this deceleration of the mouse and the cursor, and it eventually lands there. And then I click it.

Now my intuition is that the click event is the moment, that's when everything begins, if you know what I mean. But are you saying that you can go back in time prior to me actually hitting the button with my finger? Is it the mere fact that, okay, the mouse has come to a standstill, you haven't engaged the finger yet. Maybe the finger is literally on the way down in the real world, in this slow motion universe we're imagining. Is that kind of it? It's taking heuristics about, where is the mouse now? How is it decelerating? Or is it literally he clicked? Because if it's the click bit, then I don't understand what's different to how it usually was because it felt like the click was always the moment.

[00:12:19] Felix Arntz: There are different ways to configure speculative loading. And one way, and that's the way that WordPress Core does now, is to only speculatively load on the click. You say now that that feels like it's always been like that, but it's not quite always been like, that because of what I tried to mention with there's still like 500, maybe 300, whatever, little milliseconds time between the click and the actual URL loading.

So when you hit the other URL, then it starts fetching the HTML document and all the CSS and JavaScript and so on. By doing that already on the click, on the link, on the previous page that you are on, you still gain those, I'm going to say valuable milliseconds. And we're probably talking about at the very least, a hundred milliseconds, maybe a few hundred milliseconds.

[00:13:04] Nathan Wrigley: It doesn't sound like a lot, but it's, you've invented time out of nowhere. You've completely conjured up time that didn't, well, actually you've removed time. You've gone in the opposite direction. But that time was needlessly spent before. Now that time has been saved.

You also mentioned that the WordPress implementation, and we'll get into how you might be able to configure that in a moment, but the default WordPress installation, so this is in every WordPress website from 6.8 onwards, it is set to, and I'm going to use the word conservative, but it's set to a fairly dialed back approach to this Speculation Rules API.

I'm curious, and we'll get into how you do it in WordPress, but just in terms of the Speculation Rules API, what are some of the more aggressive things that you could do if you wanted to? And is things like the mouse slowing down, is that potentially part of it? Those kind of things.

[00:13:55] Felix Arntz: Right. So maybe let me take a step back, first to clarify that there's a speculative loading feature that is in WordPress Core, it's built on a browser API that is called Speculation Rules API. We can talk about maybe two things. There's like, well, how can you use the Speculation Rules API? There's different ways to configure it, and that's something that we could apply in WordPress. But then we could go beyond that, and I'm probably not the best person to speak about that, but we could also think, how can you actually, what could the Speculation Rules API possibly do, that it isn't able to do today?

So in terms of using the Speculation Rules API, it allows different configuration modes in for what is called eagerness. And you actually said it right. It's called conservative, the mode that WordPress currently uses. And it just means, I think it is conservative in the sense that it is the safest measure if you want to make sure you only load URLs that the user actually goes to.

But it's also the least performance of all the options. It's always a trade off because unfortunately we cannot predict the future, so there's no real wizardry going on here. And because of that, there is always going to be a trade off. You can use signals that are very reliable on the user visiting the other URL, like clicking on the link. There is an scenario where you click a link and then you pull your mouse away before you let go of your finger. We probably all have done this, but we probably do this like 1% of our clicks, if even that. But people do this occasionally, very occasionally.

So that's the way where a click would not trigger the actual URL to the link to be, that wouldn't result in the user visiting the other URL. This would be the one example where conservative speculative loading would still load the other URL and the user wouldn't go to it. But I think that risk, that trade off is very, very little because of how rarely that happens.

[00:15:46] Nathan Wrigley: Right, so the posture of the Performance Team was to go conservative. So although it's not the most performant, it is the least likely to end up in, you know, needlessly downloading content that is perhaps never going to be looked at.

But again, just moving ourselves away from WordPress for a minute, the Speculation Rules API, if we were to go on the more eager side, what kind of things could be brought to bear? And again, not in the WordPress setup at the moment, but I know that you can modify those things. But what can the Rules API do, if you go like full eager?

[00:16:18] Felix Arntz: Right. So you can also use, the next after conservative is called moderate. That uses signals that are less explicit, like a hover. Again, I have to specify, on desktop it uses hovering, because on the phone you can't hover, like you don't have a mouse and it doesn't know where your finger is if you don't press the screen.

So, essentially, moderate on desktop, it relies on the hover over a link to preload the URL that is behind that link. So that generally, yeah, of course if you hover over link and then you click it, there may be like a second, easily a second between this, or there may even be five seconds in between those two actions, right? And sometimes you hover and click immediately. Other times you hover and you get back there, and then you click, and in that case, the whole page can technically be already loaded.

So that's the part where speculative loading, if you configure it more eagerly, you can get to situations where you get instant page load. You go to the other page and it's already completely loaded. There's, for instance, there is also Core Web Vitals, metric Largest Contentful Paint, which measures the load time speed. So you can get to an LCP of zero. Like, literally. If you use it, for instance as moderate eagerness, let's say your page normally takes two seconds to load completely, and you hover over a link, and then you get back there like three seconds later, you click, it's already there, and your LCP is literally zero because you didn't need to wait at all.

That's the performance power that it has. But of course, it does also come with a trade off to consider. Like, how do you configure this in a way that it's the least wasteful? And wasteful in the sense of loading URLs that the user does not go to, ends up not navigating to. But you have to basically weigh off, what is the performance gain? How do users typically use your website?

There's also, there's a lot of individual configurations that websites may want to do on their specific site. So going back to the conservative option that WordPress now uses, it's just that, it's simply that we want to give the bare minimum feature and we want to make the feature available in general to WordPress sites. But because WordPress is so massive, you need to go with a literally conservative default.

[00:18:25] Nathan Wrigley: Okay. So that's all really interesting, but it sounds like all of this is happening in the browser. So all of these events are being triggered by the browser. Again, forgive my ignorance, I'm presuming that Chromium, Chrome, Firefox, all of the other variants that there may be out there, I guess they're all shipping some variant of this inside the browser because obviously it can't be WordPress that's doing this.

If that's the case, is there kind of like a broad consortium of people who are working on this initiative, maybe other similar related performance initiatives, and trying to make them all browser compatible?

[00:19:03] Felix Arntz: So there is, the Speculation Rules API is currently, it's available in Chrome, Edge and Opera, so in the Chromium based browsers, but it's not available yet in Safari and Firefox. That means that people that use Safari or Firefox, they're basically just not going to get the benefit.

[00:19:18] Nathan Wrigley: So it's like a progressive enhancement. There's no downside, it's just an upside.

[00:19:22] Felix Arntz: Exactly. So because overall the browsers that support it are very widely used, plus the other browsers not having any negative effects of this feature being on a website, that's why we thought it was a good time to roll it out.

[00:19:36] Nathan Wrigley: Okay, that's really interesting. It just suddenly, and completely unrelated to the conversation that we've had so far, it kind of makes me think that maybe in the future there'll be a hardware layer to this. You know, imagine if my mouse had built into it some pressure sensation, or even proximity sensor where it could perceive that, you know, my finger is descending and it could fire the signal from the mouse to say, yeah, he's about to click. Or even in a mobile phone, you know, you were mentioning earlier, we don't know where your finger is. Maybe at some point in the future we will know where your finger is.

[00:20:09] Felix Arntz: That would be really powerful, yeah.

[00:20:10] Nathan Wrigley: It'd be kind of interesting. Okay, you heard it here first. But it's not there yet. So, what has been the way that this has been implemented? My understanding is that you launched this as a plugin. I think you got a fairly high user account. I think 30,000, 50,000 or something websites.

[00:20:27] Felix Arntz: I think it's now at 50,000.

[00:20:28] Nathan Wrigley: 50,000. So tons of data coming back. And presumably that data gave you the confidence to, yeah, let's push this through. And I have a memory that, broadly speaking, you got fairly close to a 2% productivity gain. And obviously at 43% of the web, if we can do things 2% faster, doesn't sound like a lot, 2%. But 2% of everything that WordPress gives up, that's a lot.

[00:20:53] Felix Arntz: Performance is really like, people say sometimes things are numbers games, but performance is a tiny numbers game. Like it's very hard to make performance wins sound very appealing. It's like, here is 2% win. We scratched off 80 milliseconds of this, and it's like, what is this even, like.

[00:21:08] Nathan Wrigley: But it literally is human years. It's probably decades of time when you think about the internet as a whole. If you think about it in that sense, it's really quite a lot of time.

[00:21:18] Felix Arntz: Exactly, and I think it's important to remind ourselves of that sometimes. I feel myself like announcing something where it's like, oh, here we scratched 80 milliseconds off. It sounds like nothing. It is quite something, but it sounds like so little that, I don't know, I feel self-consciously saying such a tiny number as a great win.

But yeah, again, like I think it, you exactly mentioned it, the scale of rolling out performance enhancements like this, it really makes the number matter. And also, people browse so many webpages a day, like even for an individual person. If you go on one website, you easily might visit 10 URLs or more, and that's just one website. So think about , again, I'm just continuing with that number, like if you had 80 milliseconds gain on all the webpages you visit in a day, I don't know, it might come out at some seconds, maybe a minute, who knows. And if you do that every single day, like you gain time.

[00:22:09] Nathan Wrigley: Yeah, I agree. It's difficult to parse, isn't it? The human brain doesn't kind of work that microscopic level. That really tiny fraction of time is so difficult to become important. But there's this compound interest effect to it. You know, the more that it adds up, the more time you spend on the internet every day clicking things. And I suppose the curious thing here is, nobody even knows that it's happened. You would presumably just think, gosh, that is a very quick website. You know, I'm having a fabulous experience here. Everything's loading amazingly. They must have an amazing server set up or, you know, they've got everything configured perfectly. And all the while it's the Speculation Rules API working in the background.

But I think we've got it, you know, it's adding up to tons of time, probably years, maybe decades of time when you throw that across the whole footprint that WordPress have.

However, most people who don't follow the WordPress news really, really carefully probably won't know about this. And there's nowhere to know about it really, apart from WordPress journalism, and the blog posts that go out from the Performance Team. Because there's no way in the WordPress UI, there's no setting, there's no menu item to go to, there's no toggle, there's none of that.

So that then leads me to ask, is there a way to modify this? If you have a need for more eager. Or you just wish to, I don't know, you've got a desire to turn it off for some reason. Can it be modified with code, with hooks, with whatever?

[00:23:31] Felix Arntz: Yeah, certainly. Quick context on the reason that there is no UI in WordPress Core to control it, is that it's considered a very technical feature, and the philosophy of WordPress Core says, decisions not options. That's one of the Core philosophies. So try to use defaults that work for the majority, and most people won't have to change. And then especially when it comes to very technical things, you don't want to bother an end user that just wants to maintain, create their website with, here you need to learn now about this complex Speculation Rules API.

Like, we already talk about this for like 30 minutes now, and there's probably so much more to uncover. So you can imagine that certain site owners don't want to deal with that. So that's why there's no UI in WordPress Core. But it can be modified through hooks like you're saying. There are several filters and actions to modify the behavior programmatically.

And in addition, the Speculative Loading plugin that existed prior to the Core launch, that still exists and it's now, when you install it on top of 6.8, it still serves a purpose. While it doesn't ship the whole API anymore, because that's now part of WordPress Core, it's still includes a UI where you can configure it via UI in different ways.

And it also changes the default behavior of WordPress, for the speculative loading feature. And that's essentially because when we started the plugin, we went with a more aggressive default, because we want to know, the plugin only launches at first at small scale, it's meant to, especially in the case of a feature plugin, it's meant to inform us about how well it's working, are there potential issues, and so on.

So we went with a more more performant configuration out of the box with the Speculative Loading plugin. So if you use the plugin, it will use the moderate eagerness that I mentioned before. And then in addition, it uses, and we haven't covered that at all yet, so it pre-renders the URL. So I can explain that briefly.

The WordPress Core implementation, the Speculation Rules API allows you two alternative modes for speculatively loading a URL. Either you can pre-fetch the URL, or you can pre-render the URL.

Pre-fetching means you essentially just load the, you get the HTML content already, but then you don't do anything else. Like, it doesn't load any JavaScript or it doesn't load any CSS or images, it still waits with all of that until you go to the other page.

With pre-render, it does everything, like literally everything. It loads the HTML, it loads also all the JavaScripts, CSS, images and whatever else is on your page. And it even renders this in the browser, like it basically does everything as if you were already on the page in the browser. Let's think about it as if you had the page open in another tab and you couldn't see it.

[00:26:08] Nathan Wrigley: Yeah, you've just like pulled back a curtain suddenly and there it is. It's just, it always there. You just couldn't see it and suddenly.

[00:26:14] Felix Arntz: And the pre-rendering is the thing that can get you to those immediate page loads. Because when you use pre-fetching, it only loads the HTML, so then when you get to the page, it'll be faster, but you still have to load all the other things, and render it. But pre-render is where, if you have pre-render and eagerness of moderate, and then we go back to our previous example, you hover over link, go back there, two seconds, three seconds later, then you might get this immediate page load with LCP zero.

[00:26:43] Nathan Wrigley: Okay, that's really interesting. So you've kind of got two options. The first option is just accept WordPress Core. That's how it is. And then, maybe three options. The second option then might be you can modify things with hooks and what have you. And I'm going to link to the articles that Felix wrote in the blog post that goes with this. So go to wptavern.com and search for the episode and you'll be able to find all the bits. It's more easy for me to say that than it is to read out the blog titles and things.

And then the other option, the third option would be to download the plugin, which gives you a UI, but just caveat emptor, beware, it will then automatically make things moderate. It's going to be doing things in a more, a slightly more aggressive way.

[00:27:21] Felix Arntz: It brings you better performance, but it might also have more trade offs on, it will load, certainly to some capacity, load URLs that may not be navigated to. If you install the plugin, just keep in mind that the UI that it provides also would allow you to go back to the WordPress Core default. If you just want a UI and you install the plugin, just go into the UI of the plugin immediately, change it back to conservative pre-fetch, and you're back at what Core would do as well.

[00:27:45] Nathan Wrigley: Great. Yeah, thank you. Now you mentioned LCP and things like that. And I think there's been an obsession for the last, let's go for four years, with speed and trying to get Lighthouse scores to be impressive for your website. I'm curious, is there a way that Google scraping the internet can perceive any of this?

In other words, if you do this, are you doing it simply to make your visitors happy, because they're the people who are doing the clicking or what have you? Or is there some like Core Web Vitals metric which can be improved by this? Because it feels like there couldn't be, because I doubt that Google Bot has the capacity to kind of speculatively load anything, but maybe there's some flag in the, I don't know, I have no idea how that would work.

[00:28:31] Felix Arntz: So, that's a great question. I think you'd, certainly when you apply performance enhancements like this, the goal is that they benefit your website's end users. Google, of course, would love to know how well these features work, right? And also the people that work on the actual Speculation Rules API would love to see how the features are used in production, on production sites. And we, as a Performance Team, would also like to know that, how it goes with WordPress specifically.

So there is a public data set called Chrome User Experience Report, which is sourced from anonymous data from users that use Chrome and have opted into this anonymous data tracking. So there is essentially a data set that collects the performance data of people visiting websites. And that is made publicly available, you can literally, if you know how to use BigQuery, which is this kind of advanced version of MySQL, where you can query gigantic amounts of data, you can query the Chrome User Experience Report data set, and you could be checking like, I don't know, as long as sites that appear, it basically aggregates all the page, all the data by origin, so the domain.

Any site that is relatively popular is in there. I don't know exactly what the threshold is, but something like, maybe like at least 50 monthly users or something like that. So then your site will appear in there and you could query this for your own site to see how your site is doing. And you could do this every single month. And you get like a chart, how the performance of your site is doing over time.

Of course, neither Google nor we as a Performance Team cares about one specific site. We're doing things like in our team, we were building things for WordPress, for the WordPress ecosystem, try to improve the performance of the ecosystem as a whole. So I have been working a lot in the past years and learning a lot about this stuff. How to query the Crux, that's a short version of it, Crux, the Crux Report, to gain insights on, how do you possibly measure the impact a certain feature has on these metrics?

There's another data set called HTTP Archive, which is the domains that are in this are also sourced from the Crux Report. But what HTTP Archive is, it basically scrapes all of these URLs every single month, one time, and gets all sorts of public information from these URLs, like which technologies it uses, does it use WordPress? Does it use, I don't know, React or whatever, all these things. It also stores, from this one momentary point, it also stores the actual HTML body, and it's a gigantic data set. And also that is public as well. You can look it up on httparchive.org and how to use it.

So the goal of these efforts is to make these different performance data and to basically assess the health of the web ecosystem, publicly available, and then also these, especially HTTP Archive has a lot of charts on their own website based on their own data that essentially, yeah, makes it easily available without having to query BigQuery data.

But when you actually can query BigQuery data, it becomes really powerful. So we can combine the data from HTTP Archive to see which origins are using WordPress. So then we get like a scaled down version of the whole web that is just the WordPress sites. And then we can combine it with the Crux data that has the performance results for all origins, but scope it down to only the origins that use WordPress.

And that way we can see, for instance, the median LCP for a given month across all WordPress sites is this. Or the median INP and all the other metrics. More importantly, what we have been using as a more important metric though, is what's called the passing rate. For every Core Web Vitals metric, there is a threshold where it's, under this threshold is good, above this threshold, it's not good. So for LCP for instance, that's 2.5 seconds.

And passing rate is essentially the number of, in this example, is the number of origins that have a median LCP that's better than 2.5 seconds, the percentage of origins that have an LCP that's better than 2.5 seconds. And that you can track over time to see how WordPress LCP is improving or decreasing over time. That's how we essentially monitor performance for WordPress at a high level.

And then we've been doing all sorts of experiments to try to get feature specific improvements. That's really the difficult part because these data sets only gather data, the Archive data set only gathers data once a month, the Crux data set gave this data, it has all the data, but only the performance data. So it does not know, at what point did you activate a certain feature or deactivate another feature? That data doesn't exist. So we can only make assumptions.

Like, for instance, even when you want to measure the difference, and like an easy example, and that's already complicated, is to measure the difference from one WordPress version to the next. HTTP Archive has data, whether a site is on, let's say 6.8 or 6.7, but it's from one specific moment in time. And we generally broaden these moments in time to the whole month because that's the generally, like they do it once a month. If you see that a site is on 6.8, I think the HTTP Archive runs, like the actual queries usually run somewhere between 20th and 25th of the month.

So if you see that the site is 6.8, you don't know, is the site on 6.8 the entire month or did it just update to 6.8 a day before and most of the month data is actually the previous version? This is just unknowns that we have to deal with. And the data set being so huge, because WordPress is so popular, that helps a lot to sort of like make these unknowns maybe less impactful. Because if you're at scale see that 6.8 has a big improvement, we can't say that this value precisely is correct, but if it's a clear improvement, we can assume that there is an actual improvement to a certain degree.

And doing that for feature specific level is even more complex. I don't think we have time to get into this too much right now, but I just want to say that this 1.9% value that is in the blog post is based on such an effort, where I try to look at all the sites that have speculation rules, and I looked at all the same sites before they activated speculation rules and get this median difference between all of them. And I don't even know how to explain anymore because I don't remember, because it was so complicated.

[00:34:42] Nathan Wrigley: I am so glad that you are able to explain it though. I mean, firstly, really interesting, all of that, really interesting. Because you just sort of peeled back a whole curtain that I didn't even know existed. So there's just this aggregated, opted-in data coming out of the browser, dropping into this massive data set. I can only imagine what that is like to deal with.

But it does mean that you've got anonymised data. You can make reasonable guesses, in the aggregate, about what's happening. You know, you can refine it to WordPress, you can refine it to 6.7, 6.8, okay? And day by day, maybe it's not meaningful. But if you spread it over one month, six months, what have you, more and more trends start to pop out.

So you can see over time, you've got this 1.9%. And it, terribly complicated though it might be, I'm glad that you did that work for us. That's amazing. Okay. And I didn't know that whole thing was going on.

And again, getting back to the point that you made at the beginning, the whole purpose of this is to make it better for your users. The purpose is not for the data that Google's gathering, but it's gathering it. And it's helpful because people like you can then use it and make reasonable assumptions about what the rest of us ought to be doing with our WordPress websites. But the key metric there is, does it perform better for your users? And of course, we know the answer to that.

[00:36:00] Felix Arntz: Just wanted to quickly add like we have been, these two data sets have been important source for us as a Performance Team from the very beginning in terms of even prioritising what we work on. There's ways to get a high level idea. Like, out of all the 50 things that we could do to improve performance, which have shown to be the most impactful on the web so far outside of WordPress, or maybe even on the few WordPress sites that already use it through some other way. So it has helped a lot on the prioritisation, and personally a big advocate for data driven decision making. And in many parts of the WordPress project, we are not able to do that because we don't have much data. But I'm really pleased that on the performance side, there is this big data set that can be used to see what is actually impactful.

[00:36:46] Nathan Wrigley: Yeah, you can be really confident that your decisions are based upon fact, which is so nice. A lot of the WordPress project is, you know, intuition and design and things like that, and it's hard to get agreement about that, and hard to get things right for everybody. But in this case, that's slightly different.

[00:37:00] Felix Arntz: For anybody that's interested in this to learn more, I did write a blog post on makewordpress.org/core at some point about it. How to assess performance with HTTP Archive, something like that. That's something that we can probably, that you can probably look at. There's a whole collab. I worked out for a while on a collab to teach as a sort of like tutorial, how to get started with this for anybody that's interested.

[00:37:23] Nathan Wrigley: Okay, I've got a couple of pieces that I've got open over here, which are probably not the piece that you've just mentioned. So when I come back and edit this, I'll make sure that I get in touch with you and we find that, and we'll put that into the show notes. So there'll be at least three things that you, dear listener, can go and check out.

I'm just wondering if there are any situations, because we know what people are like. Performance experts, they love to configure their servers, they love to put things at the edge that, you know, all these clever things that are going on. Are there any scenarios where things like the speculative loading that that can conflict, or overlap or be something that you actually don't want to do because you've already got something in place that might be handling, I don't know, let's say for example, you're in team Cloudflare, and you've jumped in on all the different things that they've got? Perhaps they do this already. I don't know. But I'm just wondering if there are any scenarios where, let's say I'm a hosting company, or I'm just really into my performance. Are there any scenarios where I need to be mindful, maybe I want to switch this off?

[00:38:22] Felix Arntz: I don't think there's a lot on the hosting side, but there can be on the whatever client side's technologies you use. So because this speculative loading happens in the browser, so the, I don't think there's anything on the hosting side, or server side, that could do something similar. I think that wouldn't work.

But there are other ways that some similar things like this have already been done outside of a browser specification, outside of a browser API. Like there are certain JavaScript frameworks, for instance, that have something like speculative loading. Like, if you have a Next.js site, for instance, which I think is not very common to be used together with WordPress, but if you do have a Next.js site for instance, it might load URLs speculatively too, but through its own mechanism, like a completely separate approach. I'm not sure about specific JavaScript libraries right now that do exactly this, but there are definitely things like it that some sites were already using before the browser Speculation Rules API came around.

[00:39:15] Nathan Wrigley: Okay, so broadly speaking, if you're a WordPress, a typical WordPress user, you've got nothing to worry about. And you probably know that you've got something interesting and unusual going on with loading things in a different way, so you're probably okay.

One of the things that I did want to know, I just wondered if there were certain, I don't know, let's say I've got a WordPress website, maybe there are bits of that website that I don't wish to be speculatively loading.

I'm not really sure what that might be. An example that I think came out of one of your blog posts was you took the example of a Woo, well, I presume it was WooCommerce, you know, the end of the URL being cart or something like that, you know, so forward slash cart, forward slash whatever.

That's possible though. I presume, again, with hooks you could say, okay, this predetermined set of URLs, we don't want to speculatively load anything. That kind of stuff can be done. The URL parameters can be configured into all this.

[00:40:05] Felix Arntz: Yeah, exactly. So you can exclude certain URLs, or URL patterns from being applied to the speculative loading. And you can also configure whether you want to exclude them entirely or whether you want to exclude them only from pre-rendering, but not pre-fetching.

So this is important to consider because the WordPress site, well, probably now 95% of the sites with 6.8 use pre-fetch because that's a default. There are still sites that change it to pre-render. And then there are different implications for the site, for the URLs that are pre-rendered.

And one of the considerations is, that's actually another reason why we went with pre-fetch. because also pre-fetch, even though it's less performant than pre-render, is also a safer option at the scale that we roll this out to all WordPress sites. Because the only risk with pre-fetch occurs if there is a URL that modifies something just by visiting that URL, which is an anti-pattern, like you should not do this, but there are plugins that do this occasionally. For instance, if you have like a URL that's called empty cart, and just by visiting that URL you empty your shopping cart.

That means, if you speculatively load the URL and you don't visit it, your cart is emptied. You don't want that. This is the only risk with pre-fetch. But, for what it's worth, WordPress, the WordPress Core implementation also includes some default exclusions already. One of them is that it won't speculatively load any URL with query parameters, like those question marks, something. And that's because most WordPress sites by far are using pretty permalinks, and on those sites, having a query parameters is extremely unusual. And if there is, it's usually from a plugin that does something specific.

And so that's why we exclude URLs because the chance that, like WordPress Core doesn't have anything in the front end that will change something when you visit a URL, but plugins might. And plugins would usually handle this through query parameters if they do, and that's why we exclude any query parameter URLs.

[00:42:07] Nathan Wrigley: Yeah, I know that you will not have an answer to the next question, but I'm going to ask it anyway. But I'm just curious on your thoughts about it, because I know that anybody listening to this, there's going to be a proportion of people thinking, wait, we want less bits traveling across the internet.

And I'm thinking about the environmental impact of things now. You know, we don't want pre-fetching anything, because that's then potentially just wasted energy. Just carbon being burnt for stuff which may, or may not, be looked at. And obviously the WordPress approach that you've taken is to try and minimise that.

But I just wondered if you had any thoughts, you know, around that and whether you could sort of calm people down about that or whether or not it, was that whole thing disregarded? Where does it fit into the thinking of all of this?

[00:42:52] Felix Arntz: Yeah, like I said in the beginning, it is a trade off that you have to make, but it also depends like, which decision you take probably depends on how your site is being used, like what is the best configuration of speculative loading for your own site?

If you go with a too eager configuration where there's tons of URLs are eagerly loaded and then they might never be visited, then this definitely has a negative impact, like you're saying. But obviously the ideal outcome is that the wasteful reloaded URLs are minimised and at the end of the day you, by speculatively loading, you improve the user experience.

I can't really answer where you draw the line in that. That being said, the adverse effects of URLs being loaded that you don't navigate to with this conservative eagerness is so little. That's why we chose that value to be the default. And you can go for more performant solutions, or configurations, but when you do so, please test how that works out.

You can also, don't want to get too deep into this, but you can also, if you have some kind of analytics provider for your site, you can gather like performance data or you can see which links users typically click on. And then you could configure speculation rules in the way that these links specifically may use like a more eager configuration. But the other ones don't.

This is where people really get, I've not personally done this but when, I've heard from other people when they work with enterprise clients, they really go in and look at, oh, when somebody has sent this URL, they usually click one of these four URLs, one of these four links, and then you can configure speculation rules to say, these four links should have moderate eagerness, but all other ones only conservative, for instance.

[00:44:22] Nathan Wrigley: I can see a whole third party ecosystem of plugin developers kind of rubbing their hands together. You know, those that create performance plugins kind of leaning into exactly what you just said. Here's your entire WordPress website, and here's what we think, you know, in the same way that SEO plugins might give you a traffic light. Here's a set of URLs, which we think you are not serving in the way that is going to be beneficial to your users or what have you. So, oh, that's interesting as well.

[00:44:46] Felix Arntz: The tough thing though is that it's usually, I think it's going to be very heavily dependent on the individual site. That's where my hesitation is with that is that like, I'm not sure how much a plugin, a generally applied plugin, throughout the ecosystem could predict that. I think it's often depending on the layout of the site. What is even the content of the site, right? What do people mostly click on? I think that makes it challenging from a general plugin perspective. Like to me, that's mostly something that developers would do for their client's websites, or agencies would do for a client's website or at an individual level.

[00:45:18] Nathan Wrigley: Yeah. Well, I mean, it's just the beginning, isn't it? It's dropped in fairly recently. No doubt, the WordPress ecosystem will kind of figure out a posture on this. Maybe third party plugins will come along. Maybe developers will produce more documentation about how to wrangle it. How to surmise whether or not your website is using the Speculation Rules API in a way which is helping you, I don't know, measuring the cost of your server infrastructure and what have you. But just the beginning.

So there you go. Now, dear listener, you know a whole load of stuff about WordPress 6.8 that you didn't. Before because probably, it was completely invisible to you. So, is there anything we missed, Felix? Is there any burning issue that you think we did not cover that and that was important?

[00:45:58] Felix Arntz: No. I think we covered pretty much anything, everything. I just wanted to add that the new data from the Crux Report comes out, I think actually it came out yesterday, I believe. So it comes out every second Tuesday of the month. So I'm about to look at that. I want to take a look at that, definitely by the end of this week to see whether we can get any impact data now that speculative loading is out because, so the way that this works is the Crux data is released for the month before. That's what happened, I think yesterday. So now we should have data on April where WordPress 6.8 came out. So now we can see how much did this feature launching in 6.8, and 6.8 in general, affect performance, hopefully in a good way.

[00:46:39] Nathan Wrigley: Okay. Yeah, yeah. So this is actually for you, quite a big moment. You are suddenly going to get this data dump, which is going to actually cover this 43% of the web. It will be on all, well, most of the sites, and you are suddenly going to see what the impact is. Do you know, if you write that up, I will find it, if it's out before I produce this post, then I will definitely link to that. And I'll be fascinated to see if we can calculate how many decades, or weeks, or months, or years of time we have actually saved. That's absolutely brilliant.

Thank you so much for explaining it, helping to create it in the first place, and basically improving WordPress in a very, very demure way. You know, not shouting it from the rooftops, but doing a lot in the background to make everybody's experience of the web a whole lot better. Felix Arntz, thank you so much for chatting to me today.

[00:47:29] Felix Arntz: Yeah. Thank you.

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, what WordPress and Drupal have in common.

If you'd like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you'd like us to feature on the podcast, I'm keen to hear from you and hopefully get you or your idea featured on the show. Head to wp tavern.com/contact/jukebox, and use the form there.

So on the podcast today we have Chris Reynolds. Chris is a developer advocate at Pantheon, where he brings nearly 20 years of experience in the WordPress community, as well as deep involvement with Drupal and open source technology at large. Prior to his advocacy role, he worked at some of the top WordPress agencies like Human Made and Web Dev Studios. He's been active at events like DrupalCon, PressConf, and Word Camps.

In this episode we set aside the usual WordPress only focus, and turn our attention to two CMSs, WordPress and Drupal. What makes them tick, where they excel and where they might have something to learn from each other.

Chris draws on his unique perspective working closely with both platforms as Pantheon is one of the few hosts with a 50 50 split between WordPress and Drupal sites, and has a significant footprint in both ecosystems.

We discuss the similarities and differences between the two open source CMS communities, from the mechanics of flagship events like WordCamps and DrupalCon, to the ways these projects organize their contributors and support community initiatives.

Chris explains how Drupal's model with its association run funding, and project governance, compares to WordPress's approach, including how each community approaches plugin and module development, and what role agencies and companies play in contributing to Core and the broader ecosystem.

If you're curious about how open source projects organize themselves, how their communities navigate growth and challenge, and what WordPress can learn from Drupal, and vice versa, this episode is for you.

If you're interested in finding out more, you can find all of the links in the show notes by heading to wp tavern.com/podcast, where you'll find all the other episodes as well.

And so without further delay, I bring you Chris Reynolds.

I am joined on the podcast today by Chris Reynolds. Hello Chris.

[00:03:20] Chris Reynolds: Hi. How's it going?

[00:03:22] Nathan Wrigley: You cannot see, dear listener, what I can see. Chris has the most amazing setup where he's doing the recording. I guess it's an attic or something like that, but it looks like the Starship Enterprise from where I'm sitting.

[00:03:34] Chris Reynolds: I'm working on that.

[00:03:34] Nathan Wrigley: Yeah, it's really nice. Chris is joining us today and we're going to have a conversation about the WordPress community. The things that we do well, and perhaps the things that we could improve. And we're going to probably use Drupal as a comparison.

Before we get into that, Chris, I know it's a dreadfully banal question, but it's always good to scope out where you are and where you stand with WordPress and Drupal and the companies that you work for. So just a moment really to give us your little potted bio of who you are and what have you.

[00:04:04] Chris Reynolds: Sure. My name is Chris Reynolds, I am a developer advocate at Pantheon. I was formerly a senior software engineer for Pantheon for about three years, before joining the developer relations team around August, right before WordCamp US in September last year.

I've been in the WordPress community for close to 20 years. I think I've gone back to my first blog posts and my first, like talking about technology that I was using. And I think that I've found references to using WordPress in some capacity back in 2005, so almost exactly 20 years.

But even before that I was really interested, like as a side hobby in just open source software, playing with Linux and playing with other open source community projects that I found I was really a big fan of one called Ampache for a long time, which was a music sort of library app thing written in PHP. That was really cool. I think it still exists even.

But yeah, so I'm a developer advocate at Pantheon. That means I do a lot of these sorts of things, talk about best practices, write a lot of blog posts, get in a lot of trouble, not really, and go to events and stuff like that. So I was at DrupalCon in March. I was at PressConf last month. Probably doing stuff this summer and in the fall.

[00:05:14] Nathan Wrigley: Just to lean in a little bit on the Pantheon side of things. Pantheon, a hosting company, but very much aligned in two worlds, maybe more than two. But from my perspective, I used to use Drupal exclusively until about 2015. That was my CMS of choice for many, many years. I think Drupal 4, and then finally I jumped ship at Drupal 8 over to WordPress and have been that consistently.

But Pantheon was around as what felt like at that time, so we are going back more than a decade, the only sort of managed Drupal host, but it definitely had a WordPress side to it as well. Can you just speak to that for us for a moment? That is Pantheon's sort of MVP, isn't it? It handles managed hosting for both of those platforms. And maybe there's more, I don't know.

[00:05:57] Chris Reynolds: Yeah. I mean, I think that from a platform perspective, we obviously do host Drupal and WordPress. We also can host like Next.js and sort of front end sites. But the sort of hidden Pantheon magic is in the kind of DevOps, WebOps we like to call it, layer that happens like somewhere between pushing code and the code being a thing that like site managers and editors and things like work with, right? So automation tools, and we were one of the first providers that used Git by default. Now that's not such a big deal anymore, but like that was a big thing within Pantheon for a really long time.

When I was a developer, the first time that I used Pantheon as a developer when I was back at WebDevStudios was, the thing that was the killer feature for me was we have a thing called Multi Dev, which is, each site has a development, a test, and a live environment. So everybody gets those three things and we have a very specific sort of workflow. Code goes to dev, to test, to live in that order. But we have these Multi Devs, which are entirely separate containers where you can build, you can do all your feature development on a branch in a Multi Dev and see what that looks like before merging it into dev.

It sounds like maybe not that much now, but I know when I was back in agency life and even when I was working at Human Made and we had built our own sort of stack that had this very similar kind of system, we didn't have Multi Dev because spinning up new containers for sites that you're just going to destroy at some point in the next couple weeks or days anyway is expensive and hard.

And so what that meant was the master branch, or the development branch, of all of your code is always really messy and dirty, and you want to keep that away from the code that is going to production, right? Because that's where your experimental code is. Maybe you didn't back it out entirely. That's where like a whole bunch of weird database stuff is going. That's like the junk, right? So you want to keep that separate from like your staging branch and your production branch.

And with Pantheon, the idea is your development branch is just where your finalised code goes, because you can do all that testing in a separate environment and then when you go from dev to test, it's not a headache, it's just this is production ready code, basically.

[00:08:10] Nathan Wrigley: Yeah, I remember my recollection of Pantheon was that it was one of those platforms that, well, platform really, it felt more like a platform than a host, if you know what I mean? It just offered more as a layer on top of the typical host that you might find.

However, you also do a whole bunch of stuff around the Drupal space, but also the WordPress space. I'm just curious, maybe you don't have this information, but maybe as a developer advocate, you do. What would you say, as a percentage, does Drupal represent as opposed to WordPress? You know, is it like an 80, 20 split, a 90, 10, a 50, 50?

[00:08:40] Chris Reynolds: We're almost exactly 50, 50.

[00:08:42] Nathan Wrigley: Interesting.

[00:08:43] Chris Reynolds: And we've actually honestly been 50, 50 for about five-ish years, five or six years.

[00:08:48] Nathan Wrigley: So does that mean that in the Drupal side of things, okay, dear listener, WordPress as a CMS is a giant, it's a leviathan of a thing, you know. Occupies a massive amount of the market share. Drupal I think is somewhere in the region of, I think it's like 1.2% or something like that.

[00:09:05] Chris Reynolds: Yeah, we might be creeping up to two-ish, but yeah, it's pretty low, yeah.

[00:09:09] Nathan Wrigley: That then implies that you as a company have, you've got your foot on the pedal more on the Drupal side of things. Maybe the people who are building clever things on top of Drupal are using you much more. You're a bigger player in that space than you are inside the WordPress space, even though it's, you know, the same in terms of revenue. As a community endeavor, Drupal probably means a lot more to you than WordPress maybe.

[00:09:32] Chris Reynolds: Yeah, I mean definitely going to DrupalCon for my first time this last March, it's definitely, so there's Acquia, which is essentially Drupal's version of Automattic. Acquia is a company that was founded by Dries, who is the founder of Drupal, and very much like managed Drupal hosting the same kind of thing that Automattic is into, and a lot of the sort of same ideas, at least from a, where it sits in the ecosystem.

But, you know, you go to a WordCamp and you see the big Automattic booth and you'll see a couple other sort of bigger hosting booths. At a DrupalCon it's like, there's the Pantheon booth and there's the Acquia booth, and then there's a bunch of little things. We're definitely the kind of headliners because between the two of us, I think probably we do own most of those Drupal sites that exist in the ecosystem. But we're definitely a bigger fish in that pond, than perhaps the WordPress pond. There's also a lot more fish in the WordPress pond.

It's an interesting thing, like for me coming to DrupalCon for the first time, to see just what Pantheon's footprint is in contrast to when I go to WordCamps. And, you know, we were big in WordCamps for a long time, and then we kind of pulled back a little bit, and then the intervening time it's I think felt by the community like, well, who are you? Where did you go? We've gotten sort of feedback from folks being like, I used to think about Pantheon, but like it's been a long time, you laid a lot of people off. Why should I care anymore?

And that's, you know, part of my personal goal is to say, no, this is why you should care. That's one of the things that excited me of joining the DevRel team was to go back to our roots and go back into the community, and we still have a really good product that I believed in when I was a developer and I still think is really good as, you know, obviously I think of it as a developer advocate. But like I'm here because I like the thing. I think we have a good thing.

[00:11:19] Nathan Wrigley: Do you basically have the exact same platform for both of the CMSs? So I know there's all the other stuff that you do, but let's just concentrate on Drupal and concentrate on WordPress, those two things. Do you basically have the exact same platform? Or is there some nuance that you can do this on WordPress because of, I don't know, WP-CLI or the REST API or whatever it is that you can't do in the Drupal side? In other words, if I sign up for a Drupal account, do things look different, behave differently, or is it broadly the same?

[00:11:45] Chris Reynolds: It is broadly the same. There is sort of individual differences but they're very minor. And honestly like, in many ways, I think that when Pantheon, and this is before my time, obviously, but I think when Pantheon jumped into the WordPress boat, it was really more of a, well, we have this stack and we're really good at this thing, and WordPress is also a PHP application that has a lot of the same requirements, surely we can just run the exact same stack for WordPress.

And what's sort of evolved over time is like, well, that's like 80% true, but it's the 20% that's really important. And if you just go into building WordPress sites or hosting WordPress sites with the same mentality as you're doing Drupal, well, you are going to run into a lot of the growing pains that we ran into, right? Drupal from like a database perspective is far more efficient. The queries are much shorter because the way that it's structured is more efficient than WordPress. WordPress, you kind of have to do more sort of optimisation on top. So those are things that we needed to figure out.

The Drupal space sort of moved toward Solr as their sort of search tool of choice, which is a project from the Apache project. WordPress went into Elasticsearch. So trying to convince a WordPress team to use Solr, in fact, a pretty old version of Solr, is kind of pulling teeth. Like, well, why would I do that when I'm doing Elasticsearch for everything else? I don't know why you would do that, honestly. Like, you should probably use Elasticsearch.

And so we're like actually going in, that's a project that's on the roadmap as well finally, it's something I've been talking about for like three years internally. There's little nuances. Drupal obviously since version eight has been using Composer as a fundamental part of how the CMS just works. Whereas WordPress, you've got some people that are using Composer, in fact, last time I was here, two years ago, I was talking about Composer. And I don't know that the adoption of Composer has really changed much in the WordPress ecosystem since that time.

I would like to say that it has. I still think that you should be using Composer. Throwback to the last WP Tavern Jukebox podcast that I was on about Composer. But yeah, so there's little differences and I think that that's, there's not anything from a platform level where your experience is going to be that much different.

[00:14:00] Nathan Wrigley: Yeah. If you were to take a look at the Pantheon platform, I think quickly poking around on the site, maybe the pricing page or something would give you an intuition that really you are kind of more for the sort of enterprise level, I think would be fair to say. You know, you are trying to get the bleeding edge out of the websites that you've got, and so it's, high traffic, that kind of thing.

But the endeavor today really is to put all of that code stuff to one side and get into the community side of things. So just to reiterate, we threw around a couple of words there, and maybe the listener doesn't really know that even there's a WordPress community or a Drupal community.

There really is. There's just hundreds, maybe thousands of people who attend events, they might go to a local thing, which we might call them Meetup on the WordPress side of things. I don't know if there's similar things in Drupal. But then there's these bigger events, which we'd call WordCamps, and then there are bigger ones of those which are kind of flagship WordCamps.

There's one in the US, there's one in Asia, and there's one in Europe. They happen each year. And thousands of people show up and inhabit the same space, listen to presentations, hang out in the hallway.

And then you've got the same thing happening on the Drupal side. It's called Drupal Con, but forgive my ignorance, I think the DrupalCon thing is a once a year thing and it moves around the globe. It's not necessarily in the same space. Have I got that about right?

[00:15:15] Chris Reynolds: It's more than once a year. It's actually the equivalent. So DrupalCon is the equivalent of flagship WordCamps. So there's a DrupalCon, there was a DrupalCon US in Atlanta this last year. There is going to be a DrupalCon Europe in, where is it? Maybe Vienna, in the fall. There's a DrupalCon Asia that's just starting to get fired up. That's happening I think in, the next one is like 2026, I believe. I think they just had their first one. So very similar, like the Cons in the Drupal space are equivalent to the flagship WordCamps. There's also DrupalCamps in much the same way as there are local WordCamps.

I feel like in the WordPress space, a lot of the local WordCamps kind of, they either blew up and got super big, or they kind of fizzled after Covid, right? I don't have a lot of local camps. I don't see a lot of local camps anymore. I do see those things happening a little bit in the Drupal space, or at least starting up again.

[00:16:08] Nathan Wrigley: Yeah so, what we're basically painting a picture of here is that we've got two bits of software which basically are trying to achieve the same thing. They're a CMS. They're trying to make it so that non-technical, as well as technical people, can run a project and put it online. Whether that's a website or an e-commerce solution, whatever it may be, you're trying to get your stuff out onto the internet. And both of those things will work.

But also, behind the code is a bunch of people who are willing to go and hang out in the same place, the community, if you like, attend these events. And so there's massive similarity. In fact, you know, if you're an alien landing, I suspect that you wouldn't really know that the two things were different. Okay, there's different advertisers in the hall and there's different logos and things, but broadly they would probably look really similar.

However, in the more recent past, and if you don't know the story, I'm not going to go into it too much here, but you can figure it out by looking at various news articles in the WordPress space and what have you. The WordPress community has really been pulled in different directions, let's say that. And it's curious because no sooner had this happened than some of the more prominent people, Dries Buytaert, who is the founder of Drupal, put out a piece, really as a way of kind of offering, look, this is what Drupal do. We know you've got on the WordPress side things that are not working out for you. Here's our model.

And far be it from me to say whether that is the perfect system. I don't really know it, but I was just curious to get your thoughts on what that is. And that's going to really occupy the majority of the rest of this podcast. What the Drupal community looks like. What you believe it does well. How it does things differently. So let's start there. Let's start with Dries', what he was telling us about. How does Drupal, the community, how does it do things differently in terms of, I don't know, events, the access to the code? So yeah, a conversation around that really. So I'm just going to throw it over to you, Chris. How is Drupal different than WordPress on that level?

[00:18:05] Chris Reynolds: Well, I was saying before we got on that I kind of had a crash course in Drupal when I went leading up to, and then immediately following going to DrupalCon. Part of that crash course was at DrupalCon, they actually have a community summit. It's similar to like, in WordPress we've had sort of community summits before. At DrupalCon it was really more of like a track, with like presenters and like also conversations. It's like space for chatting and hanging out with people.

But mostly, mostly it was like community related talks in a space, talking about what's working, what's not working, as well as a sort of a get to know you sort of thing. And that was really helpful. I also did homework before the event in watching a couple of Dries' last Dries Notes. So Matt has State of the Word, Dries has Dries Notes, which is just like keynote. It's basically the same thing, like the same state of the CMS, right?

I caught up on what was going on in Drupal before the Con. And one of the things that I learned about, and then I followed up and dug into the history a little bit, was we have the same problems, right? WordPress and Drupal have the same fundamental sort of issues from both a contribution standpoint as well as a just organisational, managerial management kind of standpoint.

And Drupal, or Dries, just kind of got to a point sooner where he's like, well, I can't do all of these things. So the Drupal Association, and I'm sure there's some Drupalistas that are going to correct me on my history, but as I understand it, the Drupal Association was initially formed to sort of manage events, because Dries knew that they needed to have events. They were having events, they started off just similar to WordPress, small camp things. And they started getting bigger and Dries is like, well, I can't do all of the management stuff of this, so I need to like do something, create an organisation that can do that stuff.

And that was where the Drupal Association first was founded, to sort of manage that thing. And then over time, that evolved into being able to fund, or kind of oversee, directions for where, more of like a community representative in the general sort of CMS development ecosystem, right?

There is a board. They are elected by the community. They are paid. They manage events, but they also, all of the money that is made after expenses and stuff from DrupalCons and donations and whatever, they have the authority to direct into whatever projects they think would be most valuable for the evolution, or the fulfillment, of the ideals of the Drupal software, right?

So Dries says, I want to do a thing, and he can go do that thing. The Drupal Association is like, well, I think that what we really need is this kind of thing, and we're going to devote some of our resources that we have into hiring some folks to work on that thing.

So, most recently, where you can kind of see this in action is there's been a lot of hype about Drupal CMS. That is a thing that exists because of the Drupal Association, because the Drupal Association saw, okay, I mean, I assume, I'm reading between the lines. But I assume that you can't ignore the sort of declining line of Drupal in the broader ecosystem of CMS usage. But also, there's been a really big problem since Drupal seven of a lot of the sites on Drupal seven remain on Drupal seven.

Drupal seven should be end of life by all accounts. Everything else up to the current version is end of life. Drupal seven isn't, because there's still, it's now just under, but it's still close to 50% of Drupal sites are running Drupal seven. It's a version of Drupal that's about 10 years old.

And the reason why, there's so many people. Drupal historically has always been a thing where, when a new version came along, you kind of killed your old site and rebuilt it in the new version, because it wasn't sort of backwards compatible. WordPress has gotten around that by just remaining backwards compatible all throughout its history.

Drupal seven to Drupal eight was the first version to introduce Composer. We talked about Composer and how a Composer's been part of Drupal for a really long time. that was the cutoff. So that was a pretty big shift. And there's a lot of people, teams, organizations that have not made, or have been reluctant to make that shift because it's a, it's a rebuild. It's a full site rebuild.

It's not just, we can just migrate the thing over. You have to rebuild your site. You do need to migrate your stuff over, but also you need to rebuild your site. So in the intervening time, WordPress has gained adoption and acceptance and grown into 43%. And so now we've got these Drupal seven sites where it's like, well, we need to rebuild anyway. Do we rebuild the site in Drupal 10, 11? Or do we rebuild the site in WordPress where I'm never going to have this problem ever again.

And that's where a lot of that like, bar graph, a lot of those sites have moved to WordPress. Some of them have stayed on Drupal, but it's a declining number, right?

So obviously, folks inside Drupal see this and know that it's happening, and know that they need to do something about it. So Drupal CMS is basically like a layer on top of the latest version of Drupal, which is 11. It's got a far nicer installation screen. I wrote a blog post about this on the Pantheon blog, I think. It's got a far nicer installation screen, that actually walks you through, stepping through like what type of site, what type of content you want to have on your site. To actually get you thinking about the site that you're building before you just hit install. Which I find to be amazingly refreshing.

And then beyond that the admin interface is far less cluttered. I know one of my personal gripes about working with Drupal, even up until, up until now, like up until before Drupal CMS is that there's too many buttons, there's too many menus, there's too much stuff. Like, I don't know where stuff is.

This feels a lot more familiar, partially because I think it kind of resembles the WordPress admin a little bit. You know, sidebar on the left, menus. And it feels just more, more familiar to me. And then also they have built in some new architectural things like, recipes are a thing where, a recipe, Drupal has modules, WordPress has plugins. Modules generally need a lot of configuration, to get them actually working.

When you install a module, it's not like it just works outta the box. A lot of WordPress plugins, you install a plugin, it just works outta the box. So a recipe is like, here is, maybe a collection of modules, maybe a specific module, but it's probably a combination of a bunch of different modules, but also the configuration that goes along with them.

So when you install a recipe, it's like, here's the stuff that you probably will need. You're most likely to need this stuff in this order, configured with these settings, and then you can do whatever you need after that. But like, here's the go bag and now you can move on. So, one of the really interesting recipes for Drupal CMS is the SEO recipe.

And that is interesting because they're using a Yoast module. The Yoast module is literally taking the JavaScript of Yoast SEO from the WordPress plugin and throwing it into Drupal. And what's fascinating about that is it doesn't have all of the other stuff that comes with the Yoast plugin, it's just the traffic light system, and the scanning the text system and it's, so it's the best possible implementation of Yoast that I've seen because it's all of the good stuff.

They've also built an AI recipe. And that's interesting because when that is configured, you can actually talk to an AI chat bot inside your Drupal instance and ask it questions about Drupal or about your site. You could say, hey, I need to create an event content type. I'm gonna be hosting events. They're this type of thing. I need to have a, like a, date picker and whatever, and we are taking attendees and you can tell that the chat bot that that's the thing that you need. And it will, to the best of its ability, build that content type inside Drupal for you.

So the WordPress equivalent is, I have a podcast and I need an episode post type. I just talk to a chat bot, and it magically creates that episode post type for me with like the Gutenberg blocks I need. That makes it an audio format or whatever. And, it's just there for you. It's like, great, thank you chat bot. As a WordPress developer, I think that's really cool. Because that's kind of the thing that I want, is like I know how to do some things, but I really don't know any of the buttons and gears and gizmos in the Drupal admin.

But if I have a chat bot to sort of help guide me through, I know I can figure out the rest of the way, or I can see how it did the thing, and I can figure out, oh okay, so that's what I need to do. And so all of these things are geared toward the idea of just getting more people using Drupal and lowering the barrier to entry.

Because one of the big things with Drupal is it's always been really developer centric, really highly technical, and you need sort of skilled individuals to even just manage the site. So if we lower that barrier to entry, you can target the people that are already using WordPress, the sort of content level people or the site administrators that don't have a lot of technical experience.

That's all like basically because the Drupal Association put money, funding that they had into backing these very specific projects.

[00:27:25] Nathan Wrigley: It is kind of a curious idea, isn't it? It's like a subset of the CMSs capabilities put into this one project, Drupal CMS. Which has like a target audience in mind. So it's like a blogger, or a podcaster or something like that. You know, it's for content creators. That was the message I got from when I read all of the, the marketing bits and pieces that came out.

But also addressing the need for it to look nice. That was always an area I thought WordPress excelled at. When you logged into the WordPress admin, it was night and day looking at a Drupal admin. Everything was consistent. Everything looked modern and clean and easy to understand. On the Drupal side, it was, it was much more difficult to understand. But also things like updating plugins. Backwards compatibility on the WordPress side, always much more straightforward. On the Drupal side, much more difficult.

And so this is such a curious experiment. Putting it into the hands of people who might want a blog, or whatever it may be, and hopefully making it more straightforward. And the website for it, I will link to it in the show notes, it's just so kind of modern and appealing and friendly and, Drupal never, for me at least when I got to Drupal eight, for the exact reasons that you described, that's all of my sites would have stayed on Drupal seven.

It definitely wasn't that kind of warm and fuzzy welcome to everybody kind of thing. But now it really look like it's leaning into that. But getting back to your main point, that was funded from the inside by some, facets, some internal mechanisms, some body inside the Drupal Association that decided that's what we need to do. This is where the money's going. But are you saying that decision making was divorced from Dries?

[00:29:02] Chris Reynolds: Dries leads the technical architecture. And Dries will like say we need to do a thing. And he may be personally involved in the leadership of doing that thing, but mostly he's like at a director level. Like, go my people and go forth and do stuff. And the Drupal Association says, okay, well one of the things that Dries said we need to do is X. So how can we make X happen? And in the case of recipes, it meant getting agencies and people from agencies involved. Create like a coalition. Like there's a bunch, it wasn't just one agency. It was like a bunch of people from different agencies are working on this thing together. Which is another thing that I find really interesting about the Drupal ecosystem.

I have thoughts about that too. But in this context, yeah, I get a bunch of different people to work on this thing. Um. Whether it's the SEO recipe. Whether it's the AI recipe, and they, I think the way that it sort of broke down is, and it might have been even Dries that conceptualized the idea of recipes and it's like, okay, go out and implement this thing.

But when they did, it was like, okay, if we're gonna do this thing, we need these types of recipes from the get go, from day one. We need SEO, we need whatever. We need AI, we need content things, so that people have an idea of what a recipe is and can start building their own recipes.

[00:30:15] Nathan Wrigley: So they're bound into it? You can't install Drupal CMS without those things. They're just there.

[00:30:20] Chris Reynolds: It supports the recipes, and in the installation process, when you're doing the Drupal CMS installation, that screen that I was talking about, where it's like asking you the type of site you want to build, those types of sites in quotations, correspond to sets of recipes that align with each of those things.

It doesn't ask you about AI in the installation screen, but it does sort of say like, oh, do you want this type of content or that type of content? And then we, based on your selection, it automatically installs those recipes for you.

[00:30:48] Nathan Wrigley: So it's installing things based upon a wizard at the beginning, but the principle being though that you the end user, not really interacting with anything apart from oh, I would like that. Yes, please. I would like that. And then you finally get to the end of the wizard, wait for a few moments. The modules get installed, activated, and they're pre-configured to behave in a way which is likely to be the best that you can get.

[00:31:08] Chris Reynolds: To get you as close to what you want as possible. And the goal, the roadmap, is Dries wants to actually take that one step further, and do sort of site templates where if a recipe is a collection of modules and configuration, a template would be like, I want to build a real estate site. So I download this template, or I install this template and then click a button or two and it gives me a real estate site with the configuration that I might need to have a real estate site.

And obviously I can go in and customize things, but I have a starting point. One of the things that I heard a lot when I was talking to people within Drupal, among other things, there's not really a marketplace as much for stuff, for software, for add-ons in the way that there is in WordPress. And there's not really in particular, there's not really the same sort of like theme or a repository, or a place to go for commonly used or shared themes in the way that we have the Themes Repository. Mostly you have like the default things and then you're building your own.

So, as a user, having a template that maybe comes with a theme that is specifically tuned for that type of site is a really big win, because there really isn't an alternative in the current ecosystem within Drupal.

[00:32:23] Nathan Wrigley: Yeah, that's, really worth leaning into because again, please interrupt me if what I'm about to say doesn't actually match reality anymore. But when I was using Drupal, there was basically no commercial plugin system. Everybody had kind of leaned into the same thing for the same problem.

So if you wanted to put a form on your website, there were a few, but there was this one called Webform, and it was just the one everybody leaned into it. And so rather than in the WordPress space where you've got, you know, you've got a few repository ones that are free and easy to use, and then you've got the commercial ones that you can pay for and they add different features and support levels and all that kind of thing.

In the Drupal space, it felt like there was just this one kind of community endeavor to do the thing. Yeah, so if you wanted something to display data, Views was the thing you used. The Views module, and I think that did actually get rolled into Core. So it's there. My point being, there isn't this sort of, shattering is the wrong word, but in the WordPress space, there's often a dozen, more than a dozen, there's multiple alternatives. So you have to go and find the right thing.

In the Drupal space, it feels more like, okay, for that problem, we have this module, and everybody leans into it. So I'm presuming that all the people who contribute in the community to the code and what have you, they'll all finesse that version. But that means therefore, that when you come to build the CMS, there's basically this one way of doing it? Okay, if you want forms, we're going to use that module. And if we're going to add this feature for real estate or what have you, here's the modules that we're going to add in. And the jigsaw of those modules will make it work. And that's different from WordPress. WordPress has much more leaned into commercial plugins and kind of figure out which ones you want for yourself.

[00:34:04] Chris Reynolds: Yeah, that was one of the things that I didn't know going into DrupalCon that I learned while I was there. It's a really different approach, and I actually kind of appreciate the Drupal model because the community is built around more of an idea of, if I build a form plugin and you build a form plugin, and mine is the defacto form plugin or.

In the Drupal space, it's really more of a, well, let me talk to you and see what ideas you have that we can bring into the canonical one and just collectively like integrate those things. And that's, that is a thing that happens more often than not in Drupal. That's why you don't see the competition, the competing modules for different things.

Because if you had a competing thing, or you had a different idea, you would contribute it to the one module that does that thing. Or if you had a different thing, then you might be invited to do the same, right?

In the WordPress space, it's like I want to protect my form module or my form plugin because right now it's free, but tomorrow I might want to sell it, and I want to keep my intellectual property to myself and not contribute because, you know, I might wanna make a buck on this later.

And, I kind of like the other thing better because it's more, it is more of a community. Like I get like wanting to make money and everybody wants to make money and have a form plug in. Like, that's great. Like I'm not going to say Gravity Forms shouldn't exist or anything like that. Gravity Forms is amazing. But I do think that building an ecosystem around contributing to a collective, or a community based solution for the thing, where everybody has a, a say or a seat at the table, is a really, I don't know, possibly overly idealistic, but very optimistic sort of view of how we can contribute to software.

I find it really nice. Like it feels good. Like it feels less like we're all trying to grab our little piece of territory, you know?

[00:35:53] Nathan Wrigley: It feels to me like that moment when you first install Linux. And you realize, wow, there's a free OS that I can put on my computer. And there's just something quite remarkable about that. That a bunch of people got together and, really pointed everything at this one solution. I suppose that is the choice that you're going to make. Really, that there is something right in there.

You know, the commercial side of WordPress has probably been its single biggest accelerator. The fact that people could build businesses on it. And they could have a living. They could obviously refine and finess and dedicate real time entire lifetimes, in many cases. Get staff on, support staff and what have you. Pay all of those people because they've cracked this nut and everybody wants a piece of it.

Whereas on the Drupal side, it's much more, let's go for egalitarian, let's say that. But it, also, I suppose, means that at the moment where something doesn't work you probably have to either understand how to maintain that yourself or hire a developer.

So there's a bit of a trade off there. And I presume, like I said, I imagine that's why there was this acceleration of WordPress's popularity because the people who maybe were buying these plugins had that intention, I just want a website. I don't want to learn how to code. I'm not interested in that.

I can see over here, look, I can buy that. It's $97 a year. That's perfect. That'll satisfy me perfectly. Whereas maybe more on the Drupal side, it's okay, that kind of works, but not entirely. I now need to make it work and obviously the community can do that.

So that leads me then to the next question, which is, who the heck builds Drupal? So in the WordPress space, if you're listening to this, you probably have an understanding of that. There's a lot of volunteers, but there's also a lot of companies that will dedicate a proportion of their time. We have this idea of Five for the Future. And so 5% of whatever it is that you want to give, be that time or money, or what have you. And so there's this idea of community massively, but also corporations, businesses, putting time in. Is it the same basically on the Drupal side? Is that how it works?

[00:37:51] Chris Reynolds: Yeah, largely. One of the things that I think you'll notice that is a little bit of a distinction between WordPress and Drupal, from the events again. Is going through like the showroom, the sponsors floor. And at a WordCamp you see the hosts obviously, but then you see a lot of like plugin development shops, and that's pretty much what I would expect, right? Big plugin or theme development shops and WordPress hosts. And a lot of the WordPress hosts are doing plugin development, and like, that's sort of the thing.

In Drupal, and at DrupalCon, obviously we have the hosts. And we had a, I mean, CKE Editor was there. That was kind of weird to me. I don't know, like it's in Drupal. It was weird to have like a library have a booth space. That seemed weird to me. But like it's a lot of agencies, because agencies are the ones that are doing the work, and I've never seen an agency or maybe not since very small, like local WordCamps, have I seen an agency with a sponsorship, a booth space at a WordCamp.

But that is, that's where it is. And it's agencies that do a lot of that Core contribution, because they're also in the weeds working with clients and building these things for their Drupal customers. And so like, the SEO recipe that I was talking about, like at DrupalCon we, Pantheon has booth demos. Acquia also has booth demos, which means we can talk about, like do demos of our platform, whatever. What we actually did was bring in guest speakers from like agencies and universities and whatever that are actually using Drupal and Pantheon and to talk about their implementation of the cool stuff that they're doing, because that works better.

And one of the people that I talked to was about the SEO recipe, and he is at an agency and he worked with other people at other agencies, competing agencies even, to make this SEO recipe. So it's, that's where the contribution comes from. But again, like it's the same sort of thing.

Dries said 10 years ago, wrote a blog post about the maker taker problem, as he defines it. And then again in September, in relation to the current state of things in the WordPress ecosystem, because that's a thing that he's been thinking about for a long time. It's obviously a thing that Matt's been thinking about for a long time.

Like it's not, again, we're not that different. We have the same fundamental problems. At the Community Summit at DrupalCon, one of the topics of conversation was getting more people involved, a younger generation involved into Drupal development, which is the exact same conversation we're having in WordPress as well.

Like, how do we appeal to a younger audience? It's all the same stuff, right? And there was at some point like a contribution like pie chart. Again, similar to the pie chart that could be displayed at a WordCamp. You know, Automattic does a big chunk of that pie chart.

And then you've got, you know, maybe Google does a smaller part of that pie chart and maybe like Bluehost or whatever. Similar pie chart. Acquia does a lot of the big part of the, of that pie chart. And then like other agencies are noted around, and then there's like an other category, right, of just like individual contributors. It's a very similar breakdown.

[00:40:47] Nathan Wrigley: It's interesting because obviously you alluded to the fact that WordPress has been in a state of flux since September. But Dries, I presume prompted by the situation that arose out of WordCamp US. He wrote a piece very much timed after that. So I presume it was in, there was some sort of correlation in his head. And he was laying out how Drupal have, not solved, but how they just have a different approach to that. And I can't remember every single detail, but there was some curious examples in the Drupal community, like this kind of, I'm going to say pay to play thing.

In other words, if you as a company, let's say Pantheon may fit into this perfectly, if Pantheon steps through certain hoops and can prove that they did this thing and this thing and this thing for the community, for the Drupal project. If you step through those hoops, you then get, kind of, merit on the other side.

You can, for example, turn up to DrupalCon as a sponsor. My understanding is that maybe it's only certain tiers, I'm not really sure. But you can't sponsor DrupalCon unless you have jumped through those hoops. And we don't really have anything on the WordPress side like that. We have Five for the Future, but it's hard to pin down. It's hard to figure out who did what and what have you, because there aren't the same sort of goalposts, but it feels like the goalposts are a bit more nailed down on the Drupal side.

[00:42:03] Chris Reynolds: There is a process of nailing things down. I don't know that it goes to the level of, like you can't actually sponsor, because obviously Pantheon does sponsor and we've been, on the other end of being told that we don't contribute enough to both WordPress and Drupal. But that also depends on how you define contribution really. And I have thoughts about that. The merit thing, it's just where you're drawing the lines in the sand. And Drupal has, Dries has his particular lines and the things that make you a contributor to the ecosystem, and what that means in Drupal.

And then, to a degree, I mean, yeah, like you said, Five for the Future is kind of, sort of that thing, but it's also kind of amalgamous and like it's honor based. There's not really a real sense of tracking or, you could kind of, sort of track things, I guess. But it's very wibbly wobbly.

But my perspective on contribution always has always been, one of the things, I know we're not supposed to talk about what was talked about at PressConf, but Brad Williams, who I, was my former boss said, he was talking about Five for the Future and was talking about how Web Dev was very early on an adopter of Five for the Future, and I was there at the time, so I remember this. So it's not just Brad's words that I'm repeating. And the way that he approached Five for the Future was very much in the umbrella of if you're doing anything WordPress related that is open source, we are counting that as a Five for the Future project, right. And that was how I understood Five for the Future.

That was kind of how it was presented back in 2014 or whatever when Matt first threw the idea out to the, out to the ecosystem. And since then it's sort of become this thing where contribution to WordPress really means Core contributions, or contributions in very specific ways. And it doesn't mean all of this other stuff over here, including an up to theme development, plugin development.

Even if that stuff is on .org, even if that stuff is open source, that's not included in contribution. But I'm very much in the side of the bucket where like, well, everything is kind of contribution. We wouldn't know how good WordPress scales to like enterprise level sites that are running it today, that are driving the adoption of WordPress, and driving the bar in like the visibility of WordPress, if it wasn't for just hosts that are running the thing and making sure that it operates properly. And the teams like 10up and Human Made, and whoever who are like then, oh, to get this working at its best, fastest, most optimized state we need to do some enhancements. Either through the plugin ecosystem or contributing back to Core, so that we can push this code to these hosts, or platforms, or softwares as a service or whatever so that they operate for these clients that we're building.

So like I kind of feel like everything should be, even if you are a taker, in the language of Dries, that doesn't necessarily mean that you're not pushing the ecosystem forward. And I have that critique for both of our BDFLs, right? Because they both have very similar ideas.

Like I think that the contribution title could be applied and should be applied more broadly, because everything that we're doing is driving the project forward. A lot of the stuff that I write is like GitHub actions, or like plugins or things that are still broadly available to, and publicly available, and they're open source and they're for the community, but they're not technically contribution, because contribution is narrowed down into this very specific definition.

[00:45:30] Nathan Wrigley: It's kind of curious, you know, if you were to cast your mind back 20 years, the beginning of both Drupal and WordPress, just even the idea that they would still be around for one thing, you know, that that software wouldn't have just come and eaten them up and there would be like a two year lifespan.

[00:45:44] Chris Reynolds: And that there's an open source solution for these things.

[00:45:46] Nathan Wrigley: And it's going and it's kept rising and it's kept being used. That's just so curious. But also the teething pains of that. The idea that, you know, it started with Matt, and it started with Dries, and then people got on board and it grew. And then in the case of Drupal, and in the case of WordPress, it just grew to the point where these individuals can no longer handle everything.

You know, you described how Dries needed to sort of say, can somebody handle the events please? Because that's just not where I want to be. The same, presumably on the WordPress side. And now we're into giant communities. Really, really complicated communities. A lot of differing opinions, a lot of different maybe even politics, but a lot of different backgrounds, geography, the whole thing.

It's this international thing. And it's difficult. It's really, really hard to get it right. But what I'm taking from this conversation. Is that maybe Drupal do things differently, but they have way more in common than we have as differences.

But also maybe there are some things that WordPress does better. Maybe there are some things that Drupal does better. And it would be very, very interesting if the two communities could kind of collide more, and share those ideas and we pick the best of each of them. It's never gonna be perfect, but maybe that's something that in the future, given that really at a very core level we're not in competition with each other, it would be very nice if those conversations could take place.

And I think you've laid the groundwork for a lot of that and explained how one project is not that dissimilar to the other one. So, that's it.

Chris, thank you so much for chatting to me today. I really appreciate it. That was very enlightening.

[00:47:22] Chris Reynolds: Thank you for having me. I always love chatting with you.