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.

El CLS es una métrica de las Core Web Vitals de Google que mide el desplazamiento que sufren los elementos de la web cuando otros elementos se cargan.

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: Indicado por el FID (”First Input Delay”)

Esta es la métrica encargada de medir la interactividad de la página con el usuario, es decir, que mide el tiempo que pasa desde que el usuario interactúa con la página hasta que esta es capaz de responder a dicha interacción.

No hay nada más desesperante que hacer clic en algún lugar clicable y no obtener respuesta inmediata. Cuando pasa un eterno medio segundo vuelves a hacer clic más fuerte (yo lo hago)… pero no se trata de eso.

Cuál es el valor óptimo para el FID

Cualquier interacción que tarde más de 100ms en ser respondida es una interacción lenta para Google, por lo que el objetivo es tratar de estar por debajo de ese tiempo.

¿Te parece poco? A mi no. Ten en cuenta que a menudo no se trata de una sola interacción la que realizamos con una web. A menudo esta interacción nos lleva a una segunda interacción. Pero de todas formas, los seres humanos vivimos anclados cada vez más a lo inmediato. Si pulso y no lo obtengo ya no me gusta.

Por qué el FID puede ser malo

Puede haber muchas causas para este retardo en las acciones solicitadas por el usuario, pero la más común es la que causa un JavaScript muy pesado. Cuando esto ocurre el usuario trata de interactuar con la página, pero está no es capaz de responder porque está ocupado ejecutando un script muy pesado.

¿Cómo se puede mejorar el FID?

Para empezar, te dire que a la hora de realizar cualquier acción para mejorar el FID has de tener en cuenta que este no se puede medir con “Lab Data”, por lo que tardarás en ver los resultados unos 28 días.

En este sentido vamos un poco a ciegas, lo sé… y podría darte otros indicadores que lo sustituyan, pero no son lo mismo.

Por ejemplo, el tiempo total de bloqueo (Total Blocking Time), que e es el que Google recomienda mirar, es un concepto muy distinto al tiempo de respuesta de una interacción. Así que, si conoces alguna forma de evaluar esta métrica en tiempo real no dudes dejármela en los comentarios.

De cualquier forma, Google nos da algunas pistas con 4 recomendaciones que puedes consultar en este enlace, pero te adelanto que son estas:

  • Dividir las tareas más largas.
  • Optimizar tus páginas preparadas para la interacción.
  • Usar un “trabajador web”
  • Reducir el tiempo de ejecución del JS.

¿Vale la pena optimizar las Core Web Vitals?

Con todo esto que hemos dicho, la gran pregunta es… ¿realmente importan las CWV tanto como para que debas dedicar tu tiempo, esfuerzo y potencialmente dinero a mejorarlas?

Y como casi todas las respuestas en SEO: “depende”

Mi opinión personal es que si tu intención es pasar de la segunda página de Google a los primeros puestos de la primera… en ese caso te diría que centres tus esfuerzos en otras cosas, porque casi seguro que las Core Web Vitals no van a ser el problema.

Un contenido excelente con unas CWV “regulinchis” siempre va a ser mejor que unas Core Web Vitals espectaculares con un contenido que es una 💩.

¿No me crees? Vale. Pues a lo mejor crees a John Muller, que ya cuando empezaba a hablar de las Web Vitals señalaba que otros factores son más relevantes para el SEO, como, por ejemplo: el contenido relevante:

Así que, mi consejo es que le eches siempre un ojo a las Core Web Vitals, pero que no te importe demasiado si tu web es nueva y todavía no has trabajado otros aspectos como la generación de contenido relevante, enlazado interno, arquitectura del sitio…

Empieza a preocuparte si tu web tiene autoridad y contenido relevante para una consulta pero tienes mucha competencia en las SERPs y te cuesta alcanzar una visibilidad mejor. En ese caso es más provable que estas mejoras marquen la diferencia entre tu web (que ya tiene otros aspectos muy optimizados) y las que te superan en las SERPs.

Pero, si tienes un contenido muy relevante para una consulta concreta y además has generado autoridad sobre ese asunto… entonces estoy completamente seguro de que Google no va a penalizar tu web porque sus elementos se desplacen un poco mas durante el proceso de carga.

También estoy seguro de que no priorizar contenidos peores en las SERPs simplemente porque estos obtengan unos valores alucinantes en las Core Web Vitals.

Así que: analizar las CWV está genial, pero dándole a estos resultados el valor que realmente le corresponde.

Ahora forma parte del algoritmo de Google, eso es cierto. Pero la mayoría de los webmasters no tienen conocimientos ni capacidad para perfeccionar estos valores. Por lo tanto “la batalla” estará casi siempre en otros factores más importantes dentro del propio algoritmo.

Deja un comentario