Priorizando las Core Web Vitals para visitantes con alta intención

Priorizando las Core Web Vitals para visitantes con alta intención

Muchos de mis clientes se preocupan profundamente por aprobar las Core Web Vitals. Aprobar las Core Web Vitals significa que el 75% de todo el tráfico debe aprobar las Core Web Vitals. ¡Un objetivo admirable! Pero al optimizar para el 75% de los visitantes, un grupo pequeño pero crítico de alrededor del 5% de los visitantes puede pasarse por alto. Desafortunadamente, a veces ese es el grupo más importante: ¡los visitantes que se convertirán en clientes!

Encontrando puntos ciegos en el análisis de CWV

Si bien centrarse en las métricas generales de CWV es esencial para una buena experiencia de usuario, puede enmascarar problemas de rendimiento que afectan específicamente a los visitantes de alto valor. La optimización de las Core Web Vitals, principalmente debido al bono de Google, tiende a centrarse en optimizar al 'visitante ligeramente por debajo del promedio'.

En el comercio electrónico, tiene mucho sentido ir más allá de esto y añadir un enfoque extra en los visitantes con alta intención.  Esos son los visitantes que se convierten en clientes. Optimizar las Core Web Vitals para estos segmentos de visitantes conducirá a mayores tasas de conversión y menor abandono del carrito. 

Normalmente podemos identificar a estos usuarios por la cantidad de artículos en su carrito. 

Ahora aquí está el problema: añadir artículos a un carrito de compras puede impactar las Core Web Vitals. ¡El problema son los plugins de caché!

Los plugins de caché a menudo deshabilitan el almacenamiento en caché para usuarios con contenido dinámico. El contenido dinámico es contenido que cambia por usuario. Algo tan simple como 'artículos en un carrito de compras', obliga al servidor a reconstruir la página completa con cada solicitud. Esto aumenta significativamente el Time to First Byte, llevando a un First Contentful Paint y Largest Contentful Paint más lentos. Como resultado, los usuarios con intención de compra experimentan un sitio web más lento en comparación con aquellos que simplemente navegan.

Priorizando el rendimiento para contenido dinámico

Ve más allá de los plugins de caché: No dependas únicamente del plugin de caché. Intenta solucionar tantos problemas subyacentes y cuellos de botella como puedas antes de recurrir al plugin.. Analiza tu código backend, optimiza las consultas a la base de datos, ajusta el servidor para asegurar un TTFB rápido, incluso sin plugins de caché.

Caché parcial: Considera almacenar en caché partes más pequeñas de tu sitio que consuman mucho CPU o tiempo para generarse al vuelo. Esto te permitirá, cuando el caché de página completa esté deshabilitado, generar rápidamente la página entera. Tu CMS normalmente  soportará caché parcial con Memcached o Redis.  

Client-Side Rendering (CSR) para componentes dinámicos: Considera implementar CSR para usuarios logueados. Con el client side rendering, la mayoría de la página todavía se sirve como HTML en caché (esta parte es renderizada en el servidor) mientras que partes más pequeñas y dinámicas de la página (como el carrito, o resultados personalizados) son renderizadas en el cliente. Después de que la página se carga, el navegador usa JavaScript y AJAX para obtener contenido dinámico (como información del carrito) e inyectarlo en la página estática, haciéndola parecer dinámica.

Gestión efectiva del caché:  Soy un gran fan del caché y te animaré a implementar estrategias efectivas de gestión de caché como el keyed caching. Usa claves simples  para elementos estáticos (por ejemplo, una URL podría ser suficiente como clave para una página en caché) y usa claves complejas  para contenido dinámico como carritos de compras (la clave podría incluir el ID de usuario, IDs de producto, y marcas de tiempo para asegurar que los datos recuperados coincidan con el carrito específico del usuario).