Luke and Jonathan catch up with a long-time friend and former colleague Weston Ruter to reminisce about their agency days before talking through Weston’s ten-year tenure as a Core Committer and the legacy of his work on the Customizer. From there, they cover the early days of the WordPress Core Performance Team and Weston’s time at Google, culminating in his contributions to the Optimization Detective project. They also discuss AI—how could they not? Weston’s development practices come up too, along with their mostly shared optimism about the future of the Open Web.

Transcript#

Initial transcript generated via Castmagic and hand-edited.

Jonathan Wold:
So, Weston, it was about five years ago that Luke and I were recording—it was either the first or second episode—and we talked about who we’d want to bring on as a guest, and you were the first person that we mentioned. So this has been a long time coming. How are you feeling about the pressure of holding out for five years before we finally made this happen?

Weston Ruter:
I hope I don’t let you down.

Jonathan Wold:
I don’t think you could, Weston.

Weston Ruter:
I haven’t podcasted in many years, so it’s a big moment for me too.

Luke Carbis:
For those who don’t know Weston Ruter, perhaps you could intro. Jonathan?

Jonathan Wold:
Well, so I had the privilege of meeting Weston, oh, more than five years ago, maybe seven. I saw this little company called XWP—it was called X-Team WP at the time—had put out a shingle that they were looking for developers. And at the time, I was doing—I don’t even know—so many freelance projects. But something about the positioning, the messaging, struck my interest. So I filled out the form, and you were the one who responded back. You asked me some basic questions. You were quite kind. And in the back of my mind, I was like, I’m not sure I’m this kind of a developer, I’m not this serious. But we started the conversation, and I think what I ended up saying was something like, “Hey, I could probably help with sales.” You then connected me with Tine, which led to our first conversation, and it wasn’t long after that I joined the team. Yeah, you were my very first context for jumping into that enterprise world of WordPress development. And many shenanigans went on from there.

Weston Ruter:
My first memory of you is being on a video call with you when we were on-site in Australia at News Corp and you were joining over video and working on the project with us. That was a long time ago.

Jonathan Wold:
That was quite the experience. What about you, Luke? What was your first interaction with Weston?

Luke Carbis:
Yeah, so I joined the team maybe two months before WordCamp Austin in—I don’t know, 20-whatever. Weston had been reviewing my pull requests. He’d been code reviewing me, and I was thinking, “Man, this Weston guy, he hates me so much. He’s so hard on me in these pull requests.” But I was learning so much. Anyway, once we flew to Austin for WordCamp, we were launching Stream, and we had this great Airbnb, and you and I sat down next to each other at the kitchen island with our laptops. You helped me to set up—I don’t remember what it was—probably PhpStorm with all of the various debugging tools. And I realized, “Oh, he doesn’t hate me, he’s just a straight shooter when it comes to pull requests.” It was hard for the first month, but then I think that set me up for my career. When it comes to developers, you want developers who are just going to tell you exactly how it is in the pull request and have all that kindness and humanity outside of the pull request. Does that make sense?

Anyway, so this is my first question for you. You were my early mentor, Weston - I don’t know if you realized that. What if you were mentoring someone in that same position today? The world has changed a lot. What would be your advice to those new developers that are just getting started in WordPress?

Weston Ruter:
First of all, I think I would have a lot to learn myself. Coming into the project afresh, you see things differently. I think I’ve gotten into a rut, and I do things a certain way and maybe I should be optimizing how I’m doing something or rethinking it from a different angle. Those opportunities to sit down next to each other and share our workflows are really beneficial not just for the new team member, but also for the experienced one, because you have to explain your workflow. Sometimes, even explaining it to myself while setting up my new computer, trying to document everything—I’ve been realizing, “This doesn’t make sense, this is really not an efficient way of working.” So I think having a fresh perspective and seeing things with new eyes—I’d get just as much out of sharing my workflow with someone else as they’d get from me.

Luke Carbis:
So what did you use on your new Mac to do local development environment?

