Benchmark de formatos de imagen: 3 resultados inesperados
Un desarrollador corrió 17 conversiones de imágenes en su servidor de producción con 50 archivos reales (26 PNG y 24 fotos HEIC del iPhone) y midió tamaño y tiempo de cada una. El resultado más incómodo: convertir HEIC a JPG no achica el archivo, lo agranda un 14%. La optimización de imágenes en el servidor depende más de medir que de seguir consejos repetidos.
El benchmark lo publicó Serhii Kalyna en dev.to en junio de 2026, usando una herramienta gratuita de conversión escrita en Rust sobre libvips. La idea era simple: dejar de adivinar qué formato comprime mejor y registrar cada tamaño de archivo y cada tiempo de codificación. Algunos números confirmaron lo de siempre. Otros lo contradijeron de lleno.
La optimización de imágenes en el servidor es el proceso de convertir y comprimir archivos gráficos del lado del backend (antes de servirlos al navegador) para reducir peso, ancho de banda y tiempo de carga. Implica elegir un formato de destino (WebP, AVIF, JPG), un nivel de calidad y un pipeline de codificación, midiendo el balance entre tamaño final y tiempo de procesamiento por imagen.
En 30 segundos
- HEIC a JPG agranda el archivo un 14%, porque HEIC usa el codec HEVC, que comprime el doble que JPEG.
- Para achicar fotos del iPhone: HEIC a WebP ahorra 43%, HEIC a AVIF ahorra 57%.
- AVIF tarda 7x más que WebP a cambio de apenas 10% de compresión extra (1,30s vs 0,19s por imagen).
- PNG a 600 DPI pesa menos que a 300 DPI al rasterizar PDFs: 1.660 KB contra 2.221 KB.
- La conclusión real: medir en tu propio pipeline gana siempre contra el consejo genérico de internet.
¿Por qué conviene medir antes de elegir un formato de imagen?
Si alguna vez serviste imágenes en un sitio con tráfico de verdad, sabés que el peso de los archivos se traduce en plata: más ancho de banda, peor Core Web Vitals, usuarios que se van antes de que cargue el hero. La tentación es agarrar el primer consejo que aparece en Google y aplicarlo a todo el pipeline. Tema relacionado: integrar benchmarks en tu CI/CD automático.
El problema es que esos consejos casi nunca vienen con números. “Convertí las fotos del iPhone a JPG” es probablemente la recomendación más repetida de internet. Y según este benchmark, está mal en el caso más común. Por eso medir en tu propio servidor, con tus propias imágenes, no es un lujo de perfeccionista. Es la única forma de no estar tirando bytes (y segundos) a la basura.
¿Cuál es el mejor formato para comprimir fotos del iPhone?
WebP o AVIF, nunca JPG. Acá están los números del benchmark sobre las 24 fotos HEIC:
- HEIC a JPG: +14% de tamaño. El archivo crece. Cada vez.
- HEIC a WebP: ahorra 43%.
- HEIC a AVIF: ahorra 57%.
Ponele que tenés una galería de producto con 2.000 fotos sacadas con iPhone y las pasás a JPG “para que sean compatibles”. Acabás de hacer tu sitio más pesado, no más liviano. El mito del JPG como formato universal liviano se cae apenas mirás el origen del archivo.
HEIC a JPG: por qué el archivo se agranda en vez de achicarse
La razón está en el codec. HEIC no es un formato de imagen cualquiera: envuelve al codec HEVC, el mismo que se usa en video y que comprime más o menos el doble de bien que JPEG. Cuando convertís de HEVC a JPEG estás pasando de un codec mejor a uno peor. El resultado es inevitable: para mantener la calidad, el archivo tiene que ocupar más espacio. Para más detalles, mirá cómo medir performance en tu propio servidor.
¿Tiene sentido entonces convertir a JPG alguna vez? Sí, cuando necesitás compatibilidad con un sistema viejo que no entiende WebP ni AVIF. Pero ahí estás pagando peso a cambio de compatibilidad, no optimizando. Son dos cosas distintas.
¿AVIF vale la pena o es compresión teórica?
Depende de la escala de tu pipeline. Acá está el dato que ordena la discusión:
- AVIF Q63: 55 KB por imagen, 1,30s de codificación.
- WebP Q80: 61 KB por imagen, 0,19s de codificación.
O sea: AVIF te da un 10% más de compresión a cambio de tardar 7 veces más. Para una sola imagen de portada, a nadie le importa esa diferencia. El tema es que cambia todo cuando lo multiplicás.
Hacé la cuenta sobre 1.000 fotos de producto. Con WebP el batch tarda unos 3 minutos. Con AVIF, alrededor de 21 minutos. Ese 10% extra de compresión que en el papel suena lindo, en un pipeline que procesa miles de imágenes te come horas de CPU y bloquea la cola. Subís el lote, lo dejás corriendo, te vas a almorzar, volvés y todavía está en la mitad porque elegiste el codec “óptimo” sin mirar el reloj.
¿Por qué un PNG a 600 DPI pesa menos que a 300 DPI?
Este fue el resultado más raro de todos. Al rasterizar PDFs a imagen, el autor notó que el PNG de salida bajaba de 2.221 KB a 300 DPI a 1.660 KB a 600 DPI. Más resolución, menos peso. Dice que pasó una hora convencido de que tenía un bug. Lo explicamos en detalle en nuestro artículo sobre servir imágenes optimizadas por región.
No era un bug. Es una propiedad real de cómo codifica PNG. A mayor DPI, los gradientes entre píxeles adyacentes se vuelven más suaves, y los filtros de predicción de PNG (Paeth, sub, up) trabajan mucho mejor con esos gradientes suaves. La aplicación práctica es concreta: si rasterizás PDFs escaneados, podés exportar a máxima resolución sin pagar penalidad de tamaño. Hasta te conviene.
Tabla comparativa: las conversiones que importan
| Origen → Destino | Cambio de tamaño | Tiempo / imagen | Cuándo usarlo |
|---|---|---|---|
| HEIC → JPG | +14% (peor) | rápido | Solo por compatibilidad vieja |
| HEIC → WebP | -43% | 0,19s | Default para fotos del iPhone |
| HEIC → AVIF | -57% | 1,30s | Batch chico, máxima compresión |
| WebP Q80 | 61 KB | 0,19s | Galerías y batch masivo |
| AVIF Q63 | 55 KB | 1,30s | Pocas imágenes críticas |
| PDF → PNG 600 DPI | 1.660 KB | variable | PDFs escaneados a alta resolución |
¿Cómo medir la performance de conversión en tu propio servidor?
La metodología del benchmark es replicable y no necesitás nada raro. Estos son los pasos que siguió:
- Junтá imágenes reales, no de prueba: usó 50 archivos (26 PNG y 24 HEIC), del tipo que pasa por su pipeline todos los días.
- Definí el set de conversiones: corrió 17 combinaciones de formato y calidad sobre el mismo material.
- Registrá dos métricas por cada una: tamaño de archivo final y tiempo de codificación. Sin esas dos columnas no hay decisión posible.
- Usá una base de procesamiento seria: la herramienta del autor corre sobre Rust y libvips, que es el motor de imágenes de buena parte del ecosistema web.
Si tu sitio vive en un servidor con recursos compartidos, este tipo de medición te dice si conviene mover la conversión a un proceso aparte o a un horario de baja carga. Para infraestructura en Argentina, un VPS o hosting administrado de donweb.com te da el control sobre el entorno donde corre el pipeline, que es justo lo que necesitás para que estos números sean estables entre corridas.
Qué formato elegir según tu caso
- Galería de e-commerce: WebP. Balance de tamaño y velocidad imbatible para volumen.
- Fotos del iPhone sueltas: WebP por defecto, AVIF si son pocas y querés exprimir cada byte.
- Batch masivo de 10.000+ fotos: WebP, sin discusión. El 7x de AVIF te mata la cola.
- PDFs escaneados: PNG a 600 DPI. Más calidad y menos peso, gratis.
Errores comunes al optimizar imágenes en el servidor
- Convertir HEIC a JPG creyendo que achicás: el archivo crece 14%. Si querés peso menor, andá a WebP o AVIF directo.
- Elegir AVIF para todo “porque comprime más”: en un batch grande el 7x de tiempo te arruina el pipeline. Reservá AVIF para pocas imágenes críticas.
- Bajar el DPI de PDFs “para que pesen menos”: con PNG puede ser al revés. Medí antes de asumir.
- Confiar en consejos genéricos sin medir: tu mix de imágenes no es el de internet. Un benchmark de 50 archivos propios vale más que mil tutoriales.
Preguntas Frecuentes
¿Cuál es el mejor formato para comprimir imágenes en producción?
WebP es el mejor balance general: en el benchmark ahorró 43% sobre HEIC con apenas 0,19s de codificación por imagen. AVIF comprime un poco más (57%) pero tarda 7 veces más, así que conviene solo para pocas imágenes críticas.
¿Por qué convertir HEIC a JPG aumenta el tamaño del archivo?
Porque HEIC envuelve el codec HEVC, que comprime alrededor del doble de bien que JPEG. Al pasar a JPG estás cambiando un codec superior por uno inferior, así que el archivo crece (un 14% en la prueba) para mantener la calidad. En ejecutar conversiones sin dependencias externas profundizamos sobre esto.
¿Cuánto tarda codificar AVIF comparado con WebP?
AVIF tardó 1,30s por imagen contra 0,19s de WebP, unas 7 veces más. Sobre 1.000 imágenes eso es la diferencia entre unos 3 minutos (WebP) y unos 21 minutos (AVIF).
¿AVIF vale la pena si es tan lento?
Para una imagen de portada o un set chico, sí: ese 10% extra de compresión sobre WebP suma sin costo perceptible. Para un pipeline que procesa miles de fotos, no: la penalidad de 7x en tiempo no justifica la diferencia.
¿Cómo mido la performance de conversión en mi servidor?
Tomá 40 o 50 imágenes reales de tu sitio, corré las conversiones que te interesan y registrá dos cosas por cada una: tamaño final y tiempo de codificación. Con esas dos métricas comparás formatos sobre tu material propio en vez de adivinar.
Conclusión
Lo que cambia este benchmark no es un formato nuevo, es la actitud. Tres de los consejos más repetidos sobre imágenes (convertí a JPG, usá siempre AVIF, bajá el DPI para ahorrar) fallan en escenarios concretos y verificables. WebP queda como el caballito de batalla para casi todo, AVIF para casos puntuales, y PNG a alta resolución para PDFs escaneados.
La acción concreta: antes de tocar tu pipeline de optimización de imágenes en el servidor, corré tu propio benchmark con tus archivos reales. Cincuenta imágenes y dos columnas (tamaño y tiempo) alcanzan para tomar decisiones con data en vez de con folklore de Stack Overflow. Medí, después decidí.
