Soluciona hero images lentas y Core Web Vitals

Cómo solucionar hero images lentas - en resumen

Las hero images son imágenes grandes en la parte superior de una página web. Estas hero images causarán un Largest Contentful Paint prolongado cuando no están optimizadas. 9 de cada 10 sitios que me piden optimizar tienen problemas con las hero images. En este artículo te mostraré diferentes técnicas para acelerar las hero images.

¿Qué es una hero image?

Una Hero Image o a veces llamada 'hero header' es una imagen grande con texto, generalmente colocada en la parte superior de una página web. Una hero image sirve como la primera impresión que tiene el usuario de tu empresa y tu oferta, debido a su ubicación prominente en la parte superior de una página web que normalmente se extiende a todo el ancho.

Un recordatorio rápido: Hero images, las Core Web Vitals y el Largest Contentful Paint

Debido al tamaño de la hero image (normalmente abarca todo el ancho de la página y una buena porción de la altura del viewport visible) este elemento se convertirá en el elemento Largest Contentful Paint en casi todos los casos.

El Largest Contentful Paint es una métrica importante de Core Web Vitals. El elemento Largest Contentful Paint es el elemento más grande que se pintará en el viewport visible del navegador.

Dado que las imágenes no optimizadas tienden a consumir mucho ancho de banda y por lo tanto tardan mucho en cargar, las hero images a menudo causan malas métricas de Largest Contentful Paint

Optimización de la hero image y el Largest Contentful Paint

Existen muchas técnicas para optimizar las hero images y el Largest Contentful Paint. Las explicaré aquí. ¡La mayoría de las técnicas se pueden combinar para obtener resultados aún mejores!

1 Precargar la hero image o enviar cabeceras 103

Cuando quieres que un elemento esté disponible lo antes posible en el navegador, podrías precargar ese elemento. La precarga implica el uso de resource hints. Los resource hints le indican al navegador algo sobre la prioridad de un elemento y activarán una descarga muy temprana de ese recurso.

<link 
  rel="preload" 
  as="image" 
  href="wolf.jpg" 
  imagesrcset="hero_400px.jpg 400w, hero.jpg 800w, hero_1600px.jpg 1600w" 
  imagesizes="50vw">

En un futuro cercano los 103 early hints serán compatibles con los navegadores Chrome. Esto hará posible enviar resource hints ANTES de que se haya enviado la respuesta HTML final. Se espera que los 103 early hints sean un cambio revolucionario cuando se trata de mejorar el Largest Contentful Paint. Si estás interesado en aprender sobre early resource hints consulta mi artículo.

2 Comprimir la hero image y usar formatos de nueva generación

Comprimir imágenes hará que su tamaño de archivo sea menor. Tamaños de archivo más pequeños consumirán menos ancho de banda y estarán disponibles para el navegador lo antes posible. La compresión de imágenes se puede hacer en tu editor de fotos, en tu CMS (consejo: tu desarrollador puede configurar el nivel de compresión de WordPress) o con una herramienta de compresión de imágenes en línea

La mayoría de las hero images lentas son más lentas de lo necesario porque se sirven en el contenedor de imagen 'incorrecto' como PNG o JPEG. Existen alternativas mucho más rápidas a JPEG y PNG como WebP y AVIF. 

Para muchos sistemas CMS existen plugins de conversión que convertirán tus imágenes a formatos de nueva generación. Cuando la conversión de imágenes es difícil de integrar en tu sitio web, un CDN con soporte de conversión de imágenes podría ser la solución que estás buscando.

3. No uses background images, usa imágenes responsive normales

Tu hero image debería ser una imagen normal y nunca una background image. La forma habitual de hacer hero images es añadiendo una background image al contenedor hero y configurando el background-size de ese contenedor en cover. Esto asegurará que la hero image se ajuste a la pantalla en todos los casos.

Las background images son malas para las Core Web Vitals. ¡Recuerda eso! No hay ninguna buena razón para usar background images.

