Siempre se ha dicho que la experiencia del usuario es la clave del posicionamiento SEO y Google la está teniendo cada vez más en cuenta. Por esta razón, lanzaron lo que ellos llaman Core Web Vitals, métricas que ayudan a los profesionales de SEO y a los webmasters a comprender mejor la experiencia del usuario de un sitio web.

Pero, ¿qué miden exactamente estas métricas y cómo sabemos qué nos piden que mejoremos?

¿Qué son Web Vitals?

Ya hemos dicho que Web Vitals son métricas que nos proporciona Google para entender la experiencia que obtiene un usuario en una página web.

Cuando hace unos años hablábamos de mejorar la experiencia de usuario de un sitio web, nos centramos mucho en la velocidad de carga y cómo mejorarla. Muchos de nosotros nos hemos vuelto locos por conseguirlo.

Ahora Google nos está diciendo que no solo es importante la velocidad de carga, sino que hay muchos otros factores que deben tenerse en cuenta y nos facilita lo que son gracias a las siguientes métricas.

Cada uno de los Core Web Vitals representa una faceta diferente de la experiencia del usuario y dependiendo de la herramienta con la que los medimos, podemos extraer datos reales o datos de laboratorio. Luego veremos las diferentes herramientas para medir cada una de ellas.

Según Google, las métricas que componen Core Web Vitals cambiarán con el tiempo. En este momento, se centra en tres aspectos de la experiencia del usuario: carga, interactividad y estabilidad visual.

• El contenedor de pintura más grande (LCP)
• Retraso de la primera entrada (FID)
• Desplazamiento de diseño acumulativo (CLS)

Veamos cada uno de ellos por separado. ¿Qué quieren decir? ¿Cómo se pueden mejorar? ¿Cómo puedo medirlos?

Largest Containful Paint (LCP)

The Largest Containful Paint nos informa sobre el tiempo de renderizado de la imagen o el bloque de texto más grande visible en la ventana gráfica, incluida la primera pantalla de la web cuando un usuario la escribe como una ventana gráfica.

¿Cómo sabemos si tenemos un buen LCP?

La carga de un sitio web generalmente comienza con texto y continúa con imágenes o videos. Con esto, los usuarios pueden tener una mejor experiencia de usuario mientras navegan por la web.

Si los elementos de tu sitio web tardan mucho en cargarse, no será bueno para tu posicionamiento SEO. Según Google, para proporcionar una buena experiencia de usuario, los sitios web deben tener un LCP de menos de 2,5 segundos.

Más precisamente, las herramientas de medición nos muestran tres escenarios diferentes:

• Bueno: para cargas de menos de 2,5 segundos.
• Necesita mejorar: para cargas de entre 2,5 y 4 segundos.
• Pobre: para cargas superiores a 4 segundos.

¿Cómo medir el LCP?

El LCP se puede medir de dos formas: con herramientas que nos muestran datos de laboratorio y con herramientas que nos muestran datos de campo (en realidad).

Es como consumir un auto. Cuando vas al concesionario te dicen que el auto consume 4.5 litros cada 100 km, pero cuando lo usas en realidad consume 5.5 😅

En efecto, la medida de 4,5 se calculó sin tener en cuenta los factores que se producen en la carretera como el viento, la carga del coche, la presión de las ruedas, etc … Por tanto, podemos decir que el 4, 5 litros Estos son datos de laboratorio y 5.5 son datos de campo.

Veamos cuáles son las diferentes herramientas con las que podemos medir LCP:

Herramientas de campo:

• Informe de experiencia del usuario de Chrome
• PageSpeed ​​Insights
• Search Console (informe Core Web Vitals)

Herramientas de laboratorio:

• DevTools de Chrome
• Lighthouse
• WebPageTest

¿Cómo podemos mejorar el LCP?

Para saber cómo podemos mejorar el LCP, primero debemos conocer cuáles son los principales problemas que lo empeoran.

Estos son los problemas:

Tiempo de respuesta del servidor lento

Cuando hablamos de cómo mejorar el tiempo de carga de un sitio web, el primer paso que recomendamos es alquilar un servidor rápido. No importa qué tan bien esté optimizado su sitio web, si el servidor es lento, seguirá teniendo problemas.