Weston Ruter:
On my new Mac? Oh, I’m using everything, I guess. Well, Local WP, wp-env, Lando for WordPress environments. And then I’m using PhpStorm and iTerm, and the classics like that.

Luke Carbis:
Oh yeah, I’m looking forward to that blog post, Weston, where you go back through those setup notes and make a list of all your favorite software.

Weston Ruter:
I should. I was just seeing Jeff Paul post that on Twitter yesterday—sharing what he uses. Yeah, that was cool. And I was thinking, should I do that too? But then, I think people are going to look at my list and think, “Wow, he’s lame, he doesn’t know about this tool.” So part of me is excited to learn from others and what they’re sharing, but I feel anxiety about sharing mine, too. But I should—like I said before, you learn by sharing your perspective and from seeing others’ perspectives.

Jonathan Wold:
Before we go further, I want to give more background—especially for folks who may not know—and more context on your work, Weston. So rewind back to that agency the three of us had in common, which became XWP. We did those big enterprise projects, like with News Corp Australia. You were CTO, responsible for architecture, code review, mentoring—all sorts of things. One thing that stood out was all the work we did with the WordPress Customizer, especially with News Corp in Australia. One thing they really valued about working with XWP was, as you mentioned, how we (mostly you) contributed things developed for the client back into WordPress core. That opened up a whole new way for me of thinking about commercial/open source relationships, because News Corp was for-profit but also recognized the importance of staying aligned with core WordPress.

We went from there to more major projects—including work with Google on performance—then you ended up joining Google directly. How long were you there?

Weston Ruter:
Six and a half years.

Jonathan Wold:
Wow. So much time has gone by. So in that time frame, there’s a lot you’ve done: contributing to Core, being a core committer. For how long?

Weston Ruter:
Ten years, actually. The announcement post was today.

Jonathan Wold:
Ten years of being active in Core! The Customizer was your baby for a long time; you advocated for it, put so much care and effort into it. Later, I want to talk about that legacy, but I wanted to give everyone wider context for the perspective you bring… Now, you’re no longer at Google, right?

Weston Ruter:
That’s right, my time at Google has just ended.

Luke Carbis:
I also don’t want to overlook Weston’s contributions to performance . He was the Customizer guy for a while, then switched his focus to performance, especially via Google and the performance team—the WordPress performance project, Core Web Vitals, and AMP. I checked the commit history for the WordPress performance group GitHub repo and you’re far and away the top committer. Why the focus on performance? You were on Customizer for a while, then Gutenberg came along; did that shift things?

Weston Ruter:
Yeah. WordPress historically has struggled with performance because it’s such an open ecosystem, with no real limitations on what you can do—for better and for worse. If you look at the Core Web Vitals Tech Report, you can see how WordPress stacks up against other popular CMSs. WordPress is at the bottom—not far, but that’s partially because of recent performance work. The ecosystem is so open that there’s much room for improvement, and nobody likes a slow web page. So I was happy to work on that.

Jonathan Wold:
So, I’d like to take a step back and ask for a history lesson on the Customizer. For anyone not familiar, how would you describe it, and what drew you to spend so much time on it?

Weston Ruter: Well, when you’re working on a site as a builder or a publisher, one of the worst things is to make a change, but then not know the impact that change is going to have on the site without going to the site front end yourself. And while you are seeing that change, then any other visitors to the site would also see that change. And so that adds a lot of risk to make a change and adds a lot of anxiety to the process of making changes to your site. So with the Customizer, it provides you with a sandbox to make any change you want and see a live preview of what impact that change is going to have. And I think I used to say “what happens in the Customizer stays in the Customizer” until you hit publish. And so that—I really liked that aspect of what the Customizer provides. And it was empowering to be able to make changes to my site or a client site and then to see what the changes are going to be without breaking the site for other people. And so that’s why I was interested in the Customizer and saw it as an opportunity to invest in for providing to clients, to enhance their editorial workflows and site customization.

