Cómo comprimir imágenes para una web sin arruinar la calidad

La respuesta práctica

Para comprimir imágenes de web sin arruinar la calidad, no empieces arrastrando el control de calidad al valor más bajo que resulte tolerable. Empieza por el trabajo real que hace la imagen en la página. Un hero, la foto de zoom de un producto, una ilustración de blog, un avatar, una captura de pantalla y una textura de fondo necesitan dimensiones, formatos y niveles de calidad distintos.

La regla útil es: redimensiona primero al mayor tamaño en el que se muestra, y luego comprime lo justo para que siga viéndose igual en el diseño. Si una imagen de blog se muestra a 760 píxeles CSS de ancho, una fuente de 1500–1600 px suele ser suficiente para pantallas de alta densidad. Un original de cámara de 5000 px son datos desperdiciados. Una exportación de 760 px puede verse blanda en pantallas retina. El archivo adecuado está entre ambos extremos.

«Sin perder calidad» también necesita una definición clara. Para trabajo web suele significar sin pérdida visible al tamaño que los visitantes ven en realidad, no perfección matemática píxel a píxel. Un WebP comprimido no es idéntico al archivo original, pero puede ser visualmente indistinguible en la página.

Decide qué tipo de imagen web es

Antes de elegir WebP, AVIF, JPEG, PNG o un valor de calidad, clasifica el asset:

Esta tabla es deliberadamente opinable. La mayor parte de la mala compresión web viene de tratar todos los assets igual. Un hero de portada puede afectar al Largest Contentful Paint. Una imagen de detalle de producto puede afectar a la confianza y a la conversión. Un fondo decorativo puede ser mucho más ligero porque nadie lo mira con detenimiento.

Redimensiona primero: las dimensiones hacen la mayor parte del trabajo

La compresión reduce los bytes con los que se almacena una rejilla de píxeles fija. Redimensionar cambia la propia rejilla. Si el original tiene muchos más píxeles de los que la página puede mostrar, redimensionar es la victoria más limpia.

Fórmula sencilla de dimensionado:

ancho de fuente objetivo = mayor ancho CSS de visualización × device pixel ratio

Por ejemplo:

• Una imagen de tarjeta mostrada a 320 CSS px debería tener una fuente de 640 px para pantallas 2x.
• Una imagen de blog a 760 CSS px debería tener una fuente de 1500–1600 px.
• Un hero a ancho completo cercano a 1200 CSS px puede necesitar una fuente de 2000–2400 px, según encuadre y dispositivos del público.

No uses 3x a ciegas para todo. web.dev señala que el DPR y el layout importan a la vez, y que en muchos casos los usuarios no perciben el beneficio de fuentes con DPR muy alto. Un hero a 2400 px puede ser razonable. Un hero a 5000 px «porque más píxeles es más seguro» normalmente solo quema ancho de banda.

PhotoTools separa estas dos tareas. Usa Resize cuando necesites píxeles exactos o un lado largo más pequeño. Después usa Compress para elegir JPEG, WebP o AVIF y afinar la calidad.

Elige el formato antes de tocar la calidad

El formato decide qué tipo de detalle se puede quitar limpiamente.

• Usa WebP para la mayoría de fotos web. Está muy soportado en navegadores modernos y suele ser más pequeño que JPEG con calidad visible similar. La documentación de WebP de Google reporta ahorros del 25–34 % frente a JPEG equivalentes.
• Usa AVIF cuando cada byte importa. AVIF puede superar a WebP en assets fotográficos grandes, pero es más lento de codificar y añade complejidad a la pipeline. Úsalo con fallbacks, no como único archivo.
• Usa JPEG como fallback de compatibilidad. Sigue siendo útil para correo, flujos de CMS antiguos, descargas y como fuente de fallback en <img>.
• Usa PNG o WebP sin pérdidas para capturas y texto. JPEG/WebP con pérdida puede desdibujar texto pequeño de UI y añadir ruido de color en bordes duros.
• Usa SVG para logos e iconos. Un logo rasterizado en WebP puede pesar menos que PNG, pero un SVG limpio suele ser más nítido y más ligero.

Si usas <picture>, pon primero el formato más eficiente y mantén un fallback compatible en el img anidado:

