[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, website maintenance for WordPress agencies and freelancers.

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 Reyes Martínez, and Héctor de Prada.

Reyes has been involved in the WordPress community since 2015, with a background in journalism, digital communications, and early stage startups. From 2021 to 2024, she was sponsored by Automattic to contribute full-time to global marketing and communication efforts for the WordPress Open Source project, She led several initiatives during that time, including the experimental WordPress Media Corps. Reyes currently serves as content lead at Modular DS.

Héctor has been building websites since he was 12, and has worked with WordPress for nearly a decade, first as a freelancer, then running his own agency. Today, he’s one of the co-founders of Modular DS. He co-organizes the WordPress meetup in León in Spain, and writes a Spanish newsletter that keeps readers updated with the latest news from the WordPress ecosystem.

In this episode, we get into the nitty gritty of WordPress maintenance. What it takes to effectively manage multiple websites, and why maintenance is such a crucial, if often overlooked, part of running a successful client business.

You might think that updating plugins and themes is all there is to it, but Reyes and Héctor explained that there’s much more involved, performing regular backups, monitoring, uptime, and performance, checking for security vulnerabilities, database cleanups, and ensuring essential features like contact forms continue working as expected.

We discuss best practices for educating clients, how to position ongoing maintenance as an investment rather than a cost, and solutions which can help automate and streamline these essential tasks.

We also chat about how the maintenance landscape is changing with upcoming legal requirements around accessibility and privacy, and the emerging business opportunities for professionals specializing solely in website care.

If you’re a freelancer or agency owner looking to scale up your business, perhaps you offer care plans to clients, or are considering adding maintenance plans to your service, 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 Reyes Martínez and Héctor de Prada.

I am joined on the podcast today by Reyes Martinez and by Héctor de Prada. Hello Both.

[00:03:53] Héctor de Prada: Hello Nathan.

[00:03:54] Reyes Martínez: Hello Nathan.

[00:03:55] Nathan Wrigley: I’m so pleased to have both of you on. This is going to be interesting because I’m going to be speaking to Héctor in about a week’s time as well, which will be kind of interesting. So there’ll be two podcasts coming out in quick succession featuring Héctor.

But the topic will be very different, and I’ll explain in a moment what the topic is going to be about.

But before that, I wonder if we could just get a little bit of an introduction to both of you. If we can keep it around the subject of WordPress that would be helpful.

So let’s go to Reyes first. Tell us exactly who you are, who you work for, what do they do, whatever you like in your little potted bio.

[00:04:29] Reyes Martínez: Yeah, sure. I’m Reyes and I have been part of the WordPress community since 2015. My background is in journalism and digital marketing and communications, and over the past 10 years, more or less, I have worked with startups and tech companies closely connected to the WordPress ecosystem.

And from 2021 and 2024, I was sponsored by Automattic to contribute full time to the WordPress project, where I had the opportunity to contribute to different marketing and communications initiatives.

And now I am the content lead at Modular DS. We’re building a tool to help freelancers and agencies manage multiple WordPress sites more efficiently.

[00:05:13] Nathan Wrigley: Thank you so much. And let’s move over to Héctor. Similar question really, just give us your little potted bio.

[00:05:19] Héctor de Prada: Of course. Well, I have been making websites, I always say almost all my life, since I was like very young, at 12, 13 years old. At the beginning, not with WordPress, I have to say. But I started working with WordPress around 8, 9 years ago when I started freelancing as a web designer, and that evolved to creating a web design agency.

So I have been doing web design and websites, WordPress websites, for a long time. And 4 years ago almost, it’s when my partner and I, David and I, we started our current company, which is Modular DS, which is now where Reyes is working.

I am also part of the community. This is what you were saying, Nathan, that we are going to talk about, WordCamp Europe, because I am one of the organisers at the meetup in León, in my city. So this is also something I like a lot because we go to a lot of WordCamps, a lot of WordPress events, and it’s very nice to be able to do that in our own city as well.

[00:06:20] Nathan Wrigley: Thank you both so much. So if we stray into anything today, like a blog post is mentioned or a homepage or anything like that is mentioned, I will endeavor to link to that into the show notes. So if you head to wptavern.com and then search for the episode with these two fine people, then you’ll be able to find all of those links. It’s going to be easier to do it that way than to read anything out in an audio podcast.

The approach I think I want to take with this episode is one of somebody fairly new in the WordPress space. So if you are new in the WordPress space, then you might just have the one website. And maintaining that one simple website is probably a reasonably straightforward thing to do. You know, you log in, you update the plugins, you update the themes and what have you.

But if you’ve got any aspirations of becoming a bigger player in the WordPress space, perhaps you want to take on the job of maintaining multiple websites, perhaps you want to have clients and you want to maintain their websites, it becomes fairly obvious, fairly quickly, it’s a bit of a chore. There’s quite a lot of tasks that you need to do in order to keep those websites live.

So that’s what we’re going to talk about. What are those tasks? What’s important to notice if you are a WordPress freelancer or agency owner. What are the things that you need to make sure that your clients are getting updated with and for? And then I guess we’ll sort of mention right at the beginning that Modular DS is something which kind of can take that process off your shoulders and make it fairly automated. But you can go and check out that of your own accord.

So let’s just get into it then. What are the things that you would need to worry about? You can interrupt each other as you see fit. What are the kind of tasks that as a newbie WordPress we may not even know are coming our way, when we’ve got 2, 3, 5, 50 websites that we’ve got to keep maintained?

[00:08:14] Héctor de Prada: I don’t think it’s, how to say, like that we don’t know we have to do that, or that we don’t expect to do it when we are trying to manage a few websites. Reyes and I, we were talking this morning, normally maintenance or maintenance tasks are something nobody is very thrilled about doing, okay. It’s not like the best job. Like, you can be a designer because you love creativity and designing things, or a developer because you love to build things.

But I haven’t met anybody that is like, oh, my dream is to update plugins, create backups, and restore the website when it’s broken, you know? I think that’s the number one challenge, okay. Normally I see that one of the biggest problems is that we know maintenance has to be done in a website, but we don’t always do it. And when we have more and more websites, it becomes even a bigger problem, because we also let it aside more and more because it’s too much work. So that’s one of the main problems.

[00:09:17] Nathan Wrigley: One of the things that in my life, I don’t know what the number of websites was, but there was a point where each morning, because I decided to do the updating on a more or less daily basis, there came a point where you realise that you’d now logged into X number of websites. So you’d gone to the URL to log in, you’d found the username and password, you’d logged in, you’d inspected whether there were plugins or themes to be updated. You’d gone to them individually, you’d update them in a careful manner to make sure nothing got broken, and you moved on to the next website. And at some point you kind of have the intuition, how many minutes or hours have I just lost?

And whilst for one or two websites this really isn’t a problem, I guess what we’re talking about here is something at scale, when you’re over a, let’s say 2 or 3 or 5, or whatever that number is. It does start to add up, and you can’t afford to waste time in that way. And I think it’s exactly like you said, you don’t really know going into it that this is what you’re going to end up doing with your WordPress websites. But you’re right, nobody wrote down on their bucket list of things to do in life, I would like to update plugins for a living.

[00:10:23] Héctor de Prada: And it’s very important at the same time. Like we said, yeah, maybe Reyes, you can say a little bit more about it. But maintenance, it’s really important for many reasons, in particular in the WordPress ecosystem.

[00:10:34] Reyes Martínez: Yeah, I would say that it’s just that, that it’s not the most glamorous part of managing a website, like all the maintenance tasks. But I think it’s also what keep things running smoothly and professionally. I guess that’s the difference between being reactive and being proactive as well. I mean, that makes all the difference. So even though it’s not the most, I don’t know, glamorous part, it’s still very important to keep things professionally.

[00:11:03] Nathan Wrigley: What are the things that we’re updating? So we’ve covered plugins and themes, and I suspect that they’re the ones most people, and again, the audience for this podcast is really broad, so obviously that sentence will be really blindingly obvious to many people. But there may be a proportion of people who don’t even know that that kind of stuff needs to be updated. So let’s just work from the basics upwards. There’s plugins and themes. When you talk about maintenance, what else are you bringing into that?

[00:11:30] Héctor de Prada: You have the updates, both plugin, themes and the Core of WordPress, because it also gets updated. Now it’s once a year, it used to be like two, three times a year so those are also very important updates. But normally it’s mostly, because some people might ask, why should I update a plugin? If my website is working, if it’s perfectly fine, why do I have to update a plugin or a theme?

Well, one of the biggest things in maintenance, because we have to do these updates, is the security part. I am positive that WordPress is a secure solution, that is why it powers 40 something percent of the web. But at the same time, we have 60,000 different plugins just in the WordPress repository. Each one of them is created by an independent team or developers. And even when everybody tries to create the best possible plugin, a secure plugin, and everything, there is human error, of course. And there is always people, since WordPress is so popular, trying to find vulnerabilities to attack these kind of plugins or themes.

So many times, the most important updates are security updates. To avoid that, you have an older version of a plugin or a theme that maybe got exposed, and somebody found a vulnerability, and your website might get hacked because you didn’t do the updates. So even if your website is functioning perfectly, you should still do those updates. And this is something, for example, a lot of end clients, they normally don’t understand when you run an agency and stuff, because they don’t see the point of doing this. But this is one of the reasons, it’s super important.

[00:13:08] Nathan Wrigley: In the normal experience in life, you go into a shop and you buy a thing, like some new sunglasses or a pair of shoes. You don’t anticipate having to update the shoes or update the sunglasses. You kind of just bought the thing and the thing is now yours and off it goes. You know, you expect it to function as sunglasses from now on, and the shoes will keep going as shoes. You know, you might have to replace them from time to time, but that’s another thing altogether. So it’s kind of hard to encapsulate that.

But also, I suspect that most clients wouldn’t even know that there’s this sort of specter of security problems and the fact that bad things could potentially happen. Most clients I imagine have just come to you, the agency, the freelancer, because they want a website. They’re not interested particularly in all of that, but you have to explain that to them. And I always thought that was quite hard. I always got an intuition that the clients kind of thought, what are you on about? I’ve just bought this thing from you, why do I need to update it? Why do I need to keep doing these things?

[00:14:07] Héctor de Prada: Education is one of the biggest parts in having a WordPress maintenance service in your agency or as a professional. Most people, end clients, many people is not tech people so they won’t understand. Updates, backups, these are all very not tangible things. So it’s not hard to explain, but it is more, it’s not like you go to a store, okay? You buy something, it normally doesn’t need maintenance. But I would say it’s like, you buy a house, you buy a car, it needs maintenance, okay? Because you can keep running with a car, but even if the car still works, maybe the brakes, at some point they will stop working and you will have a crash and nobody wants that. So I would say a website is more like a car than a normal product.

[00:14:49] Nathan Wrigley: Yeah, that’s a really nice example because with a car particularly, there are bad people who are literally trying to break into the car and take the car away, or do damage to the car, or steal bits from the car. That explains it really well.

Okay, let’s imagine that you’ve had that conversation, you’ve done that education piece, you’ve said to the clients, look, we need some kind of thing going on in the background. There has to be some kind of ongoing relationship between me, the website builder, the developer, and you, the client. But what are those tasks? What are the things, I guess your software will handle these kind of things, but just talking about them hypothetically, what are the list of things just beyond plugin, theme, Core updates? Are there any other things which you recommend?

[00:15:32] Reyes Martínez: Besides updates there are also, for example, like I think it’s very important making regular backups. Monitoring up time and performance. Checking for security issues, you were just talking about that as well. Vulnerabilities, cleaning up the database, and in general, like making sure the site is running smoothly, like contact forms and links are working.

Because there are things that even people think they might have not, I don’t know, like they are not very important. They can have an impact on their business as well. For example, like a broken contact form, that’s just like a very small example, but yeah, those things come to mind. I don’t know, Héctor, if you want to add anything else.

[00:16:15] Héctor de Prada: I think those are the main ones, like your backups and the restoration of the backups when you have a problem. It happened to me I have to say. When we had the agency, I remember more than a few times having a client calling me and telling me, hey Héctor, the website is not working. And I was like, I didn’t know. So it’s like a very, very embarrassing moment because you’re supposed to be taking care of the website, but you didn’t know it wasn’t working until the client told you.

So things like monitoring. When I started making websites, I couldn’t monitor them at all. If they break, I wouldn’t find out because somebody told me or I was just trying to do something and I found out. So monitoring as well. Security Monitoring, like you said, for vulnerabilities, for malware. There are a bunch of tools. I mean, it’s not only tools, maintenance tools, like it can be Modular or others.

There are a bunch of tools in WordPress, like for everything in WordPress, that can help you with this maintenance task. Because the ideal thing, like we were saying, is to automate them so they don’t take so much time. Even if you only have one website, the ideal thing is that backups, monitoring, you have most of it automated, so you make sure even if you forget, if you go on holiday or whatever, it will still be running.

[00:17:30] Reyes Martínez: Yeah, and you can get alerts, for example. Like Héctor was saying, if a website goes down, you can get alerts so you don’t have to be monitoring all the time. Imagine like manual monitoring or going site by site, just checking if everything is working correctly. And monitoring, it’s exactly a big task as well of maintenance and because it can help you catch problems early.

[00:17:55] Nathan Wrigley: Okay, let’s just break all that now and then. So we’re imagining a scenario where we’ve built a website, we’ve handed it over to a client, and then we’re sort of presenting with the client the scenario, look, although we’ve given you the thing, here’s the website, there it is, it’s on the internet, there’s a whole load of other things that we need to do in the background.

And there’s an education piece there, but there’s also a bit of sales that has to go on there because you have to persuade them, presumably that the thing that I’m suggesting here, you are going to need to pay for probably, there’ll be a, some kind of subscription model going on there. We will do all of these things in return for a monthly fee or whatever it might be.

But broadly it is updating things. So that’s plugins, themes and Core. Making sure that those things are available. Then there’s the backup piece, a different thing altogether, and that’s just basically storing in multiple locations, an entire version of the website, the database, and the files to make sure that if an absolute catastrophe occurs, you can go back to whenever the website was last saved successfully, minus any security problems that you might have.

And then another thing is uptime monitoring, which is the process of just alerting you, and I presume it’s you, not the client, that something’s gone wrong. The website that was there 10 minutes ago is not here now. And that’s a really, really, you know, that’s not a once a day thing, that’s once every two minutes kind of thing. You want to know the minute the website goes down, so that you can be the person that contacts the client to say, look, we see that the website’s gone down. And in some curious sense, you actually paint yourself in a good light by admitting something before they’ve even learned about it.

But also something that you said that I never really think about is the idea of bits of the website, which may appear to work, but which don’t work. So the contact form is a big one. You know that whole egg on your face moment where you realise that possibly for six months, the contact form hasn’t worked, has never worked, and you have no way of saying to your client, look, sorry, we’ll be able to reverse that, we’ll be able to get all of the contact forms that would have been submitted over the last six months, because you won’t. It’s gone. And if it wasn’t working, that’s a catastrophe.

But then my mind then goes to things like e-commerce. The site might look fine. Everything might check out okay, when I say checkout, I don’t mean checkout through the cart, I mean, looks fine. But the checkout might not work. Maybe people can’t actually buy things off your website, so it’s up but it’s not working.

So there’s all this stuff. And I guess what Modular DS is doing, and the rivals that you’ve got in that space, is they’re trying to take all of those tasks, package them up into a wrapper piece of software, and basically you don’t really have to worry too much about it. You just sort of set it all up, make sure that all the dominoes are set up in the right place. And then it will do all of those things for you without you having to do too much. Have I got that about right?

[00:20:54] Héctor de Prada: Yeah, of course. That’s the idea, to try to centralise everything when you have a lot of websites. And at the same time, like we were saying, yeah, automate these kinds of tasks so they don’t slip away. And it’s a great point about the WooCommerce because one thing about maintenance is that it’s very dependent on the type of website you have. I mean, it’s not the same maintenance you have to do for maybe a small corporate website, like the Meetup group website, for example, than a big e-commerce that is selling hundreds of products every day. You won’t need to have the same systems in place, not for backups, not for monitoring, not for any kind of checks. So that’s also very important to know. Maintenance is very different depending on the website.

[00:21:38] Nathan Wrigley: So in the case of this whole idea of being able to do this for your client, I’m guessing your position would be that this is something that you can in fact sell to your clients on a regular basis. It’s not like you built the site back in 2024 and you’ve charged a fee for it, and then that’s the end of that. This is more of a, you charged a fee to build the website, and now we have this kind of, I think the term which I hear used a lot is like Care Plan or something like that.

Some kind of process of, on a monthly basis, annual basis, whatever it might be, you offer these different things in return for a subscription fee, and therefore kind of have recurring revenue. And in many cases that recurring revenue might not need a lot of work. You know, fingers crossed, if everything works out okay, and WordPress updates itself correctly, and the plugins all work out and there are no security vulnerabilities, you might have days, weeks, entire months go by where your revenue is really not that difficult to manage.

[00:22:39] Héctor de Prada: In what you said there, it’s like all the main things. Not only you can offer Care Plans or Web Maintenance Plans, but you should as a professional. Because I’ve heard you talk on another podcast, Nathan, you were saying that when you’re a freelancer or an agency, you are always waiting for next projects to see when they come. What’s going to be next? And if you’re going to have enough work to keep going.

And that’s why recurring revenue, it’s so important for us as professionals. And in web design or web development, it’s not so easy to get besides web maintenance. It might be if you want to go to plugin development or theme development or do something like that, you can start getting recurring revenue.

But if it’s just building websites, I think the only way to get that recurring revenue is by offering Care Plans. That’s why I always say, the critical thing that you were also mentioning before, is that it’s of course also a sales job to sell this to a client, but I don’t think it has to be once the website is generated, and you try to tell the client, okay, we did the website, it’s looking good, it’s working. And now we are going to do maintenance on the website, and you have to pay this or that.

I think it has to go way before that. When we were an agency, what worked really good for us, so I always give this advice because it really worked for us, is that we used to talk about maintenance with the clients before we started the website project. If somebody would come to us saying, okay, we want a new website design for our company, we’d include it always in our proposal. It’ll be, okay, we are going to design the website, we are going to do the development of the website, and then after that we are going to care for the website.

So we are going to do a maintenance on the website because this is very important. We are not going to just leave you there with your website, out in the open. Like, you don’t really know how it works, but we are going to be there with you. And this was like a massive change for us because when we were selling it this way, once the website was completed and we would tell the client, okay, now is the time to start the web maintenance job, and they were like, oh great, so this what we were talking about. It is not even a discussion anymore. It is like, oh great, it’s finally the time. So that’s like crucial. It was crucial for us.

[00:25:00] Nathan Wrigley: Yeah, I think when people do get recurring revenue into their business, especially around maintenance, it does feel like, why didn’t I do this before? Because it really is kind of, I hate to use the phrase, you are kind of leaving money on the table a little bit.

I wonder what both of you have in your head around the way to pitch that product. Because I went through lots of different ways of doing it. Some of them I’m not that proud of. So for example, in some cases I would emphasise the problems that could happen. You know, your website could go down. The internet can be a bit of a dark place, there’s hackers out there. And in the end it felt a bit like, I’m trying to scare you into giving me this maintenance deal. But then on the other hand, there was the sort of more positive way of doing it. You know, we’ll make sure that your website is always up and just different ways.

I wonder how you, both of you, tackle that. Do you have a particular kind of language? Do you have like a brochure or a booklet that you pass on to somebody which outlines it all?

[00:25:59] Héctor de Prada: For us, at least when we were an agency, you are seeing that I like to talk a lot. So for me it was like I could talk a lot with the clients. I would just try to be very educational, like we said from the beginning, in calls or in meetings I could talk about maintenance, the task it requires. Trying to explain it for everybody, of course, like not trying to make it sound technical or anything. Just trying to make them understand that technology evolves, WordPress evolves, the needs that the website, or the business, might have change so we should keep the website evolving with the business so it always stays in good shape.

Luckily, even when this is a terrible thing for our field, is that many, many clients, they come to you when they have had a bad experience before, having a website design. And this experience, so many times has more to do about not having maintenance than about the web design itself. Because they might come after three, four years and they might tell you, somebody did this website for me four years ago and now nothing works.

And it’s like, okay, when they did the website, everything worked. What happened? Nobody looked at the website for four years, so now nothing is working, which is understandable. So that also helps you a lot to make them understand that you don’t want that to happen again.

[00:27:22] Reyes Martínez: I think it’s also important to maybe reframe things or just showing clients that that’s part of, I mean that you care about their success over time. So it’s not just about launching their site. I don’t know, sometimes I like to think about maintenance as insurance. You hope you don’t need it, but if something goes wrong, you’ll be glad to have it. So I think it’s the same. Like, if you have someone who’s taking care of your website to make sure it’s healthy, that it is performant and that everything is running smoothly. I think you are investing in its long-term success as well.

[00:27:57] Nathan Wrigley: Framing it as an investment is quite a good way around it, isn’t it? As opposed to a, it’s not like a cost, it’s an investment. You’re putting something in so that it maintains. Spending money kind of feels like, oh, I’ve spent it, it’s all gone. Whereas an investment, you feel a bit more like, okay, I’ve spent some money, but as a result, things are going to be better in the future.

[00:28:15] Héctor de Prada: You both said it, Reyes, you said right now that it is kind of an insurance also, if something bad happens. Because when something really bad, like the website crashes or gets hacked or whatever, because it can always happen, at some point everybody will be glad to have a professional taking care of things.

Because another way to frame this, and you were saying that before Nathan, is that I’ve seen many, many professionals that they are like, okay, so the client doesn’t want to pay for maintenance, so I’m just going to wait until they have a huge problem that will come sooner or later. When they come without the maintenance deal, I’m going to charge them a bunch and then they will be glad they get the maintenance package. And they will start paying for that. I’m not saying I recommend that, I haven’t done that, but I’ve seen so many people do that at the same time.

[00:29:04] Nathan Wrigley: Yeah, I think describing his insurance is quite interesting. The curious thing about insurance is, how to describe it, at some point you might begin to resent paying the insurance if you never have an accident or nothing is ever stolen. So one of the things that I often got with the Care Plans was this whole thing of years would go by, I would do my job well, so nothing ever happened.

And so after 24 months of nothing ever happening, the client would turn around and say, what am I actually spending the money on? And then it occurred to me, okay, maybe there should have been some process of telling you what I was doing each month. Some kind of report or something to give to the client to say, look, literally things are happening. It’s not like we’ve gone away with your monthly subscription and done nothing.

So I wondered if you had any thoughts around those, you know those clients who think nothing’s happening, why am I spending this each month in order for apparently nothing to happen? It’s just a black hole.

[00:30:02] Reyes Martínez: That’s actually one of the hardest parts as well, like showing all the work that professionals are, like us are doing in the background. That work, that it’s not so visible as well, and how to communicate the value of all that work.

So I think there are, I don’t know, there are many different ways to communicate that value, but for example, like reports are pretty common. Showing, not just task, but all you have been monitoring and performance data, updates. And just, again, like educating on how all the work done have an impact on their business.

Because I think it’s also easy to go maybe, or to get into technical details, but I think clients don’t really care if you update a plugin or if you, you know, how you are maintaining their site. I think they care that their website is secure, fast and it’s working. It’s always working.

[00:30:58] Nathan Wrigley: One of the things that I ended up doing, which I think worked well was, I eventually landed on the idea of this report thing. So I would issue a report and it would say, during the course of the last month, these things have happened. And it would be a list of all the plugins that been updated, maybe WordPress Core had been updated, maybe I’d done some work on the server to update that, a PHP version or something like that. So all of those kind of things. And then some kind of indication of how the uptime went. You know, it was 99.9% last month, we had a little glitch on Tuesday or whatever, but that was taken care of within five minutes.

But the thing which worked best for me was I offered a proportion of time, based upon the plan that they gave me, of my actual time. And that could be deployed in any which way they wanted.So, for example, it could have been, I will just tell you what that report means or let’s just knock our heads together for half an hour or an hour, and figure out if there’s anything you wanted doing on the website. Maybe you want a telephone number updating or you want to have a different design on the homepage because Christmas is coming or whatever it might be.

And interestingly, most clients never took me up on it, but the mere fact that it was offered, and I’d offered the time, there was just something a bit more to it. There was something more tangible and more credible about it. And then when the clients did take me up on it, and I could explain what had happened and that it wasn’t this black hole where the money was just falling into for the maintenance plan and nothing happened, that really worked.

But I had the time available. And it may be that some people, most people don’t have that time available. For me, that was a good thing, you know, that kind of personal touch was a way to make it work.

[00:32:33] Héctor de Prada: Also another thing that is very important to solve, for example, in client reports, and it’s not so obvious, it’s because it is not a job you are doing. It’s some stats about how the website is working for their business. Because 99% of the time a website comes from a business that needs an online presence.

So it should be very important for them to know how this is performing or how this is helping the business. And I found this hundreds of times, that people have a website and they don’t know if somebody’s visiting the website, if you can find it on Google. They don’t know anything about the website. They are just like, yeah, I have a website there, but I don’t really know what’s happening with it.

So I think adding things like, I don’t know, like Google Analytics or any other analytics. Or search console results so you know, it’s somebody coming from Google or where is people coming. Or if you have an international website, from which countries is people coming. Things like that, I think it’s like very valuable for the end client, for the business, to know how the website is performing. And it’s not always added, but I think it’s crucial to also put that information.

[00:33:41] Nathan Wrigley: Do you know if anybody actually makes a business out of what you do? So, do people have a business of maintaining websites? Just doing that work. So they’ve decided they don’t want to be involved in creating the website, but they want to turn this product, if you like, that we’re talking about now. Is that a thing? Do people do that for a living? They maintain other people’s websites for them. Maybe you could bind yourself to an agency and they would hand the maintenance side to you. You are both nodding, so I’m guessing the answer’s yes.

[00:34:11] Héctor de Prada: We know many people, but we are kind of biased because most of our clients are agencies or freelancers that manage a lot of websites. So many of them are actually specialised in this kind of service. So we have freelancers that manage like 120 websites, and that’s all they do. They don’t do any websites, they just manage websites.

And then we have agencies that they are like fully specialised in web maintenance, web caring, and maybe if you have an urgency in your site because it’s broken or something, they can help you with that also. But they don’t design websites or create new websites.

So I think, yes. And one example I always say is that, at least in Spain, if you search in Google for WordPress maintenance, there are so many page results. So that means it’s a profitable business, okay? There is a lot of competence of people trying to get leads out of those keywords. I would imagine in most countries it could be the same. So yeah, definitely. I think it’s possible. I see it every day, so yeah, a hundred percent

[00:35:10] Nathan Wrigley: That’s kind of interesting because it may be that you are, I don’t know, you just want to take a break from actually building websites, and this might be an interesting way to pivot, especially if you’ve got your foot in the door with a bunch of agencies, and you know people that could supply you that work and they don’t wish to be involved in that. That’s curious.

[00:35:27] Héctor de Prada: You can automate much more stuff than in a web design process, or web development. In maintenance, like we were saying, with tools like Modular or other tools, you can automate most of the maintenance tasks. So many times, yeah, like one person can manage like 120 websites. Imagine how long it would take to build 120 websites. It’s almost impossible. You could say, oh, I don’t know, like five years, seven years. But you can maintain every week or every month, 120 websites by yourselves, just with the tools that are available. So that’s a really big difference.

[00:36:04] Nathan Wrigley: Does this maintenance landscape change? Because I’m just curious, the web industry changes all the time, but broadly, you know, plugins and theme updates, that’s been around since WordPress got plugins and themes. Hosting and backups, again, similar.

But there have been developments in the more recent past where I’m thinking, okay, you could definitely push that into the maintenance idea. So things that come to mind are, I don’t know, optimisation, Core Web Vital scores, maybe something like that could leak in.

And the one at the minute, which I think would be really interesting, and again, maybe it’s a thing already, is accessibility. Some kind of report about, okay, it looks like these pages need a particular bit of attention, or something’s gone wrong here from an accessibility point of view. And so really my question there is, does the landscape of maintenance change, or is it broadly fixed with whatever it is now is how it’ll be in a decade?

[00:36:57] Héctor de Prada: Now also with AI, I don’t even know what’s going to happen in a decade. But I do think things change. For example, with accessibility, like you said, now in Europe it’s going to be big changes. With security as well, with the new Cyber Resilience Act, it’s going to be changes.

And for example, we saw it a few years ago with the data privacy law in Europe. I’ve seen so many agencies offering legal checks for the cookie banners and things like that. To also add in maintenance, I don’t know, like seven years ago, that wasn’t a theme because it wasn’t mandatory, so nobody really cared that much. And it is the same with accessibility.

A few years ago, nobody, almost nobody cared about that. And I think now because of the law changes, this is going to change drastically and almost every professional is going to start doing things related to accessibility, and is going to care about that. And it’s also going to be able to offer that to their clients as an upsell, or as an extra value, they’re going to give in their care plans.

So yeah, I do think it changes. We don’t have a lot of changes because the basics are always the same, the updates, the backups, the monitoring. But there are things that, yeah, might bring big changes every once in a while and we have to adapt.

[00:38:12] Reyes Martínez: I just wanted to add that also with AI and no-code tools, I mean, it’s easier than ever to launch a website. But what happens after that? Because maybe we find that more and more sites are being left behind with no updates, no backups.

What I mean with this is that maybe, maybe not, there’s already a growing maybe opportunity, because there are more and more sites that we don’t know what would happen with them. And they will need maintenance for sure. So I think we are seeing a growing opportunity as well, there for people who want to manage or dedicate themselves to maintain websites, yeah.

[00:38:51] Nathan Wrigley: Yeah, it does feel like in the year 2025 when we’re recording this, there are some key bits of legislation which are coming. You know, the European Accessibility Act very, very soon going to be completely mandatory across the whole of the EU. I mean, basically it should be something that you’ve taken care of already, but nevertheless.

And so these kind of things I imagine, will become part of the platform, the ethos of doing maintenance in the future. So that’s kind of interesting.

Just for the last moment or two, minute or two, let’s talk a little bit about what you have. So Modular DS, I’ll put a link into the show notes, but is the URL, is it modulards.com? Is that where we would go?

[00:39:30] Héctor de Prada: Yeah, we could say dash EN for the English version.

[00:39:33] Nathan Wrigley: Lovely, okay, so I will link to that into the show notes. I’ll link to the English version in this case, just because I think that makes most sense given that we’re all talking in English.

This is what you do. This is that in a nutshell. You have a service that you can sign up to. Is it plugin based? Is it a SaaS? Is it a mixture of SaaS and a plugin? How does it work and what kind of things can you do?

[00:39:56] Héctor de Prada: It’s kind of a mixture. It’s a SaaS outside of WordPress, we are going to say, but it needs a connector plugin to connect your websites to Modular DS. So basically what you do is you connect your different websites, the ones you manage, to Modular, and then from there you can like centralise most of the maintenance tasks, do updates, for example, in all the sites at the same time.

And also you can automate monitoring, vulnerability analysis. You can automate client reports like the generation of this client reports. So it basically tries to help, yeah, agencies, freelancer to save time, to have a good maintenance business. And also, like we have been saying, to sell the maintenance business to their clients, which we all know is not easy. So that’s what we try to do.

[00:40:42] Nathan Wrigley: So if I were somebody looking after my site and a bunch of others, you cater to that market, but also you are catering towards the more agency owner, if you know what I mean, where they’ve got multiple websites.

Is it possible to, white label is often the word I hear surrounding this. Is it possible to sort of make it so that it appears your own? That seems to be something that people really like, but I don’t know if you offer that feature.

[00:41:04] Héctor de Prada: You can white label everything that goes to the client. Let’s say, client reports. Of course, you can white label that, like your agency logo, your agency email to send the reports. Also, you can white label the plugin. So in the WordPress installation, you can change the plugin info so the client doesn’t know you’re using Modular, if you don’t want them to know. So yeah, of course, that’s important for many professionals, yeah.

[00:41:27] Nathan Wrigley: You could definitely be checking that out. And obviously this entire episode really was to provide an education piece around what it is that you might need to do, especially for those people who are new. You may not realise that there’s an actual business opportunity here for you, but also that there’s a whole cavalcade of different things that you can do.

So just to reprise, plugin, theme, updates, plus up time monitoring, backups, client reports. There’s a whole laundry list of things in there.

Yeah, I think that’s everything I wanted to ask. So if that’s the case, I will say, Reyes and Héctor, thank you very much for chatting to me today. I really appreciate it.

[00:42:04] Héctor de Prada: Well, thank you, Nathan.

[00:42:05] Reyes Martínez: 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, 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.