Si tu sitio se siente lento, las imágenes son el primer lugar donde hay que mirar. En la mayoría de los sitios web representan más peso total de la página que todo el resto de los recursos combinados — HTML, CSS y JavaScript incluidos. Eso también las convierte en lo que más impacto tiene arreglar, ya que un puñado de imágenes bien comprimidas pueden recortar segundos de carga que una docena de ajustes de código no lograrían.

Dónde duelen de verdad las imágenes

Los Core Web Vitals de Google son las métricas de velocidad que entran en el ranking de búsqueda. Son tres, y las imágenes afectan directamente a dos:

Métrica	Umbral "bueno"	¿Le afectan las imágenes?
Largest Contentful Paint (LCP)	menos de 2,5 s	Directamente, y casi siempre de forma decisiva
Cumulative Layout Shift (CLS)	menos de 0,1	Sí, pero por el marcado, no por el peso
Interaction to Next Paint (INP)	menos de 200 ms	Solo de forma indirecta

LCP mide cuánto tarda en dibujarse el elemento visible más grande. En la mayoría de páginas ese elemento es una imagen: un banner de cabecera, una foto de producto, la imagen destacada de un post. Una imagen pesada es la causa más común de un LCP que no pasa.

CLS mide cuánto salta la maquetación mientras carga. Esto no tiene nada que ver con el peso: ocurre cuando una imagen llega sin declarar sus dimensiones, así que el navegador solo descubre cuánto espacio necesita después de haber colocado todo lo demás.

INP mide la respuesta a la interacción, y las imágenes lo tocan solo de refilón: una imagen muy grande cuesta tiempo de hilo principal al decodificarse, y eso puede retrasar la respuesta a un toque mientras sucede.

Un detalle que ahorra muchas confusiones: Google evalúa esto sobre el percentil 75 de usuarios reales en una ventana móvil de 28 días, vía el Chrome User Experience Report. Solo apruebas cuando al menos el 75% de las visitas reales cumple el umbral. Por eso pueden convivir tan tranquilamente una puntuación perfecta de Lighthouse y un informe de Search Console en rojo — volvemos a esto más abajo.

Lo que cuesta un megabyte en segundos

Esta es la parte que vuelve concreto el intercambio. El perfil móvil por defecto de Lighthouse limita la conexión a 1,6 Mbps con 150 ms de latencia, una conexión deliberadamente mediocre, aproximadamente el cuarto más lento del 4G. A esa velocidad te llegan unos 195 KB por segundo.

Coge la curva de calidad JPG que medimos en cómo comprimir imágenes sin perder calidad y convierte los pesos en tiempo de transferencia:

Calidad	Peso	Tiempo de transferencia a 1,6 Mbps
100	1220 KB	6,25 s
95	402 KB	2,06 s
90	234 KB	1,20 s
85	151 KB	0,77 s
80	118 KB	0,60 s
70	75 KB	0,38 s

Ahora contrástalo con un presupuesto de LCP de 2,5 segundos — y recuerda que el presupuesto tiene que cubrirlo todo, no solo la imagen: DNS, establecimiento de conexión, respuesta del servidor, parseo del HTML, CSS, y solo entonces la descarga de la imagen.

A calidad 100, la imagen sola se pasa del presupuesto entero por casi cuatro segundos. A 95 se come más del 80%. A 85 ocupa menos de un tercio y deja sitio real para todo lo demás. Es el mismo ahorro de un solo paso, de 100 a 95, del artículo de compresión, replanteado como la diferencia entre aprobar y no aprobar.

Dos advertencias para que las cifras sigan siendo honestas. Nuestra imagen de prueba tiene mucho grano, así que sus pesos absolutos salen más altos que en una foto típica de móvil: lo que se traslada son las proporciones, los KB son ilustrativos. Y una conexión real no es una tubería constante: la imagen normalmente no puede ni empezar a descargarse hasta que el HTML se ha parseado, lo que hace el panorama práctico algo peor que la tabla, no mejor.

De ahí sale un presupuesto de peso para la página

Dale la vuelta a esa aritmética y se convierte en un número con el que puedes diseñar. A 195 KB por segundo, un presupuesto de LCP de 2,5 segundos te compra unos 490 KB en total — y ese total cubre el HTML, el CSS, cualquier JavaScript bloqueante y las tipografías, antes de gastar un solo byte de imagen.

Digamos que el armazón de la página cuesta 150 KB. Te quedan unos 340 KB para lo que se dibuje sobre la línea de flotación. Una imagen de cabecera a calidad 85 (151 KB en nuestra tabla) entra cómodamente. Tres no.

Esta es además la respuesta a "cuántas imágenes son demasiadas". Una galería con diez fotos de 118 KB son 1,18 MB: seis segundos de transferencia en esa conexión, antes de que cargue nada más. El arreglo no es comprimir más cada una, es cargar dos y dejar las otras ocho en carga diferida, para que solo compita por el presupuesto lo que se ve.