<picture>
  <source
    type="image/avif"
    srcset="/images/hero-1200.avif 1200w, /images/hero-2000.avif 2000w"
    sizes="100vw"
  />
  <source
    type="image/webp"
    srcset="/images/hero-1200.webp 1200w, /images/hero-2000.webp 2000w"
    sizes="100vw"
  />
  <img
    src="/images/hero-1200.jpg"
    width="1200"
    height="800"
    alt="Reforma de cocina terminada con armarios de nogal y luz natural"
  />
</picture>

El elemento img sigue importando. Es el que lleva la fuente de fallback, alt, width y height. No escondas información de accesibilidad ni de layout dentro de elementos source.

Ajustes de calidad útiles en la práctica

Los números de calidad no están estandarizados. La calidad 80 en un encoder de JPEG no coincide necesariamente con la calidad 80 de otro. WebP 80, JPEG 80 y AVIF 50 tampoco son equivalentes. Trata la calidad como un punto de partida, y luego inspecciona el archivo exportado.

Una trampa habitual es exportarlo todo a calidad 95 o 100 porque parece más seguro. En la mayoría de fotos web, los bytes de más se ven en el waterfall de red, no en la página. Otra trampa es forzar la calidad por debajo de 50 para cumplir un objetivo arbitrario. Si la calidad tiene que caer tanto, mejor redimensionar la imagen o cambiar de formato antes de seguir degradándola.

Tamaños de archivo objetivo por rol de página

No son reglas de Google ni umbrales mágicos de ranking. Son objetivos prácticos de revisión que ayudan a detectar imágenes obviamente demasiado pesadas.

Si una imagen de blog de 760 px pesa 900 KB, probablemente necesita atención. Si una imagen de portfolio a ancho completo pesa 410 KB y se ve estupenda, reducirla a 90 KB puede ser el objetivo equivocado.

Comprimir imágenes hero y LCP

La imagen que más vale la pena optimizar suele ser la imagen más grande por encima del pliegue. En el lenguaje de los Core Web Vitals suele ser el Largest Contentful Paint. Comprimirla ayuda, pero solo si también se descubre y se carga pronto.

Para una imagen hero:

1. Recórtala a la relación de aspecto real que se usa en la página.
2. Exporta anchos responsive, por ejemplo 1200 px y 2000 px.
3. Usa AVIF primero y WebP/JPEG como fallback si tu stack lo soporta.
4. No apliques lazy-load al hero ni a otro candidato LCP por encima del pliegue.
5. Añade width y height para que el navegador reserve espacio de layout.
6. Usa fetchpriority="high" solo en la única imagen con más probabilidad de ser el elemento LCP.

Ejemplo de img fallback:

<img
  src="/images/hero-1200.jpg"
  srcset="/images/hero-1200.jpg 1200w, /images/hero-2000.jpg 2000w"
  sizes="100vw"
  width="1200"
  height="800"
  fetchpriority="high"
  alt="Reforma de cocina terminada con armarios de nogal y luz natural"
/>

No pongas fetchpriority="high" a toda una galería. Los hints de prioridad son herramientas afiladas: úsalos en la imagen que realmente tiene que llegar la primera.

Cómo comparar resultados de compresión

La comparación adecuada no es «archivo original vs. archivo comprimido al 100 %». Así es como uno se convence de publicar imágenes desmesuradas. Compara al tamaño y en el contexto que ven los visitantes.

Usa este pase de revisión:

1. Coloca la imagen comprimida en la página real o en un layout de prueba con el mismo ancho.
2. Míralo a anchos de escritorio y móvil.
3. Revisa las zonas de riesgo: caras, piel, cielo, degradados, tejido, etiquetas de producto, texto pequeño y bordes de alto contraste.
4. Alterna entre la versión original y la comprimida al tamaño renderizado.
5. Haz un breve zoom al 100 % solo para pillar artefactos evidentes, no para exigir una perfección que nadie va a ver.

Los artefactos de compresión tienen personalidad. JPEG suele mostrar bordes en bloque, ringing o ruido de color. Un WebP demasiado comprimido puede emborronar texturas. AVIF puede producir banding o un aspecto plastificado si se le exige demasiado. Las capturas PNG suelen fallar en la dirección opuesta: se ven perfectas pero pesan mucho más de lo necesario.

Un flujo con PhotoTools para imágenes de web

