Mejorar el LCP: guía completa de imágenes para Core Web Vitals en 2026

Entender el LCP: por qué tus imágenes te hunden

El LCP mide el tiempo transcurrido entre el inicio de la carga de la página y la aparición del mayor elemento visible en la zona visible (above the fold). En la práctica, en más del 80 % de los sitios web, ese "mayor elemento" es la imagen hero — la que ocupa la mayor parte de la primera pantalla.

Google considera tu LCP como: — Bueno (verde) si < 2,5 segundos — A mejorar (naranja) si está entre 2,5 y 4 segundos — Pobre (rojo) si > 4 segundos

Un LCP pobre le dice a Google que tu página tarda demasiado en entregar su contenido principal, lo que degrada tu posicionamiento SEO y aumenta la tasa de rebote. Un estudio de Google sobre 2,5 millones de sitios en 2024 demostró que los sitios con LCP < 2,5 s tienen una tasa de conversión un 24 % superior a aquellos con LCP > 4 s.

Las dos causas principales de un LCP malo: (1) una imagen hero demasiado pesada que tarda en llegar desde el servidor, (2) una imagen en tamaño bruto (4000 × 3000) representada en un banner de 1200 × 600 — el navegador tiene que descargar y decodificar una imagen 10 veces más grande de lo necesario.

Paso 1 — Mide tu LCP real (no el sintético)

Antes de optimizar, hay que saber qué experiencia tienen tus usuarios reales. Dos herramientas complementarias:

Google PageSpeed Insights (pagespeed.web.dev): introduce tu URL y obtén una auditoría completa en 30 segundos. Te da dos métricas: "Field Data" (el LCP real de tus visitantes reales durante los últimos 28 días, basado en el Chrome User Experience Report) y "Lab Data" (un test simulado en laboratorio). El Field Data es lo que cuenta para el SEO, es lo que Google usa.

Vercel Speed Insights (si estás alojado en Vercel): integrado en el dashboard, muestra el LCP medio y p75 por ruta y dispositivo, actualizado en tiempo real. Indispensable para detectar un cambio de rendimiento después de una actualización de código.

Chrome DevTools (pestaña Performance + Lighthouse): reproduce el LCP en lab en tu navegador. Práctico para iterar rápido durante el desarrollo, pero no refleja el rendimiento de tus usuarios reales en 4G.

Objetivo realista para 2026: LCP medio por debajo de 2 segundos en lab y por debajo de 2,5 segundos en field data. Los sitios del top 10 % en SEO están entre 1,2 y 1,8 segundos de media.

Paso 2 — Sirve formatos modernos (WebP, AVIF)

El JPG, a pesar de sus 30 años de existencia, ya no es óptimo en 2026. Los formatos modernos pesan entre un 30 % y un 50 % menos a misma calidad visual:

— WebP (Google, 2010): 25-35 % más ligero que JPG. Soportado por el 97 % de los navegadores en 2026 (todos los modernos: Chrome, Firefox, Safari, Edge, Opera).

— AVIF (Alliance for Open Media, 2019): hasta un 50 % más ligero que JPG, el doble de eficiente que WebP. Soportado por aproximadamente el 94 % de los navegadores en 2026 (Chrome, Firefox, Safari desde iOS 16, Edge).

La estrategia ganadora: usar la etiqueta HTML <picture> con cascade de fallback:

<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" alt="..." loading="eager" fetchpriority="high"> </picture>

El navegador sirve el formato más moderno que soporte, y cae en JPG como último recurso para los muy antiguos. Nuestra herramienta PixFlow ofrece la conversión JPG→WebP (pixflow.tech/es/convert-jpg-to-webp) y JPG→AVIF (pixflow.tech/es/convert-jpg-to-avif) para preparar estas 3 versiones en pocos segundos.

Paso 3 — Dimensiona correctamente (el tamaño real mostrado)

El error más caro en LCP: servir una imagen en 4000 × 3000 píxeles cuando se muestra en un bloque de 1200 × 600 en la pantalla del usuario. El navegador descarga todos los píxeles inútiles, tarda en decodificar y luego los descarta al mostrar.

La regla: generar varias versiones de cada imagen a las resoluciones correspondientes a las pantallas objetivo. Para una imagen hero, típicamente:

