Thread by @carlos_darko

👩‍💻 CORE WEB VITALS 👩‍💻

🏅 Hilo definitivo final | Mega-guía %%currentyear%% pre-update de Google

📚 Qué son, cómo medirlas y análisis al detalle de cada una de ellas con sus típicos errores y soluciones.

Este hilo contiene buena experiencia de usuario ⬇️

1⃣ ¿Qué son las Core Web Vitals?

Las Core Web Vitals son 3 indicadores que usa Google para medir la experiencia de usuario en una web.

Para ello, cada una representa un KPI clave:

LCP ➡️ Velocidad
FID ➡️ Interactividad
CLS ➡️ Estabilidad

Más detalles de dichas métricas luego.

Es importante tener presente que no es Googlebot el que mide dichas métricas, si no el propio navegador Chrome.

Si quieres ver cómo está la media en cuanto a puntuaciones para un sector concreto, puedes echarle un ojo a esta web:

corewebvitals.iprospect.com

Ten en cuenta que lo mostrado será en base a 1.500 webs de UK en las que se basa la tool.

2⃣ ¿Cómo medir las Core Web Vitals?

Hay un montón de recursos, y la mayoría 'oficiales', con lo que saber la puntuación de una URL.

La primera y más obvia es Page Speed Insights:

developers.google.com/speed/pagespee…

En dicha herramienta hubo además un update la semana pasada que hace un poco más accesible el ver las imágenes/textos que nos están dando problemas.

También tenemos esta otra herramienta de Google en web.dev:

web.dev/measure/

El CrUX Dashboard en DataStudio con el que poder hacer un seguimiento periódico.

Puedes hacerte una copia desde aquí:
g.co/chromeuxdash

Desde el último update de Chrome puedes también analizar las CWV de cualquier URL desde:

Inspeccionar Elemento > Rendering > Core Web Vitals

O hacer desde el mismo Chrome un audit con @____lighthouse, que también te dará la información de Page Speed Insights:

Inspeccionar Elemento > LightHouse > Generate Report

Puedes incluso hacerlo desde esta otra web:

webpagetest.org

No te van a faltar herramientas para ello.

3⃣ LCP (Largest Contentful Paint)

Mide cuánto tarda en cargar el elemento más grande dentro de lo que sea vea en el primer pantallazo de la URL.

Carga óptima: 2'5 segundos o menos.

Dicho elemento puede ser un texto, como en esta noticia de @LaVanguardia.

O una imagen, como en esta ficha de producto de @drinksco_es

Lo puedes detectar muy rápido tras hacer un test en Page Speed Insights, en el desplegable:

🔸 Renderizado del mayor elemento con contenido.

Con esta métrica por cierto, y con el #WPO en general, no hay que volverse loco.

Lo importante no es conseguir el 100/100, si no no ser excesivamente lento.

Más que recibir un push por rápido, tómalo como que puedes ser penalizado por lento.

Un par de consejos en cuanto a mejorar la carga de LCP...

El primero, no pongas un Lazy Load en dicho elemento.

Créeme, porque me pasó.

Está bien usar la carga diferida en imágenes para mejorar la carga, pero vigila con no hacerlo precisamente con el elemento que esté usando Chrome para medir el LCP.

Y consejo número 2.

Mucho cuidado con la carga de Js y CSS.

¿Quiere ver las principales causas de mala puntuación en el Largest Contentful Paint según la propia documentación de Google?

Efectivamente.

Vamos a ver un ejemplo de nuevo con una ficha de @drinksco_es, porque en casa del herrero cuchara de palo.

Mala puntuación en LCP. Miro qué elemento es.

La foto de producto, pero EY ESTÁ BIEN OPTIMIZADA.

¿Qué pasa aquí entonces?

Pues para JavaScript.

Cargan tantos (y/o tan pesados) que generan un embudo al cargar la URL, impidiendo que el LCP vaya rápido y entonces... pues da mala puntuación.

Mirad la imagen con el árbol de peticiones. Muchas pelotitas de Js/CSS y muy grandes.

Así que con JavaScript y CSS aplica siempre que puedas una o varias de las siguientes cosas:

🔸 Eliminar lo innecesario
🔸 Minificar
🔸 Comprimir
🔸 Asincronizar

4⃣ FID (First Input Delay)

Mide cuánto tarda en responder la URL desde que el usuario interactúa con la página.

Carga óptima: 100 milisegundos o menos.

Imagina ese típico momento en que ya ves la URL medio cargada en tu móvil y haces clic en un botón... y la web tarda en hacerte caso.

Ese plazo de tiempo es el que mides el FID.

Lo que tarda en responder a una interacción entre ue ha cargado cosas y termina de cargar el resto.

Por cierto, cuando hablamos de 'interacción' por parte del usuario.

Pulsar botones y cosas así SÍ cuenta, hacer scroll o zoom, NO.