• Las background images se cargan con una prioridad más baja
• Las background images no son responsive (a menos que realmente quieras complicar las cosas)
• Las background images pueden causar problemas de Core Web Vitals con la mayoría de las bibliotecas de lazy loading.
  

La forma en que yo lo hago es añadiendo una imagen normal en posición absoluta y configurando la propiedad object-fit de esa imagen en cover. Una vez que he cambiado la background image a una imagen normal, puedo empezar a usar imágenes responsive

Imágenes responsive significa que para diferentes dispositivos (móvil, escritorio, tablet) se puede enviar una versión diferente de la misma hero image. Para un dispositivo de escritorio podría enviar una hero image enorme de 1920x1280 mientras que para un dispositivo móvil solo necesitaría enviar una hero image más pequeña de 400*266 píxeles. ¡Eso es 25 veces menos datos!

• Las hero images ahora se cargan con una prioridad más alta
• Ahora puedo usar imágenes responsive para la hero image

style.css

<style>
#herocontainer{
    position:relative;
    padding:4rem 0
}
#heroimg{
    object-fit: cover;
    width: 100%;
    height: 100%;
    position: absolute;
    top: 0;
}
</style>

index.html

<div id="herocontainer">
<h1>Welcome to my site</h1>
<picture>
    <source 
        type="image/webp" 
        media="(max-width:540px)" 
        srcset="herosm.webp">
    </source>
    <img loading="eager" decoding="async" src="hero.webp" id="heroimg">
</picture>
</div>

4. Sirve hero images desde el dominio principal y considera un Content Delivery Network (CDN)

Con demasiada frecuencia veo que la imagen del Largest Contentful Paint se sirve desde un dominio diferente, por ejemplo 'static.midominio.com'. Estos subdominios a menudo apuntan a un CDN. Aunque recomiendo el uso de un CDN (ver más abajo) una configuración como esta no es aconsejable. La imagen en el subdominio requiere una nueva conexión a un nuevo servidor. Las nuevas conexiones son costosas y consumirán tiempo valioso. Cuando la imagen se sirve desde el dominio principal (www.midominio.com por ejemplo) las imágenes se pueden obtener mucho más rápido a través de la conexión ya establecida con el servidor.

Cuando se configura en el dominio principal, un CDN puede ofrecer un aumento de velocidad enorme. Especialmente cuando tu sitio es visitado desde todo el mundo. Un CDN tiene servidores estratégicamente ubicados en todo el mundo donde tus recursos estáticos (como las imágenes se almacenan en caché) para tiempos de respuesta locales rápidos. Esto significa que los datos no tienen que viajar por todo el mundo sino que pueden servirse desde un servidor edge local.

5. Evita el lazy loading en las imágenes del Largest Contentful Paint y carga explícitamente la hero image en modo eager

Asegúrate de que no se aplique lazy loading a tu hero image. Las hero images siempre deben cargarse en modo eager.

Muchos sitios, especialmente sitios WordPress, utilizan algún tipo de plugin de velocidad de WordPress como WP Rocket o WP Core Web Vitals. Estos plugins generalmente hacen un gran trabajo acelerando sitios lentos pero no pueden arreglar lo mal hecho :-)

Estos plugins aplicarán lazy loading a imágenes que parecen ser buenas candidatas para lazy loading. Si la hero image no es una imagen eager, esos plugins probablemente también aplicarán lazy loading a la hero image.

Esto, en el mejor de los casos, causará un pequeño retraso en las métricas de LCP. En el peor de los casos, especialmente cuando se activa el lazy loading basado en JavaScript, causará un retraso mayor.

Hacer que las imágenes se carguen en modo eager es bastante simple. Solo añade loading="eager" a la imagen y listo.

<img src="hero.webp"  width="800" height="400">

6. Evita los layout shifts causados por la hero image

