Los errores más comunes que perjudican Web Vitals

Bajo el ala del proyecto PageSpeed.ONE, he realizado decenas de auditorías de velocidad y análisis menores para sitios de diferentes tamaños. Decidí entonces revisar todos esos análisis y encontrar los errores más comunes que se repiten en nuestras auditorías, los cuales afectan a las métricas de Core Web Vitals.

Puedes ver la grabación de la charla en el canal de YouTube de Frontendisti. Si prefieres la forma escrita, adéntrate en el artículo de hoy a continuación.

Contenido#

• Web Vitals en resumen
• ¿Cómo medir la velocidad de tu web?
• FID: una métrica de JavaScript que casi no necesita optimización
• LCP: probablemente la métrica más importante y mi favorita
• CLS: una métrica llena de malentendidos

Web Vitals en resumen#

La velocidad web es un tema cada vez más complejo, en el que es fácil perderse. Y luego están esos Web Vitals. ¿Qué son y por qué deberíamos preocuparnos?

Web Vitals son métricas de Google que se convertirán en uno de los criterios de evaluación para la clasificación de los resultados de búsqueda. Más detalles sobre Google Page Experience merecerían su propio artículo, así que si deseas leer más sobre esta actualización, te recomiendo el blog sobre Google Page Experience de Martin Michálek.

Ahora, una rápida mirada a Web Vitals. Las métricas básicas son tres: First Input Delay (FID), Largest Contentful Paint (LCP) y Cumulative Layout Shift (CLS). Todas las métricas tienen valores recomendados, como se muestra en la imagen.

Pero aún no sabemos cómo medir estos Web Vitals.

¿Cómo medir la velocidad de tu web?#

Hay muchas opciones. Uno de los instrumentos es Google Data Studio, donde puedes crear informes con los resultados de las distintas métricas. Desafortunadamente, trabajar con Data Studio suele ser complicado y lento.

Web Vitals también puede mostrarse en PageSpeed Insights, aunque allí los datos son bastante limitados y simplificados. Por eso, en PageSpeed.ONE, mis colegas y yo desarrollamos la actualización del tester 2.0, que (entre otras cosas) resuelve este problema. El resultado es un resumen completo de los datos de usuario tras ingresar la dirección, de manera sencilla y clara.

Si has ingresado las direcciones de tus sitios web en el tester y no te gustan los resultados, tengo buenas noticias para ti. Muchos errores se repiten en casi todos los sitios web, así que ven conmigo a explorar qué deberías buscar.

FID - First Input Delay#

Comencemos con la métrica First Input Delay. Como su nombre no sugiere en absoluto, se trata de un asunto de JavaScript que mide el tiempo desde la primera interacción del usuario con la página hasta el procesamiento de esa interacción por el navegador.

Hasta ahora, no hemos tenido que preocuparnos demasiado por FID, ya que parece ser una métrica poco exigente. Su límite para una buena puntuación es de 100 ms, que los sitios web logran cumplir.

Una métrica de JS muy similar es Total Blocking Time (TBT), con la que Google señala una conexión con FID. Sin embargo, en la práctica no hemos comprobado que un mal TBT signifique una mala puntuación de FID. Si mejoras el TBT, a menudo también avanzas en la métrica FID.

Un ejemplo de métricas de JavaScript fallidas por todo. En la primera mitad de la pantalla a continuación, está el resultado de la medición de una página donde hay un video de YouTube en un iframe, un conocido asesino de las métricas TBT y Time to Interactive (TTI). Las métricas son tan altas porque YouTube descarga grandes archivos CSS y JS.

¿La solución para mejorar las métricas? Para YT incrustado a través de iframe, utiliza la carga diferida nativa lazyloading o Youtube Lite Embed.

LCP - Largest Contentful Paint#

Mi métrica favorita es Largest Contentful Paint. Favorita porque es compleja. Para optimizarla, necesitas dominar muchas áreas durante la carga. Puede poner a prueba sólidamente los conocimientos de los desarrolladores en el proceso de carga de una web y nos permite medir la renderización del elemento más grande en la página.

Al ajustar LCP, lo más importante es identificar primero los elementos LCP. Para móvil y escritorio, a menudo son diferentes. Puedes identificar de manera confiable tus elementos LCP utilizando Lighthouse, PageSpeed Insight o en el detalle del test en nuestra herramienta PageSpeed.ONE.

LCP y carga diferida#

La gran mayoría de los sitios web perjudican su métrica LCP con una mala implementación de carga diferida. Es esencial darse cuenta de que la carga diferida cambia el orden de descarga de las imágenes.

Un error muy común es implementar la carga diferida solo en imágenes grandes en la página. Sí, lógicamente, retrasar la carga de las imágenes más grandes nos ahorra más datos, pero en el caso de un elemento LCP, esto te pondrá en desventaja.

La regla es que las imágenes sin carga diferida se descargan primero. Las imágenes con carga diferida se descargan después, incluso si están en el viewport. Si tienes carga diferida en una imagen que también es un elemento LCP, se descargará mucho más tarde, lo que aumenta el tiempo de LCP.

Seguro que ya has llegado a la solución mientras leías; elimina la carga diferida de los elementos LCP en tu web y, al contrario, añade carga diferida a todos los demás elementos.

LCP y DOM complejo#

Una mala noticia desde el principio, esto generalmente toma mucho tiempo durante la optimización. Por otro lado, te ofrezco una solución temporal hasta que puedas realizar cambios mayores en el código.