Luke Carbis:
Especially big clients like News Corp, who want to not only preview changes but maybe schedule changes. Isn’t that a Customizer feature?

Weston Ruter:
Yes, that was added in 4.9—the ability to make changes in the Customizer, save a draft, and share a URL for preview (even if someone’s not logged in), and schedule the changes to go live.

Jonathan Wold:
That reminds me. We had a situation with News Corp Australia where they had thousands of widgets and were running into performance issues. You worked with others to bring a change to WordPress core to solve that—a perfect example of taking a commercial use-case and improving the platform for everyone, even if most users wouldn’t immediately notice. I’ve always seen that as an ideal example of collaboration between commercial and open source interests.

Weston Ruter:
So, yeah, from what I remember there were thousands of widgets, but not all used on the same page. There’d be different sidebar permutations. They had lots of different dynamically created sidebars for different templates. But the problem in Core is because Core doesn’t anticipate that you’re going to have thousands of widgets, it loads all the widgets that you have into memory with every page load. So the work that we did on that project was to, as I remember, lazy load those widgets that are only needed for that page and not load the ones that we didn’t need.

Jonathan Wold:
So my memory’s hazy and it’s still there—like, last I checked—even if most people aren’t making use of the Customizer, the underpinnings of it are still part of WordPress. The last thing for me on that: In your mind, Weston, what was some of the legacy of the Customizer work? Obviously Gutenberg came along and brought a lot of innovation and progress, but from my point of view, a lot of what was done in the Customizer has had influence and impact even today, even for folks who don’t realize it’s there. How do you think about the legacy of that work?

Weston Ruter:
Well, like I said, the Customizer provides you with sandbox to make changes without fear of those changes breaking the site. And so the whole idea there is that you have a live preview and that is carried on in the block editor and the site editor where you can you get the live preview experience is in some ways better because it’s your, your inline editing aspect of the page.

Luke Carbis:
There was a push for a while there to be able to inline edit content within the Customizer. Do you remember that?

Weston Ruter:
Yes. There’s the customize inline editing plugin which shows that. That it is. You could. It could be done there as well.

Luke Carbis:
To me that was like a transition point from the Customizer to go. We could go in this route, we could go down this route. This works, this is where we want to end up. And that sort of birthed Gutenberg. I don’t know if that’s true. That’s how it worked in my head.

Weston Ruter:
Well, in some ways the Customizer preview is better than the Site Editor because it’s actually rendering the front end PHP code, whereas in the Site Editor it’s all rendered with JavaScript. And so if you have PHP filters that are running that customize how certain blocks are being rendered on the front end, that’s not going to show up in the Site editor. So Site Editor is a close approximation of what you’re going to get on the front end. But I think if I. Some aspects of the Customizer have yet to be ported over to the Site Editor. I’d say so. Like the ability to save pending changes in a change set as a draft to be able to then share as a preview link so that someone else can go to the front end of the site and see those changes before they go live. I don’t think that that’s not yet a capability, but it certainly.

Luke Carbis:
And we of course still don’t have a way of previewing a post that was published but has been updated. What is that going to look like on the front end? Which you know, we once were able to do using the inline editing Customizer plugin. So cool. Let’s switch now then to AMP Accelerated Mobile pages.

Weston Ruter:
Your favorite thing.

Luke Carbis:
Yeah, you know, because when we were all working together at XWP and Google was a client, we worked on the official AMP plugin for WordPress. I kind of noped out of that; I didn’t like AMP, I thought it was bad for the web, and wrote some blog posts about that. We talked about it before and I was pretty negative on it—especially me. Meanwhile, Weston, you worked hard to make it better, especially for WordPress. And now AMP—the world kind of breathed a sigh of relief as it wound down, at least people in my circles. So, we don’t have to rehash those old debates, but there was a lot of criticism of AMP: yes, performance gains, but at the cost of privacy or platform lock-in. AMP aside—it’s mostly wound down, right?

Weston Ruter:
It’s still around, but not as actively developed as before.

