Core Web Vitals para Ecommerce: Por qué los visitantes con alta intención obtienen el peor rendimiento

El problema de rendimiento invisible en el ecommerce

Muchos de mis clientes se preocupan profundamente por aprobar los Core Web Vitals. Aprobar significa que el 75% de todo el tráfico debería tener una buena experience. Un objetivo admirable. Pero al optimizar para ese 75%, se pasa por alto un grupo pequeño pero crítico de alrededor del 5%: los visitantes que se convertirán en clientes.

¿La ironía? Estos visitantes de alta intención a menudo obtienen el peor rendimiento en tu sitio. No porque te olvidaste de optimizar. Sino porque tu sistema de caché los excluye activamente.

Revisado por última vez por Arjen Karel en marzo de 2026

Por qué tus datos de CrUX ocultan el problema

La optimización de los Core Web Vitals, principalmente debido a la bonificación de clasificación de Google, tiende a centrarse en optimizar para el visitante ligeramente por debajo de la media. En el ecommerce, tiene mucho sentido ir más allá de esto y añadir un enfoque adicional en los visitantes de alta intención. Esos son los visitantes que se convierten en clientes.

Según la investigación de Deloitte y Google, una mejora de 0,1 segundos en la velocidad de la página conduce a un aumento del 9,1% en las acciones de añadir al carrito para los sitios de venta minorista. Ese es también el momento exacto en el que la caché deja de funcionar para ellos.

Normalmente podemos identificar a estos usuarios por el número de artículos en su carrito.

Hay otro punto ciego. CrUX (el Chrome User Experience Report) solo rastrea a los usuarios de Chrome que tienen habilitada la sincronización. Muchos compradores de ecommerce usan Safari en dispositivos móviles o navegadores sin sincronización. Tu panel de CrUX podría mostrar puntuaciones verdes mientras tus compradores reales experimentan algo muy diferente. Es por esto que una puntuación de CrUX aprobada no cuenta toda la historia.

El abismo de la caché: qué sucede cuando un usuario añade al carrito

Aquí está el problema: añadir artículos a un carrito de compras destruuye tu caché. Y la caché es lo que hace que tu sitio sea rápido.

Los plugins de caché desactivan la caché de página completa para los usuarios con contenido dinámico. Algo tan simple como "artículos en un carrito de compras" obliga al servidor a reconstruir la página entera con cada petición. Esto aumenta significativamente tu Time to First Byte, lo cual ralentiza directamente el Largest Contentful Paint y el First Contentful Paint.

Los números son dramáticos. En un sitio típico de WooCommerce, el TTFB pasa de aproximadamente 100 ms (en caché) a 1.600 ms o más (sin caché). Eso es un aumento de 16 veces en el tiempo de respuesta del servidor en el momento en que alguien añade un producto a su carrito. He visto casos donde los usuarios logueados de WooCommerce esperan de 5 a 9 segundos por una página que carga en menos de un segundo para visitantes anónimos.

Cómo lo maneja cada plataforma

WooCommerce establece varias cookies cuando un usuario añade al carrito: woocommerce_cart_hash, woocommerce_items_in_cart y wp_woocommerce_session. En el momento en que cualquier plugin de caché (WP Rocket, LiteSpeed Cache, WP Super Cache) detecta estas cookies, omite la caché para cada página. No solo la página del carrito. Tu página de inicio, tus páginas de productos, tus páginas de categorías: todas sin caché. Además de eso, WooCommerce dispara una petición AJAX a /?wc-ajax=get_refreshed_fragments en cada carga de página para mantener actualizado el widget del mini-carrito. Esta petición por sí sola puede tomar de 2 a 3 segundos en alojamiento compartido.

Esta es una de las razones por las que WooCommerce tiene la tasa de aprobación de Core Web Vitals más baja de todas las principales plataformas de ecommerce. Según el Web Almanac 2025, solo el 33% de los sitios de WooCommerce aprueban los tres Core Web Vitals en escritorio, comparado con el 76% de Shopify.

Shopify maneja esto mejor gracias a su infraestructura CDN gestionada, pero incluso Shopify no puede almacenar en caché las páginas que contienen objetos customer o cart. La diferencia es que el TTFB base de Shopify (alrededor de 0,51 segundos) ya es lo suficientemente rápido como para que la penalización sin caché sea menor.

Magento 2 encontró una solución ingeniosa: la página completa siempre se almacena en caché, incluso para los usuarios con carrito. El contenido dinámico (mini-carrito, saludo al usuario, estado del stock) se obtiene del lado del cliente a través de AJAX a /customer/section/load/ y se almacena en el localStorage del navegador. La página en sí permanece en la caché de página completa. Este es el problema de "lento por diseño" resuelto a nivel de arquitectura.

Tus mejores clientes obtienen tus peores páginas

Los números hacen que esto sea doloroso. Farfetch midió una caída del 1,3% en la tasa de conversión por cada 100 ms de aumento en el LCP. Blue Triangle encontró una disminución de la tasa de conversión del 40 al 50% cuando el LCP pasa de 2 segundos a 4 a 5 segundos.

