Guía técnica 2026

Optimizar imágenes para Core Web Vitals y LCP

Optimizaste tus imágenes, añadiste lazy loading en todas partes, y tu puntuación LCP sigue siendo mala. ¿Y si fue precisamente el lazy loading el problema? La mayoría de errores en Core Web Vitals relacionados con imágenes no vienen de compresión olvidada, vienen de un atributo aplicado en el lugar equivocado.

9 min de lectura Optimizar imágenes para Core Web Vitals y LCP

En résumé

Para mejorar Core Web Vitals relacionados con imágenes: convierte tu imagen hero a WebP o AVIF, añade explícitamente atributos width y height para prevenir CLS, y usa fetchpriority='high' en tu imagen LCP principal. Nunca uses loading='lazy' en una imagen visible sin desplazamiento, es el error que más degrada LCP.

Qué recordar

✓ La imagen LCP es a menudo la imagen visible más grande al cargar, identifícala antes de cualquier optimización.
✓ loading='lazy' en la imagen LCP directamente penaliza la puntuación: el error más frecuente.
✓ WebP reduce peso entre 25 y 35% vs JPEG, pero sin fetchpriority, la ganancia sigue siendo parcial.
✓ Atributos width y height explícitos en todas las imágenes eliminan CLS del despliegue.
✓ PageSpeed Insights distingue datos de campo (CrUX) de mediciones de laboratorio (Lighthouse), ambos cuentan.

Qué Google realmente mide: LCP, CLS, INP e imágenes

Core Web Vitals son tres métricas que Google usa para evaluar la experiencia de usuario de una página. Las imágenes afectan dos directamente.

Déf

LCP — Largest Contentful Paint

Tiempo transcurrido antes de que el elemento visible más grande en la página se muestre. En la mayoría de casos, este elemento es una imagen. Google considera un LCP ≤ 2.5 segundos como 'bueno'.

Aussi appelé : Largest Contentful Paint, tiempo para renderizar el elemento más grande

Ex : En una página con imagen hero en la parte superior, LCP mide tiempo antes de que esta imagen se muestre completamente en pantalla.

Déf

CLS — Cumulative Layout Shift

Medida de movimientos visuales inesperados durante carga. Una imagen cuyas dimensiones no se declaran empuja contenido hacia abajo cuando se muestra. Google considera CLS ≤ 0.1 como 'bueno'.

Aussi appelé : Cumulative Layout Shift, estabilidad visual

Ex : Un artículo cuyas imágenes carecen de declaraciones width/height salta visualmente durante carga, cada imagen que llega empuja texto hacia abajo.

INP (Interaction to Next Paint) mide responsividad a clics e entradas, las imágenes la afectan marginalmente, excepto si su decodificación moviliza el hilo principal durante varios cientos de milisegundos. Para imágenes razonablemente tamaño, esto permanece marginal.

En la práctica: casi todos los problemas de Core Web Vitals relacionados con imágenes se concentran en LCP y CLS. Estas son las dos métricas a priorizar.

Identifica tu imagen LCP: el primer paso a menudo omitido

Antes de optimizar cualquier cosa, necesitas saber qué imagen Google está vigilando. No siempre es obvio.

En PageSpeed Insights, la sección “Diagnostics” identifica el elemento LCP e indica su retraso de carga. En Chrome DevTools, la pestaña Performance muestra el marcador LCP e destaca el elemento en el DOM después del análisis.

La imagen LCP más a menudo es:

La foto hero en la parte superior en un sitio de folleto
La primera imagen de producto en una página de producto de e-commerce
Un banner o ilustración principal en un artículo de blog

Si tu página no tiene imagen arriba del pliegue, el elemento LCP puede ser un bloque de texto, en cuyo caso las optimizaciones de imagen tendrán impacto LCP limitado.

Saber este elemento cambia el orden de prioridad. No todas las imágenes de página merecen el mismo tratamiento: la imagen LCP merece atención particular que los otros no.

Formato y compresión: el impacto real de WebP y AVIF en LCP

Un archivo más ligero descarga más rápido. Una descarga más rápida contribuye a LCP menor. El vínculo es directo, pero insuficiente solo.

WebP reduce el peso de una foto entre 25 y 35% comparado con JPEG con calidad visualmente equivalente. AVIF va más lejos (reducción de 35 a 50% dependiendo del contenido), pero su soporte de navegador permanece por debajo de WebP.

2.5 s

Umbral LCP 'Bueno' per Google

Google web.dev — Core Web Vitals

97 %

Soporte de navegador WebP en 2026

Can I Use — mayo 2026

~94 %

Soporte de navegador AVIF en 2026

Can I Use — mayo 2026

❌ Idée reçue

Convertir imágenes a WebP solo mejora LCP.

✅ Réalité