Luke Carbis:
But it made me think: Do you think performance and privacy are always going to be at cross-purposes with each other, specifically in the browser? A lot of performance optimizations, like preloading or caching, involve pulling info about the client machine or environment. Are privacy and performance always going to be at odds?

Weston Ruter:
AMP actually had privacy as one of its key design principles. Its goal was an instant page load experience from search or other surfaces. For that, you have to prerender in the background—but the AMP cache allows private prerendering without leaking info to the origin server. Analytics only fire when you actually visit the page. So in terms of privacy, you’re already on Google Search, so there’s no extra privacy leakage. But that’s why the AMP cache exists: for prerendered instant loads. As for vendor lock-in, I don’t see it—it’s just web components, JavaScript, CSS, HTML. You can migrate away any time, like you could with React or Vue. You can always use your AMP site directly without any ties to Google. The only “lock-in” is the same as with any frontend framework.

Jonathan Wold:
I wonder if the concerns expressed were mostly about public perception—because technically, people like you at Google really care about privacy and performance. But the big-picture Google narrative gets in the way, and some folks distrust even well-intentioned things. With AMP, it felt like people thought you’d need it for ranking. Any thoughts on that?

Weston Ruter:
AMP was never a ranking factor, as far as I know. Performance is a ranking factor. So a fast non-AMP page will do just as well in ranking as a fast AMP page.

Jonathan Wold:
So going back to Luke’s question though, for a moment, part of what I’m hearing from you then Weston, is that in your mind, privacy and performance don’t have to be at odds—that there’s not an inherent tradeoff there and at least it’s not one that you’ve been seeing in your experience or looking back at this. Is that fair to say?

Weston Ruter:
Yeah. Things have evolved. There’s the Speculation Rules API now for prefetching, similar to AMP’s prerendering, but using open web standards. And Core Web Vitals now give us a neutral, standard target for web performance—framework agnostic—whereas AMP aimed for best-practices but was developed before Core Web Vitals. With Core Web Vitals, we now have standards and metrics we can all target, not just a framework’s recommendations.

Jonathan Wold:
Two things stand out: One, Google’s relationship with WordPress was always interesting. When they first came to WordCamp Europe, people asked, “Is Google trying to buy WordPress?” There was some distrust at first. But it seemed clear there was an alignment of interests: if the web becomes too proprietary, that’s not good for Google. If performance is a big barrier for WordPress, improving that helps everyone—including Google and open web advocates. The work you and others did around performance and Core Web Vitals is a good demonstration.

Second, I hadn’t realized Core Web Vitals came after AMP and that AMP helped inspire some of that work. Core Web Vitals is widely respected and good for the whole web.

Luke Carbis:
And the Core Web Vitals project led into your work on Optimization Detective. Can you tell us a bit about that? Not many in WordPress know about it, I think.

Jonathan Wold:
And, by the way, before we dive in—the plugin only has three stars! So obviously no one can take it seriously…just kidding! Please, take it away.

Weston Ruter:
I will say, it is still early days. Optimization Detective actually goes back to a talk Felix gave at WordCamp US in…2022, I think? He talked about how WordPress at the time—and still—tries to have sensible defaults for resource priority: like, “featured image” is usually the LCP (largest contentful paint), so WordPress adds high-priority fetch and lazy-load attributes to images accordingly. Analyzing HTTP Archive data, you can see how often this is right. But those statistics are only “most likely”—they can only approximate reality. Felix’s talk ended with “What if we could use real visitor insights to optimize resource priority for every page on a site?” That’s what Optimization Detective does: it samples real-world visits across screen sizes and devices and records which elements are visible in the initial viewport (and which aren’t), storing that locally (no PII). Then, it uses that info to optimize things like fetch-priority on images and embed heights.

Luke Carbis:
So, say I’m viewing your blog on a 16" MacBook, full-screen. Maybe two images are above-the-fold and the rest aren’t. That info—specifically which images and which URL, along with my screen width and height—is stored. So, next time someone with the same config visits, your site knows which images can be lazy-loaded.