Mirando de nuevo documentación oficial, vemos que para optimizar esta métrica sirven las mismas acciones que para mejorar otra (no incluida en las Core Web Vitals):

El TBT (Total Blocking Time)

Hace un momento hemos dicho lo que era el FID y que se medía entre que ya cargaba parte de la web y seguía trabajando en cargar el resto.

Ese lapso de tiempo es el Total Blocking Time (TBT).

¿Y cómo mejorarlo y de rebote también el FID?

Pues si vemos las recomendaciones nos volvemos a encontrar con temas que tocan de lleno a nuestro amigo JavaScript de manera general.

Tiene lógica pues a más carga/renderizado, más tiempo cargando cosas y tardando en responder.

Puedes ver la cascada de recursos que carga una URL desde:

Inspeccionar Elemento > Network

(Recarga la URL una vez tengas la pestaña abierta)

Así si ves algún recurso innecesario o especialmente grande, igual le puedes echar una ojeada...

Antes hemos hablado de webpagetest.org.

Ahí también puedes analizar la cascada de recursos.

Y lo dicho antes cuando hablábamos del LCP y sus problemas con Js y CSS:

🔸 Eliminar lo innecesario
🔸 Minificar
🔸 Comprimir
🔸 Asincronizar

5⃣ CLS (Cumulative Layout Shift)

Mide la estabilidad de la estructura visual de la URL.

Puntuación óptima: 0'1 o menos.

¿Sabes cuando estás con una web en el móvil, vas a hacer clic en una noticia y te aparece de la nada un banner publicitario justo ahí y le das sin querer?

QUÉ RABIA EH

CLS malo.

Varias son las posibles causas que pueden llevar a esos problemas, y se resumen aquí.

Vamos a ver cómo corregir las cuatro primeras, porque la última depende más del servidor y tal.

⚙️ Imágenes sin dimensiones especificadas.

Si el navegador no sabe lo que mide una imagen, y esta tarda en cargar... cuando lo hace pues simplemente POP aparece.

Y mueve todo lo ya cargado. Mal.

Si especificas alto y ancho reservará el espacio y así cuando la cargue, todo ok.

'Pero mis imágenes son responsive, no puedo aplicar un tamaño fijo.'

No, pero puedes especificar un set de alternativas en diferentes medidas para que Google coja la que toque.

srcset=

⚙️ Anuncios, embebidos e iframes sin imágenes especificadas.

Lo que decíamos, estás en la web y PAM aparece un megabanner que empuja todo para abajo.

Relee lo de las imágenes porque pasa exactamente igual.

Define alto y ancho para reservar el espacio.

En este caso, el de los anuncios, el problema suele ser con programática y demás.

Los anunciantes que más pagan unas veces tienen un banner de un tamaño o de otro ¿cómo solucionar eso?

O te limitas a un tamaño, o dejas las medidas del más grande... te dejo alternativas aquí 👇

⚙️ Contenido dinámico

Estas navegando, haces scroll o lo que sea y porque sí te aparece una nueva sección/carousel o similar.

NO.

Si aparece algo nuevo, que sea porque el usuario ha hecho previamente una interacción para ello.

Evita este tipo de cosas. Aquí poco más a añadir.

⚙️ Fuentes haciendo FOUT o FOIT

Resumen rápido. Tienes una tipografía X para el contenido de tu URL.

FOUT: Se carga la de por defecto y al rato la tuya, y claro, ocupan diferente y se mueve todo.

FOIT: No aparece el contenido hasta que se carga tu tipo y cuando lo hace la lía.

Dos alternativas.

🔸 Poner el atributo rel=preload para que el navegador cargue de manera prioritaria tu fuente en cuanto pueda y así evitar los problemas antes mencionados.

🔸 Ponerle un display:optional vía CSS.

Con esto resumiendo dices 'si en menos de 100ms no has cargado la fuente, ya deja la de por defecto y no la líes más.'

¿Maneras de ver qué bloques nos la están liando en el CLS al moverse?

Inspeccionar Elemento > More Tools > Rendering > Layout Shift Regions

O esta web que te genera un GIF con lo que se mueve en la URL que quieras (desktop o mobile):

defaced.dev/tools/layout-s…

Personalmente, todo el mundo recomienda esta tool pero yo no entiendo nada 🧚‍♂️

Ah, un último apunte sobre CLS.

Cumulative Layout Shift en castellano sería algo así como: Cambio de Layout ACUMULATIVO.

Esto quiere decir, que cuanto más arriba de la página este el bloque que de problemas peor, porque mueve TODO lo de abajo. Se acumula.

Y ya está, ésta es mi guía sobre Core Web Vitals a las puertas del gran update anunciado hace ya cosa de un año.

¿Será para tanto o no? Quién sabe, pero prevenir es mejor que curar.

Cuídate y cuida tus webs. Hazlo por el usuario.

¡¿Es que nadie piensa en los usuarios?!