PhotoTools es útil antes de que la imagen llegue a tu CMS, CDN o repositorio. No sustituye a una pipeline de build completa, pero da un flujo manual limpio para webs pequeñas, entradas de blog, previews de cliente y assets puntuales.

1. Deja el archivo original intacto.
2. Decide el rol de la imagen: hero, imagen de contenido, foto de producto, captura, miniatura o fondo.
3. Usa Resize primero cuando el original es mucho mayor que el tamaño de visualización.
4. Abre Compress, elige JPEG, WebP o AVIF y empieza cerca de calidad 80 para WebP/JPEG.
5. Pulsa «Compress all» y lee en cada tarjeta el tamaño original, el tamaño de salida y el porcentaje ahorrado.
6. Descarga el resultado e inspecciónalo en el contexto de la página.
7. Si visualmente falla, vuelve al original o a la copia redimensionada y exporta de nuevo con más calidad.
8. Si sigue demasiado pesado, reduce dimensiones antes de bajar la calidad al terreno de los artefactos.

No recomprimas una y otra vez la descarga ya comprimida — eso acumula artefactos con pérdida. Vuelve al maestro o al intermedio redimensionado limpio.

Metadatos y privacidad

Los archivos de cámara suelen llevar metadatos EXIF: coordenadas GPS, fecha de captura, modelo de cámara, objetivo y software de edición. Esos metadatos no ayudan al visitante a ver la imagen. También pueden exponer información privada.

PhotoTools comprime las imágenes decodificando el archivo, pintando los píxeles en un canvas del navegador y exportando un archivo nuevo. MDN documenta que OffscreenCanvas.convertToBlob() puede especificar el tipo de imagen y la calidad para los formatos con compresión con pérdida. Como la salida se genera a partir de los píxeles del canvas, los metadatos de cámara habitualmente no se copian en el nuevo archivo.

Para fotos sensibles, verifica la descarga final con un lector de metadatos antes de publicarla. La privacidad no es solo tamaño de archivo.

Errores frecuentes que hacen que las imágenes se vean mal

• Comprimir antes de redimensionar: intentas quitar bytes de píxeles que el layout nunca va a mostrar.
• Usar PNG para fotos: PNG suele ser enorme con imágenes de cámara.
• Usar JPEG para capturas con texto: el archivo puede ser más pequeño, pero el texto se ve difuso.
• Juzgar al tamaño equivocado: el zoom a resolución completa hace parecer dramáticos artefactos inocuos.
• Exportar un único hero gigante para todos los dispositivos: los usuarios móviles descargan píxeles de escritorio que no pueden usar.
• Aplicar lazy-load al hero: las imágenes por debajo del pliegue pueden ir con lazy-load. La imagen LCP no.
• Sin width ni height: la página puede saltar mientras cargan las imágenes.
• Recomprimir el archivo ya publicado: empieza por la fuente siempre que puedas.

Un checklist compacto de publicación

Antes de subir una imagen de web, pasa por esta lista:

1. ¿Es el formato adecuado para el tipo de contenido?
2. ¿El ancho de la fuente se basa en el ancho real de visualización y en un DPR plausible?
3. ¿Hay un candidato móvil más pequeño si el encuadre del hero cambia en móvil?
4. ¿La calidad es suficiente para caras, etiquetas, degradados y detalle de producto?
5. ¿El tamaño de archivo es razonable para su rol?
6. ¿La página tiene width, height, un alt útil y srcset/sizes responsive cuando hace falta?
7. ¿La imagen LCP se carga en modo eager y con prioridad, mientras que las de abajo del pliegue van en lazy?
8. ¿Has revisado la imagen exportada dentro del layout real?
9. ¿Has conservado el archivo original?

El mejor flujo de compresión es aburrido en el buen sentido: elige los píxeles adecuados, elige el formato adecuado, exporta a una calidad sensata, revisa la página real y para antes de que la imagen empiece a parecer «tratada».

Fuentes técnicas revisadas

Este artículo se ha revisado frente a la implementación actual de compresión y redimensionado de PhotoTools, la guía de rendimiento de imágenes de web.dev, el insight «Improve image delivery» de Chrome, la guía «Properly size images» de Chrome, la documentación de MDN sobre OffscreenCanvas.convertToBlob(), la guía de tipos de archivo de imagen de MDN y la documentación de WebP de Google.