Weston Ruter:
Exactly. WordPress core doesn’t account for screen size when adding fetch-priority, but Optimization Detective (with the image prioritizer extension) adds preload links with media queries so the correct image is preloaded on mobile vs. desktop.

Luke Carbis:
It also does this for embeds?

Weston Ruter:
Yeah, the Embed Optimizer captures the final height of responsive embeds (like tweets or Bluesky posts) and then hard-codes that height to minimize layout shift.

Jonathan Wold:
Looks like there’s a lot of thoughtful work here that people don’t really know about. What’s the long-term vision? What would success look like?

Weston Ruter:
Optimization Detective is part of the Performance Lab plugin—a suite for incubating new performance features before suggesting them for core. If it’s successful, it should eventually merge into WordPress core, benefiting every site automatically.

Luke Carbis:
Is there any reason not to install it?

Weston Ruter:
It’s early days and still in alpha/beta. For most sites it’s great, but extremely high-traffic sites may want to wait due to current scaling limits. For those sites, we’re working on batch collection/admin screens, and WP CLI support. Most people shouldn’t run into issues, though.

Jonathan Wold:
Isn’t Gmail still in beta?! (laughs)

Weston Ruter:
Not anymore! But, for example, Optimization Detective stores up to three samples per viewport group (mobile/desktop/tablet). If you have a ton of traffic, more users may still try to submit metrics and it can add a lot of entries—something we’re refining. For high-traffic or lots-of-pages sites, scaling is a concern, but solutions are coming: for example, collecting metrics directly via the editor’s browser in wp-admin, or batch-collecting metrics for all pages.

Luke Carbis:
So, if Optimization Detective is good for nearly everyone except possibly huge traffic sites, it sounds like a no-brainer—boosts your site’s real-world performance, uses real screen sizes, etc.

Weston Ruter:
Exactly. (But again, very high-traffic users should monitor or wait for the next updates.)

Luke Carbis:
Are there performance “best practices” people obsess over that don’t really matter? For example, how much should we care about PageSpeed Insights scores, or are there other things people do that don’t make a big difference?

Weston Ruter:
One example: people focus a lot on image compression, which is great, but not as important as making sure your most important image (LCP) is prioritized for loading. If you optimize all your images but lazy-load your main image with JavaScript, your performance will still be terrible! It’s more important to let browsers easily and early discover the biggest image and give it priority.

On PageSpeed Insights: There are two parts in the report. The top is “field data,” which comes from real Chrome user experience report data (CrUX)—that’s real-world users, aggregated monthly. The section below is Lighthouse, which is lab data, a simulation with recommendations. The field data is FAR more important because it reflects what users are actually experiencing. If you don’t have enough traffic, CrUX data won’t be shown, so you rely on the Lighthouse section for real-time feedback. But if you have field data and your Core Web Vitals are good, you don’t need to worry about Lighthouse scores.

Luke Carbis:
How has your thinking about web performance changed since you started? And what’s the next frontier for performance—say, ten years ahead?

Weston Ruter:
The biggest shift is Core Web Vitals. It finally gave us concrete metrics to target for user experience, not just lab benchmarks. In the future, the browser will do even more: features like Speculation Rules API (for speculative loading/prefetching) are new and already in use at Google Search. The Speculative Loading plugin, for instance, lets you enable “pre-render” mode, which will pre-render a page when you hover over a link, giving you near-instant navigation. The new View Transitions API also lets us animate the transition between pages, smoothing out what would otherwise be a jarring instantaneous load. Sometimes loads are so fast you need an animation to tell people something happened!

Performance Lab is building plugins for all of this—speculative loading, view transitions—so WordPress sites can benefit from the latest browser innovations.

Luke Carbis:
That’s awesome for performance. What about AI? Has Gemini, ChatGPT, or Claude shown any concern for performance when writing code?

Weston Ruter:
I don’t really know. I’ve seen Adam Silverstein use Gemini by feeding it Lighthouse results and site health info, and get useful recommendations—he even gave a workshop on that at WordCamp Asia. But, as for actual code generation and if it cares about performance, I haven’t seen enough examples yet.