Hay dos cosas que te devuelven margen al margen del presupuesto. El caché significa que quien vuelve no paga nada por las imágenes que ya tiene, así que pon tiempos largos de Cache-Control en archivos cuya URL cambie cuando cambie el contenido. Y una CDN acorta el viaje de ida y vuelta, no el tamaño: esos 150 ms de latencia son por petición, y se pagan en todas.

El orden que importa

Tres palancas, y no tienen la misma fuerza. Tira de ellas en este orden:

Redimensiona al tamaño real de visualización. Una foto de 4000 píxeles de ancho en una columna de 600 descarga los datos de los 4000 píxeles para que el navegador tire casi todos. Ningún ajuste de calidad recupera eso. Es la victoria más grande y la que más se salta la gente.
Cambia de formato. WebP suele quedar entre un 25% y un 35% por debajo de un JPG equivalente con la misma calidad visual, y AVIF más todavía. Los dos se muestran sin riesgo en cualquier navegador que siga recibiendo actualizaciones. (WebP vs JPG vs PNG vs AVIF cubre las contrapartidas.)
Y entonces ajusta la calidad. A estas alturas estás optimizando un archivo ya razonable, que es justo el momento correcto para hacerlo.

Cuatro errores de entrega que arruinan una buena compresión

Puedes comprimir de forma impecable y seguir suspendiendo el LCP. Así es como.

Cargar en diferido la imagen de cabecera. El autogol más común de toda la lista. loading="lazy" le dice al navegador que esa imagen no es urgente, así que ponérselo a tu imagen de LCP retrasa activamente lo que se está midiendo. Difiere lo que está bajo la línea de flotación; nunca lo que está por encima.

No declarar las dimensiones. Pon siempre width y height (o un aspect-ratio en CSS). El navegador reserva el espacio correcto antes de que llegue el archivo, y el CLS deja de ocurrir. No cuesta nada y arregla una métrica entera.

Servir el mismo tamaño a todos los dispositivos. Un móvil recibe el mismo archivo de 2000 píxeles que un escritorio. srcset con sizes deja que el navegador elija:

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="500"
  alt="…"
  fetchpriority="high"
/>

Ese fetchpriority="high" es la contraparte del error de la carga diferida: le dice al navegador que descargue esta primero, por delante de las otras imágenes que descubrió al mismo tiempo.

No ofrecer formatos modernos con alternativa. <picture> te permite servir AVIF a quien lo admita y caer con elegancia:

<picture>
  <source srcset="foto.avif" type="image/avif" />
  <source srcset="foto.webp" type="image/webp" />
  <img src="foto.jpg" width="800" height="500" alt="…" />
</picture>

El navegador coge el primer tipo que entiende. No se rompe nada en ninguna parte.

Números de laboratorio contra usuarios reales

Conviene entenderlo antes de perseguir una puntuación. Lighthouse y PageSpeed Insights ejecutan una prueba de laboratorio: una carga, un dispositivo simulado, una conexión limitada. Determinista y útil para encontrar problemas.

El informe de Core Web Vitals de Search Console muestra datos de campo: visitantes reales, dispositivos reales, redes reales, agregados al percentil 75 sobre 28 días. Otra pregunta, otra respuesta.

Dos consecuencias prácticas. Una puntuación de laboratorio mejora en el momento en que despliegas el arreglo; el informe de campo tarda semanas en ponerse al día, porque sigue promediando la experiencia antigua. Y una prueba de laboratorio desde la fibra de tu portátil te dice muy poco sobre un visitante con una conexión móvil mala — que es exactamente a quien mide el percentil 75.

Usa la prueba de laboratorio para encontrar qué está mal. Usa los datos de campo para decidir si de verdad está arreglado.

Cómo comprobar dónde estás

Pasa la página por PageSpeed Insights. Informa de datos de laboratorio y de campo lado a lado para cualquier URL pública, y nombra el elemento concreto que eligió como tu LCP — que suele ser la forma más rápida de descubrir que la imagen que creías culpable no es la que se está midiendo.

Hacer bien la parte de comprimir

El error más común aquí no es saltarse la compresión, es tirar de una herramienta que sube tus imágenes al servidor de otro para hacer el trabajo. Es más lento, y deja una copia de tu contenido —posiblemente todavía sin publicar— en algún sitio fuera de tu control mientras se procesa.

img-compress se encarga de los pasos 2 y 3 de la lista de arriba: comprimir y convertir entre JPG, PNG, WebP y AVIF, por completo en tu propio dispositivo, incluidas las fotos HEIC de un iPhone, y una sola imagen de cabecera termina igual de fácil que un lote entero de fotos de producto antes de un lanzamiento.

El paso 1, redimensionar, no lo hace a propósito: recodifica sin cambiar dimensiones, porque las dimensiones correctas dependen de dónde vaya la imagen. Eso corresponde a tu editor de imágenes o a tu CMS. Y los atributos de entrega de arriba corresponden a tus plantillas — ningún compresor puede ponértelos.

Peso de las imágenes y velocidad del sitio