#178 – Adam Silverstein Explores Transformative Browser Features Impacting WordPress Sites
Transcript
[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 new, native browser features, are transforming what’s possible on the web.
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 and paste 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.
[00:01:10] Adam Silverstein: So on the podcast today we have Adam Silverstein.
Adam is a WordPress Core committer and works to fix bugs and improve modern web capabilities. He’s also a Developer Relations Engineer on Chrome’s Web Platform team at Google, and there he focuses on making the open web better for everyone.
Adam is here to break down how the rapid evolution of browser technology can supercharge your WordPress sites. We are doing this by referencing his presentation at WordCamp Europe 2025, in which he covered multiple new features of browsers, which can be used by WordPress users to bring a variety of experiences to their websites. In many cases these are browser APIs and features, and are quietly redefining what’s possible on the web. From CSS powered popovers, and scroll driven animations, to speculative loading that speeds up your page transitions. Adam explains how these advancements are changing what’s possible for both developers and end users.
The conversation sheds light on the collaboration between browser vendors, Chrome, Firefox, Safari, and Edge, through initiatives like Interop and Baseline, paving the way for more consistent and robust features across platforms.
Adam also talks about practical topics central to the WordPress community, like how the Popover API and native CSS carousels reduce JavaScript bloat, make sites more accessible, and deliver a better overall user experience.
He shares exciting new frontiers, such as browser-based image processing, powered by WebAssembly, which is paving the way for universal support of modern formats like AVIF and Ultra HDR, and even running AI locally in your browser, no API key or cloud server required.
He provides concrete examples on how these technologies can be leveraged in WordPress via Core updates, canonical plugins, and Gutenberg experiments, with a special focus on how developers can get involved and offer feedback to help shape future web standards. Prepare to look at your browser in a whole new light, truly.
Whether you’re a theme designer, plugin developer, or site owner simply curious about what’s next, 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 Adam Silverstein.
[00:03:47] Nathan Wrigley: I am joined on the podcast by Adam Silverstein. Hello, Adam.
[00:03:51] Adam Silverstein: Hello.
[00:03:53] Nathan Wrigley: This is our second conversation. We had a conversation, I want to say four years ago, maybe more in San Diego, think. And at that point we talked about images, AVIF, WebP, those kind of things. We might get into that today.
Adam’s been working with Google for many, many years. Making the web a faster place, I think is a fair way to sum up your career. Just tell us a little bit about yourself, just so that, because this is a fairly technical topic and you are honestly going to have to teach me an awful lot as we speak. Let us know what your credentials are, why people should listen to what you have to say.
[00:04:21] Adam Silverstein: Oh, wow. Being a Googler is not good enough, huh? Well, I’ve been doing WordPress for a long, long time. I think I started, first started contributing back in 3.6. So I’m deeply involved in the Core project. I am a Core committer, which is something that I consider an honor, a privilege, and a responsibility. There’s not that many of us in the world, but I’m one of the people that actually commits code to WordPress.
And I used to have my own run, my own agency, tiny me agency, but building sites for clients directly. Then I wound up at 10up. Learned to build enterprise sites, and work with large teams, and do a lot of planning. And then eventually made my way to Google where I’ve been doing developer relations work. I’m trying to educate developers and bring things like all these new APIs that I talked about in this talk, so that people can learn about it.
[00:05:05] Nathan Wrigley: Have you been focused more or less entirely on WordPress, or are you in any way engaged with the Chrome team?
[00:05:11] Adam Silverstein: Yeah. So our team kind of organisationally was under Chrome, like that was kind of where we sit. We worked with other, like I’ve worked with Drupal and TYPO3. So I’ve worked with some of the other CMSs out there, especially like the open source ones. So that’s kind of been in my purview, but I would say primarily focused on WordPress. That’s where I’ve had the most experience and am most comfortable.
[00:05:32] Nathan Wrigley: It’s kind of interesting because on my computer, obviously I have a browser using Chrome, it’s kind of one of the most benign pieces of software that’s there, in that it doesn’t really have a task that’s assigned to it. I have a music editing piece of software, and I go there for that. And I have a video editing piece of software, and on it goes.
[00:05:49] Adam Silverstein: Yes. And you’re running those in your browser.
[00:05:51] Nathan Wrigley: Right. But also the browser is just this open thing, you know, you can basically do anything in it, and so incredibly powerful. And it feels like in the last few years it’s got way more powerful. But most of that is entirely hidden because I open it up and it looks broadly the same today as it did five years ago. You know, the UI may have changed a little bit.
[00:06:13] Adam Silverstein: Right. But what’s changed is what you can do with it, right? So you talked about editing video or editing audio in your browser. Like, that was not something that was possible five or 10 years ago when we had blue links and HTML. And it was basically, we were publishing newspapers on the web. That was the limit of what we could do.
[00:06:29] Nathan Wrigley: I have an app, it’s called Descript. I don’t know if you’ve come across it, but it’s a full audio, video editing suite entirely in the browser.
[00:06:37] Adam Silverstein: And famously Adobe released Photoshop. Runs in the browser. The full Photoshop. Yeah, I mean it’s like mind blowing that that’s even possible.
[00:06:45] Nathan Wrigley: So the capabilities of the browser have dramatically increased. And you’ve just done, or you’re about to do? Just done.
[00:06:54] Adam Silverstein: Yes.
[00:06:55] Nathan Wrigley: Okay. Firstly, how did It go?
[00:06:56] Adam Silverstein: It went great. Packed room. I think people got something out of it. People gave me good feedback.
[00:07:00] Nathan Wrigley: And it was called Modernising WordPress with New Web Platforms. And I’m just going to read a bit of the blurb that went with that. It says, WordPress is a powerful platform for building websites of all shapes and sizes. To truly thrive, WordPress is embracing the latest advancements in web technology. This talk will explore how developers and site owners can leverage cutting edge web platform capabilities to create next generation WordPress experiences. And then there’s a little bit more which mentions web APIs and so on and so forth. So that really is going to be the core of this discussion.
Now, caveat emptor, dear listener, I have nowhere near enough knowledge to ask you these questions. But I’m going to hope that you are going to help me through it.
So first stop then, let’s just go through a whole laundry list of these different APIs. What are some of the fun things that a browser can do now, that it couldn’t do previously?
[00:07:53] Adam Silverstein: So in the talk, I sort of break it into three areas. There are features that help developers do things that maybe we could do, but we struggled or relied on heavy JavaScript libraries to do.
There’s things that help users by creating better experiences on the web than we previously had the ability to do.
And then the third category is things that previously were just impossible. Just things that we can now do, like running Photoshop in the browser, we mentioned that we could not do before.
So I did not explore, this is not, the talk was not like an exhaustive list of all the APIs, but it was rather sort of a selection of ones that I thought were interesting. Most of them are new. They are sometimes available only in one browser, not in all the browsers. So they’re things that are coming to the web platform. Some of them were already on the web platform.
So let’s go through them. I’ll see if I can remember them all. I have my little slide deck here.
So in the category of helping developers, the first one that I talked about is this thing called the Popover API. So popovers are simply like dialogues or elements that you want to hover above the rest of the page content. And in WordPress we use these extensively in the admin. Like for example, the pointers that you get when you install a new plugin. Or if you open a dialogue, or even like mobile menus use a popover.
And we have it in Gutenberg. And so we already have this technology, but it relies on JavaScript, and it’s actually surprisingly complicated to do a popover. You have to pay attention to always being at the highest level. And if there’s another popover, how do you handle that? And you have to make sure it’s accessible, so when the user hits the escape key, the popover closes.
And if it’s a pointer that’s trying to point to a new feature, say in a menu, how do you handle when the user resizes the window and that element moves? These are very complicated things. And in JavaScript that means you’ve got a heavy library that’s running just to do this simple popover thing.
So with this new CSS based popover API, you can create a popover with just a couple of lines in your code, and the browser takes care of all of the complicated parts of actually doing the popover.
[00:09:49] Nathan Wrigley: So just pausing there for a moment. The whole power of CSS, I’m going to say three years, this has been capturing my attention. CSS seems to be able to do a load of programmatic things now that it didn’t used to be able to. So in this case it’s, I don’t know, it’s calculating the height of the viewport and figuring out is there another thing, how much further to move it down? All of this being handled natively in the browser.
[00:10:13] Adam Silverstein: Exactly. And I think like your point is very true, like CSS capabilities have grown tremendously, and the ability to do sophisticated layouts. And all of these kind of feature things that typically might require JavaScript, now we can do directly in CSS, even things like calculations.
So CSS is a programming language just like JavaScript, right? People like to poo poo it and and so forth, but it’s quite powerful. And a lot of these features that I’m talking about are based on CSS.
[00:10:36] Nathan Wrigley: It’s kind of interesting, if the 18-year-old me was beginning again, I think CSS would be the thing that I would do first. I think I would learn that inside and out before ever looking at JavaScript. Because I you’ve got the foundation of modern CSS, and I know there’s a lot of W3C things that are still being decided and what have you, and obviously the browsers have got various different capabilities. But so much that we would’ve relied on for JavaScript is now capable with CSS, but unexplored I think by many.
[00:11:08] Adam Silverstein: Right. So this feature popover is available in all the browsers. It’s in Baseline. So Baseline is the set of features that developers should be looking at for deciding what they can use. Baseline is a somewhat new concept, so people might not be aware of it. But it is basically a way of knowing which features are available on all the major browsers. So if you see a feature that is labeled Baseline, like in the MDN docs, that means it’s available on all the browsers. You can count on it as a developer.
So in my talk, I covered a lot of APIs that are actually not in Baseline yet. They’re still in development. They maybe are available only in Chrome, or Chrome and Edge, or maybe Chrome and Edge and Firefox, but not Safari. As developer, those are the APIs you need to be a little bit wary of, right, because you wanna build something that’s going to work for everyone.
In many cases, the API will gracefully degrade, it just won’t work in the non-supporting browser. But in the case of like a popover, if it is supported in all the browsers, so you’re safe to use it. If it wasn’t, you would need to have that JavaScript as a fallback. So some of these APIs are, you know, new and experimental, but the browser vendors are all planning on adding support for them. So I only choose APIs that actually browser vendors have indicated their support.
[00:12:14] Nathan Wrigley: Can we just pause there a moment because I began my journey with the web, oh, Internet Explorer 5 kind of days. You probably remember the days as well as I do, and it was chaos, you know? I mean, really we had to try and fix a whole bunch of things that Internet Explorer did differently from all the other browsers. The browsers didn’t agree on almost anything. They went off in completely different directions.
That, I’m going to say, over the last five or maybe more, maybe more like eight years, there seems to have been a real confluence of, and I don’t know if that’s done from like a senior management level, but it does seem like Mozilla is talking to Chromium, Chromium is talking to Safari, and a lot of the people seem to attend the same conferences and talk the same language. They may adopt it at different rates, but they’re all trying to get to the same point, the open web.
[00:13:00] Adam Silverstein: Yes. And in fact, they’ve developed an approach to collaborate on this, and that is called Interop. So the Interop effort is sort of a group effort by all of the browsers to agree upon a set of features that they’re going to work on for each calendar year. So there’s Interop 2025, there’ll be one for 2026, and so forth.
And these features are, they come from either the browser’s needs, what they want to build, or from developers. So there’s an open process where they open a GitHub repo each fall and developers can go and submit. And we’ve actually had some from WordPress that made it in and influenced what browsers do.
So as developers are out there working, they’re finding pain points, they’re struggling to do this or struggling to do that, or it doesn’t work well in one browser. It works in one browser, but not the other. Interop is sort of the effort each year to come up with a set that the browsers agree upon working on. And those features hopefully all land in Baseline the following year.
I remember those days very well, and that’s why we have things like jQuery, right? So we had all these libraries that were built with this promise of sort of normalising the capabilities. Now, you’re absolutely right, the browsers have realised this is a problem for developers and they’ve come together to form a standard, and that is the Baseline thing that I mentioned.
So they’re always building new APIs on their own, and some of them will never make it into all the browsers, and they may go away or they may change. But if they make it into Baseline, you can be sure that you can use them. And that’s what’s different, right? We have this set of features that we can rely on.
[00:14:21] Nathan Wrigley: I kind of feel we lost a decade somewhere of real productivity. You know, the browsers could have been capable of a whole lot more than they are now. I mean, we’re happy with where we’ve got, but it does feel like we lost, this proprietary approach to browsers really wasn’t in the best interest of anybody. But you can see how it grew out of Microsoft and all of these other organizations.
I’m guessing that Google with its Chromium browser, Chromium based browser, the fact that that became utterly dominant was probably quite a pivotal point. You know, it was in the sort of eighties and nineties percent, adopted by 80 or 90%. I guess Google was able to push things through a little bit more.
[00:14:59] Adam Silverstein: Perhaps, like they do often lead on features. I mean, I wouldn’t say they’re always the lead on features, sometimes Safari has a great idea and they want to develop it, and with Firefox as well. But they do have a huge effort going into it. And, you know, of course Microsoft famously adopted Chromium as the engine for Edge. And so Microsoft is actively contributing as well to Chromium, which is the core of Chrome.
So yes, I think the dominance did allow them to sort of lead on features and have the other browsers sort of need to follow. If Chrome is going to ship a feature, everyone’s going to use it. But I don’t know if that’s always the case. You know, when you read these, I’ve read some of these proposals, you know, the browser vendors, they talk to each other in the open, right?
So these aren’t like private conversations that are happening in a room somewhere. They are all into open source software. So they’re, you know, there’s a repo where like, for example, Chrome will come in and say, we’re working on this new API, we would like feedback from the teams building Mozilla and Safari about if this is a good feature, are you going to support this? And that’s like typically early in the process where they try to get that feedback so they know whether this is something that is likely to land in the platform.
[00:16:02] Nathan Wrigley: I don’t really know whether it was the best thing for one browser to sort of win out, but it certainly seems now that the dust has settled, it seems that that was a fairly good thing to happen.
[00:16:11] Adam Silverstein: Yeah, I mean, I think if we had only had one browser, that would not be good. I mean, Apple is definitely dominant on mobile in markets where iPhones are very popular.
[00:16:21] Nathan Wrigley: North America, for example.
[00:16:22] Adam Silverstein: Exactly. North America and Europe, I think as well. Although if you look at most of the world, it’s actually Android that is far more dominant. So that’s where Chrome gets a big percentage of its users because Android is the default browser there, just as Safari is the default browser on iOS devices
[00:16:35] Nathan Wrigley: I guess there was the whole Chromebook thing as well with, you know Google trying to promote this idea of a browser computer, for want of a better word.
[00:16:43] Adam Silverstein: Chrome OS.
[00:16:44] Nathan Wrigley: Yeah, Chrome OS exactly. And but the idea that, when it first came out, I remember looking at Chromebooks and thinking, yeah, it’s intriguing. It can do Google Docs, but where’s the video editing? Where’s the audio editing? I’m guessing like a modern Chromebook is a full swap out for a, it just doesn’t have the physical storage memory in some cases.
[00:17:01] Adam Silverstein: It doesn’t have any. It’s, well, I mean, it has some for caching, but basically you log in and that’s your computer. Someone else logs in, it’s their computer. It’s fully in the cloud.
[00:17:09] Nathan Wrigley: It’s pretty amazing.
[00:17:10] Adam Silverstein: Although I will say, I bought a cheap Chromebook, like 150 bucks, refurbished, but I bought it to travel with so that I didn’t have to carry around my eight pound MacBook Pro. And because I’m a developer, I figured out how to do development work on it. You can install Linux on it and run, you know, Docker and all the things that you can do on a desktop machine.
Does take some effort, like that’s not built in. But they are actually full computers, it’s just that the way the operating system is set up is this sort of cloud-based thing.
But it’s quite, I think they’re amazing honestly. And, like I said, very inexpensive and also like bulletproof. You never have problems with them because your whole world is basically the browser.
[00:17:47] Nathan Wrigley: And it kind of boots in half a moment, and it’s so secure.
[00:17:51] Adam Silverstein: Yeah. They’re fantastic, and especially for like schools or corporate settings because it has all that management built in. I think they’re great computers. I would definitely recommend them, especially for people who don’t want to spend all the money that it takes to get, you know, and especially like you’re saying, everything’s in the browser these days. So there’s really, you don’t need a desktop computer to do most things.
[00:18:10] Nathan Wrigley: Yeah. I think we painted a picture of the power of the browser, we’ve done well there. We got kind of hijacked a little bit. So you were talking about popovers, that was the first thing. Let’s return to that. What’s one of the other things mentioned?
[00:18:20] Adam Silverstein: Next on my list is this Scroll Animations API. So this is animations like CSS animations that are either triggered or tied to a scroll event. So you could think about, like Slider Revolution has this feature in it, or you’ve seen it on like Apple’s website where you’re scrolling and as you’re scrolling an image is fading in or something is being revealed. Or another good example is like a reading indicator that Medium has at the top of the page as you scroll down.
So we can do these things today with JavaScript, but it involves paying attention to the user scroll position, and this kind of heavy handed approach to monitoring the user. With CSS scroll driven animations, it’s just a couple of lines of CSS and suddenly you’ve tied an animation to scrolling.
[00:19:01] Nathan Wrigley: So again, all handled by CSS, no need for a JavaScript library. Any impact in, I mean, these JavaScript libraries are famous for sort of bogging things down, tons of bloat and what have you. I’m guessing that because it’s shipping in the browser, that is minimal to say the least, almost non-existent.
[00:19:17] Adam Silverstein: Yes, and the animations are CSS animations, so they’re not happening on the main thread. JavaScript famously has one main thread, and if you have something running on that main thread, it’s going to interfere with other JavaScript. So if you can get rid of some of the JavaScript on your website, that’s freeing up that thread for the other JavaScript that you have, that you want to do to track your analytics or to, whatever else you’re trying to do on your page with JavaScript. This is one less piece of JavaScript you need on your site.
[00:19:42] Nathan Wrigley: The feature that you’ve just mentioned is something that I guess WordPress developers are going to be particularly interested in. They love all that stuff.
[00:19:48] Adam Silverstein: Yes, clients love it. They love animations. And again, this is something that’s very lightweight, right? The argument against these types of animations is they’re typically very heavy.
The other advantages of using CSS based features versus JavaScript is accessibility. Often these features, I mean this isn’t necessarily true with scroll driven, but like with the carousels, it’s got that accessibility built in. It’s got the escaping out of the dialogue.
Again and again we see that, when you build something in JavaScript, I’m going to talk in a minute about CSS carousels. When you build it in JavaScript, if you want to make it accessible, there’s a lot of extra work that goes into doing that well. If the browser builds the feature in as like a fundamental, almost like an HTML component, then the expectation is the browser will take care of that for you. So as a developer, you won’t even have to pay attention to it.
[00:20:36] Nathan Wrigley: I’m guessing that in the case of the one you’ve just described, that’s really easy to map onto this podcast because a WordPress user, they’re using a page builder or something like that. They’re going to have encountered these options, you know, somewhere buried in the settings for this image component is a fade in on scroll.
And I’m guessing that in the future in WordPress, this might be some sort of toggle in a block, an image block or something like that. You’ll just switch it on, assign some characteristics to it like, I don’t know, fade to 50% at halfway through the viewport. And that will just create the CSS, but all done inside of a panel of a block.
[00:21:11] Adam Silverstein: Yeah, I did exactly that as a pull request and have a link to that in my talk. Yeah, that’s a great example. It could be an image, it could be a header block.
I guess one question I have as a Core committer is whether that is actually Core territory. We have this long standing philosophy in WordPress that it’s kind of the 80 20 rule that a feature that we land in Core should benefit 80% of users, otherwise it belongs in plugin territory.
That said, one of the things we’re talking about now is this idea of canonical blocks. So there’s a lot of new blocks being proposed in Gutenberg right now, and the question is like, how many blocks do you actually want to ship with the editor? There’s a zillion different things you could think of building a block for, or a feature like animation, say for images like we’re talking about. But if it’s not valuable for all users, does it really belong in Core? And does it just overload the list of blocks they have to choose from, or the list of features they have to choose from? Why not just let plugins extend it?
The other idea, like I said is this idea of canonical blocks. So you could have a block that’s developed by the Core team, is supported by Core, and is directly installable in the admin, in a like clearly labeled way that this is a Core product. But actually not ship it with WordPress. So it’s something that you could install with one click. I mean, we actually haven’t defined exactly what a canonical block or plugin is, but this is sort of what my idea is. It’s something that’s like, you’re one step away from having it installed.
[00:22:27] Nathan Wrigley: Yeah, it feels like a canonical plugin, at least feels to me like something which has the security guarantee of Core, plus the updating guarantee of Core. Basically if you install it, it’s going to work with the latest version of WordPress, plus the all the backwards compatibility. I kind of like the idea of, like Apple ship with things like iOS, like Core animations. A plugin which just enables the animations in Core blocks.
[00:22:51] Adam Silverstein: Right. Like the capability might already be there. I mean, you know, so one of the other APIs that I talked about in another section is the Speculative Loading API. So this is a good example. And this is actually shipping in WordPress 6.8. And this is the ability for the browser to prefetch the resources for a page that a user is about to navigate to.
And in WordPress, we shipped it in the most conservative mode possible, which essentially is the user needs to click down on the link, and then before they let go of their mouse, so the time between the mouse down and mouse up event is when the browser is prefetching the resources for that link.
So if the user clicks down on the link, we’re very confident that they’re actually going to navigate. Although it is possible to drag away and not navigate. 90% of users are going to follow that link or more. And so the idea is not to waste prefetching for links that users never visit.
However it is possible to configure this API in a more bold manner where it will, for example, prefetch links that you hover over, which is going to give you much more of a head start, but also a lower hit ratio where, you know, some people will hover over links and they never click on them. So it depends on your use case.
So I’ve already seen, so we landed the API in WordPress at the very conservative level. There’s already a plugin out that lets users configure that API for their own site, so they can adjust the default settings.
There’s another setting that’s even more aggressive where it actually pre-renders the page. And in that setting, it’s almost as if you’ve loaded the page you’re about to navigate to in another tab, and when you click the link, it’s like switching tabs. It’s an instantaneous transition. It’s like amazing.
However, you know, if you’re pre-rendering every page a user hovers over, that’s going to be a huge additional load on your server. So there is a trade off there. But maybe you have like a large call to action button on your homepage that 50% of your users are going to click on. Go ahead and prefetch that. They’re going to get a better experience. You’re going to get a better conversion rate if that page loads faster.
[00:24:45] Nathan Wrigley: if memory serves, this is a browser API, Speculation Rules API and everybody’s got it switched on in 6.8 and beyond. But it’s in conservative, and it’s prefetch not pre-render, it’s click. And honestly, the chances of you not wishing to get to that page are pretty, like you say, you could slide away. But yeah, if you were to download the speculation rules, I can’t remember what the name of the plugin is. Anyway, the plugin, the option there is to do things like pre-render, or hover. And then, yeah. You could get into a real mess with the server and, you know, just wasteful.
[00:25:23] Adam Silverstein: Yeah. If you, especially if you’re on like a light end server, but maybe you want that, like the most important. Like, let’s say you have an e-commerce store and you’re really trying to get people to add things to your cart. You know, there’s all kinds of studies that show that if your pages load faster, and it’s even buy like things like a hundred milliseconds, the conversion ratio is much higher. People are quick to abandon slow sites. I mean, there’s all kinds of data on that.
So you may decide it’s worth investing the additional resources and dedicated hosting and caching so that you can prefetch and pre-render and get that faster navigation. This API enables that type of navigation that is, you really can’t get that without this API because it’s basically letting the browser know, it’s okay to like start loading resources before I even visit a page.
[00:26:06] Nathan Wrigley: Yeah, I keep having this thought that at some point Chrome’s going to come up with, it’s going to know a whole year in advance all pages that I wish to visit and just load them all for me.
[00:26:15] Adam Silverstein: Well, I did actually an experiment with AI to see, like ask AI which link is the user most likely to click on? And I tried it both with just literally dropping the HTML of the webpage in the AI, as well as drawing a screenshot. And I tried it on a very simple page, so like a WordPress plugin page. There’s a large blue button that says download. Probably the most likely link that users will click on. But the AI was like very good at identifying that. So in theory you could imagine that the browser could actually predict into some degree what users, based on their behavior, are going to click on, or based on the layout of the site.
[00:26:50] Nathan Wrigley: So this is a, curious new world in which we live, isn’t it? So there could be heuristics about what I’m literally doing with the mouse. So the mouse is, I don’t know, approaching a button. That’s a fairly strong indication. And also, I guess the speed.
[00:27:05] Adam Silverstein: Yeah, if it’s paused over the button.
[00:27:07] Nathan Wrigley: Right, or slowing down, the speed is sort of coming to a terminus. Yeah. This is all really interesting.
The 6.8, the Speculative Loading in 6.8, what I really like about that is that there’s zero configuration. It just works. So it’s using this fabulous new feature of the browser, but also no technical knowledge whatsoever. Absolutely none. And it would hopefully just save you a bunch of, well, your visitors a bunch of time.
[00:27:33] Adam Silverstein: Exactly.
[00:27:34] Nathan Wrigley: Yeah. Fabulous. Okay, that’s another one. Any others?
[00:27:37] Adam Silverstein: Oh my gosh, so many. We did touch briefly on CSS carousels, but let’s just cover that again. So over half of WordPress websites load some sort of slider or JavaScript library.
[00:27:49] Nathan Wrigley: Like them or hate them, they’re there.
[00:27:49] Adam Silverstein: Yes. And even if people don’t use them, they seem to load them because I don’t know if half of sites all have sliders, but in any case, this is a very popular feature for WordPress sites. And of course there’s many plugins out there that do this, and they all rely on a JavaScript library. There are several very popular ones. They’re very full featured libraries. They do all the things that you need for a carousel.
Now we can do that with CSS, so you don’t need the JavaScript library. Now, there may be advanced features that the JavaScript libraries will be able to do that will add some functionality. But the goal of the CSS implementation is to basically be feature parity with what you can do now with JavaScript. So all kinds of carousels
with buttons that you can click, with little indicators as to which slider, which image you’re on. You know, just all the features that you can imagine in a carousel. There’s a great demo site on the chrome.dev site of just like a zillion different carousels.
[00:28:41] Nathan Wrigley: What does the DOM look like for that?
[00:28:43] Adam Silverstein: It’s so simple. It’s like you have the images themselves, and you have a couple of pseudo elements like scroll marker, and there’s some for the scroll arrows. I don’t actually remember all the deals because I haven’t built one. But it’s all done using like CSS selectors essentially to indicate which elements are the control elements, and which elements are the target elements. And you can even do things like grouping them so that like when you hit the right arrow, it’s like a page of things moving back and forth, like several elements.
Like I said, they’ve tried to address all of the features. And again, here you would be able to do a CSS based carousel, that means no JavaScript required, right? You don’t need to load that giant JavaScript library. It’s going to be immediately available, right? So JavaScript takes some time to load. It’s going to work more quickly. And it’s also hopefully going to have accessibility built in. So you don’t have to worry about if your JavaScript library is keeping up with accessibility standards. It’s going to be a standard web component.
[00:29:36] Nathan Wrigley: Okay, okay. Of course. Yeah, if everybody’s implementing the same thing, it’s not this weirdy JavaScript thing that you downloaded from somewhere.
And okay, another question about, just sticking on that one for a moment. Will that be performant in the sense of, I don’t know, if I’ve got a carousel of 15 images, will the 15th one be loading at the moment.
[00:29:56] Adam Silverstein: Lazy loaded?
[00:29:57] Nathan Wrigley: Yeah, exactly.
[00:29:57] Adam Silverstein: You would hope so, yes. I mean, I think in general it will be more performant than a JavaScript implementation. Unless the JavaScript implementation is doing some magic that the browser’s not aware of, like lazy loading. I think that is, will be built in. But you, again, don’t have that JavaScript running on the main thread doing the actual animations. All the animations are CSS animations.
[00:30:16] Nathan Wrigley: It’s kind of curious because that example, I’ve always liked how they look but I’ve always been persuaded that it’s the wrong thing to implement because of the JavaScript bloat, the inaccessibility. So they kind of went into that pariah status for a while. But if done right, there’s absolutely no reason not to implement it.
[00:30:36] Adam Silverstein: Yeah. And I think, you know, like you said, clients love them, they’re very popular. I think one of the arguments that I’ve heard about them is that data shows that most users never navigate beyond like the second image. So there is sort of questionable value there, especially if you’ve got one that say has 30 images in it on your homepage. Maybe that’s not such a great idea.
But maybe if you have three products that you want to feature at the top and you don’t know how to feature them all, a slider is a good way to have three things that the user can see all in the same space. So I think they have their uses, but I think there is the sort of resistance to using them from developers is based on solid data.
[00:31:09] Nathan Wrigley: It’s interesting as well because given, I don’t know the, bad reputation they have, it’s kind curious that that got made.
[00:31:16] Adam Silverstein: Right. So this actually brings us to a good point. Where do the browser vendors come up? Why are they building these things right? So the reason they decided to build CSS Carousel is this is an area that developers have struggled with.
Like I said, there are several libraries that are well established that have built really good sliders, but that’s taken a long time, right? And they still have accessibility challenges.
This is something that a lot of developers want to build, their clients are demanding it, and they’ve typically struggled to actually build something quality. So this is the impetus for a lot of these features that I talked about is places that developers are struggling. And that Interop project that I mentioned earlier, that’s where developers can give their feedback to the browser vendors about which features they feel are lacking.
That was the sort of like the last question of my talk was to developers, what are you struggling, what are you constantly using JavaScript for? What are you finding that’s still incompatible between browsers? Because I think that’s actually really important to get feedback from developers. The browser builders are in a room somewhere, they’re doing their thing. You know, they’re not out here building WordPress websites, so they’re not building Gutenberg. So we as developers have a responsibility to give feedback to the actual browser vendors so they know what we need, what we’re struggling with.
[00:32:27] Nathan Wrigley: You may not know the answer to this question, but does Chrome in a default setup where I install Chrome and then just click yes, yes, yes to everything that I’m asked. Does it provide heuristics back to Google about things like that? There’s millions of people interacting with carousels, for example.
[00:32:44] Adam Silverstein: I’m going to say, well, going to say no because they’re, Chrome does collect data, but you have to opt in. By default, you would not have that box checked.
[00:32:51] Nathan Wrigley: But it is possible.
[00:32:52] Adam Silverstein: Yes. And many people do. Many people do provide that. And most of that data is available publicly. So that data is anonymised and then made available publicly as part of the CrUX, the Chrome user experience data set. And that’s an open public data set that you can query using BigQuery. If you have a website or a product that’s very popular, you can get amazing data about how many sites are using it, about the performance of those sites, about growth over time. There’s all kinds of data out there.
Of course, again, it’s a subset of the web. It’s not every website on the web because there’s a privacy concern about this data. So the only data that’s reported is when the pages or sites have enough visitors that you couldn’t track back to individual users. So it is a limited data set. Small sites with low traffic won’t appear in it. However, it’s incredibly valuable. And if you build a popular plugin, for example, this is a great way for you to gather data about how your plugin is being used, because some of the sites that install it will be in that data set and it’s public data.
[00:33:51] Nathan Wrigley: Yeah. I’ll put a link to that in the show notes. That’s CrUX. CrUX. So that’s interesting. So there’s two routes there. There’s the heuristics provided by the browser if you opt in, but also it sounds to me like there are open channels communicating through people like you, if you’re a developer.
[00:34:04] Adam Silverstein: Like me, or like the Interop process that I mentioned earlier, where they open up a GitHub repo each year and you can just open an issue saying, here are the things that we’re struggling with. And I mentioned like Gutenberg actually did that.
For a couple years I was posting on the WordPress blog, hey, Interop is open, let’s give feedback. We did have one, at least one year where the Gutenberg team went in and made a long list of things that where they found incompatibilities. And some of those made their way into actual interrupt tasks. So it is incredibly valuable to give that feedback. And the browsers want to know, they want to build products that developers like to use.
[00:34:36] Nathan Wrigley: Okay. next, if there is a next.
[00:34:38] Adam Silverstein: Oh yes. Okay, so now we’re getting into, I think I hopped around a little bit, but the next section was about improving user experience. So the first one is actually a really simple one that I think is really cool. It’s customisable select.
[00:34:49] Nathan Wrigley: Oh, so good.
[00:34:50] Adam Silverstein: Yes. So the select element traditionally has been rendered by the operating system. And that means, so if you have a select list, like a dropdown, you’re going to see a bunch of words and you’re going to be able to scroll through those. But if you want to make it more visual, say add some images or icons next to each word, you really couldn’t do that. If you wanted to do that, you’d reach for a JavaScript library that would render the select element graphically, but wasn’t really a select element.
So this is the ability to actually put HTML inside your select elements. So a great example of that is icons and images in the dropdown. So, for example, I gave a lot of different examples of how we can use this in WordPress Core, but one is in the media library where we filter by media type. We can add like nice little icons. So if you’re looking for, you know, the videos, you get a nice little video icon. It just makes it easier for users to find what they’re looking for.
And again, this is still a semantic select element, so it’s going to be accessible just like a regular select element. If the browser doesn’t support this feature, it’s just going to fall back to a regular select element.
It’s also going to autofill correctly, right? So another example I gave was a currency selector that adds flags for the country of the currency. A nice, helpful thing. If your browser knows that you use the Euro, it’s going to select the Euro because autofill is this great technology that helps us select things that we always select. But if it’s a JavaScript do hickey, the browser has no idea what’s going on inside there, so autofill will not work correctly. So it has some real key advantages over traditional, you know, the way we would build these before. Now we can just do full on HTML select elements.
[00:36:21] Nathan Wrigley: It’s the kind of thing that once you’ve seen it, it’s like, why.
[00:36:25] Adam Silverstein: Why didn’t that exist before?
[00:36:27] Nathan Wrigley: Because we just have the OS. It just looks like an OS selector. So on my Mac, it looks like a Mac. On my phone, it looks like Android, whatever that would be. Which leads me to that actually. So on the phone, same experience because it’s not stepping outside of the browser. if I’ve got those flags, for example, or I’ve got coloured backgrounds or rounded corners or whatever it may be, Because it’s not reaching out to the OS to create this select, it’ll work on any device.
[00:36:53] Adam Silverstein: Right.
[00:36:54] Nathan Wrigley: Nice.
[00:36:54] Adam Silverstein: And it’s CSS controlled, right? So you could do a different mobile implementation than your desktop implementation.
[00:36:59] Nathan Wrigley: Yeah. I mean, it’s profoundly brilliant when you see. I’ll put some links to some demos somewhere into the shownotes.
[00:37:06] Adam Silverstein: You know, I’ve got several pull requests open both in Core and in Gutenberg to add these features into the select elements that we already have. It’s kind of a simple enhancement. And again, like if your browser doesn’t support it, you don’t really, there’s no harm, right? You don’t benefit from the feature, but you don’t lose anything either. I love that one. You know, I’m hoping that form plugins in our ecosystem will adopt it.
[00:37:25] Nathan Wrigley: Oh, no doubt. I mean, why wouldn’t you, basically? that’s a brilliant one. Thank you. Next.
[00:37:30] Adam Silverstein: Another one that, this one actually pairs really well with the Speculative Loading API and it’s called, the View Transitions API.
And this one is really cool because it basically turns your static website into a, kind of a fluid app-like experience. And in the slide deck, I have this great demo video of just a classic theme, where the users just clicking through to different pages. So you’re on say, the archive list and you’ve got a list of titles. And you click on a title and it’s going to take you to the single post page. And what happens is the browser actually navigates between those two states. So you see the title that you just clicked on, grow and expand, and it winds up in the position where it will be on the page you’re navigating to.
Same thing like with the featured image. Let’s say you have featured images and those appear in a list and you click on the featured image, the image will grow to where it’s going to be in the final position. So it creates a smooth animation between the different pages of your site, or states of a single page app.
And these are again, CSS animation, so you can control them. It has an auto mode where it picks the animation for you, so you really can do a very, just few lines, and get this effect working, but you can also customise it. So if you want the page to say scroll left when you hit the next button and scroll to the right when you hit the back button, you can implement it that way.
[00:38:45] Nathan Wrigley: So the place I’ve seen this before really is on mobile applications.
[00:38:48] Adam Silverstein: On apps. You see it on apps, right. Because it creates this fluid experience. We are used to on the web this idea of, you click on a link and then there’s kind of like a little bit of a wait. Then boom, there’s a refresh and the next page starts loading. And this kind of bridges that gap. It’s something that changes how users perceive your website. It doesn’t really change what’s loading. It’s the same before and after states. What it’s doing is creating that transition between the two states.
[00:39:12] Nathan Wrigley: It feels more like you’re on a journey as opposed to these little stops along the way to get to the final destination. It just creates this sort of fluid, endless experience. And I believe, I think I saw one of your colleagues, Felix Arntz, I believe he’s got a plugin, like a feature plugin out.
[00:39:30] Adam Silverstein: It is. It just shipped. It’s part of the Performance Lab plugin suite. So that is basically going to add a way for themes to just opt in. So we have a feature in WordPress where you can be, add themes support. And you can say, my theme supports this feature. So if themes opt in, they can just enable this API and just, you instantly get the navigations.
We fortunately benefit in Core from a lot of consistent naming for things. Like the class names on titles tend to be consistent among all the Core themes. And even in the ecosystem, a lot of people have stuck to those standards. And that makes it really straightforward to sort of choose the correct elements for the transitions.
Because part of setting this up is you sort of need to tell the browser, this is the title element. On the previous page, this is the title element on the next page. I want you to navigate between those two. And fortunately, at least for the Core themes, that’s pretty standard to do. So there is a pretty straightforward way to like implement it across all the core themes.
[00:40:23] Nathan Wrigley: I just want to remind the listener that, you may have got lost, we’re not talking about WordPress per se. We’re kind of talking about what the browser enables WordPress to do. So these view transitions, of course they can be implemented by a WordPress website, but it is in effect the browser that’s doing the hard work here.
You don’t have to be tied to WordPress, you could do this in HTML and CSS if you so wish to do it. But it’s easy to imagine that this is some clever JavaScript thing that somebody’s implemented in WordPress. And it’s just not that. This is just happening inside the browser.
[00:40:53] Adam Silverstein: No, these are all browser features and, yeah, the talk is kind of like, how do they apply to WordPress? How WordPress use them?
[00:40:59] Nathan Wrigley: I can imagine a world in the future where this feature in particular will have been massively overused. You know, people will, like scrolling animations for the, you know, this grows and this shrinks, and let’s see how that’ll settle. But the implementations that I’ve seen are just magnificent. They give you that, I don’t know, I’m on my phone, I use a music app, and I go to the next song and somehow the little icon for that song grows in this nice fluid way. Things fade in and fade out. Text becomes bigger, and it’s all happening. And It just encapsulates the screen perfectly. It gives everything the perfect place. And instead of it being a moment where it all just changes, everything slides into place. And it just feels natural, and we’ve got it coming in the browser.
[00:41:39] Adam Silverstein: It is amazing. Yeah. It’s, a pretty cool feature.
[00:41:41] Nathan Wrigley: Yeah. Okay, next.
[00:41:42] Adam Silverstein: Okay. So I did talk about what you mentioned, we talked about modern images before. So I did talk a little bit about modern image formats, just a kind of love of mine. I honed in on. HDR imagery. So we all, most of us have smartphones these days that actually take high dynamic range images, right? Previously we had standard dynamic range, but now all of our phones take multiple exposures and combine those to create an HDR image.
We have long had the ability to save images in HDR with formats like AVIF, WebP supports it. However, the challenge comes when you upload those images to WordPress and then you try to use them on a standard definition monitor, an SDR monitor, right? So you’ve got an HDR image, but suddenly you’re displaying it on a monitor that can’t display HDR, and you have to sort of, re downsize it to that lower bit depth, and that degrades the image greatly.
So there is a new format available that’s ISO standard, and it’s called Ultra HDR. And this is a combination of standard jpeg SDR imagery with a gain map metadata layer. So it’s a single image format that includes both the SDR data as well as the data required to render the HDR version of the image. So it’s a full HDR image when you view it on a monitor that can support it, but on a monitor that doesn’t support it, you can just use the SDR image, you don’t need to do some conversion to try to create that alternate image.
[00:43:09] Nathan Wrigley: I’ve never heard of this, so I’m going to try and parse it in real time. Let’s see how this works. So I’m imagining an image and I’m imagining like a CSS gradient over the top, There’s a bit of metadata which does something. The underlying image is unchanged, but there’s something gone over the top.
[00:43:25] Adam Silverstein: Yes, it’s called a gain map.
[00:43:27] Nathan Wrigley: Right, so gain mapping. And I can put that on, put that off. So it’s metadata transforming the image, but the image is the same.
[00:43:33] Adam Silverstein: Yes.
[00:43:35] Nathan Wrigley: Interesting.
[00:43:35] Adam Silverstein: Yes. So I am a programmer and I deeply know about how WordPress media works, but I am not a photographer. However, there have been some great contributions from photographers who really know this space well. And they’ve come in and helped us on the media team really understand the challenges of handling these types of images and publishing them to the web, right?
So I have a link in the slide to one of those guys and his photography website. He’s a software developer and a photographer. And he’s got like those sliders you can kind of see before and after and see what the difference is between SDR and HDR imagery. And you realise, oh my God, HDR images are amazing. So the point of this feature, or the thing that I’m talking about is to try to let people actually be able to use HDR images on their WordPress websites.
[00:44:17] Nathan Wrigley: That’s fascinating. So a metadata layer living on top of an image, which visibly transforms it, but not just to add, I don’t know, to change the hue or the tint of it, to render a better image of a higher quality. Gosh that’s fascinating.
[00:44:32] Adam Silverstein: Yep. So the challenge we have in WordPress is the ability to process these images. So in WordPress, when you upload an image, it goes to the backend, to the web server, and then we process it, we convert it to various sizes for different display sizes. So you get a different image when you’re browsing the site on a mobile or a desktop or a high definition screen. We have all different sizes, and themes can add sizes.
And all of that image processing happens using a couple of image processing libraries. GD and Imagick are the two that we support natively. Those libraries do not support the latest format, so Ultra HDR was maybe just added to Imagick. It will take years before that library, the new version of the library is actually available to WordPress sites. So even a format like AVIF that’s been around for quite a while now, is only supported by 30% of WordPress servers. So only 30% of WordPress sites can actually upload AVIFs and get the full, you know, various sizes that they need.
So that’s a limitation of the architecture of WordPress. And one of the next features that I talked about is something that will help us leapfrog that limitation. Browser based image processing. Exactly right. So what I’m talking about here is WebAssembly.
So WebAssembly is the ability to run code that was written in another language like C or C++, that targeted a machine language, is meant to be run natively on the hardware. So that, for example, these image processing libraries, and also newer image processing libraries, can be run directly in the browser.
And what this gives us the ability to do is ship the latest version of the image library directly with WordPress. We no longer have to rely on hosts doing the messy and difficult process of upgrading servers, very challenging thing for hosts to do, to get the latest version of the Imagick library. We can just ship that library directly in the browser. And that gives us the ability to make every WordPress site support AVIF, and it also gives us the ability to do things we simply can’t do today on the backend.
A good example of that is converting gif or gifs to movies, right? This is a common performance recommendation. Gifs are very heavy. You convert them to a native video element and they behave just the same for users, but they’re much lighter because the compression is so much smarter. Can’t do that in WordPress right now. Neither of the image libraries support that ability. But there are image processing libraries that handle this, and we can run those directly in the browser.
[00:46:52] Nathan Wrigley: Let me see if I’ve got this right. So in this world of the future, it’ll be possible, let’s say in the block editor, I drag in a, I don’t know, a jpeg or something, but I could convert that on the fly to an AVIF for example.
[00:47:05] Adam Silverstein: Yes. Even if your server didn’t support AVIF.
[00:47:06] Nathan Wrigley: Even if. So it’s literally in the browser.
[00:47:09] Adam Silverstein: Yes
[00:47:09] Nathan Wrigley: Okay. First thing is that quick.
[00:47:11] Adam Silverstein: Well, okay, so it’s not quick on the backend either, right? But it is asynchronous, so you can continue working on your post while it’s happening.
[00:47:18] Nathan Wrigley: Right. So you wouldn’t necessarily see anything.
[00:47:20] Adam Silverstein: Right. You would that it was processing. And of course it would depend on how large your image is, how many subsized images you’re creating. But no, it’s not fast. It’s a slow process, but it’s a one time thing each time you upload an image.
[00:47:31] Nathan Wrigley: That was next question. It’s a one time thing. So the movie thing that you just described, where you got the gif to a movie, again, a one-time thing?
[00:47:38] Adam Silverstein: Yes.
[00:47:39] Nathan Wrigley: So we upload it. In the background, asynchronously, it’s converting it, and then at some point it gets saved, I guess as a .mov file or something like that? inside the media library?
[00:47:50] Adam Silverstein: And this is actually not some future technology you’ll be able to use someday. You can use this today by installing Pascal’s Media Experiments plugin. So my colleague Pascal has swisspidy as his handle, people know him by that. But he’s got the Media Experiments plugin, and that will let you do all these things that I’m talking about today. And it is experimental, so beta software, but, check it out because it really demonstrates what we can do.
There’s also a PR already open in Gutenberg with a whole roadmap for landing this feature. It is already sort of an experimental feature in Gutenberg. So if you install the Gutenberg plugin and you go into experiments, you can actually enable this feature. I don’t think it has all of the things that he has in the plugin, but it has sort of the additional framework for it.
[00:48:28] Nathan Wrigley: If I were, well, I am fairly non-technical, this is the kind of stuff I expect, I think. You just drag an image from any device of any kind into the editor, whatever that editor interface is be it Gutenberg or, you know, whatever. It should just handle that. You know, there shouldn’t be a proclivity for we prefer this thing or we prefer that thing. It should just do it and whatever output I want, I want it as an AVIF, I want it as a WebP. Okay. we’ll just transform it in the background. I know there’s a ton of technological milestones to be achieved and overcome with that, but that is, I think, the expectation. The web should just work like that. Everything should convert and be easy, and drag and droppable and, yeah.
[00:49:10] Adam Silverstein: Yeah, and famously, several years ago, Apple started storing images in the HEIC format, which is a better compression than jpeg. However, it’s not a web safe format. I think Safari is the only browser that supports it. So when we upload HEICs to WordPress now, we do convert them to jpegs for users.
However, that only happens if your server supports HEIC images. Again, we rely on the server libraries, and that statistic is very similar to AVIF. It’s about 30% of sites. Fortunately Apple does automatically convert them if you upload them from your phone. But people do get into this problem where they wind up with HEIC images on their desktop and they’re trying to upload them to their WordPress, and then it will get rejected if your server doesn’t support it.
[00:49:50] Nathan Wrigley: Yeah, this whole thing of, I’ve got images. It’s an image. Well, it’s in the wrong format. It’s an image.
[00:49:55] Adam Silverstein: Right? Why do I have to care?
[00:49:57] Nathan Wrigley: It shouldn’t matter. Yeah, okay. That’s a perfect example. Okay, so images, anything else?
[00:50:02] Adam Silverstein: The other one that I think is really cool that maybe people don’t know about is running AI directly in your browser. So there’s a great library called Transformers.js that lets you run a whole bunch of different models, kind of, it acts as an interface.
So just like the large language models that we have online, like Gemini and ChatGPT. You can actually run smaller versions of those directly in your browser. And some of the advantages of that are the data is private. There’s no API key required, or cost to you to use these. You can ship an AI directly with your product. So imagine you have a software, a plugin that is designed for company bulletin boards. You don’t really want that data going out to some remote API, but you’d like to give users a way to summarise the conversation from yesterday. A language model running in your browser is capable of doing that.
[00:50:49] Nathan Wrigley: Where does it live.
[00:50:50] Adam Silverstein: It runs in the memory of the browser and it gets downloaded in cache. So there is a large download when you first start using it to actually download the model. And then it’s cached, with the browser storage APIs.
[00:51:01] Nathan Wrigley: It’s persistent.
[00:51:03] Adam Silverstein: It’s persistent, yes.
[00:51:03] Nathan Wrigley: Okay. Switch the machine off, switch the machine on.
[00:51:05] Adam Silverstein: Yes. It’ll stay cached in your, browser. Browser has the ability to store files.
[00:51:08] Nathan Wrigley: I’m guessing the constraints around what it can do compared to, I don’t know, ChatGPT 4o or whatever is much more minimal.
[00:51:15] Adam Silverstein: Significant. Right. This is in the browser, you’re probably going to get the performance maybe that you got out of the models a year ago or a year and a half ago. Remember when.
[00:51:24] Nathan Wrigley: Oh not that bad then.
[00:51:25] Adam Silverstein: Yeah. Not that bad, right? And you can imagine that a year or two from now, they’re just going to get better. And there have been dramatic improvements, and even like new approaches to how they’re doing them. So they’re getting quite good. They’ll never be as good as the large language models that are running in the cloud that have abundant resources.
There’s also hybrid models, right, where you use the local version when that’s all you have available, your offline, say, for example. Or you have a more complex query, then it can go to the cloud. There’s different ways of approaching that. But you can build a hybrid system, but the point of, the ability to run it in the browser, is to actually be able to do everything locally, and not rely necessarily on a cloud provider.
[00:52:00] Nathan Wrigley: It really feels at the minute as if Google is in a big pivot towards AI.
[00:52:06] Adam Silverstein: Absolutely.
[00:52:07] Nathan Wrigley: In fact, it kind of feels like if you were to describe it as a race, it feels like Google is kind of nudging ahead at this moment in time. I just watched some of the bits and pieces from Google IO.
[00:52:16] Adam Silverstein: Yes. Really impressive.
[00:52:16] Nathan Wrigley: It was pretty profound in many respects. But also, can you constrain that AI? So for example, could I limit it to one, well, let’s say website? It can only be used and consumed by this thing. I don’t know if there would be a need for that. I’m just wondering, is it available to all the things or can you constrain it?
[00:52:35] Adam Silverstein: I mean, so there are actually aI things being built into the browser where you’ll get AI in the browser itself. But this is not really that, this is more like it’s running inside your app. So it would be constrained. And I see this as something that we’ll start to see like plugins, shipping AI with their plugin, and it doesn’t require you to have ChatGPT or some other service provider, it just has the AI built in.
Maybe it’s identifying objects in an image. Or maybe it’s reviewing comments as to whether they’re spam. So things like that where it’s a pretty straightforward AI capability, it works really well on these smaller models. And so that’s something that I could imagine would just be built into a plugin. You would add this AI feature, but it doesn’t require that you sign up for a ChatGPT account, and get an API key and install it. You know, there’s a lot of barriers, I guess, to using the cloud models.
[00:53:23] Nathan Wrigley: Yeah. I feel like you’ve left the most interest, well, not the most interesting, but the bomb is there. My head is kind of a bit taken by that one because I can really, I mean, everybody’s fascinated by AI, the possibilities of it. But it’s always an API key. It’s always a go off somewhere else. I mean, maybe it hasn’t been for people such as yourself, but I did not know that it was possible in the browser.
And if it’s only a year behind, honestly, the stuff that I want to do with it is give it a corpus of information and filter that a little bit and give me a summary of it. That’s what I’m using it for. I’m imagining that all of that would be possible in the browser at no monetary cost.
[00:53:59] Adam Silverstein: Exactly. Right. Because you’re doing the computing yourself on your own platform.
[00:54:03] Nathan Wrigley: And I would imagine, like I said, Google leaning into this, that’s only going to get more investment from them.
[00:54:10] Adam Silverstein: Yeah. I mean, there is, yes, there’s a lot of investment going on in AI right now, so it’s pretty exciting. Yeah, and I did have, you know, I did talk a little bit about just how AI is going to impact all of our workflows and stuff, but that’s not really in the, it was kind of an expansion because it’s not actually a web capability, per se.
[00:54:25] Nathan Wrigley: Yeah. Well, I think maybe that’s the perfect place to end it. Unless you’ve got some cataclysmic thing which can trump that.
[00:54:30] Adam Silverstein: Nope. That was the end of talk. The last slide was really just asking for feedback from developers. So that would be my last thing to say is just, you know, try to give feedback. I’m always open. My DMs are open on WordPress Core Slack. And like I said, there’s the interop thing where you can actually open up a ticket.
[00:54:45] Nathan Wrigley: So, again, dear listener, just remember all of this, the browser is doing this. It sounds like it’s WordPress doing it, or it sounds like some other third party service. It’s not, it’s all in The browser and it’s fascinating. The browser is definitely more powerful today than it was yesterday. Adam Silverstein, thank you so much for chatting to me.
[00:55:02] Adam Silverstein: Yeah, thank you.
On the podcast today we have Adam Silverstein.
Adam is a WordPress Core committer, and works to fix bugs and improve modern web capabilities. He’s also a Developer Relations Engineer on Chrome’s Web Platform team at Google, and there he focuses on making the open web better for everyone.
Adam is here to break down how the rapid evolution of browser technology can supercharge your WordPress sites. We’re doing this by referencing his presentation at WordCamp Europe 2025, in which he covered multiple new features of browsers, which can be used by WordPress users to bring a variety of experiences to their websites.
In many cases, these are browser APIs and features, and are quietly rdefining what’s possible on the web. From CSS-powered popovers and scroll-driven animations to speculative loading that speeds up your page transitions. Adam explains how these advancements are changing what’s possible for both developers and end-users.
The conversation sheds light on the collaboration between browser vendors, Chrome, Firefox, Safari, and Edge, through initiatives like Interop and Baseline, paving the way for more consistent and robust features across platforms.
Adam also talks about practical topics central to the WordPress community, like how the Popover API and native CSS carousels reduce JavaScript bloat, make sites more accessible, and deliver a better overall user experience.
He shares exciting new frontiers, such as browser-based image processing powered by WebAssembly, which is paving the way for universal support of modern formats like AVIF and Ultra HDR, and even running AI locally in your browser, no API key or cloud server required.
He provides concrete examples on how these technologies can be leveraged in WordPress via Core updates, canonical plugins, and Gutenberg experiments, with a special focus on how developers can get involved and offer feedback to help shape future web standards. Prepare to look at your browser in a whole new light, truly.
Whether you’re a theme designer, plugin developer, or site owner simply curious about what’s next, this episode is for you.
Useful links
Modernizing WordPress with new Web Platform Features – Adam’s presentation at WordCamp Europe 2025