Las Core Web Vitals son la forma en la que Google mide la experiencia de los usuarios en cada página… y no es ninguna novedad que una buena experiencia de usuario es uno de los aspectos más importantes para Google a la hora de decidir la visibilidad en los resultados que muestra.
¿Qué son las Core Web Vitals?
En realidad, las CWV (que se traduciría como ¿“principales signos vitales de la web”? 🤔) no son más que una guía que Google nos facilita a los webmasters para que, mediante un conjunto de indicadores de calidad, podamos evaluar de forma objetiva la experiencia de los usuarios de una página.
Ojo, que digo “página” y no “sitio web” porque, al igual que cuando trabajamos el WPO, la experiencia se mide siempre a nivel de página. A pesar de que muchas optimizaciones puedan afectar a todo un sitio web, la experiencia de un usuario puede ser buena al visitar una página de tu sitio, pero nefasta en otra.
En principio, el motivo por el que Google facilitó está guía es para unificar y facilitar la información de las distintas herramientas que, a lo largo del tiempo, a ido poniendo a disposición de los webmasters para medir diferentes aspectos que afectan a la experiencia de los usuarios en la página.
Se trata de hacer accesibles este tipo de mediciones para todo el mundo al mostrar estos indicadores unificados bajo las Core Web Vitals… y la verdad es que lo consiguieron: ahora es más fácil ver estos indicadores. Otra cosa es la facilidad de optimizar unos y otros. Pero de eso ya hablaremos.
¿Qué tipos de datos utiliza Core Web Vitals?
Field data
Los que podríamos llamar “datos de campo” incluyen datos reales obtenidos de los usuarios para estas métricas.
Estos datos se generan a partir del informe de experiencia de usuarios en Google Chrome (también conocido como CrUX) y se obtienen, principalmente, de los usuarios que usan Chrome y han accedido a compartir información con el navegador.
¿Dónde consultar este tipo de datos?
Estos datos los puedes consultar en Google Search Console, en el resumen de los resultados de las Core Web Vitals que ofrece la herramienta.
Si lo que quieres es obtener estos datos a nivel de cada página individual puedes utilizar PageSpeed Insights para consultarlos. Allí los encontrarás en la categoría “Field Data”.
El problema del retraso en obtener los datos
El gran “pero” que tienen estos datos es que se muestran en estas herramientas de Google pasados unos 28 días desde que se producen.
Esto es un problema, sobre todo, porque si haces cambios no podrás ver los efectos de estos cambios hasta que transcurra ese período.
La solución pasa por no utilizar estos datos reales, sino utilizar los “datos de laboratorio” que te explico a continuación.
Lab Data
…o “datos de laboratorio” como podríamos llamarlos en español, son los datos que se generan a través de herramientas. Es decir, que no son datos reales obtenidos de la experiencia real de usuarios reales navegando de forma real por nuestra web.
Son datos que se obtienen a partir de robots que visitan nuestra web.
El “pero” de estos datos es que los robots van a obviar cuestiones como la velocidad de conexión de los diferentes usuarios reales, su localización geográfica o la forma en la que interactúan con el contenido (cosa que los robots no van a hacer).
Estos datos los puedes obtener utilizando la exxtensión de Lighthouse en Chrome, en las PageSpeed Insights y en las herramientas de desarrolladores de Google Chrome.
¿Cuáles son las métricas principales de las Core Web Vitals?
Las Core Web Vitals miden 3 aspectos referentes a la experiencia del usuario en la página web y, para cada uno de ellos usa una métrica diferente.
Veamos con algo más de detalle estos 3 aspectos en los que se centran.
Carga visual: medida por el LCP (”Largest Contentful Paint”)
Para medir el rendimiento de la carga visual en nuestra web Google utiliza el LCP (o “Largest Contentful Paint”)… pero si te digo esto a lo mejor te dejo como estabas: sin saber que es exactamente la “carga visual” y con un palabro en inglés y unas siglas que no te aportan nada. Vamos a solucionarlo.
La “carga visual” hace referencia al elemento más grande que se carga en el viewport (otro palabro que hace referencia a la parte de la página que vemos en la pantalla cuando se carga).
Pues el LCP lo que mide es el tiempo que tarda en cargarse este elemento.
Para que lo veas más claro te pondré un ejemplo: imagina un artículo típico de un blog en el cual, cuando se carga puede que veas algunos enlaces del menú en la parte de arriba del todo, un título, la imagen destacada, quizás algunas etiquetas (fecha, autor,…) y tal vez algo de texto del artículo.
Pues por lo general, el elemento más grande de la “carga visual” será la imagen destacada, que seguramente tendrá más peso y más prevalencia en la parte de la página que vemos cuando se carga.
Pero otras veces puede ser la etiqueta Title, un formulario,… o cualquier otra cosa. Dependerá de la página.
¿Cuál es el valor óptimo para el LCP?
Google recomienda mantener el LCP por debajo de 2,5 segundos, pero en mi experiencia, la mayoría de las veces no es complicado mantenerlo por debajo de 2 segundos.
Como siempre dependerá de cada caso la facilidad que tengas de reducir este tiempo, pero por encima de esos 2 o 2,5 segundos deberías revisarlo siempre.
¿Cómo medir el LCP?
El LCP lo puedes comprobar en cualquiera de las herramientas que Google facilita para medir las CWV. Más adelante te las muestro todas.
Pero si utilizas PageSpeed Insights o Lighthouse tienes la ventaja de que podrás utilizar “Lab Data” en vez de los datos reales de usuarios.
Esto es especialmente útil para comprobar los efectos que tienen los cambios que realices en el LCP sin esperar los eternos 28 días que Google tardará en actualizarse.
¿Por qué tengo un LCP alto?
Si esta métrica es más alta de lo deseado puede ser por muchos motivos, pero dos de los más comunes suelen ser:
- El servidor es muy lento (eso te pasa por no utilizar un hosting bueno de verdad como Raiola Networks
) - La carga de algún fichero Java Script puede que esté bloqueando el renderizado de ese elemento.
)Algunas acciones sencillas que suelen mejorar el LCP son, por ejemplo: utilizar una cache de contenidos, un CDN para servir los contenidos estáticos, y escoger un buen hosting.
Pero a parte de esto puede haber problemas por la renderización de imágenes, de CSS o JavaScript mal optimizado.
Estabilidad visual: medida por el CLS (”Cumulative Layout Shift”)
El CLS mide la forma en la que el contenido visible de la página se reorganiza durante el proceso de carga.
¿Alguna vez te ha pasado, que al cargar una web has tratado de pulsar sobre un enlace en el menú superior y en ese momento aparece un banner que desplaza el contenido hacia abajo?
La sensación de clicar en el banner en vez de acceder al contenido que buscabas es una sensación un tanto frustrante y para nada genera una buena experiencia de usuario.
Pues situaciones como estas son las que trata de monitorizar el CLS.
A veces será un banner como el del ejemplo y otras será un iframe que se carga más tarde o cualquier otro elemento.
Un detalle importante a tener en cuenta es que Google ha cambiado la forma de medir el CLS con el tiempo.
Al principio medía la estabilidad de la página todo el tiempo (incluso una vez que esta se había terminado de cargar). Sin embargo, actualmente mide el CLS en sesiones de 5 segundos.
Así que en mi opinión ya no hace honor al nombre pues por muy Cumulative Layout Shift que le llamen, de “Cumulative” ya no tiene tanto cuando no acumula los datos ¿no?
Cuál es el valor óptimo para el CLS
Al tratarse de una métrica del desplazamiento de los elementos durante la carga, obviamente será ideal que sea lo más bajo posible.
No obstante, Google considera que un valor por debajo de 0.1 ya es bueno.
Cuales son las causas de un mal CLS
Son muchas las situaciones en las que se puede producir un desplazamiento que empeore esta métrica en una página, pero hay algunas muy frecuentes y que se pueden solucionar (en muchos de los casos) de una manera bastante sencilla:
La solución en este caso es tan sencilla como añadir el ancho y alto en los atributos de su etiqueta html o utilizar el CSS para definir esos valores.
En este caso el problema es que cuando se cargan estos elementos desplazan al resto del contenido que ya estaba renderizado. Para evitar que se produzca este desplazamiento podemos reservar el espacio necesario definiendo el alto y ancho del contenedor que los incluirá. De esta forma evitamos un desplazamiento posterior y el usuario sabrá en todo momento donde se ubican los distintos elementos de la página.
La solución puede ser tan simple como llamar antes al fichero CSS o a la fuente desde el código HTML. Pero en ocasiones, si el archivo CSS es muy grande, puede que nos interese dividirlo y en la parte superior del código llamar únicamente a la hoja de estilos que evitarán esos desplazamientos de los elementos que empeoran el CLS.
En este caso dependerá mucho de cada caso en particular, pero la solución suele pasar por prever el tipo de contenidos que se inyectan y adaptar la estructura de la web para que el contenido inyectado no provoque un movimiento de los otros elementos de la página.
Interactividad: INP («Interaction to Next Paint»)
Imagina hacer clic en un botón y esperar eternamente a que la página reaccione. ¡Una pesadilla, verdad? Bueno, el INP (Interaction to Next Paint) es la métrica que mide exactamente eso, pero de una forma más completa: evalúa el tiempo que transcurre desde que un usuario interactúa con la página (como un clic, un toque o una pulsación de tecla) hasta que esta responde, considerando todas las interacciones, no solo la primera. Es como evaluar no solo la velocidad de respuesta de un camarero en un restaurante, sino también su consistencia durante toda la noche.
Valor óptimo del INP
Entonces, ¿cuál es el valor óptimo para el INP? Lo ideal es que el INP sea inferior a 200 milisegundos.
Si tu página responde consistentemente rápido, ¡eso es genial! Si tarda entre 200 y 500 ms, hay margen de mejora, pero todavía estás en el juego. Sin embargo, si el INP supera los 500 ms, tenemos un problema, y es hora de tomar medidas para mejorar la capacidad de respuesta.
Causas del INP
Pero, ¿qué causa un alto INP? Generalmente, se debe a procesos pesados en el navegador, como ejecución de JavaScript o tareas largas que bloquean el hilo principal. Aunque el contenido sea visible y parezca que todo está cargado, el sistema puede estar ocupado procesando otras tareas en segundo plano, causando retrasos en la respuesta a las interacciones del usuario.
Cosas como el código JavaScript pesado o con muchas peticiones pueden ralentizar el INP. Piensa en la carga de Tag Manager o Analytics, vídeos incrustados, píxeles de redes sociales o herramientas de medición como mapas de calor. Si estas solicitudes se cargan al principio, aumentarán el tiempo del INP.
El INP es una métrica crucial para causar una buena impresión en los usuarios. Si un usuario llega a tu sitio web, hace clic en un enlace y la página tarda en responder, probablemente se sienta frustrado y puede que abandone tu sitio. En la navegación móvil, la velocidad es aún más importante, ya que los usuarios tienen poca paciencia para esperar a que se cargue una página.
Cómo medir el INP
Entonces, ¿cómo puedes medir el INP de una URL? Afortunadamente, existen varias herramientas para ello. La más recomendada es el Inspector de Chrome para medir las Core Web Vitals, que te mostrará el tiempo que tarda en producirse cada interacción y el valor correspondiente del INP.
Recuerda que el INP es una métrica de campo, lo que significa que necesitas datos de usuarios reales, ya que Google no puede simular la interacción del usuario. Así que no te conformes con pruebas de laboratorio, asegúrate de obtener métricas reales.
Google te explica aquí más en detalle cómo mejorar el INP.
