Solucionar imágenes hero lentas y Core Web Vitals

Cómo solucionar imágenes hero lentas: en resumen

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

Revisado por última vez por Arjen Karel en febrero de 2026

¿Qué es una imagen hero?

Una imagen hero, a veces llamada 'hero header', es una imagen grande con texto, a menudo colocada en la parte superior de una página web. Una imagen hero sirve como el primer vistazo de un usuario a tu empresa y oferta debido a su ubicación prominente en la parte superior de una página web que generalmente se extiende a todo lo ancho.

Un recordatorio rápido: Las imágenes hero, los Core Web Vitals y el Largest Contentful Paint: 
Debido al tamaño de la imagen hero (generalmente abarca todo el ancho de la página y una buena parte 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 los Core Web Vitals. El elemento Largest Contentful Paint es el elemento más grande que se pintará en el viewport visible del navegador. Según el 2025 Web Almanac, en el 76% de las páginas móviles el elemento LCP es una imagen. Solo el 62% de los orígenes móviles aprueban actualmente el LCP. Soluciona la imagen hero y solucionarás el LCP para la mayoría de los sitios.
Debido a que las imágenes no optimizadas tienden a consumir mucho ancho de banda y, por lo tanto, tardan mucho tiempo en cargarse, las imágenes hero a menudo causarán malas métricas de Largest Contentful Paint.

Optimizando la imagen hero y el Largest Contentful Paint

Hay muchas técnicas para optimizar las imágenes hero 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. Haz preload de la imagen hero o envía 103 Early Hints

Cuando quieres que un elemento esté disponible lo antes posible en el navegador, podrías hacer preload de ese elemento. El preloading implica el uso de resource hints. Los resource hints le dicen al navegador algo sobre la prioridad de un elemento y activarán una descarga muy temprana de ese recurso. Según el 2025 Web Almanac, solo el 2.1% de las páginas hacen preload de su imagen LCP. Esa es una gran oportunidad perdida.

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

Los 103 Early Hints permiten a los servidores enviar resource hints antes de la respuesta HTML final. El navegador puede comenzar el preloading de la imagen hero mientras el servidor aún está generando la página. Chrome, Edge y Firefox soportan el preloading a través de Early Hints. Safari soporta preconnect pero aún no preload a través de Early Hints. Para obtener detalles sobre cómo configurar esto, lee la guía completa de 103 Early Hints.

En los sitios monitorizados por CoreDash, las páginas con una imagen LCP en preload tienen una tasa de LCP 'bueno' del 81% en comparación con el 64% sin preloading. Para un recorrido completo por todas las opciones de preloading, consulta cómo hacer preload de la imagen LCP.

2. Usa fetchpriority="high" en la imagen hero

El atributo fetchpriority le dice al navegador qué recursos importan más. Establecer fetchpriority="high" en tu imagen hero aumenta su prioridad de descarga por encima de otras imágenes y recursos competidores como scripts y fuentes.

<img src="hero.webp" fetchpriority="high" width="1200" height="600" alt="...">

Según el 2025 Web Almanac, solo el 17% de las páginas establecen fetchpriority="high" en su imagen LCP. Eso significa que el 83% de los sitios están dejando sobre la mesa ganancias de rendimiento fáciles.

También puedes añadir fetchpriority="high" al enlace de preload mostrado arriba. Usa fetchpriority="high" solo en una única imagen por página. Múltiples imágenes de alta prioridad compiten entre sí y anulan el beneficio. Para saber más sobre cómo los navegadores priorizan los recursos, lee la guía de Core Web Vitals sobre priorización de recursos.

3. Comprime la imagen hero y usa formatos de nueva generación

Comprimir las imágenes hará que el tamaño de su archivo sea más pequeño. Los tamaños de archivo más pequeños ocupará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 establecer el nivel de compresión de WordPress) o con una herramienta de compresión de imágenes online.

La mayoría de las imágenes hero lentas son más lentas de lo que deberían porque se sirven en el contenedor de imagen 'equivocado' como PNG o JPEG. Hay alternativas mucho más rápidas a JPEG y PNG como WebP y AVIF. Según el 2025 Web Almanac, el 57% de las imágenes LCP todavía se sirven como JPEG y el 26% como PNG, mientras que solo el 11% usa WebP y menos del 1% usa AVIF.

Para muchos sistemas CMS hay 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, una CDN con soporte de conversión de imágenes podría ser la solución que estás buscando. Para un resumen completo de técnicas de optimización de imágenes, consulta optimizar imágenes para los Core Web Vitals.

4. No uses background images, usa imágenes responsivas normales

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

Las background images son malas para los Core Web Vitals. ¡Recuerda eso! Lee más sobre por qué las background images son malas para el rendimiento. Si no puedes evitar las background images por completo, al menos puedes diferir las background images que están below the fold.

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

La forma en que lo hago es añadiendo una imagen normal en una posición absoluta y configurando la propiedad object-fit de esa imagen a cover. Una vez que he cambiado la background image a una imagen normal, puedo empezar a usar imágenes responsivas. Si usas Elementor, echa un vistazo a cómo solucionar las imágenes hero en Elementor.

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

• Las imágenes hero ahora se cargan con una mayor prioridad
• Ahora puedo usar imágenes responsivas para la imagen hero

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 fetchpriority="high" loading="eager" decoding="async" src="hero.webp" id="heroimg">
</picture>
</div>

