En pocas palabras: WooCommerce 11.1, lanzada el 31 de agosto de 2026, acelera las llamadas a REST API y Store API entre 13 y 18 ms (30 a 42% más rápido) gracias al guard BlockRegistrationContext, que evita registrar bloques y patterns en requests que nunca los renderizan.
WooCommerce 11.1 hace que las llamadas a la REST API y a la Store API sean entre 13 y 18 ms más rápidas (un 30 a 42% de mejora, según el anuncio oficial del equipo de WooCommerce del 31 de agosto de 2026). El truco: dejar de registrar bloques y patterns en las requests que nunca los van a renderizar. Suena a detalle interno, pero para una tienda con tráfico se nota.
WooCommerce 11.1 es la versión que introduce BlockRegistrationContext, un guard que detecta cuándo una request no va a renderizar ni editar bloques y evita registrar los block types y patterns de WooCommerce en ese caso. Es la segunda parte de una optimización que arrancó en la 11.0, y apunta directo al tiempo de respuesta de las APIs que usan las tiendas headless, las apps móviles y el bloque de Cart & Checkout.
En 30 segundos
- 13 a 18 ms más rápido: las requests a Store API y REST API mejoran un 30 a 42% en las mediciones del propio equipo de WooCommerce.
- El mecanismo: un guard llamado
BlockRegistrationContextsaltea el registro de bloques y patterns en contextos que no los renderizan. - Frontend intacto: el sitio público, el admin y el editor de bloques siguen registrando todo, no cambia nada visible.
- Excepción incorporada: las descripciones de productos con bloques se registran on demand vía el filtro
woocommerce_short_description. - Si sos dev: revisá tu extensión antes del release final y usá el filtro
woocommerce_should_register_blockspara optar de vuelta donde haga falta.
WooCommerce es un plugin de código abierto para WordPress creado por Automattic que permite transformar un sitio de WordPress en una tienda de comercio electrónico. Ofrece herramientas para gestionar catálogos de productos, procesar pagos y administrar pedidos.
¿Cuánto más rápida es la REST API en WooCommerce 11.1?
Entre 13 y 18 ms por request, lo que da un 30 a 42% de reducción en el tiempo de respuesta de la Store API y la REST API de WooCommerce, según las mediciones que publicó el equipo. No es un número inflado de marketing: es el ahorro de dejar de hacer trabajo que la request no necesitaba.
Ponele que tenés una app móvil que pega contra la Store API para armar el catálogo. Cada vez que pedía productos, WooCommerce registraba todos sus bloques y patterns aunque esa respuesta fuera JSON puro y nunca renderizara un bloque. Trabajo tirado en cada llamada.
¿Y por qué importan unos milisegundos? Porque se multiplican. Una tienda con miles de requests por hora entre el checkout headless, las integraciones y las apps suma ese ahorro request tras request, y ahí es donde el TTFB baja de verdad. Si tu WordPress corre en un hosting WordPress con buen backend, esta clase de optimización a nivel código se combina con el cacheo del server y el resultado se siente en la latencia real.
¿Cómo funciona el nuevo BlockRegistrationContext en WooCommerce 11.1?
BlockRegistrationContext es un guard que evalúa el contexto de cada request y decide si vale la pena registrar los bloques y patterns de WooCommerce. Si la request no puede renderizar ni editar bloques, los saltea. Corre temprano, sobre plugins_loaded, antes de que se parsee la query principal.
La idea venía de antes. En WooCommerce 11.0 los patterns pasaron a registrarse por file path y su contenido se carga solo cuando el editor lo pide, igual que hace el core de WordPress. Eso ya ahorraba 5 a 8 ms por request. La 11.1 completa el laburo: en vez de solo aflojar con los patterns, directamente no registra nada de bloques en los contextos que no los usan. Para más detalles técnicos, mirá mejorar la presentación del producto.
Hay una excepción pensada para que nada se rompa. Cuando la descripción de un producto o de una variación tiene un bloque de WooCommerce adentro, los block types se registran on demand mediante el filtro woocommerce_short_description. Así las descripciones siguen renderizando bien en la products REST API, en la Store API, en el endpoint AJAX de variaciones y en las páginas de producto. No perdés nada de output dinámico ahí.
El diseño es conservador a propósito: el guard solo saltea contextos que reconoce. Si aparece un caso que no tiene mapeado, sigue registrando bloques como siempre. En palabras del equipo, un caso no contemplado «cuesta un poco de performance, nunca una regresión de renderizado». Preferían dejar plata sobre la mesa antes que romper una tienda.
¿Qué requests se benefician y cuáles no?
Se benefician las requests non-rendering: Store API, WooCommerce REST API y cualquier request custom que no renderice bloques. No cambian el frontend público, el admin del core ni el editor de bloques o de sitio, que siguen registrando todo como antes. Acá la tabla.
| Contexto | ¿Registra bloques en 11.1? | Efecto |
|---|---|---|
| Store API | No (skipped) | 13 a 18 ms más rápido |
| REST API de WooCommerce | No (skipped) | 13 a 18 ms más rápido |
| Descripciones de producto con bloque | Sí, on demand | Renderiza igual, sin acción |
| Frontend público | Sí | Sin cambios |
| Admin del core | Sí | Sin cambios |
| Editor de bloques / sitio | Sí | Sin cambios |
Lo interesante es la asimetría. El ahorro se concentra donde más pega (las APIs que alimentan headless y apps) y deja tranquilo todo lo que un usuario ve renderizado.
¿Quiénes necesitan revisar sus extensiones?
Solo te afecta si tu extensión renderiza bloques de WooCommerce, o depende de que sus block types, patterns o assets por bloque estén registrados durante una de las requests que ahora se saltean. Si tu plugin no toca nada de eso, no hacés nada. Complementá con reducir plugins innecesarios.
¿Cómo confirmás si te toca? Chequeá el registro directo en el contexto que te preocupa:
// Devuelve false en un contexto skipped en WooCommerce 11.1+.
WP_Block_Type_Registry::get_instance()->is_registered( 'woocommerce/mini-cart' );Un bloque de WooCommerce que no se registró vuelve como markup crudo (<!-- wp:woocommerce/… -->) o como HTML estático sin su salida dinámica. Dos aclaraciones que ahorran dolores de cabeza: las descripciones de productos y variaciones no necesitan acción (se manejan on demand), y los bloques que tu extensión registra por su cuenta con register_block_type() tampoco se ven afectados. Esto cubre solo el registro que hace WooCommerce.
¿Cómo adaptar tu extensión al nuevo sistema?
Si detectaste que sí renderizás bloques en una request skipped, optás de vuelta con el filtro woocommerce_should_register_blocks, y solo para esos contextos donde de verdad los renderizás. Nada de forzar el registro en todo (perderías el beneficio de la 11.1).
add_filter(
'woocommerce_should_register_blocks',
function ( $should_register ) {
return my_context_renders_blocks() ? true : $should_register;
}
);Ojo con el timing. El filtro corre sobre plugins_loaded, antes de que se parsee la query principal, así que tu condición solo puede apoyarse en lo que ya esté disponible tan temprano. Nada de depender de la query, que todavía no existe en ese punto.
Y una recomendación que el equipo remarca: no construyas tus bloques sobre AbstractBlock. Es una clase interna, y todo bloque montado ahí hereda cada decisión de registro que tome WooCommerce, skips incluidos. Su ciclo de vida va a seguir cambiando a medida que optimicen. La forma soportada es la Block API estándar de WordPress: definís el bloque en block.json y lo registrás con register_block_type() sobre init. Para arrancar, @wordpress/create-block, y para inner blocks de Cart y Checkout, el template @woocommerce/extend-cart-checkout-block. Relacionado: optimizar con generación automática de imágenes.
Diferencias entre WooCommerce 11.0 y 11.1
Las dos versiones atacan el mismo problema (registro de bloques innecesario) pero desde ángulos distintos. La 11.0 optimizó los patterns; la 11.1 saltea el registro completo en contextos non-rendering. Es una mejora incremental, paso a paso.
| Versión | Cambio | Ahorro |
|---|---|---|
| WooCommerce 11.0 | Patterns se registran por file path; el contenido se carga solo cuando el editor lo pide (igual que el core de WP) | 5 a 8 ms por request |
| WooCommerce 11.1 | BlockRegistrationContext saltea bloques y patterns en requests non-rendering | 13 a 18 ms adicionales en Store API y REST |
¿Cómo verificar que tu extensión está lista?
Probala contra WooCommerce 11.1 antes del release final, como pide el equipo. No hace falta un lab enorme: con wp-cli o unos curl contra tus endpoints alcanza para detectar si algo vuelve como markup crudo.
- Chequeá el registro: confirmá que
WP_Block_Type_Registrydevuelvefalsejusto donde esperás que el guard saltee, ytruedonde optaste de vuelta. - Testeá la Store API: pegá contra los endpoints que usa tu extensión y revisá que la respuesta traiga el output renderizado, no
<!-- wp:woocommerce/… -->. - Validá descripciones con bloques: cargá un producto con un bloque de WooCommerce en la descripción y verificá que renderice bien vía products REST API y Store API.
- Mirá los logs: buscá warnings de bloques no registrados o de HTML estático donde debería haber salida dinámica.
Casos concretos de optimización en Store API y REST API
Tres escenarios que separan lo que hay que tocar de lo que se arregla solo.
El mini-cart que vuelve como markup crudo
Tu extensión renderiza woocommerce/mini-cart dentro de una respuesta de Store API. En 11.1, sin el registro, ese bloque vuelve como <!-- wp:woocommerce/mini-cart --> en vez de su HTML. La solución es optar de vuelta con woocommerce_should_register_blocks para ese contexto puntual.
Descripciones de producto que siguen andando
Tenés productos con bloques en la descripción y los servís por la products REST API. Acá no hacés nada: el filtro woocommerce_short_description registra los block types on demand y la descripción renderiza igual que antes. Cero acción.
Una búsqueda custom que renderiza bloques
Armaste un endpoint propio que devuelve resultados con bloques de WooCommerce embebidos. Como es una request custom, entra en los contextos skipped y necesitás optar de vuelta. Igual que el mini-cart: filtro woocommerce_should_register_blocks condicionado a ese contexto y listo. Lo explicamos a fondo en mantener tu tienda actualizada.
Errores comunes al actualizar a WooCommerce 11.1
- Forzar el registro en todo: devolver siempre
trueen el filtro anula la optimización y te comés el costo que la 11.1 justamente sacó. Optá de vuelta solo en los contextos donde renderizás bloques de verdad. - Construir sobre AbstractBlock: es una clase interna que hereda todos los skips de WooCommerce y cuyo ciclo de vida va a seguir cambiando. Usá la Block API estándar con
block.jsonmásregister_block_type(). - Poner condiciones que dependen de la query: el filtro corre sobre
plugins_loaded, antes de parsear la query principal. Si tu lógica necesita saber qué página se pidió, todavía no lo sabés en ese punto.
Preguntas Frecuentes
¿Qué mejoras trae WooCommerce 11.1?
WooCommerce 11.1 acelera las requests a la Store API y a la REST API entre 13 y 18 ms (30 a 42%) al saltear el registro de bloques y patterns en contextos que no los renderizan, mediante un nuevo guard llamado BlockRegistrationContext. Se anunció el 31 de agosto de 2026.
¿Qué es BlockRegistrationContext en WooCommerce?
BlockRegistrationContext es un guard incorporado en WooCommerce 11.1 que detecta cuándo una request no va a renderizar ni editar bloques y evita registrar los block types y patterns de WooCommerce en ese caso. Corre sobre plugins_loaded, antes de que se parsee la query principal.
¿Necesito adaptar mi extensión de WooCommerce para 11.1?
Solo si tu extensión renderiza bloques de WooCommerce o depende de que sus block types, patterns o assets estén registrados durante una request skipped (Store API, REST API o custom). Si es tu caso, optás de vuelta con el filtro woocommerce_should_register_blocks para esos contextos puntuales.
¿Cómo verifico si mi extensión está afectada?
Ejecutá WP_Block_Type_Registry::get_instance()->is_registered( 'woocommerce/mini-cart' ) en el contexto que te interesa: en WooCommerce 11.1+ devuelve false en un contexto skipped. Si un bloque tuyo vuelve como markup crudo (<!-- wp:woocommerce/… -->) en una respuesta de API, estás afectado.
¿Las descripciones de productos se rompen en WooCommerce 11.1?
No. Las descripciones de productos y variaciones que contienen bloques de WooCommerce se registran on demand vía el filtro woocommerce_short_description, así que renderizan bien en la products REST API, la Store API, el endpoint AJAX de variaciones y las páginas de producto. No requieren ninguna acción del desarrollador.
Conclusión
WooCommerce 11.1 cierra una optimización que arrancó en la 11.0: dejar de pagar por registrar bloques en requests que nunca los muestran. El resultado son 13 a 18 ms menos por llamada a la Store API y la REST API, algo que las tiendas headless y las apps móviles van a agradecer en el TTFB.
Para la mayoría de las tiendas, actualizás y listo, no cambia nada visible. Si desarrollás extensiones que renderizan bloques de WooCommerce, el paso concreto es simple: probá contra 11.1 antes del release final, chequeá is_registered() en tus contextos, y donde algo vuelva como markup crudo, optá de vuelta con woocommerce_should_register_blocks solo ahí. Y si estás armando bloques nuevos, dejá AbstractBlock de lado y usá la Block API estándar de WordPress. Es menos código pegado a las tripas internas de WooCommerce y menos sorpresas en la próxima optimización.
Fuentes
- WooCommerce Developer Blog – Anuncio oficial de las mejoras de registro de bloques en WooCommerce 11.1 (31/08/2026)
- WooCommerce Developer Documentation – Documentación para desarrolladores de extensiones y bloques
- WordPress Developer Reference – register_block_type() y la Block API estándar