El problema generalmente comienza en el diseño, donde hay una gran diferencia entre la versión de escritorio y la móvil. Esto, por supuesto, debes resolverlo, a menudo ocultando elementos en móviles.

La superficie azul oscuro es bastante extensa, ¿verdad? Esto afectará tu métrica LCP. Es importante mencionar que no sería un problema si estuviéramos hablando de simples elementos de texto en el DOM. Aquí el problema radica en muchas imágenes que se descargarán aunque no sean visibles.

Hay varias soluciones. Si tienes tiempo y oportunidad, reescribe el HTML para reflejar los elementos LCP. También puedes usar preload en la imagen que se evaluó como LCP en móviles.

<link rel="preload" as="image" href="image.jpg" />

Pero ten cuidado con el preload, especialmente si ya tienes otros preloads en la página. También puedes utilizar loading="lazy", ya que las imágenes en elementos ocultos con este atributo no se descargarán.

LCP e imágenes desde WYSIWYG#

El manejo de imágenes en el editor necesita ser controlado. Muchos sitios de comercio electrónico escriben blogs bajo su propio dominio, lo que también puede perjudicar las métricas, y a menudo ocurre. No quiero criticar a los desarrolladores, pero lo que el usuario carga a través de WYSIWYG también es tu problema. Aquí también necesitas resolver tamaños, compresión, formatos adecuados y srcsets.

CLS - Cumulative Layout Shift#

Cumulative Layout Shift es una métrica que trata sobre el desplazamiento y el salto del diseño de la página. No solo son críticos los cambios de diseño durante la carga, que los medirán herramientas sintéticas, sino que también debes abordar los cambios de diseño durante la navegación por las páginas. Esto lo descubrirás mirando los datos de usuario en el informe de Chrome UX.

¿Cómo probar un CLS? Idealmente, a través de una extensión de Chrome llamada Web Vitals, o en el propio Chrome en la pestaña de renderizado hay una casilla de verificación «Core Web Vitals».

CLS y atributos width y height#

En lo que respecta a CLS, en cada sitio web comentamos sobre la falta de atributos width y height en la etiqueta de imagen. A menudo es por descuido, por lo que es necesario buscar todas las imágenes en el proyecto y verificar los atributos que faltan.

<img src="image.jpg" alt="img" width="150" height="200" />

Otra solución para evitar el salto no solo de imágenes, sino también de otros elementos de contenido, en el futuro será la propiedad CSS aspect-ratio. Con una sola línea de código, puedes resolver el espacio que un elemento debe reservar para su contenido.

.box {
  aspect-ratio: 4/3;
  background: grey;
}

Si necesitas una solución infalible de inmediato, te recomendamos el truco de padding-top.

CLS y carruseles (por ejemplo)#

El Cumulative Layout Shift puede empeorar no solo por carruseles, sino por cualquier inicialización de contenido mediante JavaScript. A menudo se trata de varios cuestionarios, calculadoras, widgets, etc.

Generalmente, la inicialización de JavaScript ocurre muy tarde, por lo que el CLS aumenta. No es bueno resolver con JavaScript cosas que podemos estilizar en CSS. Típicamente, esto incluye los anchos de los elementos en un carrusel.

Por lo tanto, resuelve los anchos y alturas de los elementos en CSS, prueba tu sitio con JavaScript desactivado. Todo esto te ayudará a descubrir dónde están los puntos débiles en tu sitio. Una herramienta que puede ayudarte es la extensión de Chrome Web Developer, donde puedes desactivar JavaScript fácilmente con un solo clic.

CLS y AJAX#

La métrica CLS no solo se calcula al momento de cargar la página, sino también durante la navegación por parte del usuario. Si el usuario decide, por ejemplo, cargar “otros 24 productos”, entonces tras hacer clic tienes un intervalo de 0.5 segundos para mostrar el contenido sin aumentar aún más el CLS.

Las instrucciones para tal situación son las siguientes: Prueba redes lentas y carga contenido de forma diferida cuando el navegador “se aburra” usando RequestIdleCallback();.

Unas palabras finales#

Si eres nuevo en el área de la velocidad web y te he abrumado con una montaña de nueva información, no te desesperes. Primero, ve a hacerte un café y luego concéntrate en la recopilación de datos y pruebas. Deberías interesarte tanto en los datos de usuario de Web Vitals como en las mediciones sintéticas. Todo idealmente en el contexto de varios meses.

En cuanto a la sintética, Lighthouse ha lanzado la versión 8, donde, por ejemplo, se ha ajustado el cálculo de la puntuación en sí. Por ejemplo, las métricas TBT y LCP juntas constituyen el 55% del peso en el cálculo total. Esto por sí solo sugiere en qué métricas deberías centrarte.

Finalmente, me gustaría transmitir a todos los desarrolladores y desarrolladoras suficiente entusiasmo y curiosidad para entender cómo realmente funciona el navegador. Enfócate en DevTools y la pestaña de Performance para optimizaciones, piensa de manera integral y trata de descubrir cómo las diferentes cosas en la web se influyen entre sí. También puedes aprender a optimizar ambas métricas problemáticas – CLS y LCP.

Discusión#

Después de la charla, también hubo una discusión moderada, donde junto con Michal Matuška respondí a preguntas del público.

Etiquetas:Core Web Vitals