Un visitante navega por tu sitio rápido y en caché. Encuentra un producto que le gusta. Hace clic en "añadir al carrito". En ese exacto momento, la caché se detiene y su TTFB salta de 100 ms a 1.600 ms. A partir de aquí, cada página que visite (comparando productos, revisando el envío, dirigiéndose al pago) no estará en caché. Las personas con más probabilidades de comprar ahora están navegando por la versión más lenta de tu sitio.

En los sitios monitoreados por CoreDash, vemos que los usuarios con carrito experimentan un TTFB de 3 a 5 veces peor que los visitantes anónimos en plataformas de ecommerce autoalojadas. En plataformas gestionadas como Shopify la brecha es menor (1,5 a 2x) pero aún medible.

Cómo detectar esto en tus datos RUM

No puedes ver este problema en Lighthouse o PageSpeed Insights. Esas herramientas prueban como visitantes anónimos sin cookies. Tus puntuaciones de laboratorio se verán geniales mientras tus compradores reales luchan.

Para encontrar este problema, necesitas Real User Monitoring. Segmenta tus datos de RUM según si el usuario tiene una cookie de carrito establecida. Compara el TTFB, FCP y LCP entre estos dos segmentos. Si ves una brecha de 2x o mayor, la omisión de la caché es tu problema.

En la mayoría de las plataformas de analítica también puedes segmentar por tipo de página. Compara tus páginas de listado de productos (generalmente en caché) con tus páginas de carrito y pago (nunca en caché). Una diferencia de TTFB de más de 500 ms entre estos tipos de página es una señal de alerta de que tu duración de espera del servidor requiere atención.

Cómo solucionar el rendimiento para los visitantes de alta intención

Arregla el backend antes de depender de la caché. No dependas únicamente de los plugins de caché. Analiza tu código backend, optimiza las consultas a la base de datos y ajusta tu servidor para asegurar un TTFB rápido incluso sin caché. Un sitio que es lento sin caché será catastróficamente lento para los usuarios con carrito. La sub-parte de duración de la caché del TTFB no debería estar haciendo todo el trabajo pesado.

Utiliza la caché parcial (caché de fragmentos). Almacena en caché las partes costosas de tu página por separado. Las descripciones de productos, los menús de navegación y el contenido del pie de página rara vez cambian y pueden almacenarse en caché en Memcached o Redis incluso cuando la caché de página completa está desactivada. Cuando un usuario con carrito solicita una página, tu CMS la ensambla a partir de fragmentos en caché en lugar de regenerar todo desde cero. Esto puede reducir el TTFB sin caché entre un 60 y un 80%.

Renderiza los componentes dinámicos del lado del cliente. Este es el enfoque de Magento 2 y funciona. Sirve la mayor parte de la página como HTML en caché (renderizado del lado del servidor). Luego usa JavaScript y una pequeña llamada a la API para obtener las partes dinámicas (conteo del carrito, saludo del usuario, recomendaciones personalizadas) después de que cargue la página. El navegador obtiene el HTML rápido y en caché inmediatamente. Los bits dinámicos se completan un momento después. Tus LCP y FCP se mantienen rápidos porque son impulsados por la estructura en caché, no por el contenido dinámico.

El framework headless de Shopify (Hydrogen) hace exactamente esto: los datos del producto se almacenan en caché de forma agresiva con TTL largos, mientras que los datos del carrito y del cliente usan CacheNone() y se obtienen del lado del cliente después de cargar. Este patrón también evita los problemas de INP porque la obtención dinámica ocurre asíncronamente en lugar de bloquear la interacción del usuario.

Implementa una gestión eficaz de claves de caché. Usa claves simples para los elementos estáticos (la URL es a menudo suficiente como clave de caché) y claves complejas para el contenido dinámico que incluye el ID de usuario, los ID de productos y marcas de tiempo. Esto te permite almacenar en caché a nivel de usuario en lugar de tener que elegir entre "completamente en caché" o "nada en caché".

Desactiva los fragmentos del carrito en páginas que no son de carrito. Si ejecutas WooCommerce, desactiva la llamada a wc-ajax=get_refreshed_fragments en las páginas que no muestran un mini-carrito. Varios plugins de rendimiento (Perfmatters, FlyingPress) ofrecen un interruptor para esto. Esto elimina una llamada AJAX de 2 a 3 segundos en cada carga de página para los usuarios con carrito.

Considera la composición del lado del borde. Si usas Cloudflare, los Workers pueden ensamblar páginas en el borde (edge): sirven el cuerpo de la página en caché desde la CDN e inyectan fragmentos dinámicos (carrito, información del usuario) a través de sub-peticiones separadas. Cloudflare publicó una implementación de Edge Side Includes para Workers que hace exactamente esto, manteniendo tu TTFB rápido mientras sigues sirviendo contenido personalizado.