Jonathan Wold:
What is going to be interesting I think too is that the barrier to create these web applications is going down. But the question is, to Luke’s point is like how much is performance being considered as these things are spinning up and coming online because the LLMs aren’t exactly known for their succinctness in code generation. So yeah, that’s going to be interesting.

Weston Ruter:
Going back to what you’ve talked about in previous episodes with the influx of AI generated plugins and the plugin directory, I—I think that, well, that I think we should. Maybe you’d said this before, but we should encourage the use of AI to generate those plugins but not submit them to the directory. Yeah, we should have—and we can integrate that ability to generate such plugins in WordPress itself. So like it would be great if you could have like in addition to add plugin, if you could do create plugin and it could create a plugin file for you.

Luke Carbis:
That’s so cool, that’s a great idea.

Weston Ruter:
And you could integrate it with Felix’s AI services plugin or browser-based AI to scaffold a plugin, then drop you into the file editor to polish or refine it. Plugins are often full of bloat; this could let you build just what you need—and nothing more.

Jonathan Wold:
That’s a great segue into my last question. Weston, you’re a real believer in open source and the open web, right?

Weston Ruter:
Very much so.

Jonathan Wold:
There’s been a clear rise in proprietary web platforms—Shopify, Wix, Squarespace, Webflow. They’re solving real problems for people, but it means less “open” web. For us on the WordPress/open side, there are strong headwinds. Do you feel optimistic about the open web, or are we seeing the end of it?

Weston Ruter:
I’m optimistic! The web platform is advancing rapidly: new HTML, CSS, and browser APIs (invoker commands is a cool one—lets you handle actions in pure HTML, like opening dialogs or nav menus, no JS needed). With open platforms like WordPress, we get to experiment and push the boundaries—sometimes faster than the proprietary platforms, sometimes slower. Proprietary systems might move fast on features, but the openness of WordPress lets us try interesting things (sometimes dangerous ones too!). There’s real opportunity here.

Luke Carbis:
Right, and in open source, there’s no business model constraints to block new experiments.

Jonathan Wold:
If Luke’s recent plugin review experience is any sign, there’s still huge interest in building for WordPress. “Create Plugin” is a great idea—bake in rails for performance and security by default. There’s lots of innovation yet to come.

Weston Ruter:
Well, I was just going back to our time in Austin, Luke, and I was looking at the photo album I had from that time and I’m seeing a photo of us all jammed to the back of that car. Remember when we rode from WordCamp Austin back to the Airbnb? Yeah, I just thinking about the times that we’ve had together over the years, the three of us, and the good memories that we’ve had and in Austin.

Luke Carbis:
And Sydney a lot also. Yeah.

Jonathan Wold:
A big part of the value that I found in being part of this community is, you know, being able to find shared interests and develop new ones. There’s a lot of things that I really didn’t care that much about before learning from you, Weston, you, Luke, and hopefully vice versa, even if it is early days on that front. .

Weston Ruter:
I hope that we’ll be able to maybe make some more memories when you both come to WordCamp US in Portland.

Jonathan Wold:
Very much looking forward to that. Weston, thank you for taking the time and sharing with us and your thoughts and perspectives. For folks who want to learn more about what you’re up to, what’s the best way for them to—to—to get in touch? Is it your phone number? Are you going to share your personal number?

Weston Ruter:
I don’t like phone calls, as you know.

Jonathan Wold:
This is a rare treat to have you on a podcast. Appreciate you doing it.

Weston Ruter:
Video is better than audio, I will say. But yeah, my website is weston.ruter.net and if you look in the footer there, you’ll see all the different socials I’m on, but primarily it would be Bluesky and LinkedIn, I think, are my top two nowadays.

Jonathan Wold:
Excellent. Thank you very much for taking the time with us, Weston, and we’re looking forward to seeing what you build next.

Weston Ruter:
Thanks for having me on.