[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 WordPress Core continues to strive to unlock greater performance.
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 Weston Ruter. Weston is a longtime WordPress user and contributor. He has been a core committer for 10 years, and he co-led the WordPress 4.9 release. He worked in the WordPress agency space, and has also been sponsored to work on the Core Performance Team. He lives in Portland, which as you will hear, was quite handy for this interview.
We start the conversation by getting into the big picture, why website speed matters more now than ever, and how WordPress performs out of the box. Weston shares details about measuring true performance. Revealing, for example, that achieving a perfect Lighthouse score isn’t the end game, and that real user experience metrics like Core Web Vitals and Largest Contentful Paint should shape how developers and site owners think about optimization.
Throughout the episode, you’ll learn about the advances made by the WordPress Performance Team, from lazy loading and new image formats, to speculative loading that shaves precious milliseconds off page transitions. Weston explains how many performance improvements are designed to work automatically, democratizing speed, so that even casual WordPress users benefit without needing to be technical experts.
The conversation also touches on the balance between adding features and avoiding plugin bloat. The hidden impact of browser and device differences, and how large companies, like Google, are working hand in hand with WordPress to raise the bar on speed and usability.
Weston offers practical tips, deep technical wisdom, and a glimpse of where WordPress performance is heading next, and it’s sure to inspire you to think differently about how your sites load, how your users engage, and how you can squeeze out every last drop of speed from the platform you love.
Whether you’re a developer, designer, site owner, or just someone curious about what keeps the web running smoothly. 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 Weston Ruter.
I am joined on the podcast by Weston Ruter. Hello.
[00:03:28] Weston Ruter: Thank you for having me.
[00:03:29] Nathan Wrigley: You are very welcome. I’m quite jealous of Weston because we’re in Portland, Oregon at WordCamp US. I had to get on a plane, which was no hardship really in the grand scheme of things. Nevertheless, it was a lengthy plane journey. You, on the other hand, had to get on some public transport to get here because you live in Portland. That must be nice
[00:03:45] Weston Ruter: I live about five miles to the east of here, and so I jumped on the bus and I got off and walked to coffee shop and over to the conference center.
[00:03:53] Nathan Wrigley: And twice, two years in a row as well. You’re very, very lucky.
[00:03:56] Weston Ruter: I was very happy when I found out.
[00:03:57] Nathan Wrigley: Yeah. So Weston’s here today because of a presentation that he’s giving at WordCamp US. I will read into the record the title of the presentation that you’re giving, The Site Speed Frontier with Performance Lab and Beyond. So it’s all about performance, this episode essentially.
This is one of those subjects where I feel you have to tell us your credentials so that we understand that what you are saying is true. Because I think there’s a lot of snake oil, certainly from my point of view, quite a lot of ignorance. I don’t really understand this topic inside and out. So would you mind, a minute or something like that? Just tell us about you and your history with, well, WordPress, but also performance and so on.
[00:04:32] Weston Ruter: Yeah, sure. I have been a WordPress Core committer for 10 years. And I was in the agency space working at XWP, working on enterprise WordPress sites. And then I joined Google and I was a software engineer working on developer programs engineer, then develop a relations engineer working on the AMP project, which is all about making webpages faster using the AMP framework. And from there I transitioned into working on the Core Performance Team for the past couple years. And we are focused on making WordPress fast for everybody.
[00:05:15] Nathan Wrigley: Okay, great. Thank you so much. So the topic at hand then is going to be about performance. Why are you interested in this? I know obviously there’s a career in it and what have you. Is this something that you lie awake at night thinking about? Do you obsess about this kind of stuff?
[00:05:28] Weston Ruter: Yeah, it’s a passion of mine because who likes a slow webpage, right? So it’s fun to eke every bit of performance out of the loading of something. There’s a lot of little technical details and things to know and best practices to observe. And so it’s a fun challenge to be as fast as possible and there’s always room for improvement.
[00:05:52] Nathan Wrigley: And it kind of feels as if the mantra over many, many years has basically been that, you know, if you can make your website faster, it will be successful. People will visit it, people are getting weary of page load time or what have you. And so maybe we’ll get into the weeds of all of that.
How does WordPress, if I was just to go, okay, ignore the hosting that it’s on. Let’s just imagine we’ve got a good host, we’ll just use that term. If I was to download a vanilla version of WordPress and use the default theme, currently 2025, and do nothing else with it, I’ve written a few blog posts, maybe that’s it. How does it do out of the box like that?
[00:06:25] Weston Ruter: Yeah, it turns out my talk is exactly about this, and it uses the 2025 theme as a test case to show how the performance of WordPress fares out of the box. And if you were to load up a site running 2025, the theme and nothing else, and you run it through Lighthouse, the performance testing tool from Google, you’ll most likely get a 100 score, performance score. And you would think, I’m done, there’s nothing else to do. But if you dig into it, just because you get a good score, that doesn’t mean there’s still not room for improvement. And there’s still head room even after 100.
But yeah, WordPress Core does great out of the box, but there are still many opportunities to make it even faster. And as you had Felix on previously to talk about speculative loading, that’s one example where the performance is improved yet further. And in the performance lab plugin, which the performance team maintains, we have different performance feature plugins that implement additional optimisations that address different scenarios and use cases that WordPress doesn’t do well out of the box.
[00:07:40] Nathan Wrigley: It’s kind of interesting, and I’ve never heard it framed that way. I’ve never heard that there was a ceiling above 100. It kind of feels as if that is the ceiling. If you score 100, all bets are off, game over, you’ve succeeded, hooray, have a party, kind of thing. But no, there’s still room to be squeezing a little bit out here and there.
[00:07:57] Weston Ruter: Yeah, if you look at a Lighthouse audit, Lighthouse is an example of a lab metric. It simulates a page load for a user, but it’s not an actual page load for an actual user. It’s just a simulation. And if you really want to know how your site is actually performing, you need to measure those visits from actual users.
And if you load up a popular site in Google’s page speed insights tool, you’ll see there’s two different sections on the page. At the top, you’ll see what users are experiencing, and then at the bottom you’ll see lab data. And the top is coming from actual site visitors through what’s called the Chrome User Experience Report. And that tells you how the site is performing in terms of the Core Web Vitals that Google has spearheaded.
And one of those is called the Largest Contentful Paint or LCP, and that measures the time it takes for the largest element that is most likely going to be the main content of the page to be rendered, from the time you start navigating to the page and that element finishes rendering.
And a good LCP value is considered from 0 to 2.5 seconds. And so you can have, within 2.5 seconds there’s a big range in the user experience. So if it’s just under 2.5 seconds, it’s considered good, but that doesn’t mean a 1.5 second page load is actually way better, and a 0.5 second page load is even better yet, and a 0.05 second page load is great, is perfect. That would be the perfection. And that is what we’re working on.
[00:09:36] Nathan Wrigley: There’s gradations of it, okay. So within that 100 there may be room to do, aspects of the 100 can be improved. And in this case, by taking the LCP time down.
We’re at a conference event. There’s over a thousand people. There must be designers, developers, SEO people here. There’s everybody. There’s the whole gamut of people that use WordPress, probably some people that are new to the whole platform as well. Do you think that performance is something that everybody needs to worry about or are you happy to be one of the few that obsess about it? Is it basically better to leave an expert like yourself to worry about it, or is this something that we can all have a little dabble at and be successful about?
[00:10:14] Weston Ruter: Well, that’s what we’re concerned about with the Core Performance Team is making it so that the regular WordPress user doesn’t have to worry about this, because nobody’s got time to spend learning like, what is LCP? What is time to first bite? What are these different metrics? And nobody has time to worry about optimising for all these. So WordPress Core should do all this out of the box, and the WordPress ecosystem should implement best practices so that users don’t have to worry about it.
[00:10:44] Nathan Wrigley: It’s kind of interesting. I remember, I’m thinking it was about six years ago, but I don’t really remember the date. But Google kind of informed everybody that in a period of time, a year’s time or what have you, these metrics, LCP and, Core Web Vitals basically were going to come in.
And it felt like everybody in our industry was running around like a headless chicken, trying to understand something that they knew, there was this sword of Damocles moment, this date in the calendar where the SERPs were going to change. It didn’t feel like a comfortable time. In some senses, it felt like Google was kind of poisoning the water a bit because they were alienating developers who suddenly had to learn this new thing, because they realised their client websites were going to probably tumble in the SERPs.
And so they had to upskill in this thing that probably they didn’t want to be involved with. So it was a curious time, but the dust seems to have settled. I don’t know too much about, you know, whether they were penalties that really were paid by people because they didn’t have these fabulous Core Web Vital scores. But it definitely put the cat amongst the pigeons for a while anyway.
[00:11:38] Weston Ruter: The factors that go into ranking pages and Google search are, I never knew what they are, so the knowledge I have is that the performance of a page contributes to the ranking in some way. And basically, as I understand it, all things being equal, you have two sites with the same content and same relevance to the user, and one has better performance, then in theory that would rank higher.
How much value you get in terms of your ranking is debatable or unknown. I don’t know. But what is important is the user experience and the benefits that you get for your users. And if they have a good experience on your site, then they’re more likely to come back. More likely to result in a conversion or a purchase, or whatever you’re looking to get out of your site. So that’s where I would focus the concerns.
[00:12:34] Nathan Wrigley: If this were the Squarespace or Wix podcast, which of course it isn’t, it would be much more straightforward to have a conversation about why your site was quick because, you know, it’s this proprietary platform. There’s constraints about what you can do on that platform, and they run the whole thing, you know, they’ve got their arms around everything.
WordPress, you download it from .org in most cases, and start to pile things on top of it. And very quickly we get the problems developing I guess, you know, the more things that you throw into it, the more plugins and what have you. Would your advice simply be circumspect about what you throw in, or can you, for want of a better phrase, can you concentrate on additional tech to mask over any problems that you have?
You know, with the best one in the world, if you’ve got an LMS, it’s probably going to slow your website down because it’s doing a lot. If you’ve got WooCommerce, it’s probably going to slow yourself, the website, down from the vanilla install with using the 2025 theme that you just mentioned.
But there’s this whole marketplace of hosting companies and performance companies who are selling you things that kind of undo the, and I’m doing air quotes, the damage that you did by putting the plugins in.
So I don’t know if you’ve got anything to say to that. You know, the whole thing about bloating the website, slowing it down, unpicking it with different tech.
[00:13:49] Weston Ruter: Yeah, well, the WordPress ecosystem has a problem with the kitchen sink issue and a plugin that has more features is somehow valued more highly than a plugin that does one thing and does it really well.
And so in the Performance Lab plugin in our suite of plugins that we feature, we have the goal that a plugin should do one thing and do it really well. And if you don’t like what the plugin is doing, you deactivate it and switch to another one that is doing that one issue and doing it well.
But if you have plugins that do so many things, then you’re really kind of, your hands are tied and it’s difficult to switch. And maybe that’s a strategy by some plugins to lock you in to their ecosystem, but it’s a difficult problem, yeah.
[00:14:39] Nathan Wrigley: And we also have a, you know, we have plugins which are performance plugins. I mean, there’s dozens of them. I’m sure we could rattle off, whose job is to fix the problems that you may have created elsewhere in the website. If you’re in the weeds of it, like you are, you’ve probably got some vague understanding about it. You understand whether something is snake oil or not, but for the rest of us, that is a Pandora’s box, and there’s only chaos in there.
I don’t know what will slow my website down. If I download, I’m going to use LMS again, if I download an LMS platform, I’m going to hope that the work has been done successfully. But I’m probably also going to be thinking about, okay, now do I need to talk to my host, get a different hosting environment, get it set up so it’s perfect for that? Do I need a performance plugin? Caching layers, putting things on the edge.
And on and on it goes. It makes WordPress a difficult thing for many, many people to use. And so this idea of democratising publishing sort of goes out the window a little bit because it’s really extraordinarily hard to use.
[00:15:34] Weston Ruter: Yeah. And I think that in addition to democratising publishing, WordPress should also be as part of that democratising performance. And again, making it so that users don’t have to worry about that.
And what we’re doing in Core, we’re doing exactly that where as one of WordPress’s core philosophies is decisions, not options, and things should work out of the box.
But when it comes to the ecosystem, it’s a open source environment and there’s no top down control over what a plugin does. So I think there’s opportunities with projects like the Plugin Check plugin to do more analysis on the performance, in addition to the security and the best practices for being accepted into the directory.
But if there’s also a surfacing of performance issues or additional audits that are done on the impact of installing a plugin, that could be really valuable for site owners to get a sense of, this may cause problems if you install it.
[00:16:37] Nathan Wrigley: How long has the Performance Team been a thing? I feel like three years or something like that, but I could be really wrong.
[00:16:43] Weston Ruter: About four years I think.
[00:16:45] Nathan Wrigley: Okay, yeah. And could you just run over the history of that? I was going to say organisation, but let’s go with team. Could you run us through the history of that team and what you’ve been able to do?
Each of the little steps, some of them are quite profound. Some of them feel less profound, but very important. But over those four years, a lot of really incredible work has been done actually. Certainly from my perspective, it does seem that without that team we’d be in a very, very different place.
[00:17:15] Weston Ruter: I hope that’s true. I think it is. Yeah, well, it started out focusing on, I think lazy loading of images was one of the first things to land through this team. And with that we also then uncovered that actually lazy loading everything, which while great for reducing the weight of a page, because you’re not downloading images that aren’t actually shown. If you lazy load images that are in the initial viewport, that actually hurts the Largest Contentful Paint metric because the browser wastes to start downloading those images until it knows that they’re in the viewport.
So out of that came work to not lazy load images that are in the initial view port, and then also moving on to this attribute called fetch priority, which you can have the value of high, for example. So if you add fetch priority high to an image, then the browser’s going to prioritise loading that first. And so a lot of work was done to add sensible defaults in WordPress Core so that, for example, the featured image of a post gets fetch priority high, so that it gets loaded sooner over images that are not going to be the Largest Contentful Paint, most likely.
So there’s that. And then there was also an issue with like emoji in posts where, on every page load there’s some JavaScript that runs in the head of the page, and it computes whether the browser supports the emoji, like all the emoji. And if the browser doesn’t support all the emoji, then it loads the Twitter emoji library to render them. And that JavaScript was causing a long task in lower performing browsers, or devices, that was hurting the largest contentful paint as well. So that was fixed as well.
And then work has been done to add support for new image formats, like AVIF and WebP so that site owners can upload those image formats instead of JPEGs, which take longer to download.
We talked about speculative loading, and you talked about that with Felix. So that landed in 6.8, which by default will start prefetching the HTML for a page when you mouse down or tap or click, pointer down on a link to give the browser a bit of a headstart. But then the API allows you to be more aggressive about starting that process, just when you hover over the link, for example, and then not just to prefetch the HTML, but to actually render the whole page.
And so in my talk, which I gave earlier today, I showed the difference between no speculative loading, speculative loading as in WordPress Core right now, the default, and then moderate prefetch. And then lastly, moderate pre-render.
[00:19:57] Nathan Wrigley: Is that done with the plugin? Well, I guess you could do that with code, but there’s an option to, if you download the plugin, you’ve got a UI for that as well.
[00:20:04] Weston Ruter: Exactly. There’s a UI in the plugin that allows you to opt into moderate eagerness, or to use pre-render instead of prefetch. And in the example I showed, let’s say your time to first bite is a second. Then in the initial example, like on a slow, or on a fast 4G connection, you’re going to get like 2.27 seconds to load the page. But then with conservative prefetch, that shaves off like 50 milliseconds because the amount of time it takes to mouse down and mouse up is just a little bit of time that it can shave off that’s just a little bit to the loading of the page.
But then when you go to moderate prefetch, then the browser can load the page fully in the background. And so then the time to first bite in that case becomes zero because the whole page is already in the browser’s cache. And that can reduce it to like one second because you totally eliminated the time to first bite.
And then with the moderate pre rendering, then when you’re hovered over that link, the browser not only downloads the HTML, but also all the images, builds out the layout, runs the JavaScript. And so then when you click on that link, the page can load instantaneously.
[00:21:12] Nathan Wrigley: So literally instantaneous.
[00:21:14] Weston Ruter: 0.05 seconds.
[00:21:16] Nathan Wrigley: Yeah. It’s instantaneous. I mean that’s pretty incredible. All of that is available inside of WordPress, but just to rewind, probably about 50 seconds, the default is not aggressive. The default in WordPress in order to satisfy the kind of 80 20 rule and what have you, the default is to make it so that there has to be some interaction. The mouse has to be invoked. There’s a click involved.
That’s fascinating. So if you really want to get into the weeds of that, you can basically make the next page load almost instantaneously, should you wish to do that.
One thing that I did get into with, I believe it was Adam Silverstein not that long ago when I had a podcast episode with him. And I don’t mean to go deeply into this, but there’s a curious balancing act here, I think with the environment and all of this speculative loading. Because it wouldn’t be desirable to load, I don’t know, there’s 12 navigation links and the mouse happens to go across all of them. And suddenly 12 unnecessary pages were entirely pre-rendered and what have you. So yeah. I don’t know if you’ve got any thoughts on that, whether there’s a balancing act between performance and environmental concerns.
[00:22:23] Weston Ruter: Yeah. By default, speculative loading only operates on pages when you’re not logged in. And so when you’re not logged into WordPress, that is most of the time when you’re going to have a page cache that can serve it from the cache. And so as long as you have page caching in place, then the server isn’t going to be overly taxed by those requests.
In the newest version of the Speculative Loading plugin, it has an opt in to speculative loading for logged in users as well. But there’s a warning that shows up if you don’t have a persistent object cache active, for example. So, yeah, it’s important to have good caching in place, good best practices for scaling.
However, in addition to pre rendering, which the speculative loading plugin enables, there’s a much older technology for instant page loads that browsers all support, and that is the back forward cache.
And WordPress sites, by default when you’re logged out, will benefit from this most of the time. But as soon as you login or if you’re navigating to like a shopping cart page, or an account page, or checkout page in an e-commerce site. Oftentimes the plugin will invoke this no cash headers function that tells the browser, primarily tells the page cache, hey, don’t hold onto this response because you don’t want to cache the shopping cart for one user and then serve it to another user, because then you would be seeing something embarrassing potentially.
And so that is one of the benefits of sending that header. But it also has the effect of preventing the browser from holding onto that page as well. So if you navigate back and forward from the shopping cart, then you’ll notice that it doesn’t load very fast. It loads slow, because the browser has to re-fetch it all from the server, and has to rebuild everything from scratch.
And so there’s a effort underway for 6.9 to stop doing that. To allow the browser to hold onto that in memory. And then to address, one of the issues that turned this off to begin with, allowing the browser to store the pages in the cache. Is if you aren’t logged in, for example, into WordPress. You’re on some sensitive page maybe putting some API key in or something, and you go to log out, with this back, forward cache, you could hit the back button to go back into the WordPress admin as another person, maybe on a shared computer and look at that page, even though the user had logged out.
[00:24:50] Nathan Wrigley: Yeah, really not good.
[00:24:51] Weston Ruter: Not good. So there’s a ticket for 6.9 which would solve that problem by invalidating those pages from bfcache so that that privacy concern isn’t there. And this issue is not just about, well, these back, forward navigations are very common. So the Chrome team found that one in 10 navigations on desktop are these back, forward navigations?
[00:25:15] Nathan Wrigley: A tenth?
[00:25:16] Weston Ruter: Yeah. And on mobile, I think it’s one in five. So 20% of the time on mobile, you’re going back and forward using a gesture instead of hitting a link.
[00:25:25] Nathan Wrigley: That maps to my life, but I hadn’t thought about it.
[00:25:28] Weston Ruter: But the benefit here is not just in that you get a faster page load, but also bfcache, this back, forward cache will preserve the entire state of the page. So in my talk, I showed an example where you, if you have BuddyPress installed, you start typing in an update, a status update, and then you click away to a separate tab, and then if you hit the back button to go back to that initial tab, then you’ll find without this back, forward cache that your update’s gone because that input field was constructed with JavaScript. And when you don’t have back, forward cache, then the entire document object model has to be rebuilt. All the JavaScript has to re-execute. This is also an issue for the block editor. If you navigated away from a page and you didn’t save a draft, then everything gets lost without this back, forward cache.
So back, forward cache not only improves performance, giving you the possibility of these instant page loads, but it also preserves that important state on a page that could be lost otherwise.
[00:26:25] Nathan Wrigley: You have a plugin if memory serves, recently in the repo.
[00:26:30] Weston Ruter: Yes. And I got some feedback that it’s a terrible name, which I agree.
[00:26:32] Nathan Wrigley: What’s the name? I’ve forgotten.
[00:26:33] Weston Ruter: It’s called no cache, bfcache.
[00:26:36] Nathan Wrigley: That was it, yeah.
[00:26:37] Weston Ruter: But if I were to rename it, which I probably will now, it would probably be called Instant Back Forward Navigations or something. It’s not so short, but.
[00:26:43] Nathan Wrigley: So is the intention to take, are you spearheading that basically? is the intention to roll the learnings from that plugin into Core?
[00:26:50] Weston Ruter: Yeah.
[00:26:50] Nathan Wrigley: And I’m just going to read this into the record so that everybody understands. You are talking about backwards and forwards by using the buttons, which I guess typically live at the top left of a browser. Those buttons, the arrows that point backwards and forwards.
[00:27:03] Weston Ruter: That’s right, or the navigation in like the gesture on Android to go back.
[00:27:07] Nathan Wrigley: Yeah, so swipe typically and swipe right. okay. Yeah, that’s really interesting because I do that all the time. It really hadn’t occurred to me that was something that could be cached. And if, as you say it’s 20% on mobile, or 10% on, that’s a lot of time that you’re saving.
Because you do, it’s a journey, isn’t it? And sometimes you get to a dead end, and so you just back three times, because you know that you wanted to go back to that product that you saw a minute ago, but you kind of got lost along the way. So that’s kind of almost like a roadmap item. That’s 6.9, hopefully. Are there any other things coming in 6.9 that are interesting?
[00:27:39] Weston Ruter: Well, one of the new features in WordPress Core is this Interactivity API.
[00:27:44] Nathan Wrigley: Oh, so nice.
[00:27:46] Weston Ruter: And one of the great things about the Interactivity API is one of its key design principles is server side rendering. So let’s say you have a navigation block, or you have an image block with a lightbox. All of the HTML and the CSS needed to render those blocks are output on the server. There’s no need for JavaScript to construct the user interface.
Nevertheless, there’s JavaScript needed because there’s interactivity involved in these interactive blocks. And so with each of these interactive blocks, there’s a script module that gets added to the page, and it’s added in the head of the page. And browsers download those script modules with a high priority. And the impact of that is, well, the browser doesn’t know that these aren’t important. It could be important, it could not be important.
But by loading them with a high priority, they compete with loading of more important critical resources like the Largest Contentful Paint image, for example. So by having these modules in the head, then they cause the LCP metric to degrade. And so there’s a ticket to add fetch priority low to these script tags, which causes the browser to bump them down in priority so that the Largest Contentful Paint image has a chance to load sooner.
[00:29:04] Nathan Wrigley: Yeah. It seems like a game of tennis, this whole thing. For example, the Interactivity API, what a fabulous thing that is, but smuggled into that with something, it sounds unexpected that nobody foresaw that one and okay, need to address that. And here we are, 6.9, that gets addressed.
[00:29:21] Weston Ruter: Yeah, and one of the great things about the Interactivity API as well is that it has really pushed forward the new Script Modules API in WordPress, where what are also called ESM modules or scripts. And these are a new way of writing JavaScript and they are, by default they don’t block the rendering of the page.
Whereas if you have a classic script like jQuery in the head of your page, as you start loading the page, the browser has to stop parsing the HTML, it has to fetch the JavaScript, it has to execute the JavaScript, and then because that JavaScript may be doing something like document.write, where it like adds HTML to the page as it’s executing. Then only after that’s all finished then the parser can continue and continue laying out the page. So it’s very bad for performance to have any external, or even inline sometimes, JavaScript in the head.
And so one way to solve that issue is to slap a defer attribute on that script tag, or an async attribute, and that causes the script to then not block rendering, and it will be executed once the page has finished loading.
And a nice feature of script modules is that they’re deferred by default. You can’t have a blocking script. And so the thinking was, oh, they don’t block rendering, so we can just put them in the head. But it turns out that they do impact the network, because there’s other things on the network than just the scripts. And we need to make sure that the critical resources are prioritised, like the LCP image and not just load everything with high priority.
[00:30:55] Nathan Wrigley: It’s kind of curious because the past of WordPress has been about, you know, you click on links and you generate, I don’t know a post, a page or something, but you’ve got this static piece of content, largely. You know, there may be some JavaScript or something, which is doing something fun.
But the interactivity, API suddenly presents a page which, I don’t know, you might be stuck on that page for quite a while doing other things. I don’t know how that leans into the whole performance thing. I don’t know we could search and filter a bunch of houses or real estate or what have you, and update things. And we are on this one URL but everything’s getting changed in front of our eyes. So I don’t know how that whole LCP thing gets bundled into that. It suddenly becomes a much more difficult problem to identify and solve, I guess.
[00:31:35] Weston Ruter: Yeah. So with LCP, it is for that initial page load. So as soon as you interact with the page, then whatever is the largest element then going to be.
[00:31:47] Nathan Wrigley: Oh, that ceases there does it?
[00:31:48] Weston Ruter: Yeah, it stops at that point. However, there are other problems with performance that can arise after that Largest Contentful Paint. So one of the newer Core Web Vital metrics is the Interaction to Next Paint, and that is this INP value. And that is all about how much JavaScript is executing on the page. And JavaScript functions can do a lot of work, so much work that they cause the user interface to appear to halt.
[00:32:19] Nathan Wrigley: Hang.
[00:32:20] Weston Ruter: Yeah, hang. And so that’s called jank. And it can cause animations to stutter, it can cause a user interface to be sluggish, and you click a button and then nothing happens and then all of a sudden it opens up. And so that’s an example of a metric that is still very relevant with the Interactivity API. And there’s been work to establish best practices to make sure that the event handlers for these interactive blocks are using the best practices. Like, it’s called scheduler.yield, and it allows you to break up a long running task to give the browser a chance to catch its breath so that it doesn’t cause those long tasks.
And then another important metric, which continues to matter even after the page is loaded is called the Cumulative Layout Shift or CLS. And that is a very common issue with, where you have ads or something that will just expand as you’re scrolling down and you lose your place in the page and that hurts your cumulative layout, that CLS score.
[00:33:19] Nathan Wrigley: Yeah. You end up with your finger in entirely the wrong place just as you’re about to click on things.
[00:33:23] Weston Ruter: That’s exactly right.
[00:33:24] Nathan Wrigley: Old TechCrunch website. I don’t know if you’ve ever came across that one. That was a WordPress one, I believe. And I don’t know how many times I click entirely the wrong article because it just shifted just at the moment that my finger was descending.
[00:33:33] Weston Ruter: Very aggravating yeah.
[00:33:34] Nathan Wrigley: Yeah, really annoying. We’re really in the weeds here and what’s kind of fascinating, obviously you understand it all, I’m just holding on for dear life here. But it feels as if there’s a dance between what we’re expecting the browser to be able to do, and what it actually can do. And I don’t know if that’s the case.
You know, I don’t know if the fact that I’ve got a shiny new Mac means that my experience of the web in the future will be better than my 8-year-old Mac over there. That never used to be something that I worried about. It took time to boot that machine, but once it was up and running, that machine was probably just as good at displaying the web as the shiny new one. But now it feels as if that’s maybe not the case.
[00:34:13] Weston Ruter: It’s funny you say that because this emoji issue that I described earlier where it was causing this long task as the page was loading, I only discovered that as a problem because I was using a Chromebook as development device.
[00:34:25] Nathan Wrigley: Yeah, notoriously low on specs.
[00:34:27] Weston Ruter: Relatively, that one was even a fast one. But yes, much slower than one of the newer Macs. And so it’s important to always be testing in an average device, and not always just use the latest and greatest. Because you’re going to miss performance issues that are probably impacting a lot of users.
And one of the issues with emojis is, going back to what I described earlier with this long script in the head, now there’s just an inline script, and even with an inline script, there is still a performance impact where it will stop, because the browser has to stop parsing the page, execute the JavaScript, and then keep going.
And so I used my new Mac to analyse the performance of that and I didn’t see a problem. But then I tried the CPU throttling in Chrome Dev Tools where you can emulate low end, low tier device. And in that case, then all of a sudden I saw this 100 millisecond long task pop up, I can’t remember how long exactly, but it negatively impacted the LCP because it had to spend that time with this underpowered device.
So, yeah, there’s many opportunities for optimising things that, if you’re using devices that people are actually using.
[00:35:41] Nathan Wrigley: I don’t really know what the expectation is from WordPress over the next decade, but it doesn’t feel like it’s going to be limiting itself to websites. It feels like that’s a portion of it, but Matt Mullenweg often has talked about it being almost like the operating system for the web. Whether or not that will transpire, I don’t know.
But certainly for me, a lot of the things that I used to associate with a downloaded app that would run on MacOS or Windows or what have you, I’m now fully expecting that to be in a browser. And so I expect that the same would be true of our websites. We’re going to be doing more with them. They’re going to be requiring more grunt in the background, you know, more interactivity, more filtering, more searching, more database queries. And yeah, I guess WordPress has got to try and keep up with all that.
[00:36:29] Weston Ruter: In improving web performance, it’s a top down and a bottom up problem. Browsers are working to get faster. They’re competing with each other, trying to be as fast as possible for all the bragging rights, right? But oftentimes it’s impossible for the browser to know, even if it’s as smart as possible, what to prioritise when loading a page.
So that’s why when I was working at Google, we were prioritising improving the web at scale through WordPress to implement best practices in how WordPress builds pages so that Chrome doesn’t have to figure out everything because it’s impossible for Chrome to figure that out from the top down.
So if you look at the, over time these Core Vital Metrics, they all consistently are going up and improving, even if a CMS isn’t necessarily focused on a performance. They all are inching upward. And that’s because the browser is getting better at performance as well. But when a CMS like WordPress also invests in improving performance, then you can start to see it edging out other CMSs in terms of the relative improvement in performance.
[00:37:35] Nathan Wrigley: Yeah, okay. Let me just parse that. So whether WordPress is at the top or the browser is at the top, you’ve got this top bottom thing, and it’s kind of inching in from the top, coming down. Maybe that’s the browser, and then WordPress at the bottom inching up, if they happily meet in the middle.
So what you’re saying is that even if no performance work was done by a Performance Team in WordPress, there would have been in recent years a performance improvement, But the fact that there’s those two things in symphony with each other means that there’s a greater performance improvement.
Given that WordPress, I don’t know what the number is right now, but the statistic of 43% was always banded around. So it’s a huge proportion of the internet. Does WordPress have a voice toward Mozilla and Chrome? Does it get to say what the future of browsers might look like? It feels like with that market share, It ought to have a big voice, but I don’t know if it does.
[00:38:26] Weston Ruter: Well, I remember back when responsive images became a thing, and as I recall that it was WordPress implementing these responsive images that caused browsers to say, okay, we’re going to implement these now as well. So I think Chrome, I can’t remember which browser did at first, but it was kind of a catalyst that caused everything to get going.
And similarly, recently with the speculative loading, it being adopted by WordPress has, I think, caused other browsers to say, okay, we’re going to implement this as well.
And yeah, I know that when I was working at Google, and still I’m in contact with people at Google who work on web standards work, there are initiatives that they’re working on that they want feedback from WordPress developers to know like, is this going to work for WordPress? And if WordPress can leverage this, and going back and forth between what works for WordPress and what works for browsers and there’s ongoing conversations, yeah.
[00:39:25] Nathan Wrigley: Yeah, it is kind of interesting. I was talking to somebody from Google, from the Site Kit team, they obviously put up quite a lot of money to be marquee sponsors, if you like. I don’t know what the word is, you know like a top tier sponsor often at these events. I don’t know if they’re sponsoring this one, but there does seem to be some interest from Google.
I know that Mozilla doesn’t have the deep pocket, so we’re not really expecting that. But it’s nice to hear that, even if it’s kind of back channels, and it may not be that WordPress gets asked all the time, that there is some sort of symbiosis there. That’s nice to know.
[00:39:55] Weston Ruter: Well, I remember also seeing recently that Site Kit was voted one of the most trusted WordPress plugins.
[00:40:01] Nathan Wrigley: Yeah, 5 Million plus installs in under five years. And I was kind of surprised by that actually. when I did that interview, I didn’t realise the numbers were so big. And then after the interview I went out and asked a bunch of random people whether they’d used it, and a hundred percent of the random selection of 10 people that I asked used it on everything.
[00:40:20] Weston Ruter: Yeah. I use it for sure.
[00:40:22] Nathan Wrigley: Yeah, yeah. It’s kind of amazing. So just sort of rounding it off a little bit, I’m guessing that if you were to have your performance hat on, I could be wrong about this. You would be advising people to step away from the classic way of doing things in WordPress with, you know, the classic editor, the classic themes and things. I genuinely don’t know if there’s a performance improvement in full site editing, block-based themes, and what have you. Over to you really, it’s an open ended question.
[00:40:46] Weston Ruter: Yeah, there definitely is a performance benefit to using block themes, and that is because the way that classic themes load, they load progressively where they will print out the head, head tag in the page and then before they render any of the template, they basically locked in the scripts and styles that the page is going to need even though that doesn’t actually know what’s going to be in the page for sure. It can make some guesses, but it doesn’t know for sure.
And so for classic themes, you’ll have these massive style sheets that are printed in the head, you’ll have a whole bunch of scripts that you may or may not use. And as we said before, those scripts may be blocking the rendering and causing all kinds of problems in performance.
But with block themes, the way that a template is rendered is completely different, where it actually will render all of the blocks in the content first before it goes about rendering the head, the links, the style sheets and the scripts that go in the head of the HTML. And so because of that, a block theme is able to selectively load just the styles and just the scripts that are relevant to the blocks on that specific page. And so the amount of CSS and JavaScript that’s on a page can be greatly reduced, which greatly improves performance.
And also, one of the initiatives that we’ve been working on in the Core Performance Team is related to these responsive images that we were talking about. Where a responsive image, it has all of the different intermediate image sizes that are available. When you upload an image, it’ll reference all those different image sizes in the source set attribute. And then there’s the sizes attribute that says which of those intermediate image sizes should be loaded for that image in the page. But because WordPress doesn’t know classically, in the classic themes, how big an element is going to be, it uses by default the image that is the width of the view port.
And so on a mobile device, that’s often fine because images are often the full width of the content. But on a desktop you often have a center column with margins on either side, and maybe the image is going to be in a column or floated to the right. And so oftentimes on desktop, you’re going to download a much larger image than is relevant to that container on the page.
And so there’s a, one of the plugins in Performance Lab is called Enhanced Responsive Images. And what it does is it leverages the block structure in block themes to be able to figure out what the width is for the container of a given image. And then it can craft that sizes attribute to be much more accurate compared to the default sizes attribute. And in my talk, I showed that the performance gains from that enhancement alone are one of the largest that you can have, much more than just using AVIF or a modern image format.
[00:43:51] Nathan Wrigley: Really?
[00:43:51] Weston Ruter: Yeah because, for example, in my test page, I had a jpeg and then I tried it again with an AVIF and the AVIF was 20% smaller, so maybe I could compress it even further. But the Largest Contentful Paint improvement for that was only 2%. But with the Enhanced Responsive Images plugin active, it was able to use a much smaller image size, which is much fewer bites, even as a jpeg compared to the AVIF. And that improved the LCP by I think 45%. So a magnitude and a half higher.
[00:44:28] Nathan Wrigley: It feels like this work is never, ever going to come to an end. There’s always going to be little things to tweak and squeeze out here, there and everywhere. And there was a really good example just there.
I think somebody listening to this podcast, if they’ve got to this point, it’s kind of really fascinating that most of this stuff would go under the radar for most people.
I’m sure almost everything that you’ve mentioned, for the casual WordPress user, they would never know that that happened. Not many people are going to read the change log or delve into the weeds of what the Performance Team are doing. And yet there it all is, laid out in front of us over the last 40 minutes or so. Yeah, absolutely loads and loads of work. and never ending. You’ll be here this time next with new things to say.
[00:45:06] Weston Ruter: Hopefully. I don’t want to work myself out of a job.
[00:45:07] Nathan Wrigley: That’s absolutely true. Where do you go to find information about this? You know, who are the scholars, or the YouTubers, or the blog post authors? Who are the people that are pushing the boundaries here?
[00:45:20] Weston Ruter: Well, I have recently been loving the WordPress newsletters that go out, like the Repository and Remkus de Vries, his WP, I forget the name.
[00:45:32] Nathan Wrigley: It’s okay.
[00:45:33] Weston Ruter: It’s something in, WP in the name. I think, Within WP, but don’t quote me on that.
[00:45:36] Nathan Wrigley: Oh, it is, Yeah Remkus, Within WP, you’re right.
[00:45:39] Weston Ruter: Yes. So I subscribe to his performance blog. So Jono Alderson, Jono or Jono?
[00:45:46] Nathan Wrigley: I think Jono. Yeah, we’ll go with that. And apologies if it’s not.
[00:45:49] Weston Ruter: Yes. And so all of his posts are brilliant, so yeah. And then, yeah, following just the newsletters, because I don’t have time to keep up on social media anymore, but I really am thankful for those newsletters because it really saves me a lot of time. It gets me what I need to know.
[00:46:05] Nathan Wrigley: Yeah, I will, link to the ones, the three that you’ve just mentioned.
Yeah, that’s amazing. Thank you. Honestly, it seems a bit trite, but I’ve been following what the Performance Team have done for the last four years now, from the capacity that I have to understand it, which is pretty low in all honesty. You know, most of what you’re saying, I can get a purchase on the overarching idea, but as soon as you were to draw back, if you were to show me what you were doing, the code and so on, I would immediately lose my purchase.
I’d just like to express how profoundly happy I am that people like you are taking the time to do it. I don’t know how much thanks you get for stuff like this, but for my part, thank you.
[00:46:42] Weston Ruter: Well, thank you, but no thanks are required because I enjoy doing it, so.
[00:46:45] Nathan Wrigley: Yeah, great. Well thank you. anyway.
[00:46:46] Weston Ruter: I’ll do it anyway.
[00:46:47] Nathan Wrigley: Yeah, well Weston Ruter thank you so much for chatting to me today. It’s been a pleasure.
[00:46:51] Weston Ruter: Thank you very much.