Bloqueo del proceso en CSS y JavaScript

Para comprender cómo CSS y JavaScript bloquean la representación de una página web, debemos comenzar por comprender cómo un navegador representa un sitio web.

Cuando un usuario accede a un sitio web, el navegador comienza a leer el código de arriba a abajo. Si encuentra un archivo CSS o JavaScript durante este proceso, debe detener la reproducción mientras espera descargar y procesar ese archivo.

Para resolver este problema, si está utilizando WordPress, simplemente instale un complemento que le permita cargar CSS y JavaScript de forma asincrónica. Recomiendo usar WP Rocket, pero si no desea invertir el dinero, recomiendo el dúo JavaScript Autoptimize + Async.

Carga lenta de recursos

Esta es una de las razones más comunes y probablemente se deba a que sus imágenes, videos u otras cosas son muy pesadas. Solo necesitas comprimir las imágenes y descargarlas en formatos menos pesados. Ayudará a que su sitio web se cargue más rápido. Además, también puede utilizar un sistema de caché que ayuda a cargarlos.

First Input Delay (FID)

FID mide el tiempo entre el momento en que un usuario interactúa por primera vez con una página y el momento en que el navegador responde a esa interacción. En español, se traduce como Latencia de la primera interacción.

Pero tenga cuidado, el FID solo mide el «retraso» en el procesamiento de eventos. No mide el tiempo de procesamiento de los eventos en sí ni el tiempo que tarda el navegador en actualizar la interfaz de usuario después de ejecutar los controladores de eventos.

¿Cómo sabemos si tenemos un buen FID?

Según Google, para que un sitio web proporcione una buena experiencia de usuario, un sitio web debe tener un FID de menos de 100 ms. Como cuando hablábamos de LCP, el FID también se muestra en tres intervalos:

• Bueno: hasta 100 ms.
• Necesita mejorar: hasta 300 ms.
• Pobre: ​​más de 300 ms.

¿Qué pasa si un usuario nunca interactúa con su sitio?

No todos los usuarios interactúan con un sitio web cada vez que lo visitan, y no todas las interacciones son realmente relevantes para FID.

Además, el FID dependerá de cuándo se produzca esta interacción. No es lo mismo interactuar cuando todavía hay procesos activos en la web que cuando la web está completamente cargada y el hilo principal está inactivo.

Dicho esto, podemos adivinar que es una métrica algo difícil de medir. Sin embargo, existe una herramienta en la que podemos confiar para poder cuantificar este proceso.

¿Cómo medir el FID?

A diferencia de LCP, donde podríamos medirlo con herramientas que usan datos de campo y con herramientas que usan datos de laboratorio, el FID solo se puede medir con herramientas que usan datos de campo. Estas herramientas son:

• Informe de experiencia del usuario de Chrome
• PageSpeed Insights
• Search Console (informe Core Web Vitals)
• Firebase Performance Monitoring (Beta).

Razones por las que podemos tener un FID incorrecto

Hay varias razones por las que podemos tener un FID malo o «malo». Veamos algunos de ellos:

Ejecución pesada de JavaScript

Si hay una gran ejecución de JavaScript durante toda la carga de la página, el navegador no podrá responder a la interacción del usuario. Algo que puede frustrar al usuario y por lo tanto no brindaríamos una buena experiencia de navegación.

Para resolver este problema, Google recomienda comprimir archivos JavaScript y eliminar los que no se utilizan.

Receso de tarea largo

Una interrupción prolongada de la tarea o una interrupción en JavaScript pueden provocar tiempos de respuesta de hasta 50 ms desde el momento en que un usuario realiza la acción.

Para resolver este problema, puede dividir estas tareas largas en otras más pequeñas. De esta forma, mostrarás lo que interesa a tu usuario en la pantalla sin tener que cargar todo primero.

Cumulative Layout Shift (CLS)

El Cumulative Layout Shift  (CLS) mide la suma total de todos los cambios de diseño inesperados que ocurren en la página web. Para que nos entendamos mejor, este es el tiempo que le toma a un sitio web poner todos los elementos en su lugar final.

