Next Tuesday is my 10-year anniversary of becoming a WordPress core committer back on May 20, 2015.
This post is somewhat of a résumé for my contributions to the WordPress project. Now that I’m being laid off from Google, I’m hoping to continue contributing the majority of my time to WordPress at another company that also cares for the health of the open web and the democratization of publishing.
Thanks to Peter Wilson for his useful WordPress Core Contribution History tool, I used it to look up my contribution history:
@westonruter is a core contributor to 32 WordPress releases
Full contribution history credits table
Note that Peter told me that the Credits API only goes back to WordPress 3.2, so that’s why it’s the first release listed. I’ve omitted the empty rows from 3.2 to 3.6 in which I wasn’t listed in the credits.
| Version | Title |
|---|---|
| 3.7 | Core Contributor |
| 3.8 | Core Contributor |
| 3.9 | Contributing Developer |
| 4.0 | Contributing Developer |
| 4.1 | Contributing Developer |
| 4.2 | Contributing Developer |
| 4.3 | Contributing Developer |
| 4.4 | Contributing Developer |
| 4.5 | Contributing Developer |
| 4.6 | Core Developer |
| 4.7 | Core Developer |
| 4.8 | Core Developer |
| 4.9 | Release Lead |
| 5.0 | Core Contributor |
| 5.1 | Core Contributor |
| 5.2 | Core Contributor |
| 5.3 | Core Contributor |
| 5.4 | Core Contributor |
| 5.5 | Core Contributor |
| 5.6 | Core Contributor |
| 5.7 | Core Contributor |
| 5.8 | Core Contributor |
| 5.9 | Core Contributor |
| 6.0 | Core Contributor |
| 6.1 | Core Contributor |
| 6.2 | Core Contributor |
| 6.3 | Noteworthy Contributor |
| 6.4 | Noteworthy Contributor |
| 6.5 | Core Contributor |
| 6.6 | Core Contributor |
| 6.7 | Core Contributor |
| 6.8 | Noteworthy Contributor |
My first credited release was WordPress 3.7. However, I grepped core commits to find that my very first prop in changeset r11567 (on June 14, 2009) came before that as part of the 2.8.1 minor release. While I had been building sites with WordPress since around 2006 (and even had a blog years earlier), this was a drive-by contribution, years before I started contributing heavily in 2013. My next prop came four years later in r25580 which is when I started contributing heavily. I’ve had credits in every major release since 3.7: thirty-two in all!
Credits I’ve had include:
- Core Contributor (18⨉)
- Contributing Developer (7⨉)
- Core Developer (3⨉)
- Noteworthy Contributor (3⨉)
- (co-)Release Lead (1⨉)
I’ve made 662 commits to trunk and I’ve had props on 465 commits:
I’ve also opened 324 Trac tickets and made 4,935 topic replies in the WordPress support forum.
It all began in 2013 when I started contributing heavily to the Customize component. My first major feature was adding widgets to the Customizer, and I continued contributing heavily to the Customizer through the end of 2017, around when WordPress 4.9 was released. Here are a few of my Make/Core posts (out of the 35 posts I’ve published) that highlight some of my work during this time:
- Widget Customizer Feature-as-Plugin Merge Proposal
- Proposal: Customizer Transactions
- Selective Refresh in the Customizer
- Improving Setting Validation in the Customizer
- Customize Changesets (formerly Transactions) Merge Proposal
- Customize Changesets Technical Design Decisions
- Code Editing Improvements in WordPress 4.9
- New Features and Enhancements with Customizer Changesets in 4.9
I also blogged a recap of co-leading the 4.9 release, and I presented highlights from the 4.8 & 4.9 releases during SotW at WordCamp US 2017. My time working on the Customizer and the 4.9 release was sponsored by XWP, where I was CTO.
In that year, development on the Gutenberg project took off, and this coincided with a decline in direct contributions to WordPress core. Over that summer I also started ramping up on Gutenberg, but then I got the call to lead the 4.9 release and I had to leave Gutenberg behind. I focused instead on continuing to improve the Customizer among other aspects of WordPress core. However, once 4.9 was out the door, it became clear that the Customizer was not going to be a priority focus for the WordPress project going forward, with all efforts being put into Gutenberg. In fact, there was no major release of WordPress for more than a year until the Gutenberg project was ready for inclusion in WordPress 5.0.
Since I somewhat missed the boat on Gutenberg, and since new Customizer feature development was at an end, I pivoted in 2018 to work on something new: the AMP plugin for WordPress. (I also joined Google in Q4 2018.) This was largely my focus until I joined the WordPress Core Performance Team in 2023. This was an interesting challenge to democratize performance for WordPress sites by leveraging the open source AMP web component framework. Since AMP is a declarative framework, I implemented some interesting things like CSS tree shaking for all stylesheets used on a page and print them inline to eliminate a large source of render blocking. Ultimately, a lot of what I learned while working on the AMP plugin I could apply directly to our initiatives on the WordPress Core Performance Team. AMP was developed before Core Web Vitals (CWV), and it contributed toward the development of LCP, CLS, and FID. So now as opposed to working on ecosystem compatibility with the AMP HTML specification, my performance work transitioned to improving CWV metrics.
Some highlights from my work on the Core Performance Team:
- Architected and led engineering of the Optimization Detective plugin, including the dependent Image Prioritizer and Embed Optimizer plugins. By far this was (and is) my primary focus on the team. See my talk Boosting Performance with Optimization Detective which I gave at WordCamp Asia 2025. More on this below.
- Identified and fixed an emoji loader performance problem (#58472) that caused a long task during page load for lower-powered devices, which could cause a 100-200 ms delay in LCP for every page load.
- Collaborated on launching script loading strategies (
async&defer). - Collaborated on developing the Speculative Loading feature plugin and landing in WordPress 6.8.
- Managed Performance Lab releases and led development of the plugin.
- Improved Interactivity API to prevent causing a long task at hydration.
- Contributed to wpp-research to improve benchmarking performance changes in WordPress and analyzing data from WP pages indexed by HTTP Archive.
Note that, on the Core Performance Team, my core commit contributions didn’t more significantly increase in 2023 in the chart above since my commit activity was focused on the WordPress/performance repo:
The loss of my sponsorship from Google to work on WordPress performance at this moment hits the hardest because the Optimization Detective project is just starting to show real fruit. The plugin now has 40,000+ active installs with the dependent plugins Image Prioritizer and Embed Optimizer each having 40,000+ and 30,000+ active installs, respectively. As of March 2025, there were almost 18,000 URLs in HTTP Archive which had Image Prioritizer active at the time of crawling. The week I lost my position, I was analyzing those URLs to see how accurate Image Prioritizer was at applying optimizations. I still intend to publish a post with all of the data, but the accuracy of the optimizations was looking quite promising.
When WordPress core adds fetchpriority=high to an IMG, I found that this was the LCP element only ~23% of the time. With Image Prioritizer’s use of client-side detection and fetchpriority=high preload links with media queries, the prioritization accuracy more than doubled to ~50%. Furthermore, when WordPress core adds fetchpriority=high to an IMG, this element is only in the viewport ~60% of the time, but with Image Prioritizer this increases to ~78%. I also found large improvements (>10%) to the accuracy of adding loading=lazy to images that only appear outside the viewport. Here is some of the provisional accuracy data:
| Optimization | Original Mobile | Optimized Mobile | Original Desktop | Optimized Desktop |
|---|---|---|---|---|
| LCP image prioritized | 24.2% | 50.3% | 22.4% | 49.1% |
IMG with high fetch priority only in viewport | 53.9% | 75.2% | 66.4% | 81.5% |
| IP-prioritized image in viewport | n/a | 90.9% | n/a | 93.3% |
Lazy loaded IMG not in viewport | 79.8% | 91.1% | 71.5% | 86.1% |
In terms of the performance impact of this improved accuracy in applying image prioritization optimizations, I looked at the difference in LCP with and without the optimizations applied while also subtracting the TTFB (i.e. “LCP-TTFB”) since my analysis script intentionally busts any page caching. When the LCP element is an image, the LCP-TTFB results were as follows:
- Average diff time for mobile: -1157.6ms (-7.7%)
- Median diff time for mobile: -138.7ms (-2.7%)
- Average diff time for desktop: -174.0ms (-2.3%)
- Median diff time for desktop: -65.9ms (-4.9%)
I was beginning to analyze cases for why Image Prioritizer was “only” prioritizing the LCP image with ~50% accuracy, and I was finding some bugs and low-hanging fruit to increase the accuracy yet higher. When the LCP element was an image that was prioritized correctly, the LCP-TTFB results were as follows:
- Average diff time for mobile: -1949.2ms (-17.3%)
- Median diff time for mobile: -654.1ms (-11.1%)
- Average diff time for desktop: -298.5ms (-8.3%)
- Median diff time for desktop: -136.8ms (-10.4%)
These are significant improvements.
Now as the WordPress project is facing a sharp drop-off in corporate contributions, I’m hoping to find a sustainable way for me to continue devoting a significant amount of my time to WordPress, perhaps in part via GitHub sponsorship (which I’m new to). I’ll be open to starting a new position after the June 15th termination date for my job at Google, as I’m currently on “garden leave”.
Where I’ve posted about this:
Leave a Reply