5. Sirve las imágenes hero desde el dominio principal y considera una CDN

Con demasiada frecuencia veo que la imagen largest contentful paint se sirve desde un dominio diferente, por ejemplo 'static.midominio.com'. Estos subdominios a menudo apuntan a una CDN. Aunque animo al uso de una CDN (ver a continuación), 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 tomarán un 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 del servidor ya establecida.

Cuando se configura en el dominio principal, una CDN podría ofrecer un enorme aumento de velocidad. Especialmente cuando tu sitio es visitado desde todo el mundo. Una CDN tiene servidores ubicados estratégicamente por todo el mundo donde tus recursos estáticos (como 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 ser servidos desde un servidor edge local. Para una guía de configuración completa, consulta cómo configurar Cloudflare para los Core Web Vitals.

6. Evita el lazy loading en la imagen hero

Asegúrate de que no se esté aplicando lazy loading a tu imagen hero. Las imágenes hero siempre deberían usar eager loading.

Muchos sitios, especialmente los sitios de WordPress, están utilizando algún tipo de plugin de pagespeed para WordPress como WP Rocket o WP Core Web Vitals. Estos plugins generalmente hacen un gran trabajo acelerando sitios lentos, pero no pueden arreglar la estupidez :-)

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

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 está activado el lazy loading basado en JavaScript, causará un retraso mayor. Según el 2025 Web Almanac, aproximadamente el 17% de las páginas hacen lazy-load de su imagen LCP. Eso es un 17% de sitios que empeoran activamente su LCP. Si Lighthouse te advierte sobre esto, consulta cómo solucionar la advertencia de lazy loading en la imagen LCP.

Hacer que las imágenes usen eager loading es simple. Solo añade loading="eager" a la imagen. Ten en cuenta que eager es en realidad el predeterminado del navegador. Omitir el atributo loading por completo tiene el mismo efecto. El objetivo real es asegurarse de que la imagen hero NO tenga loading="lazy". Añadir explícitamente eager sigue siendo útil como señal de intención, especialmente en sitios donde un CMS o plugin puede auto-aplicar lazy loading.

<img src="hero.webp" loading="eager" fetchpriority="high" width="800" height="400">

7. Evita los layout shifts causados por la imagen hero

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

• El elemento hero es creado con JavaScript. Se sabe que algunos plugins hero y constructores de páginas como Elementor 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 generalmente contiene un texto grande con una llamada a la acción y un eslogan. Asegúrate de que estas fuentes grandes no causen un layout shift.
• Falta de dimensiones en la imagen. Cuando la imagen hero no es una imagen cover (ya sea como background image o una imagen con posicionamiento absoluto), la falta de dimensiones de la imagen (width y height) ciertamente causará un gran layout shift.

Aunque arreglar el layout shift no mejorará el Largest Contentful Paint, mejorará los Core Web Vitals de la página. Para más información sobre cómo solucionar el layout shift, por favor lee la guía en profundidad sobre cómo solucionar el Cumulative Layout Shift!

8. Usa 2-stage loading para mejorar los Core Web Vitals de la imagen hero

El 2-stage loading 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 más grande de alta calidad. Una vez que la imagen de baja calidad se ha pintado en la pantalla, se activa el 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 2-stage loading. Los dos primeros son métodos que deberías considerar. El último es uno que no deberías hacer.

1. 2-stage loading completo

Con el 2-stage loading completo, la primera imagen de baja calidad tiene exactamente las mismas dimensiones (width y height) que la imagen original de alta calidad.

El resultado de este 2-stage loading es que el elemento largest contentful paint será la imagen mucho más rápida y de baja calidad (que luego se intercambiará de forma perezosa). El intercambio de la imagen ocurrirá 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 a la mejora de los Core Web Vitals.

2. Placeholders inline más pequeños

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

La idea básica es la misma que para la técnica de 2-stage loading, pero en lugar de una imagen de baja calidad con las mismas dimensiones, se coloca una imagen mucho más pequeña con dimensiones más pequeñas de forma inline a través de una data URI. La imagen hero final, que será la imagen largest contentful paint, todavía 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 2-stage loading.

3. Placeholders transparentes

Una técnica común de 2-stage loading 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 pueden colocarse de forma inline, al igual que el placeholder inline más pequeño.

Usar un elemento SVG inline e intercambiarlo 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 imagen hero real y no tiene valor añadido para tu visitante. Donde las métricas de pintura podrían ser geniales, la UX de la página en realidad empeorará.

Por eso la imagen hero siempre debería cargarse de forma eager sin trucos que causen una mala UX.

Juntándolo todo

Así es como se ve una imagen hero optimizada cuando combinas preloading, fetchpriority, imágenes responsivas y eager loading:

<!-- En el <head> -->
<link rel="preload" as="image" href="hero-800.webp" fetchpriority="high"
  imagesrcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  imagesizes="100vw">

<!-- En el <body> -->
<img src="hero-800.webp"
  fetchpriority="high"
  loading="eager"
  decoding="async"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  sizes="100vw"
  width="1600" height="900"
  alt="Texto alt descriptivo">

Después de hacer los cambios, verifica la mejora con Real User Monitoring. Lighthouse te da una instantánea de laboratorio, pero Google clasifica basándose en datos de campo de usuarios reales recopilados durante los 28 días anteriores.