Optimización
Compresión de imágenes para Core Web Vitals — Lo que realmente impacta
Los cambios de optimización de imágenes que de verdad mejoran LCP, CLS e INP — con cifras reales. Salta los mitos, envía los que mueven la métrica.
Los Core Web Vitals son las tres mediciones de Google sobre la experiencia real del usuario, y las imágenes están metidas en las tres. El Largest Contentful Paint casi siempre lo marca una imagen hero. El Cumulative Layout Shift normalmente es una imagen cargando sin espacio reservado. El Interaction to Next Paint puede tumbarlo trabajo de decodificación de imágenes bloqueando el hilo principal. Arregla las imágenes y las puntuaciones se mueven — a menudo más que cualquier otra optimización.
Esta guía repasa lo que mueve la aguja, con cifras reales, no el clásico “optimiza tus imágenes”.
Las tres métricas y los objetivos
Para referencia, los objetivos de 2026:
| Métrica | Qué mide | Bueno | Mejorable | Malo |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Tiempo hasta renderizar el mayor elemento visible | ≤2.5s | 2.5-4s | >4s |
| CLS (Cumulative Layout Shift) | Estabilidad visual durante la carga | ≤0.1 | 0.1-0.25 | >0.25 |
| INP (Interaction to Next Paint) | Capacidad de respuesta al input del usuario | ≤200ms | 200-500ms | >500ms |
INP sustituyó a First Input Delay (FID) como Core Web Vital en marzo de 2024. Si lees artículos antiguos que mencionan FID, tradúcelo a INP — es una medición más estricta y realista de la interactividad.
LCP casi siempre es una imagen
Los datos de campo de Google muestran de forma consistente que el elemento LCP en la mayoría de páginas es una imagen — un hero, una foto de producto o una imagen destacada. Texto es LCP quizá en el 20% de las páginas. Así que “optimizar LCP” casi siempre significa “optimizar la imagen LCP”.
Tres palancas mueven el LCP en páginas dominadas por imagen:
1. Dimensiona la imagen al tamaño correcto. La mayor victoria de LCP es servir la imagen al tamaño al que realmente se muestra, no 4× más grande. Un hero que renderiza a 1200 px de ancho no debería ser un JPG de 4000 px. Usa Redimensionar imagen o un flujo responsive para limitar las dimensiones de entrega.
Un ejemplo real: un hero 4000×2667 en JPG 85 pesa 1.8 MB. El mismo hero a 1600×1067 (el máximo al que se mostrará en escritorio a 1.5× DPI) pesa 280 KB. Son 6.4× menos datos por el cable. En 4G a 5 Mbps, eso son unos 2.9s vs 0.45s de tiempo de transferencia — fácilmente la diferencia entre fallar y pasar LCP.
2. Usa un formato moderno. A la misma calidad visible, WebP es 25-35% más pequeño que JPG y AVIF 40-55% más pequeño que JPG. Para un hero, eso es presupuesto LCP directo. Consulta PNG a WebP o nuestra guía comparativa sobre WebP vs AVIF en 2026.
3. Haz preload de la imagen LCP. Si tu hero solo es descubrible tras parsear un stylesheet o un bundle JS, el navegador pierde tiempo. Un <link rel="preload" as="image" href="/hero.webp" fetchpriority="high"> en el <head> le dice al navegador que empiece a descargarla ya.
En 2023, Chrome añadió el atributo fetchpriority="high" para <img>. Usarlo en tu imagen LCP es un cambio de una línea que suele mover LCP entre 100 y 400 ms en conexiones lentas.
CLS casi siempre son dimensiones ausentes
La causa más común de CLS alto son las imágenes sin espacio reservado. Cuando una imagen carga y expande la página, todo lo que hay debajo salta. Google lo cuenta en tu contra.
La solución lleva cinco años disponible: pon siempre atributos width y height en los tags <img>.
<!-- A prueba de CLS -->
<img src="/hero.webp" alt="..." width="1200" height="600">Los navegadores usan la relación width/height para reservar espacio antes de que la imagen cargue. Puedes seguir estilando con CSS (max-width: 100%; height: auto;) — los atributos son pistas de proporción, no dimensiones fijas.
Para imágenes responsive con srcset, width/height deben coincidir con el src por defecto. El navegador se encarga del resto.
Para imágenes de fondo puestas por CSS, no hay reserva automática de proporción. Si tienes una imagen de fondo crítica, pon un min-height explícito o usa aspect-ratio: 16/9; en el contenedor.
INP y coste de decodificación
INP es la métrica más nueva y menos comentada. Mide la capacidad de respuesta de la página al input — click, tap, tecla — a lo largo de toda la sesión, no solo la primera interacción.
Las imágenes afectan a INP de dos maneras:
Coste de decodificación. Decodificar un JPG o PNG grande ocurre en el hilo principal por defecto. Si cargas una imagen de 6 MB y el usuario toca un botón mientras se decodifica, la respuesta al toque espera. Enviar imágenes más pequeñas (vía compresión y dimensionado correcto) reduce el tiempo de bloqueo del hilo principal y mejora INP de forma indirecta.
Decodificación asíncrona. El atributo decoding="async" en <img> le dice al navegador que decodifique la imagen fuera del hilo principal cuando sea posible.
<img src="/foto.webp" alt="..." width="800" height="600" loading="lazy" decoding="async">Combinado con loading="lazy" para imágenes bajo el pliegue, este patrón es el valor por defecto de 2026 para imágenes que no son LCP. No uses loading="lazy" en la imagen LCP — lazy-load del hero retrasa LCP y lo hunde.
Ajustes de calidad que importan
Un ejemplo concreto. La misma fotografía a 1600×1067, codificada a distintas calidades JPG:
- Calidad 95: 410 KB (visualmente indistinguible del original)
- Calidad 90: 260 KB (sin pérdida visible al tamaño de visualización)
- Calidad 85: 180 KB (imperceptible salvo al hacer zoom 200%+)
- Calidad 80: 135 KB (ligero suavizado en gradientes si lo buscas)
- Calidad 75: 105 KB (artefactos de croma visibles en zonas suaves)
- Calidad 70: 85 KB (artefactos evidentes, los tonos de piel sufren primero)
Para fotografía en página de contenido, calidad 82-85 es el punto dulce. Es donde la curva de tamaño empieza a aplanarse y reducir más empieza a doler visiblemente. Calidad 95 es derroche para web. Calidad 70 es falso ahorro que te hace parecer barato.
La escala de calidad de WebP es similar. La de AVIF es distinta — calidad 60-65 en AVIF produce una salida visualmente similar a JPG calidad 82-85.
Usa Comprimir imagen para iterar por niveles de calidad y ver el tamaño para tu imagen concreta. Los sitios con mucha foto deberían fijar una calidad por caso de uso y respetarla; mezclar calidad 70 y 95 en la misma galería produce inconsistencia visible.
Chroma subsampling, el mando subestimado
JPG usa por defecto chroma subsampling 4:2:0 — los canales de color se codifican a media resolución en ambas dimensiones. Para la mayoría de fotografía esto es invisible y ahorra ~40% del tamaño frente a 4:4:4 (sin submuestreo).
Dos casos donde 4:2:0 duele:
- Texto dentro de la imagen. Capturas, infografías con etiquetas, cualquier imagen con texto de color nítido. 4:2:0 produce halos de color visibles en los bordes del texto. Usa 4:4:4 para esos casos, o usa PNG.
- Imágenes con bordes de color de alta saturación. El detalle fino en rojos y azules sufre más que en verdes por cómo el espacio de color YCbCr separa luminancia de croma.
La mayoría de herramientas de compresión usan 4:2:0 por defecto y exponen 4:4:4 como opción. Si comprimes fotografía y la salida se ve blanda o el texto borroso, revisa primero el subsampling.
Checklist del pipeline completo
Para pasar Core Web Vitals en una página con muchas imágenes:
- Servir la imagen LCP al tamaño correcto (tamaño de entrega, no el del original).
- Usar WebP o AVIF para la imagen LCP; fallback JPG en un
<picture>. - Preload de la imagen LCP con
fetchpriority="high". - Poner
widthyheighten cada<img>. - Usar
loading="lazy"ydecoding="async"en imágenes bajo el pliegue. - Comprimir a calidad 82-85 para fotografía, 90+ para imágenes con texto.
- Reservar espacio para imágenes de fondo con CSS explícito de aspect-ratio.
- Evitar cargar imágenes enormes solo para reducirlas por CSS.
Haz estas siete cosas y LCP, CLS e INP mejorarán todas — a menudo lo suficiente para mover una página de “Mala” o “Mejorable” directamente a “Buena” sin cambios de framework ni trabajo de servidor.
Herramientas relacionadas
Preguntas frecuentes
¿Pasar de JPG a WebP mejora el LCP?
Normalmente sí, y a menudo de forma significativa. A la misma calidad visible, WebP es 25-35% más pequeño que JPG, lo que recorta directamente el tiempo de transferencia de la imagen LCP. Para un hero en 4G, puede suponer 200-500 ms menos de LCP. AVIF es 40-55% más pequeño que JPG y ahorra todavía más. Combina el cambio de formato con un dimensionado correcto y fetchpriority=high en la imagen LCP y es habitual mover una página de Mala o Mejorable a Buena sin tocar nada más.
¿Qué calidad JPG es segura para fotos de producto?
Calidad 82-85 es el punto dulce para fotografía en página de contenido. A 85, los tamaños son un 40% menores que a 95 con diferencia visible imperceptible. Calidad 75 empieza a mostrar artefactos de croma en zonas suaves como tonos de piel o cielos. Calidad 70 es falso ahorro que parece barato. Para fotos de producto donde el detalle fino importa más, 85-90 es más seguro; para miniaturas, 75-80 vale. Mantén un único ajuste por caso de uso a lo largo de una galería para evitar inconsistencia visible.
¿Cuándo loading=lazy perjudica al LCP?
Cuando lo pones en la propia imagen LCP. Lazy-load difiere la petición hasta que la imagen se acerca al viewport, así que aplicarlo al hero o a la imagen sobre el pliegue retrasa justo lo que LCP mide. Usa loading=lazy solo en imágenes bajo el pliegue. En la imagen LCP, haz lo contrario: añade fetchpriority=high para que el navegador la priorice, y considera un rel=preload en el head si la imagen se descubre tarde en el HTML.
¿Necesito los atributos width y height si dimensiono las imágenes con CSS?
Sí — los atributos son lo que previene el Cumulative Layout Shift. Los navegadores usan la proporción width/height para reservar espacio de layout antes de que la imagen cargue. Sin ellos, todo lo que hay debajo salta al llegar, y Google lo cuenta en tu contra. Puedes seguir estilando con CSS (max-width: 100%; height: auto;) — los atributos actúan como pistas de proporción, no como tamaños fijos. Para imágenes de fondo por CSS no hay reserva automática; usa aspect-ratio o min-height explícito en el contenedor.
¿Cuándo usar chroma subsampling 4:4:4 en vez del 4:2:0 por defecto?
Cuando la imagen contiene texto de color nítido — capturas, infografías, etiquetas sobre fotos — o bordes de alta saturación en rojos y azules. El 4:2:0 por defecto codifica los canales de color a media resolución y produce halos de color visibles en los bordes del texto. 4:4:4 preserva la resolución completa de color a cambio de archivos ~40% más grandes. Para fotografía corriente, 4:2:0 es invisible y ahorra ancho de banda real, así que la elección solo importa cuando hay texto o detalle saturado en el encuadre.