WebP reduce peso de archivo, y un archivo más ligero descarga más rápido. Pero si la imagen no se descubre temprano por el navegador (sin preload) o si loading='lazy' está activo, la ganancia de formato se cancela por retraso de descubrimiento de recurso. Formato y carga son dos variables independientes.

Source : Google web.dev — Optimizar LCP

En la práctica: convertir la imagen LCP a WebP con pérdida es un paso bueno, no una solución completa. Hay que combinarse con técnicas de carga de secciones siguientes para tener impacto de puntuación medible.

Para conversiones concretas — herramientas, umbrales de calidad recomendados, casos especiales — nuestra guía de formato de imagen JPEG, PNG, WebP cubre detalles por caso de uso.

Dimensiones explícitas: dos atributos que eliminan CLS

CLS causado por imágenes tiene una causa raíz: el navegador no sabe las dimensiones de imagen antes de descargarla. Muestra contenido circundante, luego cuando llega la imagen, empuja todo lo que le sigue.

La solución son dos atributos HTML:

<img src="hero.webp" width="1200" height="630" alt="Descripción" />

width y height dejan al navegador calcular relación de imagen y reservar espacio correspondiente antes de descarga. El contenido no se mueve. CLS cae a cero en estas imágenes.

Para imágenes responsivas que cambian tamaño por pantalla, la propiedad CSS aspect-ratio sirve el mismo propósito:

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

Estos dos atributos (width + height en HTML, o aspect-ratio en CSS) son la corrección más rápida de desplegar en un sitio existente. El impacto de CLS es inmediato.

loading=“lazy”: cuándo es un error (y qué imágenes evitarlo)

loading="lazy" es una instrucción útil para imágenes debajo de la página: difiere su descarga hasta que se acerquen al viewport. Menos solicitudes en carga inicial, la página se siente más ligera al navegador.

El problema: muchos desarrolladores la aplican a cada imagen sin excepción. Incluyendo la imagen hero, que es el elemento LCP.

loading='lazy' en la imagen LCP: el error más costoso

Si tu imagen hero o primera imagen de producto tiene atributo loading=“lazy”, estás pidiendo al navegador que difiera la carga del elemento que Google prioriza. El navegador espera a que la imagen esté en el viewport, pero lo está desde el primer instante. El retraso artificial se traduce directamente a LCP degradado.

La regla es simple: loading="lazy" conviene a imágenes debajo del pliegue: aquellas que el usuario no verá sin desplazamiento. En todas las imágenes visibles sin desplazamiento (arriba del pliegue), el atributo es contraproducente.

En la práctica: elimina loading="lazy" de tu imagen LCP identificada. Déjalo en todas las otras imágenes no inmediatamente visibles.

fetchpriority y preload: precarga tu imagen LCP para ganar decimales

El navegador carga recursos en un orden que determina solo. Por defecto, las imágenes no son prioridad — comienza con HTML, CSS crítico, luego JavaScript antes de atender imágenes. La imagen LCP puede así esperar varios cientos de milisegundos antes de descarga.

fetchpriority="high" cambia este orden: dice al navegador que este recurso es crítico y debe descargar como prioridad.

Precarga la imagen LCP: implementación

1

Identifica la imagen LCP en PageSpeed Insights

Ejecuta un análisis en tu página. En sección 'Opportunities' o 'Diagnostics', PageSpeed Insights identifica el elemento LCP y su URL exacta. Anota la ruta exacta del archivo.

En Chrome DevTools > pestaña Performance, haz click en 'Record' luego recarga la página, el marcador LCP aparece en la línea de tiempo con el elemento destacado.
2

Añade fetchpriority='high' a la etiqueta img

En la etiqueta <img> para tu imagen LCP, añade el atributo fetchpriority='high'. Elimina loading='lazy' si está presente. Este atributo único puede reducir LCP varios cientos de milisegundos en red móvil.

No apliques fetchpriority='high' a múltiples imágenes, la señal pierde efectividad si demasiados elementos son marcados prioridad.
3

Añade preload a <head> para imágenes cargadas vía CSS

Si la imagen LCP se carga vía CSS (background-image) en lugar de etiqueta <img>, el navegador solo la descubre después de analizar y aplicar la hoja de estilos. Un <link rel='preload'> en el <head> anticipa este retraso.

Ejemplo: <link rel='preload' as='image' href='/hero.webp' fetchpriority='high' />
4

Verifica impacto en PageSpeed Insights

Re-ejecuta análisis. Compara LCP antes y después en ambas columnas: datos de campo (CrUX) y datos de lab (Lighthouse). El cambio de lab es inmediato — el cambio de campo toma 28 días colección Chrome UX Report.

Si LCP estanca, verifica que la imagen sea servida desde un CDN o hosting rápido, el servidor TTFB (Time to First Byte) puede ser el factor limitante.

fetchpriority está disponible desde Chrome 101, Firefox 132 y Safari 17.2. En navegadores antiguos, el atributo simplemente se ignora, sin riesgo de regresión.

