Optimización de imágenes para Core Web Vitals: LCP, CLS e INP

Última actualización: June 28, 2026

Las imágenes son la causa más grande de puntuaciones bajas en Core Web Vitals. En los sitios que audité este año, el elemento LCP fue una imagen 8 de cada 10 veces, y el hero mediano pesaba 1.6 MB antes de que yo hiciera cualquier cosa. Optimicé esas imágenes y vi cómo el LCP caía de 3.9s a 1.7s en datos de campo, mientras que CLS llegó a cero.

Esta inmersión profunda se centra únicamente en las correcciones de imágenes que mueven las tres métricas Core Web Vitals: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) e INP (Interaction to Next Paint). Si quieres el flujo de trabajo más amplio de redimensionamiento, CDN o formato, combínalo con la lista completa de optimización de imágenes.

Respuesta rápida: ¿qué correcciones de imagen mueven Core Web Vitals?

Los cinco arreglos que realmente movieron mis puntuaciones:

1. Comprimir y redimensionar la imagen hero a su tamaño de visualización, y luego enviarla como WebP o AVIF.
2. Precargar la imagen LCP con fetchpriority="high".
3. Nunca cargar perezosamente (lazy-load) el hero visible en la parte superior.
4. Establecer ancho y alto explícitos (o aspect-ratio CSS) en cada imagen para eliminar CLS.
5. Agregar decoding="async" y redimensionar con srcset para proteger INP.

Mide antes y después con datos de campo de PageSpeed Insights, no solo con ejecuciones de laboratorio de Lighthouse. Los datos de laboratorio mienten sobre CWV porque utilizan un único dispositivo simulado; los datos de campo son lo que Google clasifica.

¿Cómo afectan las imágenes a cada Core Web Vital?

Cada métrica se relaciona con un modo diferente de fallo de imagen. Saber cuál estás combatiendo evita que arregles la cosa equivocada.

La trampa: arreglar LCP con un hero más grande y nítido puede empeorar INP, y la carga perezosa agresiva puede empeorar tanto LCP como INP. Optimiza por métrica, luego vuelve a medir el conjunto completo.

¿Cómo reducir el tamaño del archivo de imagen LCP?

La palanca más directa. Tomé un hero de cliente de 2.1 MB PNG a 148 KB WebP con estos tres pasos, y el LCP cayó aproximadamente 1.1s inmediatamente:

• Redimensionar a 2x del ancho de visualización más grande (una pantalla de 1200px necesita aproximadamente 2400px fuente, no 6000px).
• Comprimir a calidad 75 a 80; el ahorro es del 60 al 70 por ciento sin pérdida visible.
• Exportar WebP o AVIF; AVIF es otro 25 al 35 por ciento más pequeño que WebP.

Para el flujo de trabajo completo de dimensionamiento, consulta la guía para redimensionar imágenes para web. Una fuente de 4000px servida a un cuadro de 400px son bytes desperdiciados en cada dispositivo.

¿Cómo precargar el hero con fetchpriority?

Los navegadores descubren las imágenes tarde. Analizan HTML, cargan CSS y luego encuentran la etiqueta <img>. Precargar le dice al navegador que comience la solicitud inmediatamente, en paralelo con CSS:

<link rel="preload" as="image" href="/hero.webp"
      imagesrcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
      imagesizes="100vw" fetchpriority="high">

Medí una ganancia de LCP de 200 a 500ms solo con esto. fetchpriority="high" eleva la prioridad de la solicitud para que el hero supere otro tráfico de red. Google documenta este patrón en su guía de Largest Contentful Paint.

¿Por qué nunca debes cargar perezosamente la imagen LCP?

loading="lazy" retrasa la solicitud hasta que la imagen se acerca al viewport. Para imágenes por debajo del pliegue (below-the-fold), eso es exactamente correcto; para el hero, es fatal. Una vez envié un hero con carga perezosa y el LCP saltó 800ms porque la solicitud comenzó un segundo más tarde.

La regla que sigo: la primera imagen visible obtiene loading="eager" (o ningún atributo). Todo por debajo del pliegue obtiene loading="lazy". Si quieres la estrategia completa de carga perezosa, lee el desglose de cargar imágenes perezosamente.

¿Cómo reservar espacio para eliminar CLS?

CLS mide el movimiento inesperado del diseño. La causa clásica de las imágenes: un <img> sin dimensiones se renderiza con altura cero, luego salta a su tamaño completo cuando llegan los bytes, empujando cada párrafo debajo hacia abajo.

Cuando el navegador conoce las dimensiones por adelantado, reserva el cuadro y nada se mueve cuando la imagen pinta.

<!-- Mal: causa desplazamiento de diseño -->
<img src="photo.webp" alt="Storefront">

<!-- Bien: el navegador reserva el cuadro -->
<img src="photo.webp" alt="Storefront" width="800" height="600"
     decoding="async">

Audité una página de catálogo con 40 imágenes de productos y cero dimensiones; CLS era 0.34. Agregar ancho/alto a cada imagen llevó el CLS a 0.02 en el siguiente ciclo de datos de campo. Google explica el mecanismo en su guía de Cumulative Layout Shift.

Para imágenes responsivas, cuando CSS anula el atributo width, solo el atributo height no es suficiente. aspect-ratio reserva espacio vertical correcto a cualquier ancho de viewport:

img.hero {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

¿Cómo mantener el decode de imágenes fuera del hilo principal (INP)?

INP reemplazó a FID como la métrica de capacidad de respuesta. Un enorme decode de imagen puede bloquear el hilo principal durante 50 a 100ms, por lo que el toque de un usuario en un menú o botón "Añadir al carrito" se siente congelado.

<img src="photo.webp" alt="Storefront" decoding="async"
     width="800" height="600">

decoding="async" sugiere al navegador que decodifique fuera del hilo principal. Es una ganancia de un solo atributo sin desventajas; aplícalo a cada imagen, no solo al hero.

Redimensiona con srcset también: una imagen de 4000x3000 mostrada en 400x300 fuerza al dispositivo a decodificar aproximadamente 100 veces más píxeles de los que muestra. Sirve el tamaño correcto por viewport con srcset y sizes:

<img srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1280.webp 1280w"
     sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1280px"
     src="photo-800.webp" alt="Storefront" decoding="async"
     width="800" height="600">

En un teléfono esto ahora descarga y decodifica el archivo de 400w, una fracción del trabajo. Combinado con un CDN que re-codifica y almacena en caché cada derivado, esta es la corrección INP de mayor apalancamiento. Consulta la guía de CDN de imágenes para configurar el redimensionamiento sobre la marcha.

¿Qué formato debo enviar?

La elección del formato se acumula con cada arreglo anterior, porque los archivos más pequeños significan un LCP más rápido, menos decode y mejor INP.

Envío AVIF con un fallback WebP a través de un elemento <picture>. Para la mayoría de los sitios, WebP es suficiente y evita la complejidad de codificación de AVIF.

Mi antes y después medido

Para demostrar que esto no es teoría, aquí hay una página real que optimicé el mes pasado (datos de campo móviles, ventana de 28 días):

• LCP: 3.9s a 1.7s (hero redimensionado de 2.1MB a 148KB WebP, pre-cargado).
• CLS: 0.34 a 0.02 (ancho/alto en todas las imágenes).
• INP: 230ms a 140ms (decoding="async" más redimensionamiento con srcset).

El patrón se repitió en otras páginas: el tamaño del archivo mueve más LCP, las dimensiones mueven más CLS y la estrategia de decode mueve más INP. Optimiza cada métrica y luego vuelve a ejecutar el conjunto completo.

Lista de verificación de imágenes Core Web Vitals

Ejecuta esto antes de enviar cualquier página donde las imágenes importen:

1. Hero comprimido a menos de 200 KB.
2. Hero pre-cargado con fetchpriority="high".
3. Hero no cargado perezosamente (loading="eager").
4. Cada imagen tiene atributos width y height.
5. Las imágenes fluidas usan CSS aspect-ratio.
6. Todas las imágenes usan decoding="async".
7. Imágenes por debajo del pliegue usan loading="lazy".
8. Se sirve AVIF o WebP, JPEG solo como fallback.
9. srcset y sizes entregan archivos apropiados para la visualización.
10. Las imágenes se envían desde un CDN con caché de borde.

Una advertencia real

Los números de laboratorio no son números de campo. Mis limpiezas se veían perfectas en Lighthouse y aún se movieron de manera desigual en el campo, porque los usuarios reales están en 4G limitado, Androides de gama media y Wi-Fi congestionado. Después de aplicar cada arreglo aquí, observa tus datos de campo de PageSpeed Insights durante una ventana completa de 28 días antes de declarar la victoria. CWV se puntúa según lo que experimentan los usuarios reales, no según lo que predice el simulador.

Preguntas frecuentes

¿Qué métrica Core Web Vitals afectan más las imágenes?

LCP. El elemento Largest Contentful Paint suele ser una imagen hero, por lo que su tamaño de archivo y orden de carga dominan la métrica. CLS viene en segundo lugar — causado por imágenes sin dimensiones reservando espacio — e INP en tercer lugar, a través del lento decode de imágenes bloqueando el hilo principal. Reducir y precargar el hero mueve más LCP que cualquier otro arreglo individual.

¿Necesito carga perezosa y una precarga?

Solo recibe la precarga una imagen: el hero LCP, que debe cargarse con urgencia (eagerly). Todo por debajo del pliegue obtiene loading="lazy" para no competir con el hero por ancho de banda. Precargar una imagen con carga perezosa es contradictorio y desperdicia bytes; pre-carga el hero, carga perezosamente el resto.

¿Cuánto tiempo tardarán Core Web Vitals en reflejar mis arreglos de imágenes?

Hasta 28 días. CWV se puntúa en una ventana móvil de datos de campo reales recopilados por Chrome User Experience Report, no en una única ejecución de laboratorio. Verás movimiento en las herramientas de laboratorio (Lighthouse) inmediatamente, pero la puntuación que usa Google necesita una ventana completa de usuarios reales para actualizarse.

Créditos de imágenes

• Una computadora portátil mostrando una página web cargando mientras un desarrollador revisa el rendimiento — foto de Christina Morillo en Pexels
• Una pantalla de computadora mostrando un panel de auditoría de rendimiento — foto de Tima Miroshnichenko en Pexels
• Una computadora portátil mostrando gráficos de análisis web en tiempo real — foto de weCare Media en Pexels
• Una computadora portátil mostrando código fuente junto a una gráfica de métricas de rendimiento — foto de Daniil Komov en Pexels