Faster REST and Store API requests
WooCommerce block types and patterns were previously registered on nearly every request, including many that never render or edit blocks. We are changing that deliberately: a request should only pay for block registration when it can actually render or edit blocks.
The first step shipped in WooCommerce 11.0, where patterns register by file path and their content is loaded only when the editor requests it, matching WordPress core and saving 5–8 ms on every request that registers blocks .
WooCommerce 11.1 completes the change: a new BlockRegistrationContext guard now skips block and pattern registration on non-rendering requests. One exception is built in: when a product or variation description contains a WooCommerce block, block types are registered on demand via the woocommerce_short_description filter, so descriptions still render correctly in the products REST API, the Store API, the variation AJAX endpoint, and product webhooks.
Front-end, core admin, and block/site editor requests are unchanged, and the guard only skips contexts it recognizes; anything else keeps registering blocks, so a missed case costs a little performance, never a rendering regression.
The benefit: Store API and WooCommerce REST requests are 13–18 ms (30–42%) faster in our measurements.
How can developers tell if they are affected?
This applies from WooCommerce 11.1.0. You are affected only if your extension renders WooCommerce blocks, or relies on WooCommerce block types, patterns, or per-block assets being registered, during one of the skipped requests above. A WooCommerce block comes back as raw block markup (<!– wp:woocommerce/… –>) or as static HTML without its dynamic output which can be confirmed in code:
// Returns false in a skipped context on WooCommerce 11.1+.
WP_Block_Type_Registry::get_instance()->is_registered( 'woocommerce/mini-cart' );
Product and variation descriptions need no action; they are handled on demand. Blocks your extension registers itself with register_block_type() are also unaffected; so this only covers registration done by WooCommerce.
What action do developers need to take if affected?
Opt back in with the new woocommerce_should_register_blocks filter; return true only for the requests where you actually render blocks:
add_filter(
'woocommerce_should_register_blocks',
function ( $should_register ) {
return my_context_renders_blocks() ? true : $should_register;
}
);The filter runs on plugins_loaded, before the main query is parsed, so the condition can only rely on what’s available that early ($_SERVER, $_GET).
Please test your extension against WooCommerce 11.1 before the final release.
One more recommendation: don’t build your blocks on AbstractBlock. It’s an internal class, and blocks built on it inherit every registration decision WooCommerce makes, including the skips above; its lifecycle will keep changing as we optimize registration.
The supported way to create a block is the standard WordPress Block API: define it in block.json and register it with register_block_type() on init. Good starting points: Scaffolding and sample store data, @wordpress/create-block, and for Cart and Checkout inner blocks the @woocommerce/extend-cart-checkout-block template.
Leave a Reply