Imágenes responsivas: srcset y sizes para servir formato correcto a pantalla correcta

Un smartphone muestra tu imagen hero en 390 píxeles ancho. Sin srcset, descarga la misma imagen que el monitor 1920px — potencialmente 4 a 6 veces más pesada de lo necesario.

srcset declara múltiples versiones de imagen a diferentes resoluciones:

<img
  src="hero-800.webp"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  sizes="(max-width: 768px) 100vw, 50vw"
  width="800"
  height="450"
  fetchpriority="high"
  alt="Descripción de imagen"
/>

sizes dice al navegador qué ancho ocupará la imagen por tamaño de pantalla, antes de renderizar la página. Sin sizes, el navegador asume la imagen es 100% del ancho de ventana y puede descargar versión innecesariamente grande.

En la práctica: para la imagen LCP, ofrecer tres variantes (400 px, 800 px, 1600 px) cubre casi todos los casos móvil, tablet y desktop. La generación de variante ocurre aguas arriba — en exportación o vía pipeline de imagen.

Mide y valida: PageSpeed Insights, Lighthouse, CrUX — leyendo los números correctos

PageSpeed Insights muestra dos tipos de datos en la misma página. La distinción importa.

Datos de campo (CrUX): colectados en usuarios reales de Chrome visitando tu URL. Reflejan realidad de tu audiencia: conexiones móviles, dispositivos variados, cache lleno o vacío. Estos datos impactan ranking de Google.

Datos de lab (Lighthouse): medición sintética simulando dispositivo móvil en conexión lenta. Útil para diagnosticar y comparar antes/después, pero no representativo de realidad de campo.

Google Search Console > Reporte “Core Web Vitals” agrupa datos de campo URL por URL en ventana rodante de 28 días. Es el panel a vigilar después de desplegar correcciones — los cambios no aparecen allí antes de varias semanas de colección.

Lighthouse es la herramienta de debugging, CrUX es la medida final. Optimizar a 100 en Lighthouse sin mejorar CrUX es posible, y vice versa. Ambas métricas tienen su rol.

Preguntas frecuentes

¿Qué es LCP y por qué las imágenes la afectan? ▾

LCP (Largest Contentful Paint) mide tiempo antes de que el elemento visible más grande de página se muestre. En la mayoría de páginas, ese elemento es una imagen — a menudo la hero o primera imagen de producto. Google considera LCP ≤ 2.5 segundos como 'bueno'. LCP lento impacta tanto experiencia de usuario como ranking de búsqueda.

¿Cómo sé qué imagen es mi imagen LCP? ▾

Ejecuta análisis en PageSpeed Insights en la URL. La sección 'Diagnostics' identifica el elemento LCP y su ruta exacta. Otro método: Chrome DevTools > pestaña Performance > grabar una carga de página. El marcador LCP en la línea de tiempo designa el elemento con su duración de renderizado.

¿Cambiar a WebP automáticamente mejora Core Web Vitals? ▾

Parcialmente. WebP reduce peso de archivo entre 25 y 35% vs JPEG con calidad equivalente, acelerando descarga. Pero si la imagen no está precargada correctamente o loading='lazy' está activo en la imagen LCP, la ganancia de formato se cancela por retraso de descubrimiento de recurso. Formato y carga son dos variables independientes.

¿Es loading='lazy' siempre una buena práctica? ▾

No — depende de la posición de imagen. En imágenes debajo del pliegue (invisibles sin desplazamiento), loading='lazy' es beneficioso: reduce solicitudes de carga inicial. En imágenes inmediatamente visibles (especialmente LCP), es contraproducente y degrada directamente la puntuación LCP.

¿Qué es fetchpriority='high' y por qué usarlo? ▾

fetchpriority='high' es un atributo HTML diciendo al navegador priorizar este recurso sobre otros. En la imagen LCP, reduce retraso entre inicio de carga de página y descarga de imagen. El atributo es soportado desde Chrome 101, Firefox 132 y Safari 17.2, navegadores antiguos simplemente lo ignoran sin error.

¿Cómo las imágenes causan CLS? ▾

Cuando el navegador no sabe las dimensiones de una imagen antes de descargar, no reserva espacio en el layout. Cuando llega la imagen, empuja contenido circundante hacia abajo — ese es un Layout Shift. Solución: declara explícitamente width y height en todas las etiquetas <img>, o usa CSS aspect-ratio para imágenes responsivas.

¿Cuál es la diferencia entre datos Lighthouse y datos de campo en PageSpeed Insights? ▾

Lighthouse es medición de lab: simula un dispositivo móvil en conexión lenta en condiciones controladas. Los datos de campo (CrUX) vienen de usuarios Chrome reales en tu URL durante los últimos 28 días. Google ranking usa datos de campo — no Lighthouse. Lighthouse es útil para diagnosticar y comparar antes/después; CrUX es la métrica que importa para SEO.