— 640 × 360 para móvil (≤ 768 px de ancho) — 1024 × 576 para tablet (769-1280 px) — 1920 × 1080 para escritorio (≥ 1281 px) — 2560 × 1440 o 3840 × 2160 para pantallas Retina si quieres calidad máxima

Usa la etiqueta <img srcset> o <picture> con breakpoints para servir la versión correcta según el tamaño de la pantalla:

<img src="hero-1024.jpg" srcset="hero-640.jpg 640w, hero-1024.jpg 1024w, hero-1920.jpg 1920w" sizes="(max-width: 768px) 640px, (max-width: 1280px) 1024px, 1920px" alt="..." loading="eager" fetchpriority="high" >

Nuestra herramienta PixFlow (pixflow.tech/es/resize-image) gestiona el redimensionamiento por lotes — cargas la imagen fuente en 4K, generas 3-4 versiones en un clic.

Paso 4 — Indica al navegador: fetchpriority + preload

Una vez optimizada la imagen, queda un problema: el navegador no sabe que esa imagen es crítica. Por defecto, la prioriza como una imagen normal (prioridad baja después del HTML/CSS/JS). Resultado: tu imagen hero espera a que se cargue el resto, y tu LCP se resiente.

Dos técnicas para priorizarla:

fetchpriority='high' en la etiqueta <img> de la imagen hero. Le pide al navegador que la descargue con prioridad, en cuanto descubra el tag en el HTML. Soportado por Chrome, Edge y Firefox desde 2023, ignorado sin efecto por Safari (sin regresión). Es la mejora #1 para el LCP en 2026.

<link rel='preload'> en el <head> del HTML para forzar la descarga incluso antes de que el navegador parsee el <body>:

<head> ... <link rel="preload" as="image" href="hero-1024.webp" type="image/webp" media="(min-width: 769px) and (max-width: 1280px)"> <link rel="preload" as="image" href="hero-1920.webp" type="image/webp" media="(min-width: 1281px)"> </head>

Esta técnica avanzada permite ganar entre 300 y 600 ms de LCP en sitios SSR o estáticos. En un SPA puro de React, el impacto es menor porque el HTML se sirve vacío inicialmente.

Paso 5 — Lazy load todo MENOS la imagen hero

El atributo HTML loading='lazy' le dice al navegador que retrase la carga de una imagen hasta que entre en el viewport. Es gratis, soportado nativamente por el 95 % de los navegadores en 2026 (sin librería JS), y libera ancho de banda para las imágenes críticas.

La regla: aplica loading='lazy' a TODAS las imágenes EXCEPTO la imagen hero (que debe cargar inmediatamente para el LCP). Si tienes una galería de 20 fotos en una página, son 19 imágenes ahorradas en la carga inicial.

<img src="hero.webp" alt="..." loading="eager" fetchpriority="high"> <!-- HERO: eager + high priority --> <img src="gallery-1.webp" alt="..." loading="lazy"> <!-- Below the fold: lazy --> <img src="gallery-2.webp" alt="..." loading="lazy">

Error frecuente: aplicar loading='lazy' a todas las imágenes, incluida la hero. Resultado catastrófico: el navegador espera a que la hero esté en el viewport para cargarla, lo que puede hacer que el LCP pase de 1,5 s a 4 s en móvil. Comprueba siempre que tu imagen hero esté en loading='eager' (o sin atributo, que es el valor por defecto).

Paso 6 — Reservar el espacio para evitar el CLS

El LCP no es la única métrica impactada por las imágenes. El CLS (Cumulative Layout Shift) mide los saltos visuales — cuando una imagen llega y empuja el contenido existente. Un CLS > 0,1 se considera malo.

La solución: indica siempre width y height en tus etiquetas <img>, incluso si después las sobreescribes en CSS. Esto permite al navegador reservar el espacio exacto antes de la carga, evitando el salto visual.

<img src="hero.webp" width="1920" height="1080" alt="..." style="width: 100%; height: auto;" <!-- responsive en CSS --> loading="eager" fetchpriority="high" >

El ratio de aspecto (width / height) calculado por el navegador le permite reservar el espacio correcto incluso si lo redimensionas en CSS. Sin estos atributos, el navegador no sabe el espacio a reservar e inserta la imagen abruptamente cuando llega, empujando el contenido y disparando el CLS.

Misma regla para las imágenes SVG en línea: indica width / height en la etiqueta.