¿Qué son las Core Web Vitals?
Hoy vamos a hablarte de una de las últimas novedades anunciadas por Google, las Core Web Vitals. Detrás de ese nombre lo que tenemos son las nuevas métricas utilizadas por Google para impulsar una mejor experiencia de usuario y evaluar la velocidad de carga de una web.
Google lleva tiempo trabajando en este sentido y empujando para que los usuarios disfruten de un ecosistema web más rápido y que les ofrezca una mejor experiencia. Para ello ha lanzado herramientas como PageSpeed Insights o Lighthouse, ha impulsado la adaptación a móviles dándoles prioridad en su rastreo o apostado por iniciativas como AMP – Accelerated Mobile Pages-.
Las Core Web Vitals fueron anunciadas desde el blog de Chrome a principio de mayo como unas métricas esenciales para la salud de un sitio. Son el corazón de la nueva iniciativa Web Vitals, la cual además de dichas métricas incluye una serie de herramientas y guías para ayudar a los desarrolladores a cumplir el objetivo de ofrecer una experiencia de usuario perfecta.
Más recientemente hubo un nuevo anuncio por parte de Google, esta vez en su blog para webmasters, en el que avisa de que están trabajando para incorporar las nuevas métricas como factores de posicionamiento en su ranking de resultados de búsqueda.
Como ya hemos anticipado, se trata de un nuevo conjunto de métricas útiles para valorar la velocidad de carga, el tiempo de respuesta y la estabilidad visual de una web, con el objetivo de poder brindar una mejor experiencia de navegación a los usuarios.
Google lleva años ofreciendo diferentes herramientas y guías para ayudar a los propietarios de sitios web a medir y mejorar el rendimiento de sus páginas. Después de un tiempo ha llegado a la conclusión de que podía estar dando un exceso de recursos e información que acaban complicando la vida a los responsables de las web en vez de ayudarles.
Con la iniciativa Web Vitals su objetivo es unificar criterios, simplificar este panorama y ayudar a los sitios a centrarse en lo que realmente consideran importante, las Core Web Vitals. Con este objetivo han reducido todo a 3 métricas clave, cada una centrada en una faceta específica de la experiencia de usuario.
El LCP se centra en la velocidad de carga, concretamente trata de medir cuánto tiempo pasa hasta que el usuario puede percibir como “cargada” una web, es decir, cuando ve totalmente renderizados los elementos que aparecen en su pantalla al acceder a una url.
Para ello se mide cuando se ha pintado el elemento de contenido que ocupa el mayor espacio en la pantalla del usuario al cargarse la página, dando por hecho que en ese momento será visible la mayor parte del contenido que se muestra en pantalla. Y para que este dato se consideré bueno no debería superar los 2’5 segundos.
Establecer esto no ha resultado sencillo y por eso se han venido utilizando diferentes métricas a lo largo del tiempo. Inicialmente se utilizaron los eventos load, que se activa cuando se ha cargado toda la página incluyendo estilos, imágenes, etc. y DOMContentLoaded, que se activa cuando se ha cargado el html inicial (sin esperar a cargar nada más). El problema es que estos eventos no son representativos de lo que el usuario ve en pantalla pecando en un caso por exceso y en otro por defecto.
De ahí se pasó a utilizar métricas de rendimiento más modernas que sí tenían en cuenta y buscaban centrarse en la experiencia de usuario como el FCP que mide cuando se pinta el primer elemento en pantalla. Sin embargo, no resulta útil en el momento en que se utilizan pantallas de bienvenida o indicadores de carga, por eso se empezó a recomendar tener en cuenta otras métricas. Se llegó a un punto en que todo se había complicado mucho y además las medidas no resultaban fiables para identificar cuando el usuario realmente percibe como cargada una página.
¿Qué elementos se consideran?
Actualmente se consideran los siguientes elementos de contenido:
- Imágenes (<img> e <image> dentro de un elemento <svg>).
- Imagen de portada de vídeos (elemento <video>).
- Elementos con una imagen de fondo cargada por css.
- Elementos de bloque html que contienen textos.
Aunque avisan de que se podrían añadir más elementos en el futuro si se consideran relevantes.
¿Cómo se determina el tamaño de un elemento?
Básicamente se tiene en cuenta el tamaño que ocupa dentro de la pantalla del usuario en el momento de cargar la página. Si un elemento se extiende más allá de la ventana visible para el usuario, solo se tiene en cuenta la parte que queda dentro de dicha ventana visible.
Además no se tienen en cuenta es espacio dedicado a márgenes, bordes, etc., esto es especialmente relevante en los bloques de texto, ya que solo se contabiliza el espacio del área más pequeña que ocupa el texto.
Otro dato curioso a tener en cuenta es que, en el caso de las imágenes que se muestran redimensionadas, se toma siempre el tamaño más pequeño. Es decir, si tenemos una imagen grande que redimensionados por css para mostrarla más pequeña utilizará el tamaño con el que se muestra, mientras que si tenemos una imagen pequeña y la estiramos utilizará el tamaño real de la imagen.
¿Cómo se decide cual es el elemento de mayor tamaño?
A veces conforme una web va cargando pasa por diferentes etapas que pueden hacer que el elemento de mayor tamaño vaya cambiando, para tener esto en cuenta el navegador va informando del elemento de mayor tamaño descubierto en las distintas fases de carga. Además, si un elemento considerado que es cargado inicialmente se considera el más grande pero acaba desapareciendo, es sustituido por el elemento más grande que acaba siendo visible al final de la carga.
En las imágenes anteriores puedes ver como en el primer caso, en la nueva home de nuestra web, en la primera carga de contenido (FCP) se detecta el encabezado como contenido de mayor tamaño y este se mantiene como tal hasta que la página ha cargado completamente, por lo que en este caso el valor del FCP y del LCP sería el mismo (1’5s). En cambio, en la segunda imagen lo que ves es como inicialmente se elige un texto cuando se empieza a pintar el contenido de la página, pero este cambia más adelante al cargar una imagen que ocupa el mayor espacio en pantalla, por lo que el LCP cambia (1,9s).
First Input Delay (FID)
La segunda métrica es el FID, en ese caso se centra en medir la interactividad de la página, es decir, el tiempo que el navegador tarda en responder ante la primera acción realizada por el usuario, como por ejemplo un clic en un enlace.
En este caso, a diferencia del LCP, se necesita una acción real de un usuario para poder medir el tiempo de respuesta, por lo que no podremos ver directamente este valor utilizando herramientas como Lighthouse. Como veremos más adelante tenemos formas de conocerlo si nuestra web ya es pública y en caso contrario podemos utilizar otras métricas para hacernos una idea de si lo estamos haciendo bien o no. Un buen valor para el FID no debe ser mayor de 100ms.
A todos nos ha pasado alguna vez que cuando parece que una web está cargada, tratamos de hacer algo en ella pero el navegador no responde, especialmente cuando navegamos desde el móvil. Normalmente esto ocurre porque aunque parece que la página se ha terminado de cargar y ya estamos viendo el contenido cuando tratamos de interactuar con ella en realidad el navegador está procesando algún fichero descargado de forma asíncrona, habitualmente ficheros de javascript, por lo que hasta que no haya terminado esa tarea no podrá responder a la petición del usuario generando un retraso o latencia entre la acción del usuario y la respuesta del navegador, este tiempo es precisamente lo que mide el FID.
Uno de los motivos de medir el retraso de respuesta solamente para la primera acción del usuario es precisamente que los principales problemas de interactividad de un sitio web se producen durante la carga inicial. Pero no es el único, también se puede justificar por la importancia de causar una buena primera impresión en el usuario y porque una latencia alta en la respuesta a acciones del usuario cuando la página ya está totalmente cargada suele tener su origen en problemas muy distintos, por lo que la métrica sería menos útil a la hora de poner una solución.
La imagen anterior representa la carga de una página web. Por un lado, en gris claro vemos representadas las peticiones de red hechas por el navegador para descargar los recursos necesarios desde el servidor (html, css, js, imágenes, etc.). Por otro lado, en azul vemos las tareas que el navegador realiza para procesar los recursos descargados y poder mostrar la web correctamente al usuario. Cuando las tareas de procesamiento han finalizado la página se considera completamente preparada para la interacción con el usuario (TTI).
Pero hasta aquí no ha habido todavía ninguna acción por parte del usuario y por tanto no sabemos cual es el FID, vamos a ver una situación en la que podríamos tener un FID elevado.
Sobre la primera imagen, ahora hemos representado una acción del usuario llevada a cabo a la vez que el navegador todavía está ocupado en una tarea, por lo tanto el usuario deberá esperar a que finalice dicha tarea antes de que haya una respuesta a su acción. Ese tiempo de espera es el valor FID para ese usuario en esa visita a la página.
Se mide desde el momento en el que el usuario realiza la acción hasta que el hilo principal de procesado del navegador queda libre para poder atenderla. De esta forma el FID no depende de que la acción tenga un detector de eventos asociado, ya que muchas acciones de usuario no lo requieren.
Podemos ver pues, que el FID depende mucho del momento en el que el usuario interactúa con nuestra página, por eso es necesaria una medición con interacciones reales de usuarios reales y lo que veremos será el tiempo promedio de respuesta. De hecho, habrá usuarios que no realicen ninguna acción en nuestro sitio y no generen valores de FID, otros que lo tengan muy bueno y otros no tanto.
Como ya hemos adelantado, se considera que el FID es bueno si es menor a 100 ms y si lo es, al menos, para el 75% de los usuarios que visitan nuestra web.
Cumulative Layout Shift (CLS)
Por último tenemos el CLS, que sirve para evaluar la estabilidad visual de la página. Esta métrica ofrece información sobre los movimientos inesperados que se producen en los elementos visibles de la página, tanto por desplazamiento como por cambio de tamaño de algún elemento. Para considerarse buena su valor tiene que ser inferior a 0,1.
La intención de Google con esta métrica, al igual que con las dos anteriores, es que sirva para ayudarnos a mejorar la usabilidad de la web. Hoy en día es muy habitual que al navegar por una web, sobre todo desde el móvil, veamos movimientos repentinos que generan desplazamientos en el texto que estamos leyendo o en peor de los casos nos pueden llevar a pulsar un botón erróneamente al aparecer justo en el hueco del enlace que queríamos clicar. Esto resulta molesto para el usuario y es precisamente lo que se pretende medir con el CLS para así poder detectar si nuestra web tiene un problema y en ese caso poner una solución.
¿Cómo puedo medir las Core Web Vitals de mi web?
Ahora que ya sabes lo que son las nuevas métricas de Google para mejorar la experiencia de usuario, probablemente lo siguiente que quieras saber es cómo medirlas en tu web. Antes de empezar a hablar de herramientas, es importante tener claro que existen dos formas de medir, utilizando datos de campo o en base a experimentos de laboratorio.