No estoy seguro de si alguna vez has notado que en muchas páginas web, cuando comienzan a cargarse ven ciertos elementos en un lugar y cuando termina, están en otro. Bueno, el tiempo que tardan los elementos en terminar en su lugar final es el CLS.

¿Cómo sabemos si tenemos un buen CLS?

Según Google, para que un sitio web cumpla con los estándares de Core Web Vitals, el CLS debe ser inferior a 0,1 segundos. Como comentamos con las otras 2 métricas, también tenemos 3 notas:

• Bueno: hasta 0,1.
• Necesita mejorar: hasta 0,25.
• Pobre: más de 0,25.

¿Cómo medir el CLS?

En este caso, también podemos medir esta métrica con herramientas que usan datos de campo y herramientas que usan datos de laboratorio. En concreto, podemos utilizar las siguientes herramientas para analizar el CLS:

Herramientas de campo:

• Informe de experiencia del usuario de Chrome
• PageSpeed ​​Insights
• Search Console (informe Core Web Vitals)

Herramientas de laboratorio:

• DevTools de Chrome
• Lighthouse
• WebPageTest

¿Cómo puedo mejorar el CLS?

Como ya hemos visto, un CLS deficiente puede resultar muy aburrido. Pero, ¿cómo podemos mejorarlo?

Veamos algunas recomendaciones:

Optimizar el tamaño de la imagen

El problema de utilizar imágenes grandes en una página web es bien conocido. Si la imagen es más grande que el espacio en el que aparece, el navegador debe cambiar el tamaño de la imagen y esto aumenta considerablemente el tiempo de carga. Pero no solo eso, a veces también hace que las imágenes se muevan mientras se cargan.

Para evitar estos problemas, las dimensiones de las imágenes y los videos se pueden indicar mediante atributos en el código, como cuadros de relación de aspecto CSS.

Tamaño de banners y anuncios.

En caso de que vaya a utilizar anuncios o banners en su sitio web, primero debe asegurarse de que tengan el tamaño adecuado. Puedes pedir a los anunciantes que te sirvan anuncios con métricas específicas y con un peso determinado para que no afecte la experiencia de usuario de tu sitio web.

Evita usar contenido dinámico o pop ups

Cada vez más páginas web utilizan ventanas emergentes para captar la atención de sus lectores y aumentar su número de clientes potenciales. Este contenido dinámico influye en el CLS por lo que si evita su uso, mejorará la experiencia del usuario a ojos de Google.

Google Search Console y Web Vitals

Como ya hemos visto, todas las métricas se pueden analizar desde Google Search Console. Ahora, ¿cómo podemos ver qué URL están causando problemas y cuáles no?

En el menú de mejoras en el menú de la izquierda, hay una opción llamada Core Web Metrics que nos muestra las métricas de Core Web Vitals.

Una vez allí, veremos cómo la web nos divide entre la versión de escritorio y la versión móvil, y es que los sitios web no cargan igual cuando se ven desde una computadora que desde un móvil.

Mi recomendación es que mires principalmente la versión móvil ya que este dispositivo se usa cada vez más para la navegación. También le recomiendo que analice en Analytics si la mayor parte del tráfico de su sitio es móvil o de escritorio antes de comenzar a tomar decisiones. Pero ahora le digo que si puede optimizar con éxito su sitio web para dispositivos móviles, es probable que también lo haya optimizado para el escritorio.

Una vez aquí abrimos el informe que queremos y podemos ver qué URL están causando problemas para poder analizarlas y ver cómo optimizarlas.

Cómo afectan las Core Web Vitals al SEO

Según Google, en mayo de 2021, agregarán Core Web Vitals a sus múltiples factores de clasificación. Como ya hemos comentado al inicio del artículo, Google cada vez tiene más en cuenta la experiencia del usuario y es por ello que Web Vitals tendrá cada vez más peso en los factores SEO.

Google ya ha introducido un módulo en Google Search Console en el que nos muestra estas métricas. Es más que una pista que muestra cuán importantes pueden ser en SEO.

Por ahora, estas tres métricas que hemos visto conformarán Core Web Vitals.

Sin embargo, Google ya advirtió que se agregarán nuevas métricas que encajarán en la idea de la experiencia de la página.