Otro problema común que veo con los hero banners y hero images es que causan un layout shift enorme. Estos layout shifts pueden ocurrir por diferentes razones.

• El elemento hero se crea con JavaScript. Algunos plugins de hero y page builders como Elementor se sabe que dependen de JavaScript para renderizar el contenido hero. Aunque no hay nada malo con JavaScript, asegúrate de que el elemento hero se renderice igual sin JavaScript.
• Las fuentes en el elemento hero causan un layout shift. El elemento hero normalmente contiene texto grande con un call to action y un tagline. Asegúrate de que estas fuentes grandes no causen un layout shift.
• Dimensiones de imagen faltantes. Cuando la hero image no es una imagen cover (ya sea como background image o como una imagen posicionada de forma absoluta) las dimensiones de imagen faltantes (width y height) ciertamente causarán un layout shift grande.

Aunque solucionar el layout shift no mejorará el Largest Contentful Paint, mejorará las Core Web Vitals de la página. Para más información sobre cómo solucionar el layout shift, lee esta guía detallada sobre cómo solucionar el layout shift.

7. Usa la carga en 2 etapas para mejorar las Core Web Vitals de la hero image

La carga en 2 etapas es una técnica rápida que aplicamos a todas nuestras imágenes. Primero servimos una imagen de calidad extremadamente baja que se espera que se descargue mucho antes que la imagen de alta calidad más grande. Una vez que la imagen de baja calidad se ha pintado en la pantalla, se activa al navegador para obtener la imagen de alta calidad en segundo plano. Una vez que la imagen de alta calidad se ha descargado, la imagen de baja calidad será reemplazada por la imagen de alta calidad.

Hay 3 métodos de carga en 2 etapas. Los primeros dos son métodos que deberías considerar. El último es uno que no deberías usar.

1. Carga en 2 etapas completa

Con la carga en 2 etapas completa, la primera imagen de baja calidad tiene exactamente las mismas dimensiones (width y height) que la imagen original de alta calidad.

El resultado de esta carga en 2 etapas es que el elemento Largest Contentful Paint será la imagen de baja calidad mucho más rápida (que luego se intercambiará de forma lazy). El intercambio de la imagen sucederá tan rápido que un visitante casual probablemente nunca lo notará. El resultado de esta técnica es que el LCP se pinta mucho antes, la página parece 'lista' mucho antes, lo que contribuye a una experiencia de usuario mucho mejor y unas Core Web Vitals mejoradas.

2. Placeholders en línea más pequeños

El placeholder más pequeño es una técnica bastante interesante que tiene un inconveniente: no mejora las Core Web Vitals. Sigue siendo una gran técnica porque mejora la experiencia de usuario.

La idea básica es la misma que para la técnica de carga en 2 etapas pero en lugar de una imagen de baja calidad con las mismas dimensiones, se coloca en línea una imagen mucho más pequeña con dimensiones menores a través de un data URI. La imagen hero final que será la imagen del Largest Contentful Paint aún se descarga en segundo plano. Este truco no mejorará el Largest Contentful Paint pero hará que la página parezca lista incluso más rápido que la técnica de carga en 2 etapas

3. Placeholders transparentes

Una técnica común de carga en 2 etapas y un método para engañar al navegador para que envíe una métrica de Largest Contentful Paint temprana es usar elementos SVG transparentes. Esos elementos son pequeños y se pueden colocar en línea, igual que el placeholder en línea más pequeño.

Usar elementos SVG en línea e intercambiarlos es en realidad una técnica de lazy loading. La ventaja de esta técnica es que funciona en todos los navegadores. 

El lazy loading, por supuesto, solo debería aplicarse a elementos fuera del viewport. En este caso, el elemento SVG transparente solo retrasará la hero image real y no tiene valor añadido para tu visitante. Donde las métricas de pintado pueden ser buenas, la UX de la página en realidad empeorará.

Por eso la hero image siempre debe cargarse de forma eager sin trucos que causen una mala UX.