WooCommerce 11.0 activa el caché de objetos de productos por defecto en las tiendas nuevas. Es un caché en memoria que vive lo que dura cada request del servidor y acelera la carga de productos variables entre un 9% y un 12%. Las tiendas que ya están andando no se tocan: siguen con su configuración actual.
En 30 segundos
- Solo tiendas nuevas: instalás WooCommerce 11.0 desde cero y el caché de objetos viene activado, sin que toques nada.
- Las existentes quedan igual: si actualizás una tienda vieja a 11.0, no se activa solo. No te cambia el comportamiento.
- Velocidad real: productos variables cargan 9-12% más rápido en la página de producto; los bundles procesan 6-12% más rápido en el checkout.
- No es persistente: el caché se borra entre requests, no se guarda en disco ni en Redis. Cero mantenimiento manual.
- Compatibilidad por defecto: desde 10.6 las extensiones se asumen compatibles salvo que declaren lo contrario.
WooCommerce es una extensión de código abierto para WordPress, desarrollada por Automattic, que convierte sitios en tiendas online para vender productos digitales y físicos.
Si tenés una tienda con cientos de productos variables y notaste que la ficha de producto tarda en pintar, esto te interesa. WooCommerce lo viene cocinando desde la 10.5, primero como experimento, y ahora lo dejó prendido por defecto en las instalaciones frescas.
El caché de objetos WooCommerce es un mecanismo que guarda los objetos de producto en la memoria RAM del servidor durante una única petición (request) y los reutiliza en vez de volver a instanciarlos desde la base de datos. Lo desarrolló el equipo de WooCommerce, se introdujo como experimental en la versión 10.5 y quedó activado por defecto para tiendas nuevas en la 11.0, publicada el 17 de junio de 2026.
¿Qué es el caché de objetos de productos en WooCommerce 11.0?
Ponele que una página de producto carga el mismo producto cinco veces durante el armado del HTML: una para el título, otra para el precio, otra para las variaciones, otra para el stock. Sin caché, WooCommerce iba a la base y reconstruía ese objeto cada vez. Un desperdicio.
El product object caching corta con eso. La primera vez que se pide un producto por su ID, lo carga y lo deja en un caché en memoria que dura lo que dura ese request. Las llamadas siguientes al mismo ID se sirven desde ahí. Acordate de un detalle clave: el caché es no persistente, se limpia entre requests. No queda nada guardado para la próxima visita.
Hay una decisión de diseño que vale la pena marcar. Cuando pedís el mismo producto dos veces dentro del request, WooCommerce no te devuelve una referencia compartida, te devuelve una copia clonada. ¿Por qué importa? Porque así dos partes del código no pueden pisarse el estado entre sí sin querer. Si una modifica el objeto, no le rompe el dato a la otra. Ya lo cubrimos antes en enriquecer los datos de tus productos.
¿Cuánta velocidad gano activando el product object caching?
Los números que WooCommerce confirmó en el anuncio original (los de la fase experimental) siguen vigentes:
- Productos variables, 9-12% más rápido: en la carga de la página de producto. Es donde más se nota, porque cada variación implica leer datos extra.
- Productos bundle, 6-12% más rápido: durante el procesamiento del checkout, cuando WooCommerce arma el pedido con sus componentes.
El motor de la mejora es simple: se evita reinstanciar objetos que ya tenés a mano. Cuantas más veces se repita la carga del mismo producto en un request, más zafás de ir a la base.
¿Dónde pega más fuerte? En catálogos grandes y, sobre todo, en productos con muchas variaciones. Una remera con cinco talles y seis colores genera un montón de lecturas repetidas; ahí el ahorro se acumula. En un producto simple sin variaciones el impacto es chico, porque no hay tanta repetición que evitar.
¿Se activa automáticamente en WooCommerce 11.0 o lo tengo que configurar?
Depende de si tu tienda es nueva o vieja. Esta es la parte donde mucha gente se confunde.
- Tienda instalada fresca en 11.0 o superior: el caché de objetos viene activado de fábrica, como parte del proceso de instalación. No configurás nada.
- Tienda existente que actualizás a 11.0: no se activa sola. Seguís con tu configuración actual, sin cambios.
La lógica detrás de esto es prudente: WooCommerce no quiere meterle un cambio de comportamiento a tiendas en producción que ya tienen su ecosistema de plugins armado y testeado. En una instalación nueva no hay nada que romper, así que ahí sí lo prenden. Sobre eso hablamos en optimizar las imágenes del catálogo.
¿Qué diferencia hay entre caché de objetos y caché de página tradicional?
Acá viene una confusión clásica. No es lo mismo cachear el HTML de una página que cachear los objetos que la generan. Y dentro del caché de objetos, tampoco es lo mismo el request-scoped que el persistente tipo Redis.
| Tipo de caché | Qué guarda | Dónde vive | Cuánto dura | Ejemplo |
|---|---|---|---|---|
| Caché de página | El HTML completo ya renderizado | Disco o RAM del servidor | Hasta que expira o lo purgás | LiteSpeed Cache, WP Super Cache |
| Caché de objetos (request-scoped) | Objetos de producto en memoria | RAM, dentro de un request | Se borra al terminar el request | Product object caching de WooCommerce 11.0 |
| Caché de objetos persistente | Resultados de queries y objetos | RAM externa (Redis/Memcached) | Entre requests, hasta invalidar | Redis Object Cache |
El product object caching de la 11.0 es la fila del medio. No reemplaza a un caché de página, ni a un objeto persistente como Redis. Convive con ellos. Si tu hosting WordPress te da Redis o Memcached, podés seguir usándolos para el caché persistente entre visitas; este nuevo caché ataca otro problema, el de las lecturas repetidas dentro de una misma carga. En hosting WordPress de Donweb, por ejemplo, podés combinar caché de página con object cache persistente sin que se pisen.
¿Qué cambió entre WooCommerce 10.5, 10.6 y 11.0?
La función no apareció de la nada. Tuvo su recorrido:
- 10.5: WooCommerce introdujo el product object caching como experimental. Quien quería probarlo lo activaba a mano.
- 10.6: cambió el default de compatibilidad. La declaración de compatibilidad de plugins pasó de «incompatible salvo aviso» a «compatible salvo aviso».
- 11.0 (junio 2026): quedó activado por defecto en tiendas nuevas.
El cambio de la 10.6 es el más interesante de los tres. Durante todo el período experimental no se detectó ni un solo problema de compatibilidad en el ecosistema de extensiones. Con esa evidencia sobre la mesa, el equipo dio vuelta el criterio: ahora una extensión sin declaración explícita se asume compatible. Las que se declaran incompatibles a propósito con product_instance_caching siguen mostrando el aviso de incompatibilidad de siempre en la pantalla de Features.
¿Qué extensiones pueden tener problemas de compatibilidad?
La respuesta honesta: durante la fase experimental, ninguna. WooCommerce dice que no identificó incompatibilidades en el ecosistema de extensiones mientras la función estuvo en pruebas. Por eso se animaron a invertir el default.
Eso sí: el sistema sigue dejando la puerta abierta para que una extensión se declare incompatible si su autor lo considera. ¿Cómo identificás un conflicto en tu tienda? Andá a WooCommerce > Settings > Advanced > Features y fijate si alguna extensión surge un aviso de incompatibilidad con el product instance caching. Si lo ves, esa extensión es la que pidió quedar afuera.
Un consejo de quien migró tiendas más veces de las que quisiera: antes de confiar a ciegas, probá en staging. Subís una copia, activás los plugins que usás de verdad, recorrés fichas de producto y un par de checkouts, y mirás si algo se comporta raro. Después lo pasás a producción tranquilo. Relacionado: actualizar WooCommerce de forma segura.
¿Cómo afecta el caché de productos al carrito y al checkout?
Esta es la duda que más miedo da, y la respuesta tranquiliza. El product object caching no cachea el carrito ni el checkout. Esas páginas no deben cachearse nunca, porque son personales: muestran lo que cada cliente tiene en su carrito, con su precio y su stock.
Lo que este caché acelera es la carga de los objetos de producto que esas páginas usan por detrás, dentro de un mismo request. El cliente sigue viendo datos actualizados. Si cambiás un precio o se agota el stock, eso se refleja, porque el caché se limpia entre requests y no arrastra datos viejos a la próxima visita.
Distinto es el problema clásico de sesión y cookies (que un caché de página mal configurado te muestre el carrito de otro usuario). Ese riesgo vive en el caché de página, no acá. El object caching request-scoped no lo toca.
Esto se conecta con nuestro artículo sobre Product Object Caching Enabled by Default for New Stores in, que profundiza bastante en el tema.
Si querés simplificar esto, el editor productos WooCommerce es donde administrás todo desde un único lugar.
Si querés profundizar, tenemos un artículo que cubre los cambios deprecados WooCommerce 11.0 en detalle.
Si querés saber más sobre esto, en nuestro artículo de object caching en WooCommerce 11 lo explicamos en detalle.
Qué está confirmado y qué no
- Confirmado: activación por defecto en tiendas nuevas con 11.0, según el anuncio oficial de WooCommerce del 17/06/2026.
- Confirmado: las tiendas existentes no se ven afectadas al actualizar.
- Confirmado: mejoras de 9-12% en productos variables y 6-12% en bundles, cifras heredadas del anuncio original.
- Confirmado: no se detectaron problemas de compatibilidad durante el período experimental.
- No especificado en el anuncio: si habrá un activador oficial en un clic para tiendas existentes en futuras versiones. Por ahora, en una tienda vieja, queda en manos del desarrollador.
Errores comunes al pensar este caché
- Creer que se activa solo al actualizar: no. Si venías de 10.x y pasás a 11.0, tu tienda no lo prende sola. Solo las instalaciones frescas.
- Confundirlo con Redis: este caché es request-scoped y se borra al terminar la petición. No reemplaza un object cache persistente. Podés (y conviene) tener los dos.
- Pensar que va a cachear el carrito: no cachea carrito ni checkout. Acelera la carga de productos por detrás, nada más.
- Desactivar plugins por las dudas: antes de bochar una extensión, verificá en la pantalla de Features si realmente se declaró incompatible. Lo más probable es que no.
Preguntas Frecuentes
¿Qué es el caché de objetos de productos en WooCommerce 11.0?
Es un caché en memoria que guarda los objetos de producto durante un único request y los reutiliza en vez de reconstruirlos desde la base de datos. Es no persistente: se limpia entre peticiones. WooCommerce lo activa por defecto en tiendas nuevas instaladas con la versión 11.0.
¿Cuánta velocidad gano si activo el product object caching?
Los productos variables cargan entre 9% y 12% más rápido en la página de producto, y los productos bundle procesan entre 6% y 12% más rápido durante el checkout. El impacto es mayor en catálogos grandes y productos con muchas variaciones, donde se repiten más las lecturas. Esto se conecta con lo que analizamos en configurar tu tienda desde cero.
¿Se activa automáticamente en nuevas tiendas WooCommerce 11?
Sí, en instalaciones frescas con WooCommerce 11.0 o superior viene activado de fábrica, sin configuración manual. Las tiendas existentes que actualizan a 11.0 no se ven afectadas y conservan su configuración actual.
¿Qué extensiones tienen problemas de compatibilidad con este caché?
Durante el período experimental WooCommerce no identificó ninguna incompatibilidad en el ecosistema de extensiones. Desde la versión 10.6, las extensiones sin declaración explícita se asumen compatibles; solo las que se declaran incompatibles con product_instance_caching siguen mostrando el aviso correspondiente.
¿Cómo afecta el caché de productos al checkout y al carrito?
No los cachea: el carrito y el checkout no deben cachearse porque son páginas personales. Este caché solo acelera la carga de los objetos de producto que esas páginas usan por detrás dentro de un request. Los clientes siguen viendo precios y stock actualizados.
Conclusión
WooCommerce dio un paso prolijo: probó la función como experimental, no encontró conflictos, dio vuelta el default de compatibilidad y recién ahí la activó por defecto en tiendas nuevas. Nada de apurar un cambio sobre tiendas en producción.
Si arrancás una tienda desde cero con la 11.0, ya tenés el caché de objetos WooCommerce trabajando a tu favor sin hacer nada. Si venís de una versión anterior, sabé que no se prende solo, y que este caché convive con tu Redis y tu caché de página, no los reemplaza. Para sacarle todo el jugo, lo que importa es que tu infraestructura acompañe: un hosting WordPress con buena RAM y object cache persistente te suma sobre lo que ya trae WooCommerce. Probá en staging, revisá la pantalla de Features y, si todo anda, dejalo correr.
¿Funciona el caché de objetos en WooCommerce 10.9?
No se activa automáticamente. El caché de objetos estaba disponible desde WooCommerce 10.5 como feature experimental, pero solo se prende por defecto en tiendas nuevas desde la versión 11.0. En 10.9, si querés usarlo, tenés que revisarlo en staging primero.
¿Qué pasa si actualizo desde 10.9 a 11.0?
Si actualizás una tienda existente de 10.9 a 11.0, el caché de objetos NO se activa solo. Tu tienda sigue con su configuración actual, sin cambios en el comportamiento. El caché solo se prende automáticamente en instalaciones nuevas.
¿El caché de objetos de 11.0 es distinto al de 10.9?
Es el mismo mecanismo, pero con diferente estrategia de activación. Desde la versión 10.5 funciona igual: guarda objetos de producto en memoria durante un único request. La novedad en 11.0 es que se prende por defecto en tiendas nuevas, para acelerar desde el primer día.
Fuentes
- WooCommerce Developer Blog – Product Object Caching Enabled by Default for New Stores in WooCommerce 11.0
- WooCommerce Developer Blog – Experimental Product Object Caching in WooCommerce 10.5
- WooCommerce Developer Blog – What’s Coming for Developers in WooCommerce 10.6
- WooCommerce – Recomendaciones de servidor
- AyudaWP – Estrategias de caché en WordPress
