No es que esté muy metido en WPO, pero cuando me dedico en cuerpo y alma a un proyecto web me gusta tener todo bien hilado y que no haya fugas por ninguna parte.
Es por eso que, cuando Google anunció las métricas web principales, o Core Web Vitals, me entusiasmé de pensar que los desarrolladores tendríamos una nueva forma de medir la calidad de nuestras webs y su experiencia para nuestros usuarios.
Para los que llegáis aquí de nuevas, empezamos por el principio.
Esquema del artículo
¿Qué son las Core Web Vitals?
Las Core Web Vitals son métricas que miden los diferentes aspectos que afectan a la navegación del usuario cuando entra en nuestro sitio web.
En pocas palabras, miden la experiencia de usuario (UX) durante la carga de tu web mediante unos valores consensuados entre San Google y los desarrolladores.
Al principio, cuando se anunciaron, únicamente se tenían en cuenta tres valores, el LCP, el FID y el CLS, y poco a poco han ido ampliando el número.
Google también ha indicado que tanto los valores para aprobar como el número de métricas consideradas están abiertas a cambios, y como ya hemos visto estos últimos meses, seguramente cambien.
Datos obtenidos del Chrome User Experience Report
A pesar de lo que pueda parecer, las Core Web Vitals no son unos datos obtenidos en una única prueba, conocidas como pruebas de laboratorio, sino que son el resultado medio de las métricas obtenidas del Chrome User Experience Report.
Este informe se elabora usando experiencias reales de los usuarios del navegador Google Chrome, tanto en escritorio como en móvil, que no se han negado a compartir datos anónimos.
De esta forma, y creo que es la mejor, los resultados de rendimiento de tu sitio web proceden de experiencias reales y no de una prueba puntual en un servidor que está cruzando el charco.
¿Qué factores tienen en cuenta las Core Web Vitals para posicionar?
A pesar de que claramente no parece que vaya a tener una gran repercusión, el caso es que oficialmente sí que dicen desde Google Search los valores y factores que se tendrán en cuenta.
Estos son:
- El tiempo de carga. Nada nuevo, en el antiguo Pagespeed Insights veíamos que esto ya era importante.
- La estabilidad visual. Esto significa que no hayan grandes movimientos de elementos durante el periodo de carga, ya que esto produce resignación por parte de los usuarios si pinchan en un elemento, se desplaza y equivocadamente pinchan en otro.
- Los bloqueos en página. Una de las peores experiencias en la web es que pinches en un elemento y tarde excesivamente en responder. Por tanto, este último factor es el del tiempo que tarda la web en estar disponible para la interacción.
¿Qué mide exactamente el informe de Lighthouse?
El informe de lighthouse hace una mezcla de resultados en los que junta las métricas del examen que se realiza a modo de simulación y los datos recogidos en los navegadores de tus visitantes.
Las métricas y las puntuaciones para sacar un 100 o el marcador en verde están actualizados a septiembre de 2021 con la versión 8 de lighthouse para móvil.
Estas siete métricas se miden casi todas en segundo/milisegundos y son las siguientes:
First Contentful Paint (FCP)
El First Contentful Paint, o primer pintado del contenido, es el tiempo que tarda en cargar el primer elemento de la parte superior de la página web, es decir, el above the fold.
Para conseguir poner el marcador en verde 🟢 este valor tiene que ser de 1,9 segundos o menos y para el 100 tendrás que dar 1060 milisegundos como máximo.
Speed Index (SI)
El Speed Index, o índice de velocidad, mide el tiempo total que tarda la página web en cargar. Hasta ahora este valor ha sido el genérico de relevancia en WPO, pero ahora acompaña al resto de métricas.
Para obtener una puntuación en verde 🟢 tienes que quedarte por debajo de los 3,4 segundos y para un 100/100 necesitas quedarte en 1,9 segundos o menos.
Largest Contentful Paint (LCP)
El Largest Contentful Paint, o pintado del contenido más grande, indica el tiempo que tarda en cargar el elemento más grande del above the fold y se mide en segundos. Recordar que el above the fold es ese espacio de la página web visible en el navegador antes de hacer scroll.
Para obtener el verde 🟢 en las métricas de Core Web Vitals necesitas que tarde como mucho 2,5 segundos, pero para el 100 en la nota, necesitas estar en 1,5 segundo o menos.
Time to Interactive (TTI)
El time to interactive, o tiempo en estar interactivo, mide el tiempo que tarda una web en estar completamente operativa, incluyendo el tiempo de procesamiento de estilos y javascript.
Para conseguir poner el marcador del informe de Lighthouse en verde 🟢 este valor tiene que ser de 3,8 segundos o menos y para el 100 sobre 100 tendrás que dar 1.860ms como máximo.
First Input Delay (FID)
El First Input Delay, o retardo de la primera interacción, mide el tiempo que pasa desde que el usuario interactúa con la web y el navegador la procesa.
Como ya he dicho antes, aunque las métricas de las Core Web Vitals las puedes obtener de test de laboratorio como lo es el informe de Lighthouse, la validez real de las métricas procede de experiencia real con usuarios navegando por nuestra web usando sus dispositivos propios.
Este valor solamente lo podemos obtener de los datos recogidos del Chrome User Experience Report, por lo que en pruebas de laboratorio como el caso de Pagespeed Insights, no aparece.
Por tanto, no se puede conseguir un 100%, sino que simplemente podemos obtener el marcado verde 🟢. Para ello debemos obtener de media 100 ms o menos.
Total Blocking Time (TBT)
El Total Blocking Time, o tiempo de bloqueo total, es el acercamiento del First Input Delay medido en laboratorio, es decir, en el reporte de Lighthouse.
Esta métrica se calcula sumando los tiempos de bloqueo que suceden durante la carga entre el First Contentful Paint y el Time to Interactive.
Para obtener el verde en esta métrica 🟢 necesitas quedarte por debajo de los 200 milisegundos, pero para el 100 en la nota, necesitas estar en 50 ms o menos.
Cumulative Layout Shift (CLS)
Por último, el Cumulative Layout Shift, o acumulación de cambios en el diseño, mide la estabilidad visual de la página durante la carga.
Arroja una puntuación del 0 al 1 en base al desplazamiento visual de los elementos durante la carga.
El resultado es proporcional al tamaño del elemento que se mueve y la distancia del desplazamiento.
Para conseguir poner el marcador del informe de Lighthouse en verde 🟢 este valor tiene que ser de 0,1 o inferior y para obtener la nota máxima necesitas un 0,03 o menos.
¿Dónde puedo medir las Core Web Vitals de mi sitio web?
Una vez que conocemos bien en qué consisten estas métricas, toca analizar nuestros sitios web para ver en qué condiciones están.
El primer lugar donde deberías ir a medir tu web es Pagespeed Insights. En esa web, después de introducir la URL de la página que quieres analizar, te arrojará un informe, conocido como Lighthouse report, y que te muestra las métricas de esa URL en 5 apartados:
- Datos de campo recogidos de usuarios reales sobre la velocidad de carga de esa página.
- Un resumen de las métricas “Core Web Vitals” recogidas los últimos 28 días de usuarios reales.
- Datos de laboratorio, cifras reales sobre los tiempos de carga tomadas en el momento de ejecutar el análisis.
- Oportunidades claras de mejora.
- Otros diagnósticos sobre el estado del rendimiento de nuestra página web.
Conocido este report, también puedes obtener datos sobre las métricas web principales en los siguientes sitios:
- El apartado de mediciones de Web.dev, dónde además del informe de rendimiento podremos obtener un informe más completo incluyendo los apartados de accesibilidad, mejores prácticas y SEO.
- Usando la extensión de Chrome Web Vitals puedes ver tres de estas métricas en tiempo real usando como laboratorio tu navegador: el LCP, el FID y el CLS. Además, si activamos la opción de Console Logging podremos ver qué elementos son los que más daño nos están causando a cada métrica, como qué elemento es el Largest Contentful Paint, y cuál es el que más se está moviendo para el Cumulative Layout Shift.
- Si te gusta cacharrear utilizando Google Chrome Dev Tools, en la pestaña de “Performance” o “Rendimiento” encontrarás un checkbox que se llama “Web Vitals”. Cuando realizas la grabación, en la franja de Timings te aparecen todas las Web Vitals, con su tiempo en milisegundos y haciendo referencia al elemento en cuestión.
- Por último, en el informe de Google Search Console, en la categoría de “Experiencia” tenemos tres apartados:
- Experiencia en la página, que te indica qué porcentaje de tus páginas tienen las Core Web Vitals en verde.
- Métricas Web Principales, que te señala qué páginas tienen puntuación ambar o roja en según qué Core Web Vital.
- Y por último, en Usabilidad Móvil, si las páginas están optimizadas para móvil.
- Experiencia en la página, que te indica qué porcentaje de tus páginas tienen las Core Web Vitals en verde.
No es bueno obsesionarse solamente con las Core Web Vitals
Y digo solamente porque, aunque no tengan excesivamente relevancia para el posicionamiento en las SERPS de Google, si que tiene importancia de cara cómo te perciben tus clientes.
Actualmente, y debido a toda la prensa que se le está dando desde finales del año pasado, estas métricas están en boca de todos. Vamos, lo que viene siendo una moda pasajera. Es por eso que la gente tiende a darle más importancia de la que realmente tiene.
Pasó lo mismo con el update de Google que dijo que iba a penalizar a las webs sin responsive y que el crawleo sería exclusivamente mobile. Años después la cosa sigue igual y no hemos visto esos cambios.
Las últimas noticias sobre el Page Experience update de Google que tenemos es que ya ha terminado el despliegue y los resultados reales los comenzaremos a ver de cara a comienzos de noviembre.
Prioridades SEO antes de optimizar las Core Web Vitals
Antes de meterse de lleno a realizar cambios de optimización de rendimiento, si realmente quieres mejorar el posicionamiento de tu sitio web en los resultados de búsqueda de Google, tienes que priorizar dar solución a otros problemas que te puedan estar sucediendo.
Un ejemplo de esto es revisar que todas las páginas web de tu sitio se puedan indexar correctamente, que las metaetiquetas estén bien configuradas, que no tengas bloqueados a los robots, que hayas realizado un interlinking interno coherente, que hayas trabajado las menciones (linkbuilding) desde webs externas, que el contenido de cada página resuelva una pregunta, que de respuesta al usuario, etc.
Primero el contenido y los enlaces, después la indexabilidad y los temas SEO técnicos y por último el rendimiento.
Ejemplos de errores en las Core Web Vitals al sobreoptimizar el WPO
Aquí la cagamos todos, yo el primero.
Muchas veces nos ponemos a meter plugins de optimización sin fijarnos detenidamente en qué está sucediendo en nuestro sitio web. Y puede ser que os pase lo que a mi me ha pasado.
Si tenemos una imagen en el above the fold, ya sabes, ese área visible en tu pantalla de la página web en el momento que carga y antes de hacer scroll, y esa imagen tiene lazy loading, esa imagen tardará en cargar el tiempo total de la página más el tiempo de descarga de la imagen.
Por lo tanto, este largest contentful paint se convertirá automáticamente en un lastre que te tirará esa métrica por tierra, al ser mucho mayor que todas las demás, y apareciendo en las Core Web Vitals de Google Search Console en rojo.
Más, si encima tenemos el caso que ese contenedor donde va la imagen no tiene un tamaño bien definido y debajo tenemos, por ejemplo, un botón, ese botón que aparece inicialmente en la posición donde debería ir la imagen se desplazará hacia abajo, tumbándote también la métrica de Cumulative Layout Shift.
Para solucionar esto tan solo necesitamos definir que esa imagen no tenga atributo “loading”, y que si lo tiene, sea un loading:“eager” para que cargue forzadamente junto a la carga inicial de la web.
Conclusiones finales y mi experiencia
Para los que llegáis de nuevas a la optimización de rendimiento web, o Web Performance Optimization (WPO) para los puristas, comentaros que trabajar teniendo delante estas métricas está muy bien.
Pero no debe obsesionarte antes de lanzar la web. Necesitas tráfico real para sacar conclusiones reales.
Y, encima, cada cambio requiere de, al menos, 28 días para mostrar los cambios en las métricas.
Así que mucha paciencia.
Un último consejo de WPO
Trabajar con un buen hosting te da la mitad del trabajo hecho. Para ello tienes que buscar un proveedor con caché de servidor, tipo litespeed cache, varnish o Apache+Plugin de cache para WordPress como WP-Rocket.
Y poco más tengo para ofrecerte hoy, si quieres compartir tu forma de afrontar las Core Web Vitals o te surge alguna duda, abajo en los comentarios puedes hacerlo sin problemas.
Fotografía principal realizada por @marceloleal80 en Unsplash
