Woo's latest merchant survey uncovers a growing "preparation gap" for Black Friday and Cyber Monday (BFCM). Larger merchants, especially those earning over $1M annually, are prioritizing website performance optimization over inventory management and preparing months ahead, while many smaller merchants still rely on traditional, last-minute tactics. The findings reveal key shifts shaping the 2025 holiday […]

28 Aug 2025 2:26pm GMT

At WordCamp US 2025 this year, I'm presenting a talk called "The Site Speed Frontier with Performance Lab and Beyond" with the following description:

The Core Performance team has been incubating enhancements for WordPress through the Performance Lab plugin. These have been available for a few years now; some have been merged into core (e.g. Speculative Loading) while others are more experimental and remain in testing (e.g. Optimization Detective). This talk will look at how these performance plugins impact the speed of a stock WordPress site running the Twenty Twenty-Five default theme, using Core Web Vitals benchmarks and Lighthouse scores. It will also look at how the theme's performance can be further tuned, including the use of core patches proposed for the next major release (also available in plugin form to leverage today) to further accelerate the loading of pages to improve the user experience of site visitors.

Here's the livestream recording:

And here are my slides as well:

And what follows is my talk in blog post form, greatly expanded with a lot more details than I had time to share during my talk.

Table of contents:

Performance Lab

I've been a WordPress core committer for over 10 years, and since Spring 2023 I've been heavily involved on the Core Performance Team. In addition to contributing patches directly to the WordPress core codebase, we also develop new performance optimizations in the form of feature plugins. We use our Performance Lab plugin as a way to collect the feature plugins we're currently working on to facilitate discovery:

Most of these performance feature plugins are developed in the WordPress/performance monorepo on GitHub. In the same way as the Gutenberg plugin serves as a way to develop new editor features, the Performance Lab plugin is a way we incubate new performance features. It allows us to get feedback from users and test the impact prior to being proposed for merging into a new release of WordPress core when it gets rolled out to ~43% of the web.

Case Study: Twenty Twenty-Five

The default theme for the current version of WordPress is Twenty Twenty- Five. Default themes in core basically encapsulate the latest and greatest in what WordPress has to offer in terms of features and performance. Indeed, block themes are generally faster than classic themes (especially with page caching) for a few reasons, including:

