Reduce el peso de una imagen eligiendo las dimensiones adecuadas, el formato correcto y un nivel de calidad controlado, sin una degradación visible innecesaria.
Publicado el 31 de agosto de 2026Lectura : 26 minPor Equipo Bethemesh
Comprimir una imagen «sin perder calidad» parece contradictorio. Si no debe desaparecer ninguna información, hablamos de compresión sin pérdida. Si el objetivo consiste más bien en reducir considerablemente el peso sin que la diferencia sea perceptible en el contexto de visualización, una compresión con pérdida bien ajustada puede ser mucho más eficaz.
En la Web, esta segunda definición suele ser la más útil.
Una fotografía destinada a mostrarse con 1.200 píxeles de ancho normalmente no necesita conservar exactamente todos los datos de un original de varios miles de píxeles. Por el contrario, una captura de pantalla que contiene caracteres pequeños o una ilustración con contornos nítidos puede soportar muy mal determinados tipos de compresión.
Por tanto, la pregunta adecuada no es:
«¿Qué porcentaje de compresión debo utilizar?»
sino:
«¿Cuál es la representación más pequeña que conserva todo lo que el usuario necesita realmente?»
Compresión y redimensionamiento: ¿cuál es la diferencia?
Una imagen de:
4000 × 3000 px
contiene 12 millones de píxeles.
Si la reduces a:
1200 × 900 px
solo contiene 1,08 millones.
Por tanto, has eliminado más del 90 % de los píxeles antes incluso de hablar de códec o de control de calidad.
El redimensionamiento actúa sobre la cantidad de información espacial que hay que representar.
La compresión intenta después codificar esa información de forma más eficiente.
Por eso, reducir unas dimensiones innecesariamente elevadas suele aportar una mejora mayor y más previsible que forzar un ajuste de compresión hasta que aparezcan defectos.
Una imagen raster es una cuadrícula de píxeles. Cada píxel puede contener varios componentes: rojo, verde, azul y, eventualmente, alfa.
Una imagen RGB de 4.000 × 3.000 píxeles a 8 bits por canal representa, en una aproximación simple sin comprimir:
4 000 × 3 000 × 3 bytes= 36 000 000 bytes
es decir, unos 36 MB en conteo decimal, antes de considerar otra información o estructuras.
Sin embargo, un JPEG de esa fotografía puede pesar solo unos pocos megabytes, o incluso mucho menos.
¿Por qué?
Porque los datos de una imagen no son todos independientes ni tienen todos la misma importancia para su reproducción perceptiva.
Esta distinción entre información bruta, redundancia y representación eficiente enlaza directamente con los conceptos presentados en Claude Shannon y la teoría de la información. La compresión de imágenes es una aplicación especialmente concreta: representar un mensaje con menos datos, ya sea sin perder la información necesaria para reconstruirlo o aceptando determinadas aproximaciones controladas.
¿Qué es la compresión sin pérdida?
La compresión sin pérdida permite reconstruir exactamente los datos codificados.
La idea no consiste en eliminar píxeles considerados poco importantes, sino en representar de forma más eficiente estructuras repetitivas o previsibles.
Imagina una línea que contiene cien píxeles blancos idénticos. Una representación ingenua podría repetir cien veces la misma información. Un método de compresión puede aprovechar esa repetición.
Los algoritmos reales son, evidentemente, más sofisticados, pero el principio general es el mismo: aprovechar la redundancia.
PNG es el formato sin pérdida más conocido en los usos Web. WebP también dispone de un modo sin pérdida y otros formatos pueden ofrecer sus propios mecanismos.
¿Sin pérdida significa que no se modifica absolutamente nada?
Hay que distinguir dos etapas.
Un archivo PNG puede comprimir sin pérdida la imagen que recibe. Pero si previamente has:
reducido sus dimensiones;
cuantificado sus colores;
eliminado su canal alfa;
transformado su perfil;
eliminado metadatos;
el flujo de trabajo completo ya ha modificado el archivo.
Decir «PNG es sin pérdida» no significa:
«todo lo que había en el archivo fuente se conservará necesariamente».
Significa que el mecanismo de codificación de los píxeles correspondiente al modo utilizado no introduce las pérdidas típicas de un códec fotográfico con pérdida.
Este matiz es esencial al comparar herramientas de optimización.
¿Qué es la compresión con pérdida?
La compresión con pérdida acepta no reconstruir exactamente los datos originales.
Intenta eliminar o aproximar cierta información para obtener un archivo mucho más pequeño.
JPEG es el ejemplo histórico más conocido en la Web. WebP y AVIF también ofrecen modos con pérdida.
El principio resulta especialmente eficaz para las fotografías, porque una imagen natural contiene una enorme cantidad de variaciones y detalles.
Un códec puede aprovechar:
las similitudes entre zonas;
las propiedades de la percepción visual;
una menor sensibilidad a determinadas variaciones;
representaciones frecuenciales o predictivas según el códec.
El resultado deja de ser idéntico píxel por píxel, pero puede seguir siendo visualmente muy parecido.
¿Por qué se puede eliminar información sin percibir inmediatamente la diferencia?
El ojo humano no concede la misma importancia a todas las variaciones de una imagen.
Por ejemplo, somos más sensibles a determinados contornos y estructuras que a ciertas variaciones cromáticas finas.
Los códecs con pérdida aprovechan estas propiedades para dedicar más datos a la información perceptualmente importante y menos a los detalles que pueden aproximarse.
Esto no significa que las pérdidas sean «invisibles por definición».
Cuando la compresión se vuelve demasiado fuerte, aparecen las aproximaciones:
bloques;
halos;
contornos artificiales;
manchas;
pérdida de textura;
superficies irregulares;
bandas en los degradados.
El trabajo consiste precisamente en mantenerse antes de ese punto de degradación molesta.
Paso 1: conservar siempre un original
La primera regla es independiente del formato:
no conviertas tu archivo comprimido en tu única fuente.
Conserva un original o un archivo maestro con calidad suficiente.
Puede ser:
el archivo de la cámara;
una exportación de alta calidad;
un PNG maestro;
un archivo procedente del software de creación;
un original vectorial.
Los archivos Web deben considerarse derivados reproducibles.
Así podrás, dentro de seis meses:
generar una nueva anchura;
adoptar un nuevo códec;
modificar la calidad;
crear un recorte;
cambiar tu estrategia responsive.
Sin una fuente maestra, tendrás que partir de una versión ya degradada.
¿Qué es la pérdida generacional?
Supongamos este flujo de trabajo:
original→ JPEG con calidad reducida→ reapertura→ nueva exportación JPEG→ nueva exportación WebP
Cada codificación con pérdida trabaja sobre una imagen que ya contiene las aproximaciones de la etapa anterior.
Sin embargo, hay que tener en cuenta las pantallas de alta densidad: una imagen mostrada a 600 CSS px puede beneficiarse de un recurso más ancho en determinados dispositivos.
La respuesta no consiste en enviar 4.000 px a todo el mundo. Hay que producir varias variantes y permitir que el navegador seleccione la más apropiada. La futura guía Imágenes responsivas: comprender srcset y sizes explicará precisamente esta etapa.
¿Redimensionar hace perder calidad?
Cuando reduces una imagen, efectivamente eliminas información.
Pero si esos píxeles no son necesarios para el uso final, esa pérdida es deseable.
Una miniatura de 300 px no necesita contener los detalles de una fuente de 5.000 px.
Por tanto, la pregunta siempre depende del contexto.
En cambio, ampliar posteriormente esa miniatura a 2.000 px no recreará los detalles eliminados.
La resolución apropiada es la que conserva información suficiente para el tamaño de visualización y los usos previstos.
¿Redimensionamiento o recorte?
Son dos operaciones diferentes.
Redimensionamiento
Se conserva toda la imagen, pero cambian sus dimensiones.
Recorte
Se elimina una parte del encuadre.
En ocasiones, un recorte puede reducir aún más los datos y mejorar al mismo tiempo la composición.
Imagina una fotografía en la que el sujeto ocupa únicamente el centro de un encuadre muy grande. Un recorte pertinente evita codificar zonas que no aportan nada al contenido.
Pero evidentemente modifica el encuadre y, por tanto, debe seguir siendo una decisión editorial.
Paso 3: elegir el formato antes del nivel de calidad
El formato influye enormemente en el resultado.
Una fotografía guardada como PNG puede seguir siendo muy pesada incluso después de una optimización intensa, porque PNG intenta conservar exactamente los píxeles codificados.
La misma fotografía en JPEG, WebP o AVIF con pérdida puede resultar mucho más ligera.
Por el contrario, una captura de pantalla con caracteres pequeños puede degradarse con un JPEG demasiado comprimido, mientras que un PNG o un WebP sin pérdida seguirá siendo muy limpio.
Por tanto, la elección del códec se realiza antes de buscar el control deslizante ideal.
Compara varias salidas procedentes del mismo original y con las mismas dimensiones.
No compares:
JPEG 4000 px
con:
WebP 1200 px
y concluyas que el formato explica toda la mejora.
Para aislar el efecto del códec, las dimensiones deben ser idénticas.
¿Qué formato utilizar para una captura de pantalla?
Las capturas de pantalla suelen contener:
texto;
líneas finas;
colores planos;
iconos;
zonas repetitivas.
Empieza normalmente por PNG o WebP.
Inspecciona especialmente los caracteres y los bordes.
Una compresión con pérdida demasiado agresiva puede crear halos alrededor del texto, lo que perjudica considerablemente la legibilidad a cambio de una reducción que a veces es mediocre.
Si la captura se utiliza como documentación, la precisión puede ser más importante que ahorrar unos pocos kilobytes.
¿Qué formato utilizar para un logotipo o un icono?
Antes de comprimir un logotipo raster, pregúntate si debería estar en SVG.
Un gráfico geométrico puede describirse mediante formas en lugar de miles de píxeles.
Pero un porcentaje elevado no supone automáticamente un éxito.
Pasar de:
500 KB → 80 KB
con una fotografía visiblemente degradada puede ser menos interesante que:
500 KB → 140 KB
con un resultado prácticamente indistinguible.
El objetivo adecuado es el menor peso aceptable, no el menor peso posible.
¿Por qué pueden importar unos pocos kilobytes?
En una sola imagen, ahorrar 20 KB puede parecer insignificante.
En una página con 30 miniaturas:
20 KB × 30 = 600 KB
En varias páginas consultadas desde una red móvil, el impacto se vuelve real.
Por tanto, hay que razonar a dos escalas:
la imagen individual;
el presupuesto global de la página.
Por el contrario, dedicar una hora a ahorrar 2 KB en una imagen que se carga raramente probablemente no sea rentable.
Optimizar también es priorizar.
¿El peso en disco es el peso transferido?
No siempre exactamente.
La red puede verse afectada por:
caché;
CDN;
cabeceras;
reutilización de recursos;
protocolo;
comportamiento del navegador.
Para una imagen ya comprimida como JPEG, WebP o AVIF, una compresión HTTP adicional suele aportar poco frente al trabajo realizado por el propio códec de imagen.
Por tanto, mide los recursos en las herramientas de red del navegador cuando evalúes el rendimiento real.
Compresión e imágenes responsivas
Una única imagen muy comprimida no constituye necesariamente una buena estrategia.
Supongamos que creas:
hero-2000.webp
y la comprimes perfectamente.
Un teléfono que solo necesita 600 u 800 px seguirá descargando el recurso grande si no se ofrecen variantes.
No conviertas un SVG a WebP únicamente para poder utilizar un compresor raster: perderías una de sus principales ventajas, su independencia respecto de una resolución fija.
¿Por qué PNG puede volverse más pesado después de «comprimirlo»?
Hay varias razones posibles:
la herramienta vuelve a codificarlo con una estrategia diferente;
el archivo fuente ya estaba muy optimizado;
se han añadido metadatos;
la paleta ha cambiado;
la herramienta no utiliza un codificador especializado.
Una operación llamada «comprimir» no garantiza matemáticamente que el resultado vaya a ser más pequeño.
El pipeline debe comparar:
tamaño antestamaño después
y conservar la versión anterior si la nueva no aporta nada.
¿Por qué un WebP puede ser más pesado que un JPEG?
Se aplica el mismo principio.
Un JPEG muy optimizado puede superar a un WebP mal ajustado.
El peso depende de:
el códec;
el codificador;
el ajuste;
la imagen;
los metadatos;
las dimensiones.
El nombre de la extensión nunca basta para predecir el resultado.
Por eso la elección del formato debe seguir siendo experimental cuando el rendimiento importa realmente.
¿Por qué AVIF no es una solución mágica?
AVIF puede ofrecer resultados excelentes, pero:
su codificación puede ser más costosa;
algunas imágenes responden mejor que otras;
las mejoras pueden ser pequeñas en archivos reducidos;
una mala configuración puede degradar el resultado.
Para una biblioteca grande, el tiempo de build también puede convertirse en un parámetro operativo.
El mejor pipeline no es el que produce teóricamente el archivo más pequeño a cualquier coste. Es el que equilibra:
peso;
calidad;
tiempo de generación;
compatibilidad;
mantenimiento.
¿Se puede automatizar la compresión?
Sí, y es incluso recomendable cuando el sitio contiene muchas imágenes.
Un pipeline puede:
tomar la fuente maestra;
determinar varias dimensiones;
generar los formatos elegidos;
aplicar ajustes de calidad;
eliminar determinados metadatos según la política;
producir un informe de peso.
Pero la automatización debe incluir mecanismos de protección.
Por ejemplo:
no sustituir un archivo por una salida más pesada;
conservar la fuente;
señalar imágenes anormalmente voluminosas;
permitir excepciones para imágenes sensibles.
¿Hay que fijar un peso máximo por imagen?
Un umbral puede ser útil como alerta, pero un límite universal rara vez es pertinente.
Una imagen hero a todo lo ancho y un icono no tienen el mismo presupuesto.
El lazy loading retrasa la carga de determinados recursos que no son necesarios inmediatamente.
Ambas técnicas pueden combinarse.
Una imagen situada muy por debajo de la parte visible de la página puede estar:
correctamente comprimida;
correctamente dimensionada;
cargada más tarde.
Por el contrario, una imagen hero importante no debe retrasarse ciegamente con el pretexto de que el lazy loading es una «optimización».
Cada técnica responde a una pregunta diferente.
Caché y compresión
Una imagen correctamente almacenada en caché no vuelve a descargarse en cada navegación.
Esto reduce enormemente su coste en visitas posteriores.
Pero la caché no justifica servir un archivo innecesariamente pesado durante la primera visita.
Compresión y caché son complementarias:
compresión → menos datos por transferencia;
caché → menos transferencias repetidas.
El flujo completo de optimización Web debe tener en cuenta ambas.
CDN y transformación al vuelo
Algunos CDN de imágenes pueden:
redimensionar;
convertir;
ajustar la calidad;
seleccionar un formato;
almacenar variantes en caché.
Esta arquitectura puede ser muy eficaz para un sitio dinámico.
Pero desplaza parte de la complejidad hacia el servicio de transformación.
Entonces hay que vigilar:
costes;
caché;
URLs;
calidad;
dependencia del proveedor;
comportamiento en caso de fallo.
Para un sitio estático, generar las variantes durante el build puede ser más sencillo.
Compresión local y privacidad
Cuando la imagen se procesa localmente en el navegador, el archivo puede permanecer en el dispositivo del usuario, según la implementación de la herramienta.
Esto puede resultar interesante para archivos privados.
Pero hay que distinguir:
la promesa general de un servicio;
el funcionamiento concreto de cada herramienta.
El procesamiento local tampoco impide que un archivo exportado conserve eventualmente metadatos sensibles.
No compares dos archivos procedentes de generaciones diferentes.
Mismas dimensiones
De lo contrario, estarás midiendo a la vez el redimensionamiento y el códec.
Mismo contexto
Muestra las versiones al mismo tamaño.
Varias zonas
Inspecciona las partes fáciles y difíciles.
Peso real
Anota el tamaño exacto de los archivos.
Decisión
Elige la versión que ofrezca el mejor equilibrio para el uso previsto.
Este método es más fiable que un juicio basado en la extensión o en el control deslizante.
Ejemplo: fotografía hero
Fuente:
4000 × 2667 px3,8 MB
Supongamos que se muestra como máximo alrededor de 1.400 px.
Primera etapa:
1400 × 933 px
Después generas varias pruebas:
JPEG alta calidadWebP alta calidadWebP calidad intermediaAVIF alta calidadAVIF calidad intermedia
A continuación comparas:
peso;
rostro;
cabello;
fondo;
degradados.
No eliges el archivo más pequeño, sino el primero en el que una reducción adicional empieza a resultar visualmente costosa.
Después podrás generar varias anchuras para el responsive.
Ejemplo: captura de pantalla de documentación
Fuente:
1800 × 1000 px
La captura contiene código y texto pequeño.
Aquí, una compresión fotográfica agresiva resulta arriesgada.
Prueba:
PNG optimizado;
WebP sin pérdida;
WebP con pérdida a alta calidad.
Amplía los caracteres.
Si el WebP con pérdida ahorra un 20 % pero añade halos que hacen que el código resulte menos cómodo de leer, conserva la versión sin pérdida.
La calidad funcional tiene prioridad sobre la tasa de reducción.
Ejemplo: miniatura de tarjeta
Una miniatura se muestra aproximadamente a:
320 × 180 px
La fuente mide 2.400 px.
La principal mejora procede del redimensionamiento.
Una vez creada la variante, puedes aceptar una compresión más fuerte que para la imagen hero, porque los microdetalles no son necesarios.
Pero no sirvas esta miniatura cuando el usuario abra después una vista ampliada: utiliza un recurso adecuado para cada contexto.
Ejemplo: logotipo transparente
Si dispones del SVG original, mantenlo en formato vectorial.
Si solo tienes un PNG:
evita JPEG debido a la transparencia;
prueba WebP sin pérdida;
compara el peso;
inspecciona los contornos sobre varios fondos.
Si la mejora es de solo unos cientos de bytes, la simplicidad puede justificar conservar PNG.
No es necesario aplicar todas las optimizaciones.
¿Puede una compresión aumentar el peso?
Sí.
Si la imagen fuente ya está muy optimizada, un nuevo codificador puede producir un archivo más pesado.
Esto ocurre especialmente cuando:
el ajuste es demasiado alto;
el códec no es adecuado;
se añaden metadatos;
el codificador es menos eficaz para ese contenido.
Por tanto, un pipeline serio debe aplicar una regla sencilla:
no sustituyas automáticamente un archivo por una versión más pesada sin una razón funcional.
¿Cuándo hay que dejar de optimizar?
Detente cuando la mejora marginal ya no justifique:
la pérdida visual;
el tiempo de trabajo;
la complejidad;
el coste del build;
el riesgo de regresión.
Pasar de 1,5 MB a 250 KB merece claramente atención.
Pasar de 42 KB a 39 KB puede no justificar una nueva variante y una regla adicional.
La optimización Web busca rendimiento, no ganar una competición de compresión.
Lista de comprobación antes de publicar
Antes de publicar una imagen:
¿he conservado una fuente maestra?
¿las dimensiones corresponden al uso?
¿necesito varias anchuras?
¿el formato corresponde al contenido?
¿se conserva la transparencia si es necesaria?
¿he comparado varios ajustes?
¿los detalles importantes siguen siendo legibles?
¿he inspeccionado la imagen a su tamaño real?
¿el archivo final es realmente más ligero?
¿se conservan los metadatos necesarios?
¿se han revisado los metadatos sensibles?
¿las dimensiones están declaradas en la página?
¿la estrategia de carga corresponde a la posición de la imagen?
Si varias respuestas son «no», probablemente la prioridad no sea forzar aún más el control de calidad.
Los errores más frecuentes
Comprimir antes de redimensionar
Estás optimizando píxeles que nunca se utilizarán.
Sobrescribir el original
Pierdes la posibilidad de regenerar correctamente los derivados.
Recodificar un JPEG ya degradado
Las pérdidas se acumulan.
Utilizar calidad 100 por principio
El archivo puede crecer enormemente a cambio de una mejora imperceptible.
Utilizar un único valor como verdad universal
Cada imagen reacciona de manera diferente.
Elegir PNG para una fotografía únicamente porque no tiene pérdida
Puedes obtener un archivo desproporcionado a cambio de una ventaja inútil en pantalla.
Convertir un logotipo SVG a raster
Pierdes la ventaja del formato vectorial.
Evaluar únicamente al 25 %
Los artefactos finos pasan desapercibidos.
Evaluar únicamente al 400 %
Puedes rechazar una compresión cuyas diferencias serían totalmente invisibles durante el uso real.
Eliminar todos los metadatos a ciegas
Algunos pueden ser necesarios.
Olvidar las variantes responsivas
Un archivo muy bien comprimido puede seguir siendo demasiado grande para una pantalla pequeña.
Lo que hay que recordar
Comprimir una imagen sin pérdida visible no consiste en elegir un valor en un control deslizante. Es un método.
Empieza antes de la compresión:
conservar un original;
elegir las dimensiones adecuadas;
seleccionar el formato apropiado.
Continúa con:
un ajuste progresivo;
una comparación visual;
una medición del peso.
Y termina en el contexto real:
variante responsive;
carga;
caché;
rendimiento de la página.
La distinción fundamental sigue siendo:
sin pérdida significa que los datos codificados pueden reconstruirse exactamente;
con pérdida controlada significa que se elimina determinada información para obtener una mejora mayor, manteniendo al mismo tiempo una calidad suficiente para el uso.
¿Se puede realmente comprimir una imagen sin ninguna pérdida?
Sí, con compresión sin pérdida. Pero para una fotografía Web, una compresión con pérdida visualmente imperceptible suele producir un archivo mucho más pequeño.
¿Qué calidad elegir para JPEG?
No existe un valor universal. Empieza con una calidad relativamente alta, redúcela progresivamente y compara el resultado con el peso.
¿Qué calidad elegir para WebP?
El mismo principio. El valor numérico no es directamente comparable con el de un codificador JPEG. Evalúa el archivo producido.
¿Calidad 80 significa que se conserva el 80 % de la imagen?
No. El número es un parámetro del codificador, no un porcentaje universal de información o fidelidad.
¿Se puede comprimir PNG?
Sí. PNG utiliza compresión sin pérdida y distintos codificadores o transformaciones pueden reducir su peso. Pero un control de «calidad» no tiene el mismo significado que para JPEG.
¿Por qué un PNG es enorme después de convertir un JPEG?
Porque un PNG debe representar sin pérdida los píxeles ya decodificados del JPEG. No recupera los detalles perdidos y puede necesitar muchos más datos.
¿Por qué mi archivo comprimido es más pesado?
La fuente puede estar ya optimizada, el formato puede no ser apropiado o los ajustes pueden producir más datos. Compara siempre antes de sustituir el archivo.
¿Hay que redimensionar antes de comprimir?
Generalmente sí. Eliminar los píxeles innecesarios suele ser la primera mejora importante.
¿Reducir las dimensiones destruye la calidad?
Elimina información, pero esa información puede ser inútil si la imagen nunca se muestra a su tamaño original.
¿Se puede comprimir varias veces el mismo JPEG?
Es posible, pero no recomendable. Cada recodificación con pérdida puede añadir degradaciones. Vuelve a partir del original.
¿Cómo saber si la compresión es visible?
Inspecciona las zonas sensibles al 100 % y después observa el archivo a su tamaño real de visualización. Compara contornos, texturas, degradados y texto.
¿AVIF comprime siempre mejor que WebP?
No. Puede ser excelente con determinadas imágenes, pero el resultado depende del contenido y de los ajustes.
¿Debo eliminar los metadatos para reducir el peso?
No automáticamente. Algunos son inútiles o sensibles; otros pueden ser importantes. Inspecciónalos primero con el lector de metadatos.
¿Basta la compresión para optimizar las imágenes de un sitio?
Utiliza el redimensionador para las dimensiones, el conversor para el formato y el compresor para experimentar con el peso y la calidad.
¿Qué relación tiene esto con la teoría de la información?
La compresión intenta representar los datos de forma más eficiente aprovechando su estructura y redundancia. Para conocer el contexto histórico y conceptual, consulta Claude Shannon y la teoría de la información.
Entiende srcset, sizes, los descriptores de anchura y densidad, picture, la dirección artística y cómo el navegador elige la imagen responsive adecuada.
Elige el formato de imagen adecuado para una foto, una captura, un recurso transparente o una interfaz, sin sacrificar innecesariamente la calidad ni el rendimiento.
