El Largest Contentful Paint (LCP) sigue siendo, con diferencia, la métrica de Core Web Vitals más difícil de aprobar en 2026. Los datos del Web Almanac lo dejan claro: solo el 62% de las páginas móviles consiguen un LCP inferior a 2,5 segundos. Y aquí viene lo interesante — en la gran mayoría de esos casos, el elemento LCP es una imagen. El hero banner, la foto de producto, el thumbnail del artículo... siempre una imagen.
La buena noticia es que no necesitas reescribir tu aplicación para arreglar esto. Con los formatos adecuados (AVIF, WebP), el marcado HTML correcto (<picture>, srcset, sizes) y un par de atributos estratégicos (fetchpriority, loading), puedes recortar tu LCP entre un 30% y un 50%. Sin tocar una sola línea de JavaScript.
Así que vamos al grano. En esta guía vas a aprender exactamente cómo hacerlo, con código que puedes copiar y pegar y datos actualizados a marzo de 2026.
Por qué las imágenes son el cuello de botella del LCP
El LCP mide cuánto tarda en renderizarse el elemento visible más grande dentro del viewport. Google considera buenos los valores por debajo de 2,5 segundos. Cualquier cosa por encima de 4 segundos es directamente una señal de alarma.
Pero el LCP no depende de un solo factor. Son cuatro eslabones encadenados:
- TTFB (Time to First Byte): cuánto tarda el servidor en responder
- Bloqueo de renderizado: CSS y JS que impiden pintar la página
- Tiempo de carga del recurso: cuánto pesa la imagen y cuándo empieza a descargarse
- Tiempo de renderizado del cliente: cuánto tarda el navegador en pintar el elemento
En la práctica, el factor 3 es donde la mayoría de sitios pierden la batalla. Y tiene sentido: una imagen hero de 800 KB en JPEG, sin srcset y sin priorización, puede consumir ella sola más de 2 segundos en una conexión 4G normal. Pero esa misma imagen en AVIF con fetchpriority="high" podría cargar en menos de 600 milisegundos. La diferencia es brutal.
AVIF vs. WebP vs. JPEG: los números reales en 2026
Antes de meternos con código, veamos las cifras de compresión y compatibilidad. Porque sin datos, cualquier debate de formatos es pura opinión:
| Formato | Reducción vs. JPEG | Soporte global (2026) | Características |
|---|---|---|---|
| JPEG | — | 100% | Universal, sin transparencia, 8-bit |
| WebP | 25-34% | ~98% | Lossy/lossless, transparencia, animación |
| AVIF | 41-50% | ~95% | Lossy/lossless, transparencia, HDR, 10/12-bit |
AVIF ofrece un 20% de reducción adicional sobre WebP, que ya de por sí reducía un 27% respecto a JPEG. En total, estamos hablando de hasta un 50% menos de tamaño comparado con JPEG manteniendo la misma calidad visual. Y en imágenes con gradientes o detalles complejos, la diferencia puede llegar al 76% (sí, leíste bien).
En cuanto a compatibilidad, AVIF ya funciona en Chrome (desde v85), Firefox (desde v93), Safari (desde v16.6) y Edge (desde v121). Con un soporte global por encima del 95%, puedes usarlo como formato principal sin problemas. Eso sí, siempre con un fallback a WebP o JPEG para ese pequeño porcentaje restante.
¿Cuándo usar cada formato?
| Caso de uso | Formato recomendado |
|---|---|
| Fotos / imágenes hero | AVIF → WebP → JPEG |
| Fotos de producto con HDR o gradientes | AVIF primero |
| Logos, iconos, elementos UI | SVG (o WebP lossless / PNG) |
| Animaciones cortas | WebP animado |
| Imágenes con transparencia | AVIF o WebP |
El elemento <picture>: servir AVIF con fallback inteligente
La forma correcta de servir formatos modernos es con el elemento <picture>. El navegador recorre las etiquetas <source> en orden y se queda con la primera que pueda procesar. Sencillo y elegante:
<picture>
<source
type="image/avif"
srcset="hero-400.avif 400w,
hero-800.avif 800w,
hero-1200.avif 1200w,
hero-1600.avif 1600w"
sizes="(max-width: 640px) 100vw,
(max-width: 1024px) 80vw,
1200px"
>
<source
type="image/webp"
srcset="hero-400.webp 400w,
hero-800.webp 800w,
hero-1200.webp 1200w,
hero-1600.webp 1600w"
sizes="(max-width: 640px) 100vw,
(max-width: 1024px) 80vw,
1200px"
>
<img
src="hero-1200.jpg"
srcset="hero-400.jpg 400w,
hero-800.jpg 800w,
hero-1200.jpg 1200w,
hero-1600.jpg 1600w"
sizes="(max-width: 640px) 100vw,
(max-width: 1024px) 80vw,
1200px"
alt="Descripción de la imagen hero"
width="1200"
height="800"
fetchpriority="high"
loading="eager"
>
</picture>Los puntos clave de este marcado:
- AVIF primero, WebP segundo, JPEG como fallback universal
srcsetcon descriptoreswen cada<source>para que el navegador elija el tamaño óptimosizespara indicar cuánto espacio ocupa la imagen en cada breakpointwidthyheightexplícitos para evitar CLS (Cumulative Layout Shift)fetchpriority="high"yloading="eager"porque esta imagen es el elemento LCP
El error fatal: srcset sin sizes
Honestamente, este es uno de los errores que más me encuentro en auditorías. Y es de los más costosos en rendimiento. Muchos desarrolladores usan srcset con descriptores de ancho (w) pero se olvidan del atributo sizes.
¿El resultado? Sin sizes, el navegador asume 100vw por defecto. En una pantalla de escritorio de 1920px, eso significa que descargará la imagen más grande disponible aunque solo se muestre en una columna de 600px. Estás proporcionando los ingredientes correctos pero olvidándote de la receta.
Ejemplo incorrecto:
<!-- MAL: srcset sin sizes -->
<img
src="imagen-300.jpg"
srcset="imagen-300.jpg 300w,
imagen-900.jpg 900w,
imagen-1800.jpg 1800w"
alt="Producto"
>Ejemplo correcto:
<!-- BIEN: srcset con sizes -->
<img
src="imagen-300.jpg"
srcset="imagen-300.jpg 300w,
imagen-900.jpg 900w,
imagen-1800.jpg 1800w"
sizes="(max-width: 600px) 300px,
(max-width: 1200px) 900px,
1800px"
alt="Producto"
width="900"
height="600"
>fetchpriority="high": una línea que mejora el LCP hasta un 30%
Cuando el navegador carga una página, descarga CSS, JavaScript y fuentes con prioridad alta. Las imágenes, en cambio, se quedan en cola con prioridad media. Sí, el navegador eventualmente sube la prioridad de la imagen LCP después del layout, pero para entonces ya está compitiendo con docenas de recursos que le sacaron ventaja.
fetchpriority="high" cierra esa brecha. Le dice al navegador desde el primer momento: "esta imagen es crítica, descárgala ya":
<img
src="hero.avif"
alt="Banner principal"
width="1200"
height="600"
fetchpriority="high"
>Y los resultados hablan por sí solos:
- Google Flights redujo su LCP de 2,6s a 1,9s — un 27% de mejora — con un solo atributo HTML
- Etsy mejoró su LCP un 4% con Priority Hints, y algunos sitios reportaron mejoras del 20-30% en pruebas de laboratorio
- El equipo de rendimiento de WordPress Core documentó mejoras típicas del 5-10%, llegando hasta el 30% en ciertos escenarios
Eso sí, una regla importante: usa fetchpriority="high" solo en 1-2 recursos por página. Si lo aplicas a todo, los recursos compiten entre sí y el beneficio desaparece. Lighthouse ya te avisa si tu imagen LCP no tiene este atributo.
Preload: cargar la imagen LCP antes de que el HTML la descubra
Incluso con fetchpriority="high", el navegador necesita llegar hasta la etiqueta <img> en el HTML para empezar la descarga. Si tu imagen está dentro de un componente renderizado por JavaScript, o si el CSS tarda en procesarse, la descarga se retrasa más de lo necesario.
¿La solución? Un <link rel="preload"> en el <head>:
<head>
<!-- Preload de la imagen LCP con soporte responsive -->
<link
rel="preload"
as="image"
type="image/avif"
href="hero-1200.avif"
imagesrcset="hero-400.avif 400w,
hero-800.avif 800w,
hero-1200.avif 1200w,
hero-1600.avif 1600w"
imagesizes="(max-width: 640px) 100vw,
(max-width: 1024px) 80vw,
1200px"
fetchpriority="high"
>
</head>Gracias a imagesrcset e imagesizes, el preload respeta las reglas responsive y descarga solo el tamaño que necesita el dispositivo. Discord usó esta técnica para su imagen LCP y obtuvo mejoras medibles en sus métricas.
Lazy loading: úsalo bien o te destruye el LCP
El lazy loading es fantástico para imágenes por debajo del viewport (below the fold). Reduce la contención de red y deja espacio para que los recursos críticos carguen primero.
Pero aplicarlo a la imagen LCP es un desastre. Y te lo digo porque es uno de los errores más frecuentes que veo en producción.
Lo que debes hacer
<!-- Imagen LCP (above the fold): NUNCA lazy -->
<img
src="hero.avif"
alt="Banner principal"
width="1200"
height="600"
fetchpriority="high"
loading="eager"
>
<!-- Imágenes below the fold: lazy loading nativo -->
<img
src="producto-1.avif"
alt="Producto destacado"
width="400"
height="300"
loading="lazy"
>Lo que NUNCA debes hacer
<!-- DESASTRE: lazy loading en la imagen LCP -->
<img
src="hero.avif"
alt="Banner principal"
loading="lazy" <!-- ESTO DESTRUYE TU LCP -->
>En 2026, loading="lazy" tiene soporte en más del 95% de navegadores, incluido Safari desde la versión 15.4. No necesitas librerías JavaScript para esto.
Un truco rápido: si tu página tiene 10 imágenes y solo la primera está en el viewport inicial, aplica loading="lazy" a las 9 restantes. Eso reduce la contención de red y puede mejorar indirectamente la carga de tu imagen LCP.
Nunca uses imágenes de fondo CSS para el elemento LCP
Este es un error de arquitectura que ninguna optimización posterior puede compensar. El preload scanner del navegador solo lee HTML, no archivos CSS. Si tu imagen LCP está como background-image en CSS, el navegador no se entera de que existe hasta que:
- Descarga el HTML
- Descarga el CSS
- Analiza el CSS
- Compara los selectores con el DOM
Solo entonces empieza la descarga. Son cuatro pasos encadenados que prácticamente te garantizan un LCP mediocre. La solución es simple: usa siempre <img> o <picture> para el elemento LCP.
Automatizar la conversión: herramientas y pipelines
Generar a mano versiones AVIF y WebP para cada imagen y cada tamaño es inviable (a menos que te sobre mucho tiempo libre). Estas son las opciones más prácticas en 2026:
Herramientas de línea de comandos
# Convertir a AVIF con calidad 50 (buen balance calidad/tamaño)
avifenc --min 30 --max 50 --speed 6 input.jpg output.avif
# Convertir a WebP con calidad 80
cwebp -q 80 input.jpg -o output.webp
# Script batch para generar múltiples tamaños
for size in 400 800 1200 1600; do
convert input.jpg -resize ${size}x -quality 85 "output-${size}.jpg"
cwebp -q 80 "output-${size}.jpg" -o "output-${size}.webp"
avifenc --min 30 --max 50 "output-${size}.jpg" "output-${size}.avif"
doneCDNs con transformación automática
Los CDN modernos como Cloudflare Images, Cloudinary y Fastly Image Optimizer detectan automáticamente las capacidades del navegador mediante el header Accept y sirven el formato óptimo sin que toques tu HTML. Si el navegador soporta AVIF, lo recibe; si no, WebP; y como último recurso, JPEG.
Eso sí, si usas CDN, configura el header Vary: Accept. Es fácil olvidarlo, pero sin él las cachés intermedias pueden servir el formato equivocado a los usuarios.
Build tools y frameworks
La mayoría de frameworks modernos ya traen optimización de imágenes integrada:
- Next.js: su componente
<Image>genera tamaños responsive automáticamente, sirve AVIF/WebP, añadewidth/heightpara prevenir CLS y aplica lazy loading a imágenes below the fold - Astro: procesa imágenes en build time con sharp, generando múltiples formatos y tamaños
- Vite con
vite-imagetools: genera variantes como parte del pipeline de build
Checklist de optimización de imágenes para LCP
Para que no se te escape nada, aquí tienes una lista de verificación que puedes aplicar a cualquier proyecto:
| Acción | Impacto en LCP | Esfuerzo |
|---|---|---|
| Servir imágenes en AVIF con fallback WebP/JPEG | Alto | Medio |
Añadir fetchpriority="high" a la imagen LCP | Alto | Bajo |
Eliminar loading="lazy" de la imagen LCP | Alto | Bajo |
Usar <picture> con srcset y sizes | Alto | Medio |
Preload de la imagen LCP en el <head> | Alto | Bajo |
Definir width y height en todas las imágenes | Medio (previene CLS) | Bajo |
| Lazy loading en imágenes below the fold | Medio | Bajo |
Mover la imagen LCP de CSS background a <img> | Alto | Medio |
| Usar CDN con detección automática de formato | Alto | Medio |
| Comprimir imágenes al tamaño máximo necesario | Medio-Alto | Bajo |
Cómo medir si tus cambios funcionan
Optimizar sin medir es ir a ciegas. Estas son las herramientas que realmente necesitas (no más, no menos):
- Google PageSpeed Insights: combina datos de campo (Chrome UX Report) con datos de laboratorio (Lighthouse). Te muestra el valor exacto de LCP con diagnósticos accionables
- Chrome DevTools: en la pestaña Network, busca tu imagen LCP y comprueba su tamaño, tiempo de descarga y prioridad de fetch. En Performance, verifica que el LCP coincida con tu imagen hero
- Google Search Console: datos reales de Core Web Vitals agrupados por URL. Es la referencia definitiva porque refleja la experiencia real de tus usuarios, no un test sintético
- web-vitals.js: librería ligera para monitorear Core Web Vitals en producción con tus propias analíticas
Mi recomendación personal: configura alertas al 80% del umbral de Google, es decir, LCP > 2,0s. He visto regresiones de rendimiento tras un deploy pasar completamente desapercibidas durante semanas porque nadie estaba monitorizando.
Preguntas frecuentes
¿Puedo usar solo AVIF sin fallback a WebP o JPEG?
Técnicamente podrías, ya que el soporte supera el 95% en 2026. Pero no lo haría. Algunos Android antiguos, versiones de iOS anteriores a 16 y ciertos crawlers de buscadores no soportan AVIF. Lo más seguro es usar <picture> con AVIF como primera opción y WebP o JPEG como fallback. El marcado extra es mínimo y te aseguras de que todos tus visitantes vean las imágenes.
¿Por qué no debo aplicar lazy loading a la imagen LCP?
Porque loading="lazy" retrasa la descarga hasta que el viewport se acerca a la imagen. Si la imagen ya está visible al cargar la página, el lazy loading añade entre 500ms y 2 segundos de retraso innecesario a tu LCP. La imagen LCP debe usar loading="eager" (que es el valor por defecto) y, si es posible, fetchpriority="high".
¿Qué tamaños de imagen debo generar para srcset?
Una buena regla general: genera variantes en incrementos de 400px — 400, 800, 1200, 1600, y opcionalmente 2000px para pantallas de alta densidad. El objetivo es que el navegador nunca descargue más de 400px de imagen innecesaria. Si tienes datos de analíticas sobre los dispositivos de tus usuarios, ajusta los breakpoints a los anchos más comunes de tu audiencia.
¿fetchpriority="high" funciona en todos los navegadores?
Sí. En 2026, fetchpriority tiene soporte completo en Chrome, Edge, Safari y Firefox. Los navegadores que no lo soporten simplemente lo ignoran, así que es totalmente seguro añadirlo. Chrome lo soporta desde la versión 101, y WordPress lo añade automáticamente desde la 6.3.
¿Es mejor un CDN con detección automática o generar las imágenes en el build?
Depende. Los CDNs con detección automática (Cloudflare Images, Cloudinary) son ideales para contenido dinámico o subido por usuarios, porque no necesitas pipeline de build. La generación en build time (sharp, imagemin, o las herramientas de Next.js/Astro) funciona mejor para sitios estáticos o con contenido controlado, porque te da control total sobre la calidad sin depender de un servicio externo. En ambos casos, no olvides el header Vary: Accept para evitar líos con la caché.