• Scripts and styles are selectively loaded based on whether their blocks actually used on the page.
• Blocks are more likely to use the Interactivity API which involves deferred script modules (which don't block rendering) and server-side rendering.

So the Twenty Twenty-Five theme should be very fast, and indeed it is. But with Performance Lab features (and beyond), it can be made even faster.

Your mileage will vary with other themes, either having an even greater impact or a lesser one. Every site is unique (hopefully!) and so the impact of optimizations depends on a page's contents, how a theme is built, and which plugins are active. But in this post, I'll show the impact of the optimizations in various page layouts of the Twenty Twenty-Five Theme.

Performance Testing Methodology

Perhaps the most popular way to analyze the performance of a webpage is to use Lighthouse, either in Chrome DevTools or via the bottom half of PageSpeed Insights. Lighthouse allows you to test pages either as a desktop or mobile device, emulating the viewport, CPU, and connection speed. Lighthouse is an important tool to get a sense of a page's performance, but it has limitations. It captures data from a single page load on a simulated device. There is often variability in the results, and it also doesn't reflect the experience of real users which is what you'd get from Real User Monitoring (RUM), such as in the Chrome User Experience Report (CrUX)-shown in the first section of PageSpeed Insights. Lighthouse provides simulated lab data whereas CrUX provides real field data, which is more accurate. Nevertheless, field data can take a long time to collect and it can be difficult to do A/B tests at scale to capture the before/after performance impacts. That said, CrUX is definitely used to track the performance of new WordPress releases overall, as Felix Arntz shared the WordPress performance impact on Core Web Vitals in 2023. Felix also wrote up how to conduct WordPress performance research in the field.

For the purposes of measuring the impact of performance optimizations here, lab data will be more practical because the results are available in real time, without having to wait for real users to provide field data. And I'm interested in relative performance impacts, not necessarily absolute ones.

Running a Lighthouse audit before and after a Performance Lab feature plugin is active is a way to measure the impact of the optimization. However, given variability in the results, it can be difficult to be certain of the improvement. A Lighthouse audit may no longer flag an area for improvement, but the overall Lighthouse score may be unchanged. Indeed, even a Lighthouse score of 100 doesn't mean the page performance is "perfect". As found by Brendan Kenny:

Of the pages that got a 90+ in Lighthouse in September [2021], 43% didn't meet one or more CWV threshold.

A great score-even 100-doesn't mean there still isn't a lot of room for improvement!

Largest Contentful Paint

One of the main components in calculating Lighthouse's Performance score is the Largest Contentful Paint (LCP) metric of Core Web Vitals (CWV). LCP metric is weighted at 25% of the total Lighthouse score. As noted in how how Lighthouse scores are determined:

The metric value for LCP represents the time duration between the user initiating the page load and the page rendering its primary content. Based on real website data, top-performing sites render LCP in about 1,220ms, so that metric value is mapped to a score of 99.

A 1.2 second LCP is 12 times slower than a 100 ms LCP, where 100 ms is a proposed threshold for the user to perceive a reaction as being instantaneous. Nevertheless, a "good" LCP value is 2.5 seconds and below:

The LCP metric can be further subdivided, with the first part represented by the Time To First Byte (TTFB) metric. The longer it takes the server to respond with the generated HTML document, the more this will hurt the LCP metric. A slow TTFB means you are less likely to have a good LCP. If a site has a 1.5-second TTFB which needs improvement, then this leaves only 1 second for the LCP element to be rendered to get a good LCP metric. A good TTFB is considered to be about half that, at 800 ms and below:

Unfortunately, in looking at HTTP Archive's Tech Report, as of July 2025, only 31% of desktop clients visiting WordPress sites experience a good TTFB, whereas it's just 24% for mobile clients. This means it is all too likely that a 1.5-second TTFB is the norm for WordPress sites. This is in part what contributes to WordPress lagging behind most other CMSes for the LCP metric on mobile and on desktop, even about 10% below the average on all measured sites.

In comparison with the other CWV metrics-Cumulative Layout Shift (CLS) and Interaction to Next Paint (INP)-WordPress is doing worse in terms of LCP, as evident in the metric passing rates from the following reports on HTTP Archive:

Therefore, improving LCP remains the most important focus for performance optimizations in WordPress. So in this post I'll focus on the LCP impact for the plugins featured in Performance Lab and some other changes proposed for WordPress 6.9.

Benchmarking

Because the Lighthouse score is variable and a 100 score merely reflects a "good" LCP, evaluating the performance benefit of an optimization requires measuring the LCP metric itself. Due to the variability in the metric, it's important to obtain the median value of the LCP over many measurements. By capturing the median LCP value before and after an optimization is applied, the relative impact on performance can be measured.

The tool I use for benchmarking LCP is in the GoogleChromeLabs/​wpp-research repo, which my team developed when I was at Google. Specifically, I use the benchmark-web-vitals command which includes the ability to emulate mobile and desktop devices, network connections, and CPU speeds.

Here's an example command I use to benchmark two URLs emulating a mobile device on a Fast 4G connection, and compare their results:

npm run research -- benchmark-web-vitals \
        --url="http://localhost/?enable_plugins=none" \
        --url="http://localhost/?enable_plugins=foo" \
        --number=50 \
        --network-conditions="Fast 4G" \
        --emulate-device="Moto G4" \
        --diff \
        --output=md

<?php
/**
 * Plugin Name: Active Plugins Override
 */

namespace ActivePluginsOverride;

function get_always_active_plugins(): array {
        return array(
                'user-switching/user-switching.php'
        );
}

add_filter(
        'option_active_plugins',
        static function ( $plugins ) {
                return array_unique( array_merge( $plugins, get_always_active_plugins() ) );
        },
        100
);

if ( isset( $_GET['disable_all_plugins'] ) || ( isset( $_GET['enable_plugins'] ) && $_GET['enable_plugins'] === 'none' ) ) {
        add_filter( 'option_active_plugins', '__return_empty_array' );
}

if ( isset( $_GET['disable_plugins'] ) ) {
        if ( is_array( $_GET['disable_plugins'] ) ) {
                $disable_plugins = $_GET['disable_plugins'];
        } else {
                $disable_plugins = explode( ',', $_GET['disable_plugins'] );
        }

        add_filter(
                'option_active_plugins',
                function ( $active_plugins ) use ( $disable_plugins ) {
                        return array_merge(
                                array_filter(
                                        $active_plugins,
                                        function ( $active_plugin ) use ( $disable_plugins ) {
                                                $slug = strtok( $active_plugin, '/' );
                                                return ! in_array( $slug, $disable_plugins );
                                        }
                                ),
                                get_always_active_plugins()
                        );
                }
        );
}

if ( isset( $_GET['enable_plugins'] ) ) {
        if ( is_array( $_GET['enable_plugins'] ) ) {
                $enable_plugins = $_GET['enable_plugins'];
        } else {
                $enable_plugins = explode( ',', $_GET['enable_plugins'] );
        }

        if ( count( array_intersect( $enable_plugins, array( 'embed-optimizer', 'image-prioritizer' ) ) ) > 0 ) {
                $enable_plugins[] = 'optimization-detective';
                $enable_plugins[] = 'od-admin-ui';
        }

        add_filter(
                'option_active_plugins',
                function ( $active_plugins ) use ( $enable_plugins ) {
                        return array_filter(
                                $active_plugins,
                                function ( $active_plugin ) use ( $enable_plugins ) {
                                        $slug = strtok( $active_plugin, '/' );
                                        return in_array( $slug, $enable_plugins );
                                }
                        );
                }
        );
}

This results in a table like the following, showing the median metrics for the number of requests to both URLs:

In this example, the LCP improved by ~25% by enabling the "foo" plugin, which is exactly the kind of performance improvement we're looking for on the Core Performance Team. Note this "LCP-TTFB" metric is simply the LCP metric minus the TTFB metric; this allows for measuring the client-side contributions to LCP by discounting any server-side variability in generating the response. The LCP-TTFB metric is important considering the lack of page caching on a local environment, and that certain optimizations may increase TTFB when page caching is not involved. For WordPress to scale, it's important to have some page caching layer in place.

Analyzing Optimization Impact on LCP

I'm going to analyze the impact of the following feature plugins featured in Performance Lab:

• Image Placeholders
• Modern Image Formats
• Enhanced Responsive Images
• Image Prioritizer
• Speculative Loading
• View Transitions

I'm not covering Performant Translations since it was mostly merged into core as of 6.5. I'm also not covering Embed Optimizer since it primarily helps with INP by lazy-loading and CLS by reserving space for resizing embeds; the LCP improvement is difficult to measure for embeds that appear in the initial viewport given their cross-origin nature. Lastly, I'm not covering Web Worker Offloading since it is quite experimental and it is only related to INP. However, I am going to cover enhancements beyond Performance Lab being targeted for WordPress 6.9:

• No-cache BFCache (actually, brand new to Performance Lab)
• Script Module Deprioritization
• Minified CSS Inlining

The first four Performance Lab feature plugins are all related to images. In focusing on improving the LCP metric, this makes sense because images are the LCP element 73.3% of the time on mobile and 83.3% of the time on desktop, according to Web Almanac 2024:

Image Placeholders

The Image Placeholders plugin, originally called "Dominant Color Images", adds a non-transparent image's dominant color as the background color. This improves the perceived page loading experience by showing something sooner, rather than just a blank spot on the page.

Instead of this:

With the plugin active (and the media regenerated), the following is the result:

The visual impact that this plugin has on the loading of the page is that there is a brown rectangle serving as a placeholder for where the user can expect an image to load.

However, when benchmarking the web vitals, there is no improvement in LCP. In fact, there even appears to be a slight regression:

npm run research -- benchmark-web-vitals \
        --url="https://wcus-perf-talk-demo.local/2025/07/30/bison-featured-image/?enable_plugins=none" \
        --url="https://wcus-perf-talk-demo.local/2025/07/30/bison-featured-image/?enable_plugins=dominant-color-images" \
        --number=250 \
        --network-conditions="Fast 4G" \
        --emulate-device="Moto G4" \
        --diff \
        --output=md

Moreover, there is no difference in the Lighthouse performance score which is already maxed out at 100 (but again, this doesn't mean perfection). Nevertheless, just because there is no improvement on the raw performance metric, this doesn't mean there isn't value in doing it. User-perceived performance is also important, as long as it doesn't negatively impact LCP (which should hopefully not conflict). We'll revisit this later with View Transitions.

Modern Image Formats

Modern image formats, like WebP and AVIF, are able to compress much higher compared to older formats like JPEG and PNG. For example, an image compressed with AVIF could be 50% smaller than a JPEG with similar visual quality. It stands to reason that if an image is smaller, then it will take less time to download, and the LCP metric will be improved since the image can render sooner. This also addresses a common audit you encounter in Lighthouse to serve images in next-gen formats:

Note that the audit here estimates that the image in a modern image format would be 54% smaller for this image. (Note also the shameless plug for Performance Lab thanks to the Stack Pack for WordPress.)

The Modern Image Formats plugin (originally called "WebP Uploads") addresses this audit's complaint by converting uploaded images into AVIF or WebP, depending on which is available on your server. With the plugin active, the original Bison image uploaded as a JPEG is compressed from 356 KB down to 292 KB in AVIF format. This is ~18% smaller, not the hoped-for ~50% reduction in file size. Nevertheless, will this yield a 18% improvement in LCP? Here are the results of testing the same page as when testing Image Placeholders above, a post where the featured image is the LCP element:

npm run research -- benchmark-web-vitals \
        --url="https://wcus-perf-talk-demo.local/2025/07/30/bison-featured-image/?enable_plugins=none" \
        --url="https://wcus-perf-talk-demo.local/2025/07/30/bison-featured-image/?enable_plugins=webp-uploads" \
        --number=50 \
        --network-conditions="Fast 4G" \
        --emulate-device="Moto G4" \
        --diff \
        --output=md

So while the image file size was reduced ~20%, the LCP improvement here was only ~2%.

Brendan Kenny's article on Common Misconceptions About How to Optimize LCP shows that among the LCP sub-parts, the TTFB and "image load delay" contribute much more to the overall time compared with actually downloading the image resource. (Also described in Web Almanac.) Remkus de Vries has likewise emphasized that we should Stop Obsessing Over Image Optimization. We absolutely shouldn't be serving 10 MB images to visitors, but there are diminishing returns for optimizing LCP with each percentage reduction in an image's file size. There are far more impactful ways to improve LCP than to use the most optimal image compression.

Thanks to Adam Silverstein for championing support for modern image formats both in this plugin and in core!

Enhanced Responsive Images

The Enhanced Responsive Images plugin was originally developed as a way to automatically add sizes=auto for images with loading=lazy. This new part of the HTML spec lets the browser compute the responsive sizes because lazy-loaded images are loaded after the page has been laid out. This enhancement landed in WordPress 6.7. Since then, the scope of the plugin has changed to improve the calculation of the responsive sizes attribute for images which are not lazy-loaded.

By default, WordPress uses the same formula for constructing the default sizes attribute for all images. For example, if an image is 1024 pixels wide, then the sizes attribute is set to:

(max-width: 1024px) 100vw, 1024px

This is problematic, however, because if the image takes up half the width of the screen, then the browser will select the image URL from the srcset attribute for the size corresponding to the width of the viewport, not the width of the actual IMG element. This is often fine on mobile when images are more often taking up the full page width, but on desktop viewports it means a much larger image will be downloaded than is appropriate for the container size. For example, consider these images in a Columns block (sourced from Wikipedia, as linked):

These images were all resized to be 1024 pixels wide, and so using the default WordPress scheme, they all have the same sizes attribute (as shown above), in spite of the fact that the first IMG element is twice the width of the second and third, and 1024px itself is about double the entire 645px width of the root Columns block on desktop.

In Lighthouse, the properly size images audit correctly identifies these images as having inaccurate sizes:

On my test page, this Columns block is at the beginning of the content, so none of the IMG tags are lazy-loaded and likewise none are eligible for auto-sizes. This is where the enhanced Enhanced Responsive Sizes plugin comes in. Now that auto-sizes was merged into core, the plugin's scope has changed to improve the accuracy of the sizes attribute by using the structured layout information available in block themes (which is not available in classic themes). With this plugin active, the width in the sizes attribute for the IMG in the first column reduces from 1024px down to 429px:

(max-width: 429px) 100vw, 429px

And the two smaller IMG tags in the second narrower column get reduced from 1024px down to 134px:

(max-width: 134px) 100vw, 134px

Here is the performance impact when benchmarking the change:

npm run research -- benchmark-web-vitals \
        --url="https://wcus-perf-talk-demo.local/2025/07/31/bison-two-columns/?enable_plugins=none" \
        --url="https://wcus-perf-talk-demo.local/2025/07/31/bison-two-columns/?enable_plugins=auto-sizes" \
        --number=50 \
        --network-conditions="Fast 4G" \
        --emulate-device="Moto G4" \
        --diff \
        --output=md

This has a dramatic ~25% reduction in LCP!

This also has an improvement in the Lighthouse score for this example page, whereas I did not find an improvement when testing the previous plugins.

The optimization also greatly improved the properly size images audit, before and after:

Note that this audit is unlikely to ever pass completely unless you generate many more intermediate image sizes to better fit all possible dimensions for your responsive images. This is something that an image CDN could do for you, however.

The effect of the more accurate sizes can be is evident in which intermediate image size files get downloaded:

	Before	After	Reduction
	2048×1336	1024×668	-75%
	2048×1483	300×217	-98%
	2048×1413	300×207	-98%
Total:	8,667,136px	811,232px	-91%

In this test of images in a Columns block, what follows is the impact of Modern Image Formats with AVIF versus Enhanced Responsive Images with more accurate sizes, and then with them both active together:

As is evident, the use of a more accurate sizes attribute has three times the reduction in bytes compared with using the AVIF image format (87% vs 29%)! Adding AVIF on top of the better sizes only yields an additional 2% reduction in transferred bytes in this example. It's no wonder why Enhanced Responsive Images has a greater impact on LCP compared with Modern Image Formats!

Props to Mukesh Panchal and Joe McGill for their work on this! Joe also first proposed the original sizes attribute.

Image Prioritizer

The last Performance Lab feature plugin which focuses on images is Image Prioritizer. As indicated by the name, the plugin optimizes image loading prioritization. For example, it boosts the priority of the detected LCP image with fetchpriority=​high while also deprioritizing the loading of images outside the viewport with lazy-loading. This plugin depends on the Optimization Detective plugin as its framework for the optimizations it applies. I gave a talk at WordCamp Asia 2025 all about this plugin:

In that talk, I cover Image Prioritizer in depth; the plugin description also has the full list of optimizations. But I'll highlight here a couple of the most impactful optimizations which improve the LCP metric for images.

Responsive Image Prioritization

Take for example this gallery of three images (again, from Wikipedia as linked):

This gallery is configured without the "Crop images to fit" setting enabled. On desktop, the second image is the largest image of the three, and so it is the LCP element. However, on mobile it's actually the third image which is the largest (and the LCP element) since it appears on a row by itself:

Nevertheless, WordPress core adds fetchpriority=​high to the first IMG, of the bison and calf, even though it is never the LCP element. WordPress adds the fetchpriority attribute to the first sufficiently-large image it finds on the page, making a best guess as to which is the LCP element. But even when core does add the attribute to the right image on a desktop viewport, it could be wrong for mobile, and vice versa. In my research, when WordPress core correctly adds the fetchpriority attribute to the LCP IMG element on desktop or mobile, I found that 37% of those pages have a different IMG which is the LCP element for the other viewport. This means it's only safe to use the fetchpriority attribute on IMG tags when they are the LCP element on both desktop and mobile (and tablet too). But WordPress doesn't know how the page is laid out (although this is starting to change in the case of block themes, as with Enhanced Responsive Images above). This is where Optimization Detective comes in.

The Optimization Detective plugin provides a framework to capture measurements from site visitors about what elements are displayed on a page across a variety of device form factors and responsive breakpoints (e.g. desktop, tablet, and mobile). These measurements are stored in "URL Metrics" (a custom post type) which can then be used by extensions, like Image Prioritizer, to apply more accurate optimizations. In this case, Image Prioritizer:

1. Removes fetchpriority=​high from the first IMG in the Gallery.
2. Adds responsive preload LINK tags for the actual LCP element based on media queries.

For example, the following LINK tags are added to the page:

<link
 rel="preload" as="image" fetchpriority="high"
 href=".../bison-2.jpg"
 imagesrcset="..." imagesizes="..."
 media="screen and (width <= 480px)"
>
<link
 rel="preload" as="image" fetchpriority="high"
 href=".../bison-3.jpg"
 imagesrcset="..." imagesizes="..."
 media="screen and (782px < width)"
>

Note how the first LINK preloads the second bison image on mobile, but the second LINK preloads the third bison image on desktop. Here is the performance impact for these changes on mobile:

npm run research -- benchmark-web-vitals \
        --url="https://wcus-perf-talk-demo.local/2025/08/04/bison-gallery/?disable_all_plugins" \
        --url="https://wcus-perf-talk-demo.local/2025/08/04/bison-gallery/?enable_plugins=image-prioritizer" \
        --number=50 \
        --network-conditions="Fast 4G" \
        --emulate-device="Moto G4" \
        --diff \
        --output=md

This is the biggest LCP improvement I've yet shown, with a 27.5% reduction compared with the 24.5% improvement in Enhanced Responsive Images. This shows up as an improvement in the Lighthouse performance score, increasing from 95 to 99:

But what becomes truly impressive are the results on desktop:

The LCP improvement here on desktop is almost double the improvement on mobile, at an over 50% reduction in LCP! In other words, the LCP metric is cut in half! This shows impressively in the Lighthouse performance score increasing from 93 to 100:

Background Image Prioritization

Related to there being different LCP IMG elements on desktop versus mobile is that the LCP element's image may not be an IMG at all, but rather a DIV (or some other element) with a CSS background-image. This is a very common way that imagery is added in page builders. Background images are also present in WordPress core, such as in some classic themes' header images; background images are also on any WordPress site using the Cover block when using a fixed background or when adding a background image to a Group block. The prevalence of non-IMG LCP images is captured in this data presented in Web Almanac 2022, showing that the DIV (presumably with a background image) is the LCP element ~26% of the time compared with an IMG at 42% of the time:

The problem with the background-image style is that it is CSS: there is no way for core to attach a fetchpriority=​high HTML attribute as can be done for LCP IMG candidates. Take the following page for example, where there is a parallax Cover block at the beginning of the content, followed by some paragraphs of text, and finally a Gallery block with five images in it. The black rectangle denotes the desktop viewport:

Cover image courtesy Gintare K. on Pexels. Other previously-unused images courtesy Wikipedia: 1, 2, 3.

The DIV in the Cover block with the CSS background-image is the LCP element. Nevertheless, WordPress core is adding fetchpriority=​high to the first IMG in the Gallery block because it is the first sufficiently large image, just in terms of its width and height attributes. Additionally, WordPress core omits loading=lazy from the first three content images (the first three images in the Gallery), but they are not even visible on either the desktop or mobile viewports. The effect here is that the first three images of the Gallery are all loaded first before the all-important background image for the Cover block. Image Prioritizer fixes this by:

1. Removing fetchpriority=​high from the first IMG in the Gallery, since it is not the LCP element.
2. Adding loading=lazy to the first three IMG tags in the Gallery, since none of them are visible in any initial viewport.
3. Adding a preload LINK for the CSS background-image so that it is properly prioritized.

The preload LINK looks like the following:

<link
 rel="preload"
 as="image"
 fetchpriority="high"
 href=".../bison.jpg"
 media="screen"
>

Unlike with the responsive image prioritization, the Cover block here is the LCP element for both desktop and mobile, so here there is only one LINK and the media attribute doesn't need to add any viewport constraints.

Here is the performance impact:

npm run research -- benchmark-web-vitals \
        --url=https://wcus-perf-talk-demo.local/2025/08/04/cover-block/?disable_all_plugins \
        --url=https://wcus-perf-talk-demo.local/2025/08/04/cover-block/?enable_plugins=image-prioritizer \
        --number=50 \
        --network-conditions="Fast 4G" \
        --emulate-device="Moto G4" \
        --diff \
        --output=md

This is the second-best improvement to LCP I've shown here in analyzing these plugins. The Lighthouse performance score is also improved from 92 to 99:

Surely nothing can improve LCP more than what was achieved here with the Image Prioritizer plugin, right? Read on.

Speculative Loading

The Speculative Loading plugin is the first discussed here not specifically focused on improving LCP for images, although they do benefit. This was a feature plugin actually to bring the Speculation Rules API to WordPress core, which was merged in 6.8. This API allows pages to either:

• Prefetch a link, reducing TTFB to zero.
• Prerender a link, potentially reducing LCP to zero.

As such, Speculative Loading is somewhat cheating at performance because you can't get any faster at loading something than to have it already loaded.

The degree by which TTFB and LCP are improved is largely dependent on the "eagerness" of the speculation. There are three main eagerness values for when speculation starts:

• Conservative: when you pointer-down on a link.
• Moderate: when you hover over a link (or soon on mobile when a link is in the viewport).
• Eager: right away without any user interaction.

For the initial core merge, the default cautious configuration was to use prefetch with conservative eagerness. Conservative eagerness was to avoid unused speculations which can overly tax under-powered servers, and prefetching was to avoid potential compatibility issues with prerendering, such as with analytics or ads.

Here's the impact that the various configurations of Speculative Loading have on LCP:

Navigation with prerendering results in a practically instantaneous page load with a near zero LCP! In all these cases the LCP is still considered "good" at being less than 2.5 seconds, but just because something is good doesn't mean it can't be better!

Note that the test page here adds a 1 second TTFB via sleep(1). This reflects a fairly typical server response time considering that only a quarter of WordPress sites have a good TTFB passing rate, which is 800 ms and faster.

Props to Felix Arntz for spearheading this feature and landing it in core.

View Transitions

As described in the previous example, page navigations with Speculative Loading can be nearly instant with prerendering. This is great, but it's almost too good. The navigation can feel so instant as to be abrupt. There can also be a white flicker between the page loads. To help in part with having too much of a good thing, the newest plugin to be featured in Performance Lab is View Transitions. There is a new web platform feature for cross-document view transitions for multi-page applications, and this plugin brings these smooth page navigation animations to WordPress. With Speculative Loading and View Transitions, navigating around a regular multi-page WordPress site can feel as fluid as a single-page app (and without all the implementation complexity).

Take a look at the impact on the user experience when navigating between the homepage and a blog post:

Note that these view transitions apply not only when navigating via links, but they also apply when navigating with the back/forward buttons in the browser:

Nevertheless, as nice as these cross-document view transitions are, do note that there is no LCP improvement to using them. As referenced previously with Image Placeholders, the View Transitions plugin provides a non-performance user experience improvement. So don't expect to find any difference in your Lighthouse scores or LCP passing rates with this plugin.

Props again to Felix Arntz for spearheading this feature plugin.

No-cache BFCache

Originally, the No-cache BFCache plugin was part of the "beyond" part of my talk because it wasn't among the plugins featured by Performance Lab. However, this is no longer the case since v4.0.0. In the previous section about Speculative Loading, I showed how prerendering enabled near instant page loads with practically zero LCP. But there is a much older browser technology for instantaneous page navigations: the back-forward cache (bfcache). This was also depicted above in the back/forward navigation videos with view transitions.

I wrote up a blog post already all about bfcache and this plugin:

To recap, webpages are generally not eligible for bfcache when they are served with Cache-Control: no-store. This header is sent when a user is logged-in and often on e-commerce sites for the shopping cart, checkout, and account pages. While it importantly prevents such pages from being cached by proxies, it also prevents the browser from storing pages in bfcache. This plugin removes the no-store directive. In its place, it ensures that the private directive is sent to prevent proxies from caching the response; also, to ensure preserve privacy after logging out, it includes logic to invalidate pages from the bfcache so they cannot be re-accessed.

What follows is an example of a site running Twenty Twenty-Five with the BuddyPress plugin and Slow 4G network emulation. After entering an activity status update, I navigate from the Personal tab to the Mentions and Favorites tabs. Then I use the back button to go back to the Personal tab. Without bfcache, navigating back from the Favorites tab to the Personal tab is very slow since (1) the browser has to re-fetch the HTML from the server, and (2) the DOM has to be completely reconstructed. Without bfcache, there is also the unfortunate result that the drafted status update is lost, since the form field was re-constructed with JavaScript. In contrast, when bfcache is enabled, navigating to the previous tabs is instant, and the DOM is preserved with each navigation, resulting in the drafted status update being kept intact:

Without bfcache, the back navigation has an LCP of 1.41 seconds whereas with bfcache the LCP is 0.02 seconds: nearly instantaneous.

There are other reasons why pages may be ineligible for bfcache than the no-store directive, but it is one of the most common causes. It's very important to try to preserve bfcache eligibility because back/forward navigations are very common on the web:

Chrome usage data shows that 1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.

Script Module Deprioritization

Moving on from instant page loads with Speculative Loading and bfcache, another way to shave off milliseconds on the LCP metric is to reduce network contention for loading the LCP element resource (e.g. an image). Consider a template with an Image block and a Navigation block, where the Image block has a lightbox and the Navigation block expands on mobile. These blocks use the Interactivity API which involves adding script modules to the page with the necessary logic. As noted previously, one of the key design principles of the Interactivity API is server-side rendering. This means that by design the Navigation block and the Image block do not need their script modules in the critical rendering path.

It turns out that these script modules are currently loaded with high priority because the browser doesn't know they aren't critical. So they compete with the loading of critical resources, like the LCP image, even though script modules aren't render blocking.

I've written a separate post all about this problem and the solution:

To summarize, there are two ways to prevent script modules from delaying the loading of critical resources:

1. Add fetchpriority=​low to the SCRIPT module tags and the modulepreload LINK.
2. Move the SCRIPT tags to the end of the BODY (the footer).

Here are the results of these optimizations on an emulated broadband connection with an IMG as the LCP element:

This is a healthy LCP improvement, more impactful than using the Modern Image Formats with the AVIF format in my testing above. There are two plugins available on GitHub which implement these optimizations while waiting for them to be available in core:

• Script Fetch Priority Low (cf. #61734)
• Script Modules in Footer (cf. #63486)

Minified CSS Inlining

The final optimization I'm analyzing is the impact of eliminating render-blocking external stylesheets. With JavaScript, adding defer to a SCRIPT is an easy way to prevent them from blocking rendering (assuming they can be deferred). However, this is not so easy to do with external stylesheets. CSS is always render-blocking because otherwise there is a flash of unstyled content (FOUC). The web platform does not (currently) provide an official way to opt in to async CSS. Instead, the best way to handle this is to inline the CSS in STYLE tags (at least for the critical CSS).

On a vanilla WordPress install when loading the Sample Page, where the LCP element is text, there are two render-blocking stylesheets:

• The Navigation block's style.min.css
• The Twenty Twenty-Five theme's style.css

Despite these render-blocking stylesheets, Lighthouse is giving the page a 100 performance score. But as I've said before, just because you have a 100 score in Lighthouse, this doesn't mean you can do more. Even with a perfect Lighthouse score, there is actually an audit that is pointing out the performance problem: Eliminate render-blocking resources.

It's strange that this audit has an overall estimated savings of zero milliseconds, but for the theme's stylesheet it shows an estimated savings of 150 milliseconds.

To inline these two stylesheets to prevent them from being render-blocking, what is needed is to:

1. Opt in to inline the (minified) theme's style.css.
2. Increase the styles_inline_size_limit.

To inline Twenty Twenty-Five's stylesheet, all that is required is to add the path data for where the registered style is located on the filesystem. This can be done as simply as follows:

add_action(
        'wp_enqueue_scripts',
        function (): void {
                wp_style_add_data(
                        'twentytwentyfive-style',
                        'path',
                        get_parent_theme_file_path( 'style.css' )
                );
        },
        20
);

However, since the stylesheet is not yet minified (cf. #63012), you can hack in runtime minification using a plugin like Twenty Twenty-Five Stylesheet Inlining. This plugin is currently just in a Gist since I hope this will land soon in core for 6.9 via #63007.

To increase the limit for inline CSS, all that is needed is a simple filter. The default limit is 20 KB which seems low considering the inline CSS limit for an AMP page is 75 KB. To increase the limit to 30 KB which allows enough room for the Navigation block's relatively stylesheet to be inlined, you can use this PHP code:

add_filter(
        'styles_inline_size_limit',
        function (): int {
                return 30000;
        }
);

<?php
/**
 * Plugin Name: Increase Styles Inline Size Limit (styles_inline_size_limit)
 * Author: Weston Ruter
 * Update URI: false
 */
add_filter(
        'styles_inline_size_limit',
        static function (): int {
                $limit = -1;
                if ( isset( $_GET['styles_inline_size_limit'] ) ) {
                        $limit = (int) $_GET['styles_inline_size_limit'];
                }
                if ( $limit < 0 ) {
                        $limit = 75000;
                }
                return $limit;
        }
);

Increasing this limit in core is being tracked in #63018. We still need to determine the optimal threshold for inlining, weighing against the benefits of serving stylesheets from the browser cache for subsequent page navigations.

As for the performance impact of inlining these stylesheets, here are the results for the loading Sample Page on an emulated Fast 4G connection:

npm run research -- benchmark-web-vitals \
        --url="https://wcus-perf-talk-demo.local/sample-page/?enable_plugins=twentytwentyfive-stylesheet-inlining" \
        --url="https://wcus-perf-talk-demo.local/sample-page/?enable_plugins=twentytwentyfive-stylesheet-inlining,increase-styles-inline-size-limit.php&styles_inline_size_limit=30000" \
        --number=50 \
        --network-conditions="Fast 4G" \
        --emulate-device="Moto G4" \
        --diff \
        --output=md

This decreases the LCP by over a third!

And here are the results when emulating a Slow 3G connection:

npm run research -- benchmark-web-vitals \
        --url="https://wcus-perf-talk-demo.local/sample-page/?enable_plugins=twentytwentyfive-stylesheet-inlining" \
        --url="https://wcus-perf-talk-demo.local/sample-page/?enable_plugins=twentytwentyfive-stylesheet-inlining,increase-styles-inline-size-limit.php&styles_inline_size_limit=30000" \
        --number=50 \
        --network-conditions="Slow 3G" \
        --emulate-device="Moto G4" \
        --diff \
        --output=md

A 44.4% reduction in LCP is on par with the largest improvements achieved by the Image Prioritizer plugin in my evaluations here. This means that on a Slow 3G connection, the LCP goes from poor at 4.31 seconds to good at 2.38 seconds.

What's Next

My hope is that several of these improvements will land later this year in WordPress core. Some of them are tracked in the Roadmap to 6.9:

Planned performance improvements include improving Data Views performance by supporting partial entity fetching and smart field resolution, adding the ability to handle "fetchpriority" to ES Modules and Import Maps, standardizing output buffering so developers can hook into a unified filter and manipulate the entire rendered HTML after it's generated but before it's sent to the browser (e.g. for page caches and performance optimizations), implementing instant page navigations from browser history via bfcache even when pages are flagged with "nocache" such as when users are logged in, and stylesheet improvements around minification and inlining.

You can get involved with the Core Performance Team to help make this happen!

Where I've shared this, if you want to discuss or boost:

• LinkedIn
• Bluesky
• Twitter
• Mastodon
• Threads

The post The Site Speed Frontier with Performance Lab and Beyond appeared first on Weston Ruter.

27 Aug 2025 6:05pm GMT

এই নিবন্ধটি বাংলায় পাওয়া যায়

Beginnings

My story with WordPress began in a classroom. I was a student working on a simple project, a portfolio website. I wanted to use WordPress because it felt easy to learn and flexible enough to build what I had in mind. I completed the project and proudly showed it to my teacher.

Instead of encouragement, I was told to scrap it. "Do it with raw PHP coding," my teacher said. WordPress was dismissed as the easy way out. At the time, that felt discouraging. I followed instructions and rewrote everything in PHP, but the memory stayed with me.

What my teacher could not see was what I had already discovered. WordPress had opened a door. It gave me confidence that I could build something meaningful with the skills I had. That moment became a seed. It was the beginning of a path that would later shape my career, my community work, and my life.

Learn

In 2016, I joined weDevs. This was my first real step into the professional WordPress ecosystem. Products like Dokan and WP User Frontend were not just plugins. They were solutions that empowered people. Dokan made it possible for anyone to create a multi-vendor marketplace without needing deep technical knowledge. WP User Frontend gave site owners control from the frontend in a way that felt natural and accessible.

Then came WP ERP. This plugin fascinated me more than anything else at that time. The idea that WordPress could run HR, CRM, and accounting for a business was almost unbelievable. For me, it was proof that WordPress is like water. It can take any form. It can flow into any gap and solve almost any problem.

Later, I worked with newer products, including ElementsKit, MetForm, ShopEngine, GetGenie AI, which now powers more than 2 million websites around the world. Over the years, I built an 8-year career in WordPress product marketing, working with multiple global companies to grow their eCommerce, LMS, SaaS, and WordPress products.

But my learning did not stop there. Coming from a computer science background, I shifted into marketing. At first, I wasn't sure I belonged in this space. But I discovered that having the knowledge of algorithms, logic, and technical systems helped me become a better marketer. It allowed me to solve business problems more effectively and to connect with product teams in a way that bridged technical and user needs. That blend of skills became my advantage.

As Shakespeare wrote, "To be or not to be, that is the question." For me, the answer has always been to be-to be curious, to be adaptable, and to be willing to learn. Or in the words of Bruce Lee, "Be water, my friend." That is what WordPress has taught me. Adapt, flow, and find your form.

Connect

In 2017, I organized my first WordPress meetup. It was a small gathering, but the energy in the room was undeniable. People came together to share, to teach, to learn, and to encourage each other. That was when I saw the true strength of WordPress. It was not just software. It was a community.

From that point on, I made community a core part of my life. Meetups turned into WordCamps. I spoke at events. I volunteered wherever I could. And I attended as many gatherings as possible. To date, I have been part of 25 WordCamps around the world. Each one gave me new lessons, friendships, and a sense of belonging.

The first time I spoke at WordCamp Kathmandu 2019, I was nervous. I had fixed what I would say but my heart was racing. I kept thinking, "What if nobody listens? What if I fail?" When I walked onto the stage and looked at the audience, something changed. I saw faces eager to learn. I realized they were not there to judge me. They were there to grow with me.

It was a panel discussion where I sat together with my mentor, M Asif Rahman, and we discussed marketing WordPress products. That panel discussion gave me confidence I had never felt before. It showed me that sharing what you know, even if it feels small, can inspire others. After that, I participated in two other panel discussions: WordCamp Nagpur in 2022 and WordCamp Sylhet in 2024.

Over the years, I have served as a WordCamp Organizer, Speaker, Volunteer, Global Mentor, and Event Supporter. I mentored teams as they organized their first WordCamps, helping them overcome challenges and celebrate success. These connections showed me that WordPress is not just a platform to build websites. It is a platform to build people. It gives us the tools, but more importantly, it gives us the relationships that carry us forward.

In 2022, I was humbled to receive the Yoast Care Fund award for my community contributions. It reminded me that the efforts we give to the community, often behind the scenes, do not go unnoticed.

Contribute

With learning and connection came responsibility. I knew I had to contribute.

Contribution takes many forms. For me, it has been about building communities, mentoring, and supporting events. I have served as a WordCamp Mentor and Global Event Supporter, helping new organizers take their first steps. I have guided teams, answered their questions, and encouraged them through the challenges of organizing. Seeing them succeed gave me joy that no personal achievement could replace.

WordCamp Asia holds a special place in my heart. I have been part of its organizing team three times so far, including working with the AX and communications teams. It was a chance to tell stories, welcome attendees, and celebrate the diversity of Asia's WordPress community.

When I joined the organizing team for the first WordCamp Asia in 2022, it felt like stepping into history. This was the first flagship WordCamp in our region, and expectations were sky high. I worked on the AX team, helping to provide an amazing experience to the attendees. There were long nights, endless discussions, and moments of uncertainty. But when the doors opened and thousands of people gathered, it was worth it. That event showed me how powerful Asia's WordPress community had become. It was proof that our voices, our energy, and our contributions mattered on a global scale.

Since then, I continued serving as part of WordCamp Asia 2023 and 2025, and later joined the organizing team of WordCamp US 2025, one of the biggest WordPress events in the world. Being part of that team was a reminder that no matter where we come from, our contributions connect us on a global scale.

In 2025, I was also honoured to be selected as a recipient of the Automattic Open Horizons Scholarship, which supports contributors from underrepresented communities in continuing their WordPress journey.

At the same time, I am pursuing a PhD in marketing, researching Agile Marketing Methodologies for Promoting Digital Software Products. For me, this connects directly to WordPress. Agile and AI-driven methods are shaping how we market plugins, SaaS platforms, and digital tools. My research helps me give back not only to academia but also to the WordPress ecosystem by exploring new ways to reach people, improve adoption, and create sustainable growth.

Volunteering, speaking, organizing, mentoring, researching - each role has shown me the same truth. Contribution is not about doing everything. It is about showing up, sharing what you can, and making space for others to shine.

A Story for Marketers Who Wonder: "Can I Belong?"

If you are a marketer, a writer, or someone who feels more comfortable with words than code, you may wonder if you truly belong in WordPress. I want to speak directly to you.

You do belong.

WordPress needs your thinking. It needs your storytelling. It needs people who can bridge the gap between product and user. Your technical background, even if it is small, is an asset. Your creativity is essential. Your ability to connect with people is what gives technology meaning.

I moved from computer science into marketing and found my place. You can too. You don't have to be a developer to be valuable. Contribution comes in many forms. Learning, connecting, mentoring, writing, organizing-all of these matter.

Remember: WordPress is like water. It adapts to the needs of its people. And in the same way, you can adapt your own path in it.

Lessons

Looking back, three words define my WordPress journey.

• Learn. WordPress taught me more than software. It taught me resilience, curiosity, and the courage to explore.
• Connect. The relationships I built through meetups, WordCamps, mentoring, and organizing have been the most valuable part of this journey.
• Contribute. Giving back to the community has been my way of honouring everything I have received.
  

Wrapping Up

I sometimes think about that moment in my classroom when my teacher told me not to use WordPress. At the time, it felt like rejection. Today, I see it as the spark that lit the way forward. Without that moment, perhaps I would not have discovered what WordPress truly means to me.

WordPress has been my teacher, my platform, and my community. It has given me a career, friendships across the world, and a purpose that goes beyond myself.

I am also a loving father of a 3-year-old daughter and a proud husband. My family gives me balance and joy, and they remind me why community and contribution matter so much.

If you are reading this and wondering whether you belong in WordPress, I want you to know that you do. Whether you are a developer, a writer, a designer, or someone still figuring out your path, there is space for you here.

Start by learning. Reach out and connect. Then, when you are ready, contribute in your own way.

That is how WordPress grows. That is how communities grow. And that is how we grow as people.

Learn. Connect. Contribute. That is my story.

শিখুন, যুক্ত হোন, অবদান রাখুন; আমার ওয়ার্ডপ্রেস গল্প

শুরু

আমার ওয়ার্ডপ্রেসের যাত্রা শুরু হয়েছিল ক্লাসে। তখন আমি একজন ছাত্র, একটা পোর্টফোলিও ওয়েবসাইট বানাচ্ছিলাম। কাজটা করার জন্য আমি ওয়ার্ডপ্রেস বেছে নিয়েছিলাম কারণ এটা শেখা সহজ আর ব্যবহার করতেও আরামদায়ক। প্রোজেক্টটা শেষ করে গর্ব করে স্যারকে দেখালাম।

কিন্তু প্রশংসার বদলে স্যার বললেন, "এটা বাদ দাও, একেবারে শুরু থেকে PHP দিয়ে বানাও।" কথাটা শুনে খারাপ লেগেছিল। তবুও তার কথা মেনে PHP তে আবার করলাম। কিন্তু সেই অভিজ্ঞতা মনে গেঁথে রইল।

তখনই আমি বুঝে গিয়েছিলাম ওয়ার্ডপ্রেস আমার জন্য একটা নতুন দরজা খুলে দিয়েছে। সেটাই পরে আমার ক্যারিয়ার আর জীবনের পথ ঠিক করে দিয়েছে।

শিখুন

২০১৬ সালে আমি যোগ দিই weDevs এ। তখন কাজ করেছি Dokan, WP User Frontend, WP ERP এর মতো প্রোডাক্টে। এগুলো আমাকে দেখিয়েছিল ওয়ার্ডপ্রেস কতটা শক্তিশালী হতে পারে।

পরে কাজ করেছি ElementsKit, MetForm, ShopEngine, GetGenie AI এর মতো প্রোডাক্টে, যা এখন লাখ লাখ ওয়েবসাইটে চলছে। গত ৮ বছরে আমি ওয়ার্ডপ্রেস প্রোডাক্ট মার্কেটিং এ ক্যারিয়ার গড়েছি, বিভিন্ন আন্তর্জাতিক কোম্পানির সাথে কাজ করেছি তাদের eCommerce, LMS আর SaaS প্রোডাক্ট বড় করতে।

আমি কম্পিউটার সায়েন্স থেকে মার্কেটিং এ চলে এসেছিলাম। প্রথমে ভয় ছিল আমি পারব কিনা। কিন্তু টেকনিক্যাল ব্যাকগ্রাউন্ডটা আমাকে এগিয়ে দিয়েছে। এতে প্রোডাক্ট টিমের সাথে কাজ করা আর ব্যবসার সমস্যা বোঝা সহজ হয়েছে।

ওয়ার্ডপ্রেস আমাকে শিখিয়েছে কৌতূহলী থাকতে, মানিয়ে নিতে আর শেখা চালিয়ে যেতে।

যুক্ত হোন

২০১৭ সালে আমি প্রথম ওয়ার্ডপ্রেস মিটআপ আয়োজন করি। অনুষ্ঠানটা ছোট ছিল, কিন্তু সেখানে সবাই একে অপরকে শেয়ার করছিল, শেখাচ্ছিল, শিখছিল। তখনই বুঝলাম ওয়ার্ডপ্রেস শুধু সফটওয়্যার না, এটা আসলে একটা কমিউনিটি।

এরপর থেকে আমি মিটআপ, ওয়ার্ডক্যাম্প, নানা ইভেন্টে যুক্ত থেকেছি। এখন পর্যন্ত আমি ২৫টা ওয়ার্ডক্যাম্পে অংশ নিয়েছি, কখনো বক্তা হিসেবে, কখনো স্বেচ্ছাসেবক বা আয়োজক হিসেবে। প্রতিটি অভিজ্ঞতা আমাকে নতুন বন্ধু আর আত্মবিশ্বাস দিয়েছে।

প্রথমবার ওয়ার্ডক্যাম্প কাঠমাণ্ডু ২০১৯ এ বক্তা হই। শুরুতে ভয় লাগছিল, মনে হচ্ছিল যদি কেউ না শোনে? কিন্তু মঞ্চে উঠে দেখলাম সবাই শিখতে এসেছে। তখনই সাহস পেলাম।

২০২২ সালে কমিউনিটিতে অবদানের জন্য আমি Yoast Care Fund Award পেয়েছিলাম।

অবদান রাখুন

শেখা আর সংযোগের পর বুঝলাম ফিরিয়ে দেওয়ার সময় এসেছে।

আমি কাজ করেছি WordCamp Mentor আর Global Event Supporter হিসেবে। নতুন আয়োজকদের পাশে দাঁড়িয়েছি, তাদের সাহায্য করেছি। তাদের সাফল্য আমাকে সবসময় খুশি করেছে।

WordCamp Asia আমার কাছে খুবই বিশেষ। আমি ২০২২, ২০২৩ আর ২০২৫ এ আয়োজক টিমে ছিলাম। পরে যুক্ত হই WordCamp US 2025 এর টিমেও।

২০২৫ সালে আমি পাই Automattic Open Horizons Scholarship। একই সময়ে মার্কেটিং এ পিএইচডি করছি, যেখানে গবেষণা করছি কিভাবে নতুন পদ্ধতিতে সফটওয়্যার প্রোডাক্ট প্রচার করা যায়।

এসব অভিজ্ঞতা আমাকে শিখিয়েছে: অবদান মানে সবকিছু করতে হবে না, বরং যা পারেন সেটুকু নিয়মিত শেয়ার করাটাই আসল।

মার্কেটারদের জন্য কথা

আপনি যদি মার্কেটার হন, লেখক হন বা কোডের চেয়ে লেখালেখি ভালো পারেন, তবে নিশ্চিন্ত থাকুন, ওয়ার্ডপ্রেসে আপনার জায়গা আছে।

ওয়ার্ডপ্রেস শুধু ডেভেলপারদের প্রয়োজন নেই। প্রোডাক্ট আর ব্যবহারকারীর মধ্যে সেতু গড়তে যারা পারে, গল্প বলতে পারে, মানুষের সাথে সংযোগ তৈরি করতে পারে, তাদেরও সমানভাবে দরকার।

আমি কম্পিউটার সায়েন্স থেকে মার্কেটিং এ এসেছি, আপনিও পারবেন নিজের জায়গা খুঁজে নিতে। শেখা, লেখা, আয়োজন, মেন্টরিং সবই অবদান।

শিক্ষা

আমার যাত্রাকে তিনটি শব্দ সবচেয়ে ভালোভাবে বোঝায় -

• শিখুন. কৌতূহলী হোন, শিখুন, এগিয়ে যান।
• যুক্ত হোন. সম্পর্ক আর বন্ধুত্বই আসল শক্তি।
• অবদান রাখুন. যা শিখেছেন, সেটা অন্যদের সাথে ভাগ করুন।

শেষ কথা

শুরুতে শিক্ষক আমাকে ওয়ার্ডপ্রেসে কাজ করতে মানা করেছিলেন। তখন খারাপ লেগেছিল, কিন্তু আজ বুঝি সেটাই আমাকে সামনে এগিয়ে নিয়ে গেছে।

ওয়ার্ডপ্রেস আমার শিক্ষক, আমার প্ল্যাটফর্ম, আমার কমিউনিটি। এখান থেকেই আমি ক্যারিয়ার, বন্ধু আর জীবনের উদ্দেশ্য খুঁজে পেয়েছি।

আমি একজন ৩ বছরের মেয়ের বাবা আর একজন গর্বিত স্বামী। পরিবারই আমাকে সব সময় প্রেরণা আর আনন্দ দেয়।

আপনি ডেভেলপার হোন, লেখক হোন বা এখনও নিজের পথ খুঁজছেন, ওয়ার্ডপ্রেসে আপনার জন্য জায়গা আছে। শুরু করুন শেখা দিয়ে, তারপর সংযোগ তৈরি করুন আর ধীরে ধীরে অবদান রাখুন।

শিখুন. যুক্ত হোন. অবদান রাখুন. এটাই আমার গল্প।

The post Learn. Connect. Contribute. My WordPress Story - শিখুন, যুক্ত হোন, অবদান রাখুন; আমার ওয়ার্ডপ্রেস গল্প appeared first on HeroPress.

27 Aug 2025 3:00pm GMT

The presentations for WordCamp US are just a few days away! We have some really exciting keynotes including Danny Sullivan from Google, John Maeda from Microsoft AI, and Adam Gazzaley (one of the top neuroscientists in the world) from UCSF. I think being in the room and able to meet the speakers and ask questions is even more valuable this year, as things are changing so quickly. If you know anyone in or near Portland, Oregon have them get a ticket! Here are all the other AI-related talks:

• Scalable, Ethical AI: How to Own Your Content and Your AI with WordPress
  • Presenter: Jeffrey Paul, VP of Open Source, Fueled
  • Wednesday, August 27, 1:15 PM PT
• Catch Bugs Faster with AI & Playwright (No Hype, Just Results)
  • Presenter: Wendy Erdheim-Poch, Senior Automation Engineer, Elementor
  • Wednesday, August 27, 3:15 PM PT
• Core AI: What We're Building
  • Presenter: James LePage, Head of AI, Automattic
  • Thursday, August 28, 10:30 AM PT
• Zero to Plugin in 30 Minutes - Harnessing AI Coding Assistants for WordPress Development
  • Presenter: Maulik Vora, Founder and CEO of Zluck Solutions
  • Thursday, August 28, 1:45 PM PT
• Fixing and Optimizing websites with AI
  • Presenter: Arnas Donauskas, Product Manager at Hostinger
  • Thursday, August 28, 3:45 PM PT
• Turn your local WordPress install into your AI coding assistant
  • Presenter: Jonathan Bossenger, Developer Educator, Automattic
  • Friday, August 29, 10:30 AM PT
• From Storefront to Strategy: What Happens When AI Shops for Your Customers?
  • Presenter: Sonja Ibele, Delivery and Account Manager, Syde
  • Friday, August 29, 1:15 PM PT
• Unlock Developer Superpowers with AI
  • Presenter: Adam Silverstein, Developer Relations Engineer, Google
  • Friday, August 29, 2:15 PM PT

26 Aug 2025 2:21am GMT

We're excited to share that Open Channels is an official media partner for LoopConf 2025, the leading event for WordPress developers, engineers, and builders. This year's conference takes place on Thursday, 25 September 2025 at the historic Bishopsgate Institute in London. LoopConf is known for its high-quality, developer-focused sessions covering everything from advanced WordPress development […]

25 Aug 2025 9:00am GMT

Hi there,

I am thoroughly giddy for WordCamp US. The schedule looks fantastic. A great collection of Keynote speakers with Amy Sample Ward (NTEN), Danny Sullivan (Google), John Maeda (Microsoft), and Adam Gazzaley (Neuroscape at UCSF).

There are in total 44 sessions, covering three overall topics: "Technical WordPress," "Honing your skills," and "AI." Below you'll find a list of block and block theme-related talks you can follow on the livestream or on demand later on.

And when you read this, I am already on my way to Portland.

Yours,
Birgit

WordCamp US talks and workshops on block development and block themes

Staying within the block editor context, here is the list of talks that tackle the latest blocks buzz.

• Joeleen Kennedy: Modernizing at Scale: How FSE Supports Wikimedia's Evolving UX
• Josh Bryant: Reimagining WordPress Editing: How We Embedded Gutenberg Into Our Product Ecosystem
• Seth Rubenstein: Block Composability: The Past and The Future
• Stephanie Stelzer: Coding the Magic: A Developer's Journey Through Aloha
• Mary Ann Aschenbrenner: Moving a Website from Classic to a Block Theme
• Anton Plauche: Building Resilient Interfaces by Embracing Fluid Design
• Jemima Abu: A PHP Developer's Guide to ReactJS
• Michelle Schlup Hunt: Building Experiences: Design Systems, User Experience, and Full Site Editing
• Tammie Lister: The System is the Strategy
• Jamie Marsland: Launch Your Personal Portfolio-A Hands-On WordPress Workshop
• Ryan Welcher: The Block Developer Cookbook

Developing Gutenberg and WordPress

Jeff Paul posted the members of the Release Squad for WordPress 6.9. It's a mix of community and sponsored contributors. Five squad members are from Automattic; two of them, Jonathen Bossenger and Ryan Welcher are first-timers, paired with longtime contributors on the Triage team and Test team.

In a personal blog post, Exploring work in progress for WordPress 6.9, Anne McCarthy selected a few features on their way to the WordPress 6.9 release and reported on their status. She followed fairly closely the Roadmap 6.9 post and shared updates and discussions that are happening right now, roughly two months away from Beta 1 on October 21.

Rae Morey, The Repository, reported on both publications in WordPress 6.9 Release Squad Named as Features Take Shape.

The latest episode is Gutenberg Changelog 119-WordPress 6.8.2 and 6.9, Gutenberg 21.1, 21.2, and 21.3 Releases with Tammie Lister.

If you are listening via Spotify, please leave a comment. If you listen via other podcast apps, please leave a review. It'll help with the distribution.

Release lead Hector Prieto published What's New in Gutenberg 21.4 and highlighted

• DataViews table layout grouping and multi-selecting
• More on DataViews enhancements
• Style shuffling in write mode

In his August edition of the What's new for developers roundup post, Justin Tadlock has a vast array of released or upcoming updates for you to review. He also added three discussions you might want to chime in on if they are relevant to your work.

1. Expanding the Core block library? It might be in the cards
2. Proposing more theme.json settings control
3. Discussion on "composite" blocks

You also learn about Playground updates and Theme related changes and interesting bug fixes. If you only have time to read one post this week, make it this one.

Never ever miss another post from the WordPress Developer Blog! Subscribe!

Plugins, Themes, and Tools for #nocode site builders and owners

In previous editions of this newsletter, I mentioned the new Events plugin by Lesley Sim and Ahmed Fouad called EventKoi. It works natively with the block editor, supports recurring + multi-day events, and gives you beautiful calendar views out of the box. They are running a Founding Partner Lifetime Deal from Aug. 25-31 only. Learn more and get on the waitlist now.

Ajit Bohra and the team at LubusIN have shared their super cool Slider Block that they originally used for their own projects! Now, you can get it from the WordPress Plugin Directory, complete with a handy setup guide to help you get started.

The new plugin WPMozo Blocks and Addons by Elicus comes with a set of very fancy blocks like FlipBox, Image Card, Tilted Image, and some more. Each of them has also many design choices. If you need some interactive blocks on your site, it's worth checking out.

Theme Development for Full Site and Blocks

On the Developer Blog, Justin Tadlock wrote a tutorial on how to use a new extensibility feature to add custom social links to the block editor: Registering custom social icons in WordPress 6.9. If you want to test this for yourself before WordPress 6.9 comes out, make sure you install Gutenberg plugin 21.1 or newer.

I used this new feature to add podcast directory icons for my block theme on Gutenberg Times. The plugin will be in the WordPress repository as soon as I figure out this SVN version control thingy. The code is available on GitHub.

In her latest tutorial, Anne Katzeff, ASK Designs, explores the core Gallery block and shows how to arrange multiple images in a grid of rows and columns. She also mentioned the 'click to enlarge' feature. Katzeff then continues comparing the default gallery block with the one provided by Kadence Blocks.

Web developer Elliott Richmond delivers a thirty-year veteran's verdict: "Menus have always had one job… to help people find their way around a website." His manifesto against mega-menu bloat reveals hidden SEO penalties-link dilution, crawlability nightmares, and semantic confusion plague JavaScript-heavy navigation systems. Richmond advocates for WordPress's foundational principle: semantic simplicity over marketing spectacle. The prescription? Five to seven top-level items maximum, unified cross-device structure, and letting content-not navigation-handle conversion duties.

Building Blocks and Tools for the Block editor.

Paulo Carvajal shared in his blog post how to build Blocks That Work Seamlessly with Block Themes and the Site Editor. He covers the paradigm shift where everything becomes blocks, emphasizing the importance of integrating with theme.json design systems rather than using hard-coded styles. Key topics include responsive design integration, global styles compatibility, block patterns usage, and performance optimization for the evolving WordPress ecosystem.

Carvajal is also working on the block editor book called WordPress Editor and Blocks-A Comprehensive Guide.

In his livestream, Ryan Welcher let you in on Block Deprecation Secrets Only WordPress Experts Know as one of the Block Development Cookbook series. He cooked up a tasty recipe block and walked through the process of updating it with block deprecations-the secret ingredient to keeping your blocks fresh while maintaining compatibility with older content.

Brendan O'Connell started a video series talking about Remote Data Blocks. the plugin by the WordPress VIP team. Using it helps you connect the block editor to external APIs and sync data in real time to blocks. It also auto-registers custom blocks with a custom schema.

• In Part 1, O'Connell gives you an introduction.
• In Part 2 He covers using the plugin with an Airtable.

WordPressVIP also held a webinar highlighting the Remote Data Block. Rae Morey, The Repository, has the report for you. WordPress VIP Demos Its New Enterprise Suite: Remote Blocks and Parse.ly AI Updates

Questions? Suggestions? Ideas?
Don't hesitate to send them via email or
send me a message on WordPress Slack or Twitter @bph.

For questions to be answered on the Gutenberg Changelog,
send them to changelog@gutenbergtimes.com

23 Aug 2025 1:58am GMT

A couple months ago, this blog reached a web performance milestone which I shared on LinkedIn, Bluesky, Mastodon, Twitter:

For the first time ever, I've just seen my blog appear in field metrics from CrUX (Chrome UX Report), albeit in desktop only and for the origin not an individual URL. Baby steps. In any case, Core Web Vitals Assessment: Passed

Yesterday, I checked PageSpeed Insights again, and I was excited to discover that my blog is now also appearing in field metrics for mobile as well! And like desktop, the CWV assessment is also passing for mobile. The eligibility criteria for the CrUX dataset includes that "there must be a large enough number of visitors in order to create a statistically significant dataset." Granted, my site is still only getting enough traffic for origin-level metrics, and I can't see field metrics for the homepage URL specifically, but it's another baby step! (Or maybe a toddler step?)

I've really been trying to double down this summer on tuning every bit of performance possible out of WordPress (on the frontend), using my site as a case study, and I've been sharing my findings in posts here. I hope the site traffic is an indication that the community has found my posts helpful. The learnings are also making their way into Performance Lab feature plugins as well as in performance improvements on the roadmap for WordPress 6.9. I have some more posts that I'm working on. You can subscribe to get them in your inbox.

On August 27th (next Wednesday) at WordCamp US 2025 here in Portland, Oregon, I'm giving a talk called "The Site Speed Frontier with Performance Lab and Beyond" at 11:30am PDT. I hope to see you there, but it will also be livestreamed and recorded. I'll be blogging an elaborated version of what I have time to share in my talk. (By the way, if you are attending in person, check out My Portland Picks post for what I recommend visitors check out!)

One takeaway I'll be emphasizing in my talk is that we needn't settle with sites merely passing the Core Web Vitals assessment or achieving a "perfect" 100 performance score in Lighthouse. Why be content with a good 2-second LCP when it could be half that or even practically zero? Web performance is a journey, and there's always room for improvement. I can see from my blog's field metrics, for example, that the TTFB is hovering around the threshold between "needs improvement" and "poor". In spite of this, the frontend is so tuned that on mobile the LCP-TTFB in CrUX is 400ms and on desktop it's only 100ms.

I personally love optimizing the performance of WordPress sites, but I get it that this isn't for everyone (nor should it be). By landing our improvements from the Core Performance Team, my hope is that WordPress core (and the ecosystem) will have best practices implemented by default so that site owners needn't worry about performance.

I had to take some PSI screenshots to memorialize the milestone:

Field Data via CrUX

Lab Data via Lighthouse

Where I've shared this on social media if you want to discuss there:

• LinkedIn
• Bluesky
• Twitter
• Threads
• Mastodon

The post Web Performance Milestone appeared first on Weston Ruter.

22 Aug 2025 6:13am GMT

My good friend Tim Ferriss has launched a new card game with the Exploding Kittens folks, I just ordered it and you should do so too. It's a lovely way to share an evening with a few friends.

20 Aug 2025 11:07pm GMT

At a previous job, we had an engineering book club. Once a week we would meet and discuss a chapter of a book. It was a good opportunity to hear multiple perspectives on an author's work, to see who agreed with the author and where people thought the author was off-base.

I would like to bring this concept to WordPress, especially to fellow Core Contributors. For the first book, we will be reading Producing Open Source Software by Karl Fogel. This is a book that has greatly influenced my perspective on open source and software development in general.

The club will meet on Google Meet on Tuesdays at 16:00 UTC (edit: This was originally 15:00 UTC. Moving to not conflict with recurring meetings of multiple WordPress teams) for one hour with the following schedule:

• 2 September 2025: Preface and Chapter 1. Introduction
• 9 September 2025: Chapter 2. Getting Started
• 16 September 2025: Chapter 3. Technical Infrastructure
• 23 September 2025: Chapter 4. Social and Political Infrastructure and Chapter 5. Organizations and Money: Businesses, Non-Profits, and Governments
• 30 September 2025: Chapter 6. Communications
• 7 October 2025: Chapter 7. Packaging, Releasing, and Daily Development
• 14 October 2025: Chapter 8. Managing Participants
• 21 October 2025: Chapter 9. Legal Matters: Licenses, Copyrights, Trademarks and Patents

While not an official WordPress event, the expectations from the WordPress Community Code of Conduct will apply and at my sole discretion, violations may result in individuals not being invited to continue. Additionally, participants are also encouraged to blog their thoughts on each chapter.

If you are interested, please leave a comment on this post. I will be getting in touch with respondents. If there is an overwhelming interest, I may need to restrict attendees or run a second meeting.

Props to Jonathan Desrosiers and Tammie Lister for discussing this idea with me, Pattie Reaves for starting the club at PMC and the PMC PEP team who ran the club I was a part of.

The post A WordPress Book Club appeared first on Aaron Jorbin.

20 Aug 2025 7:36pm GMT

On the podcast today we have Michelle Frechette and Jonathan Desrosiers.

Michelle is well known in the WordPress community for her myriad roles, including Executive Director of Post Status and program director for WP Includes. She's a prolific freelancer, podcaster, and a driving force behind many WordPress initiatives.

Jonathan is a WordPress core committer, contributing to the project since 2013, and has been sponsored by Bluehost to work on WordPress core since 2018. His work largely takes place behind the scenes, supporting contributors, maintaining build tools, and keeping WordPress running smoothly for millions of users.

If you've ever searched for "WordPress" online, you've probably found both WordPress.com and WordPress.org at the top of your results, and, like many, you might be unsure what really separates the two.

Today, Michelle and Jonathan help clear up the history, philosophy, and practical differences between WordPress.com and WordPress.org. They talk about how these two flavours of WordPress came to be, why they've both been key to WordPress' growth, and the ways they overlap and differ in features, user experience, and monetisation.

Michelle shares her perspective as a long-time user and advocate, with experience across both .com and .org sites, while Jonathan dives into the technical and historical details from his core contributor vantage point.

They also explore whether the naming conventions .com and .org have helped or hindered the project, and how the WordPress community's open source ethos shapes the ongoing conversation.

Along the way, they touch on how .com made WordPress accessible in the early days, the importance of data portability, and evolving efforts to unify the user experience between the two platforms.

If you've ever wondered which version of WordPress is right for you, why the project seems split into two variants, or how community and commerce intertwine in the WordPress ecosystem, this episode is for you.

Useful links

 Blogger

 Michelle's WP Trail Buddies on WordPress.com

 The story of forking b2

Bluehost

 Data Liberation

 Five for the Future

 Calypso

20 Aug 2025 2:00pm GMT

When I first heard about WordPress, people talked about it like it was a joke - the cheap shortcut for people who couldn't "do real coding." I wasn't looking for money, fame, or even a side hustle. I just wanted to know what the fuss was about so I could talk with authority the next time it came up. What I didn't know was that I was picking up a stone that would later prove to be gold - taking me from clueless newbie to community leader, and from replacing demo content to designing websites for real clients… and even offer consultancy services

"The thing you throw away may be the thing you look for tomorrow." - Ugandan Proverb

Scratching in the Sand

People often ask me:

"Moses, tell us about your WordPress journey."

I always laugh and say: "Ah, my friend, it's the story of the stone that turned out to be gold."

In life, we pick things here and there. Like children at the seashore - a shiny shell here, a bottle cap there, a flat stone for skipping on the water. You never really know which one will be precious until life polishes it for you.

For me, that "stone" was WordPress.

The Reputation of a 'Cheap' Tool

Back then, WordPress had a bad reputation in my circles. I have a computer science background, and among my peers, real developers stayed up late wrestling with raw code until their eyes were bloodshot.

WordPress? "That's for people who can't code," they'd say. Even teachers, IT technicians, and random tech hobbyists had an opinion - and it wasn't kind.

But one day, while working as a school technician, I saw my friend Mr. Dumba mention WordPress on a teachers' WhatsApp group. He had just started using it to build sites and was offering to journey with some people.

I thought: "Hmm… let me check this thing for myself. If it's nonsense, at least I'll know. And if it's good, I can talk about it without looking like I just fell off the mango tree."

I wasn't looking for money. I just wanted to have an opinion. You see, I'm the kind of person who enjoys jumping into conversations with some authority - even if I learned the thing yesterday.

My First Meetup - Lost in the Blocks

My first WordPress Meetup was all about Gutenberg. This was around 2018 - actually 2018. Gutenberg was super fresh and not even fully launched yet

Laurence was introducing this "block editor" thing. Everyone was nodding seriously. Me? Everything went in through one ear and politely left through the other without even greeting my brain on the way out.

Just as I was wondering if I had wasted my time, someone said:

"If you're here for the first time and you don't understand anything, that's okay."

Inside me, something jumped: "Eh! That's me you're talking about!"

The Mind-Opener: Offline Development

Then, Mr. Lutaaya introduced us to building WordPress sites offline.

My friend, this was a million Dollar revelation.

Until then, I thought websites could only be built online - which meant needing fast internet and a good computer. And in Uganda? The Internet was like a stubborn goat - expensive and disappearing when you needed it most.

With XAMPP, I could build ten websites in a week without spending a coin on data. They were ugly, yes, but they were mine.

Falling in Love With Elementor

Not long after, I met Elementor. Ah! It was like discovering rolex after years of plain chapati.

No coding headaches. Just drag, drop, and design. I paired it with the Astra theme plus Starter Templates (now called Starter Sites) and started cranking out websites - or what I thought were websites.

If a client needed a hospital site, I'd hunt for a hospital theme with demo data. School site? Same thing. All I did was replace demo pictures of dogs with cows, or gardeners with goat herders, and voilà - "Nice website!"

The Drupal Disaster That Changed Me

Then came my humbling moment.

At WordCamp Kampala in 2019, a UCU student asked me to help her migrate her site from Drupal to WordPress. I said confidently: "No problem!"

A few hours later, I realized… big problem.

This wasn't a "replace the dog with a cow" job. It needed a full custom theme. I needed knowledge on custom design which I had never paid attention to. I had no clue how to make one from scratch. That day, I felt like a boda boda rider asked to fly a helicopter.

I failed her completely.

But in that failure, a fire was lit. I decided to actually learn custom design.

Facing Real Problems

By January 2019, I built my company's first fully custom site. It wasn't perfect, but it taught me about responsiveness, optimization, and making sure a site looked good on desktop, laptop, and mobile. My first website was so beautiful on Desktop but so broken on Mobile. Everyone was complaining about it and I wasn't seeing the problem until I saw it on my phone. Whoah, it looked so horrible that a witch's house was more organized. Everything was flying to where it found peace but inside my heart, I was happy with the learning curve that was super achievable.

This was no longer a hobby. I was in deep. Curiosity building into a desire

A few years later, I learned Divi. I learned Gutenberg properly now known as FSE (Full Site Editing). I even designed my first block editor site and felt like a genius. A few years later, I used the block editor to design an entire WordCamp website, with a friend (a member from the local community) - and it worked beautifully.

Finding the Real Gold: Community

The real treasure, though, wasn't Elementor, Divi, or even my first paying client. It was the WordPress community.

Other tech communities can be stingy with knowledge. In WordPress, people shared openly. Sometimes the knowledge shared required resources that even cost money but people still offered. In my very first days Rogers offered me a starter package with hosting and management and by then we were using the .ml and .tk domains from FreeNom since it was free. The people I met in the community teach you how to do the exact thing they do for a living - no gatekeeping, no "first pay me - Awesome, Right? I thought so too."

I realized:

Contributing to WordPress is like washing the plate you ate on.

It's a privilege, not a burden.

From Local Meetups to the White House

I've spoken at Meetups, organized WordCamps, helped beginners install WordPress for the first time, and served in multiple WordPress teams.

And I've seen where WordPress can go. It powers embassy websites. It's used by the Ugandan State House. It even runs the White House site in the USA.

If the White House trusts it, my friend, no one can convince me otherwise.

From Rock to Treasure

I joined WordPress at version 4.9. Now we're in the 6.x series. I've grown alongside it - from a confused attendee to a community leader, from a "text-replacing" novice to a custom developer.

When I picked up WordPress, I thought it was a useless rock. But when I washed it, shaped it, and put it in the fire, it gleamed like gold.

WordPress is gold. Pure and simple.

"The thing you throw away may be the thing you look for tomorrow. WordPress was my stone that turned out to be gold."

The post The Stone That Turned Out to Be Gold - My WordPress Journey appeared first on HeroPress.

20 Aug 2025 5:00am GMT

Following the incredible success of WordCamp Kolhapur 2025 (January 11-12), our passionate local WordPress community launched a dedicated nine‑event Online Contribution Series to help new and aspiring contributors explore different ways to contribute to the WordPress project.

As the Lead Organizer of WordCamp Kolhapur 2025, I felt inspired to conceptualize and lead this initiative, supported by my fellow community members. After several thoughtful discussions and planning sessions, the series was finalized and officially kicked off on March 14, 2025. The complete nine‑event series was organized through the WordCamp Kolhapur Meetup group, with Abhay Kulkarni organizing and volunteering for every meetup to ensure smooth coordination. I served as the speaker and mentor for each session, guiding both new and experienced contributors through various areas of the WordPress project.

Why We Started the Contribution Series

I was a mentee in the WordPress Contributor Mentorship: 2024 Q4 Cohort and successfully graduated from the program in November 2024. During this journey, I not only learned how to contribute effectively to WordPress Core, but I was also recognized as an All-Star Mentee and earned a place in the program's Hall of Fame!

Additionally, I received a Diversity Scholarship to attend WordCamp Asia 2025. These scholarships are designed to support individuals who are passionate about contributing to the WordPress ecosystem but may face financial or logistical challenges.

Inspired by my cohort experience and the opportunities I received, I wanted to give back to the community. What better way than by becoming a mentor myself, guiding and inspiring others to start their own contribution journey?

And that's the core reason we started the WordPress Contribution Series.

Event Recap

After the planning and preparation, here's how the contribution series unfolded across different meetup topics:

Kickstart Your WordPress Contribution Journey

Date: March 15, 2025

This opening session focused on getting contributors started with the basics - setting up a WordPress.org profile, joining global Slack channels, and understanding the various Make WordPress teams. The session concluded with a photo contribution activity where participants submitted original images to the WordPress Photo Directory.

• Total Contributors: 9
• First-Time Contributors: 3

Core Contributions: Testing & Release Parties

Dates: March 25, April 1, 8, 14, and 15, 2025

These sessions were designed to help participants contribute to WordPress Core by testing the Release Candidate versions of WordPress 6.8. Rather than writing code, the focus was on functional testing, identifying bugs, and joining the community for release celebrations.

• Total Contributors: 28
• First-Time Contributors: 23

Pattern Contributions

Date: March 29, 2025

This meetup introduced contributors to the WordPress Pattern Directory. Attendees learned how to design block patterns, follow accessibility guidelines, and submit reusable layout designs to enrich the editor experience for users worldwide.

• Total Contributors: 12
• First-Time Contributors: 11

Polyglots / Translation Contributions

Date: April 5, 2025

This session focused on language accessibility. Contributors worked on translating WordPress core, plugins, and themes into regional languages. Guidance was provided on using translation tools and maintaining quality across localized strings.

• Total Contributors: 8
• First-Time Contributors: 7

WordPress TV: Talks, Videos & Guest Participation

Date: April 12, 2025

In this session, contributors explored how to contribute to WordPress TV through video uploads, captioning, and translating community talks. We also hosted guest speaker Prathamesh Palave, who shared insights on creating impactful presentation content.

• Total Attendees: 13
• Guest Speaker: Mr. Prathamesh Palave

Contributors from the Series

We're proud to recognise all the individuals who actively participated in the series: Rajesh Rathod, Suraj Sutar, Prashant Patil, Shubham Patil, Pritam Sonone, Vaibhav Singh, Ketan Niruke, Digvijay Zite, Rajendra Ghorpade, Prathamesh Bhagat, Shreyas Desai, Sunita Khattar, Nilesh Shiragave, Amit Bhosale, V Gautam Navada, Snehal Kashid, Rupesh Patil, Akshay Dhere, Aditya Bansode, Suhas Sutar, Vaibhav Nawale, Dheeraj Bhosale, Rajendra Patil, Prathamesh Palave, Soham Joshi, Mrunal Kulkarni, Harshada Patil, Abhay Kulkarni & Makarand Mane

Additional Online Meetup: Contributing to the Test Team

Two months later, we hosted an online meetup dedicated to contributing to the WordPress Test Team.

• Date: June 15, 2025 (update if needed)
• Guest Speaker: Mrs. Krupa Nanda

Krupa explained how the Test Team helps ensure the quality of WordPress releases by performing functional and regression testing. She also guided attendees on:

• Reporting and triaging bugs
• Using testing tools effectively
• Participating in release testing initiatives on Make WordPress Test

The session provided a clear roadmap for contributors to get started with testing activities.

Recording: Watch Here

Closing Thoughts

The WordPress Kolhapur Contribution Series proved that WordPress thrives when we lift each other up. New contributors gained confidence, mentors found joy in guiding, and our community grew stronger and more inclusive.

The Kolhapur WordPress community continues to host regular contribution‑focused events and welcomes contributors from around the world to join us.

If you feel inspired to begin your own contributor journey-or to help others start theirs-connect with the Make WordPress Community Team.

Together, we can build a better WordPress for everyone.

19 Aug 2025 12:41pm GMT

Over the weekend, Automattic/Beeper had the pleasure of hosting and sponsoring the Build the Future MCP Hackathon in New York City organized by Adam Anzuoni, alongside Anthropic, Stainless, WorkOS, Smithery, and MongoDB. As someone deeply passionate about open-source technology and the potential of AI, I was thrilled to not only support this event but also to speak at it and serve as one of the judges. For those unfamiliar, MCP stands for Model Context Protocol and enables AI models to interact with multiple tools in a more efficient and structured manner, allowing developers to create sophisticated agents that can handle complex tasks. And it's only 8 months old! The energy in the room was electric-hackers collaborating, iterating, and demoing groundbreaking projects in just a few hours. (I would love to see the results of a longer overnight or all-weekend hackathon.)

For a wrap-up of the winners, check out this great X/Twitter thread by Alex Reibman. The first-place winner, Levels AI, orchestrates different AI/ML models to solve specific business requirements without needing heavy manual coding or specialized teams. Essentially, it's models creating more models-a meta-approach to AI that could streamline operations for companies of all sizes. Yusuf Olokoba said the name was inspired by Pieter Levels, which is pretty cool. I wanted to note one team in particular: BeepResearch, which used our early access Beeper API and local MCP.

Judging the entries was tough! People built so much cool stuff in a really short period of time. I always say technology is best when it brings people together, and this was a great example of that, and makes me very excited for Contributor Day at WordCamp US next week. (Which has such a stacked AI program as well.) Hopefully some people who enjoyed the office might consider getting 24/7 access.

I also just want to take a beat and say how amazing it is that I'm blogging this, on a United flight from Houston to San Francisco I've taken a million times, on a plane 36,000 feet in the air and technology is amazing. I can't wait until United has Starlink!

Also last week the WordPress AI team shipped its MCP adapter!

19 Aug 2025 7:15am GMT

We are taking a break until September to accommodate vacations and back-to-school preparations while finalizing our rebranding efforts for a polished look.

18 Aug 2025 12:16pm GMT

These days, it feels like every business is leaning on AI, chatbots, or endless help articles. While those tools can help, they often leave customers frustrated and waiting for real answers. What actually makes a difference is human-centered service. Customers want to know someone is listening, taking ownership of their problem, and working to solve […]

18 Aug 2025 8:25am GMT

In this episode, listen in as we discuss the significance of backward compatibility in WordPress, sharing insights from expert Gary Pendergast on technical challenges and real-world examples.

14 Aug 2025 10:09am GMT