Comprimir imágenes para tu web

Por qué importa más de lo que parece

En una página normal, las imágenes suelen ser la mayor parte de los bytes que se descargan. Y no es solo cuestión de comodidad: Google mide la velocidad de carga como señal de posicionamiento a través de las llamadas Core Web Vitals, y la métrica principal de esas tres depende directamente de las imágenes.

Esa métrica es el LCP (Largest Contentful Paint): el tiempo que tarda en aparecer el elemento visible más grande de la pantalla. En la mayoría de las páginas ese elemento es una imagen — la foto de cabecera, la imagen destacada del artículo, la del producto. Si esa imagen pesa dos megas, tu LCP es malo por definición, y no hay optimización de código que lo compense.

El umbral que Google considera bueno es 2,5 segundos en el percentil 75 de visitas reales. Con conexiones móviles medias, eso deja muy poco margen para una imagen de varios megabytes.

Cuánto debe pesar cada imagen

Referencias que funcionan bien en la práctica:

Y un presupuesto global que ayuda a decidir: intenta que el total de una página no pase de 1 MB de imágenes. Si tienes veinte fotos en una página, eso son 50 KB cada una, y entonces lo que necesitas no es comprimir más sino cargarlas más tarde.

El error que anula toda la compresión

Es, con diferencia, el problema más frecuente: servir una imagen mucho más grande de lo que se va a ver. Subir una foto de 4000 píxeles de ancho y dejar que el navegador la muestre en un hueco de 600. El navegador descarga los cuatro mil píxeles, gasta los bytes y la memoria, y luego la reduce para pintarla.

Ese es también el motivo por el que la compresión sola no arregla una web lenta: puedes dejar la foto en 300 KB, pero sigue teniendo diez veces más píxeles de los necesarios. Lo correcto es reducir las medidas primero al tamaño real en que se muestra —con margen para pantallas de alta densidad, del orden del doble— y comprimir después.

Lo que hay que hacer además de comprimir

Declara las medidas en el HTML

Poner width y height en la etiqueta permite al navegador reservar el hueco antes de que la imagen llegue. Sin eso, el texto salta cuando la foto aparece, y eso empeora otra de las Core Web Vitals, la de estabilidad visual:

<img src="foto.jpg" width="1200" height="800" alt="Descripción">

Carga diferida, pero no en la primera imagen

loading="lazy" retrasa la descarga de las imágenes que están fuera de la pantalla. Es una de las mejoras más grandes por menos esfuerzo. Con una excepción importante: no lo pongas en la imagen de cabecera. Esa es justamente la que mide el LCP, y diferirla la empeora.

<!-- Cabecera: se carga cuanto antes -->
<img src="cabecera.jpg" width="1600" height="900" fetchpriority="high" alt="...">

<!-- Más abajo: se carga cuando haga falta -->
<img src="detalle.jpg" width="1200" height="800" loading="lazy" alt="...">

Varios tamaños con srcset

Un móvil no necesita la misma imagen que un monitor grande. Con srcset ofreces varias versiones y el navegador elige la que le conviene:

<img src="foto-800.jpg" alt="..."
     srcset="foto-400.jpg 400w, foto-800.jpg 800w, foto-1600.jpg 1600w"
     sizes="(max-width: 700px) 100vw, 800px"
     width="800" height="533">

Es más trabajo, pero en una web con muchas imágenes ahorra más que cualquier ajuste de compresión.

Formatos modernos

WebP suele pesar entre un 25 % y un 35 % menos que un JPEG equivalente, y AVIF baja aún más. Los admiten todos los navegadores actuales. Para una web propia son la opción sensata; esta herramienta entrega JPG y PNG porque están pensados para subir a formularios y enviar a terceros, donde WebP todavía se rechaza a menudo.

Cómo medir si has mejorado

1. Abre las herramientas de desarrollo del navegador, pestaña de red, y recarga. Verás el peso de cada archivo y el total. Ordena por tamaño: las primeras filas te dicen dónde está el problema.
2. Usa PageSpeed Insights de Google: te da el LCP y te señala las imágenes concretas que sobran, con cuántos kilobytes ahorrarías en cada una.
3. Mira los datos de campo si los tienes: lo que Google usa para posicionar son las visitas reales de tus usuarios, no la prueba de laboratorio.

Orden de prioridades si tienes poco tiempo: primero las medidas de la imagen de cabecera, luego carga diferida en el resto, luego compresión, y por último formatos modernos. El primer punto suele valer más que los otros tres juntos.

El caché, que es gratis

Una imagen bien configurada se descarga una vez y se queda guardada en el navegador de quien te visita. Si tu servidor no manda las cabeceras de caché adecuadas, cada visita vuelve a descargar todo. Es un ajuste de servidor de cinco minutos que no tiene nada que ver con la compresión y que a menudo importa más.

Por el mismo motivo, cuidado con incrustar imágenes como Base64 dentro del HTML o del CSS: al ir dentro del código se descargan en cada página y no se pueden cachear por separado.