El Formato Es la Decisión que Viene Antes que la Compresión

En la lección anterior establecimos que las imágenes son el recurso más pesado en la mayoría de las páginas, que dimensionarlas correctamente importa más que la compresión por sí sola, y que la optimización de imágenes abarca seis problemas distintos. Esta lección se enfoca en el primero que debes resolver: ¿en qué formato debería estar esta imagen?

La elección del formato está por encima de todo lo demás. Puedes comprimir un JPEG hasta un tamaño razonable, pero si en primer lugar debería haber sido un WebP o un SVG, ya has aceptado una penalización que ningún control de calidad puede recuperar. Tomar esta decisión correctamente antes de abrir cualquier herramienta es lo que separa un pipeline de imágenes eficiente de uno que comprime la cosa equivocada de manera eficiente.

Dos Tipos Fundamentalmente Diferentes de Imágenes

La primera pregunta que debes hacerte sobre cualquier imagen no es "¿qué tan comprimida debería estar?". Es: ¿qué tipo de datos está representando esta imagen? La respuesta determina si debes trabajar con un formato vectorial o un formato raster, y estos dos son cosas fundamentalmente diferentes.

Imágenes Vectoriales (SVG)

Una imagen vectorial es un conjunto de instrucciones matemáticas: dibuja un círculo aquí, rellena esta ruta con este color, escala esta forma para que se ajuste a su contenedor. SVG es el formato vectorial dominante en la web, y vale la pena entender realmente lo que eso significa: un archivo SVG es código XML. No es una imagen en el sentido tradicional, sino un documento de texto que describe cómo dibujar una imagen.

Dado que SVG es texto, se comprime tan eficientemente como cualquier archivo JavaScript o HTML. Puede ser incluido directamente en tu markup. Y debido a que es matemático en lugar de basado en píxeles, escala a cualquier tamaño sin ningún cambio en los datos subyacentes. Un logo a 20px y el mismo logo a 2000px usan exactamente el mismo archivo, con exactamente el mismo tamaño de archivo.

Un paso importante cuando se trabaja con SVGs exportados desde herramientas como Figma, Illustrator o Affinity Designer es procesarlos con SVGO o SVGOMG, que funciona con SVGO.

Las herramientas de diseño incorporan cantidades significativas de metadatos del editor: nombres de capas, definiciones no utilizadas, datos de rutas redundantes de manejadores bezier que se cancelan entre sí. SVGO o SVGOMG elimina todo eso. Es común ver que los tamaños de archivo se reducen entre un 40 y un 60 por ciento sin ningún cambio visible en el resultado renderizado.

Logos, íconos, ilustraciones, gráficos, diagramas, etc. En general, cualquier cosa cuyo contenido esté definido por formas, rutas y rellenos. Si estás sirviendo un PNG raster del logo de tu empresa, estás incurriendo en un costo real que SVG eliminaría por completo.

Puede haber algunas excepciones, como banderas de estados con formas complejas que deberían servirse como íconos de imágenes raster, pero en general SVG es la elección correcta para cualquier cosa que no sea una fotografía o textura fotorrealista.

Eso es todo sobre SVG y los formatos vectoriales, ya que esta serie se enfocará en los formatos raster, que son los más comunes y los que se manejan incorrectamente con mayor frecuencia.

Imágenes Raster (JPEG, PNG, WebP, AVIF)

Los formatos raster funcionan de manera completamente diferente. Una imagen raster es una cuadrícula fija de píxeles, y cada píxel almacena información de color. Una fotografía de 2000 por 1000 píxeles es siempre de 2000 por 1000 píxeles. Si la amplías, el navegador inventa los píxeles adicionales mediante interpolación, lo que degrada la calidad. Si la reduces, estás descargando muchos más píxeles de los que la pantalla mostrará alguna vez.

Esta naturaleza de resolución fija es lo que hace que las imágenes raster sean simultáneamente el formato más común en la web y el que se maneja incorrectamente con más frecuencia. La fotografía, las imágenes de productos y cualquier cosa con gradientes de color complejos o texturas fotorrealistas pertenece a un formato raster. La pregunta es: ¿cuál formato raster?

Ahí es donde comienza la verdadera decisión de ingeniería.

El Duelo de Formatos: WebP, AVIF, y Cuándo Elegir Cada Uno

JPEG ha sido el formato predeterminado para el contenido web fotográfico desde 1992. Sigue siendo ubicuo porque todos los navegadores, todos los sistemas operativos y todos los visores de imágenes del planeta lo soportan. Ese soporte universal lo ha mantenido vivo mucho después del punto en que existen mejores alternativas. En 2026, JPEG debería ser tu recurso de último recurso, no tu punto de partida.

WebP: El Predeterminado Seguro

WebP fue desarrollado por Google y lanzado en 2010 como un reemplazo directo tanto de JPEG como de PNG. Soporta compresión con y sin pérdida, soporta transparencia (cosa que JPEG no hace), y produce archivos aproximadamente 25 a 30 por ciento más pequeños que JPEG con calidad visual equivalente. El soporte de navegadores ha estado en aproximadamente el 97 por ciento durante años y puede considerarse universal.

Si necesitas un único formato que funcione en todas partes, no imponga un costo de codificación significativo y sea inequívocamente mejor que JPEG en todas las dimensiones, WebP es ese formato. Es el predeterminado seguro y sensato para la gran mayoría de las imágenes web.

AVIF: El Peso Pesado

AVIF deriva del códec de video AV1 y representa un salto generacional en eficiencia de compresión. Con calidad equivalente, los archivos AVIF son típicamente 40 a 50 por ciento más pequeños que JPEG y 20 a 30 por ciento más pequeños que WebP. Para fotografías con gradientes complejos, tonos de piel sutiles o superficies con mucha textura, la relación calidad-tamaño de AVIF suele ser visiblemente mejor porque evita los artefactos de bandas de color que ocasionalmente aparecen en WebP con configuraciones de calidad más bajas.

La contrapartida es la velocidad de codificación. Generar un archivo AVIF requiere mucho CPU de una manera que WebP simplemente no requiere. Codificar un JPEG grande a AVIF puede tomar segundos de tiempo de CPU. Es precisamente por esto que la librería @jsquash (sobre la que se construye toda esta serie) descarga la codificación AVIF en un Web Worker que ejecuta WebAssembly en lugar de bloquear el hilo principal del navegador.

El soporte de navegadores para AVIF está en aproximadamente el 93 por ciento a principios de 2026 y continúa creciendo. La práctica estándar es ofrecer AVIF como formato primario con WebP como alternativa, usando el elemento HTML <picture> para que el navegador seleccione el mejor formato que pueda manejar.

JPEG XL: Obsérvalo, Pero Espera

JPEG XL (JXL) merece una breve mención como formato emergente con impresionantes propiedades teóricas: compresión casi sin pérdida con tamaños de archivo muy pequeños, soporte para imágenes de rango dinámico muy alto, y un modelo de decodificación progresiva. A partir de 2026 no tiene suficiente soporte de navegadores para desplegarlo en producción sin advertencias significativas. Es un formato del que hay que estar al tanto y seguir de cerca, no para implementarlo.

Formato	Transparencia	Animación	vs tamaño JPEG	Velocidad de codificación	Soporte de navegadores
JPEG	No	No	línea base	Rápida	100%
PNG	Sí	No	mayor	Rápida	100%
WebP	Sí	Sí	~30% menor	Rápida	~97%
AVIF	Sí	Sí	~50% menor	Lenta	~93%
JPEG XL	Sí	Sí	~60% menor	Lenta	Limitado

¿Fotografía principal? Usa AVIF como primario y WebP como alternativa y JPEG como última fuente dentro de un elemento <picture>. ¿Gráficos de UI, miniaturas de productos, imágenes de contenido general? Si deseas ofrecer un solo formato, WebP debería ser tu predeterminado. ¿Logos e íconos? SVG, siempre.

Compresión con Pérdida vs Sin Pérdida: Entendiendo el Equilibrio

El árbol de decisiones al final de esta lección se bifurca en un concepto que las descripciones de formato anteriores mencionaron de pasada pero no explicaron: compresión con pérdida versus sin pérdida. Vale la pena tomarse un momento para entender qué significa realmente esta distinción, porque determina la decisión de formato para una categoría significativa de imágenes.

Con la compresión con pérdida, el codificador descarta permanentemente algunos datos de la imagen. Lo hace de manera inteligente, apuntando a texturas sutiles, grano fino y otros detalles que es poco probable que el ojo humano note en condiciones normales de visualización, pero el resultado es un archivo que no puede reconstruirse perfectamente en el original. JPEG es un formato exclusivamente con pérdida. WebP y AVIF pueden operar en modo con pérdida, que es su modo predeterminado para fotografías.

Con la compresión sin pérdida, el codificador reduce el tamaño del archivo sin descartar ningún dato. Cada valor de píxel se conserva exactamente, y la imagen original puede reconstruirse perfectamente a partir del archivo comprimido. PNG es un formato exclusivamente sin pérdida. WebP y AVIF ambos soportan un modo sin pérdida como opción.

Una analogía útil: piensa en la compresión con pérdida como resumir un libro para alguien que quiere las ideas clave sin leer cada palabra. El resumen es mucho más corto y captura la mayor parte de lo que importa, pero se pierde algún detalle. La compresión sin pérdida se parece más a un archivo ZIP, todo sigue ahí, simplemente empaquetado de manera más eficiente. El original sale completo cuando lo descomprimes.

¿Cuándo importa la distinción? Para fotografías e imágenes con gradientes de color suaves, la compresión con pérdida funciona extremadamente bien. El ojo humano es tolerante a los pequeños cambios en el detalle fotográfico, y un codificador con pérdida bien ajustado puede reducir el tamaño de los archivos entre un 60 y un 80 por ciento sin ninguna pérdida de calidad perceptible.

Para imágenes con texto nítido, líneas finas, elementos de UI o bloques sólidos de color plano, como capturas de pantalla, diagramas e íconos exportados guardados como imágenes raster, la compresión con pérdida introduce artefactos visibles en los bordes y alrededor de las letras. Sin pérdida es la elección correcta para esos casos.

Por eso el árbol de decisiones separa "fotografía o gradientes complejos" de "contiene texto o bordes nítidos" en ramas diferentes. El primer grupo se beneficia de la compresión con pérdida. El segundo necesita compresión sin pérdida.

Para los formatos con pérdida, controlas el equilibrio con una configuración de calidad, típicamente un número del 0 al 100. La relación no es lineal: pasar de calidad 60 a 80 produce una mejora notable en la mayoría de las imágenes. Pasar de 80 a 95 es mucho más sutil, mientras que el aumento del tamaño del archivo es sustancial. Una calidad de 80 para WebP y alrededor de 65 para AVIF son puntos de partida confiables que dan en el punto óptimo para la mayoría del contenido fotográfico. El resultado serán archivos pequeños con una pérdida de calidad mínima que a menudo es imperceptible.

Un Detalle Importante que Vale la Pena Conocer: Perfiles de Color

Si alguna vez exportaste una fotografía desde Lightroom, Capture One o Photoshop y notaste que se ve vibrante y saturada en tu pantalla pero extrañamente plana o apagada después de colocarla en una página web, has encontrado una incompatibilidad de perfiles de color. Es una sorpresa común y la solución es una sola casilla de verificación.

Las cámaras y las herramientas de diseño a menudo incorporan datos de perfil de color directamente en el archivo de imagen. Estos datos le indican al dispositivo de visualización cómo interpretar los valores de color en la imagen. La web se basa en un espacio de color llamado sRGB, pero las herramientas profesionales de fotografía y diseño frecuentemente guardan imágenes en espacios de color más amplios como Display P3 o Adobe RGB, que representan una gama más amplia de colores.

Cuando un navegador encuentra uno de estos perfiles más amplios en una imagen, maneja la incompatibilidad de manera inconsistente entre dispositivos y sistemas operativos. El resultado son colores que se ven incorrectos, o metadatos adicionales que se llevan sin ningún beneficio para el usuario.

La solución es simple: siempre exporta imágenes en sRGB y elimina el perfil de color incorporado antes de servirlas. La mayoría de los diálogos de exportación tienen una opción de espacio de color "web" o "sRGB". Cuando procesas imágenes con @jsquash más adelante en esta serie, el paso de codificación elimina los perfiles incorporados automáticamente.

Si una imagen se ve rica en tu herramienta de diseño pero deslavada en la página, abre Chrome DevTools, ve al panel de Red, haz clic en la solicitud de la imagen y cambia a la pestaña Vista previa. Si la vista previa se ve bien pero la imagen renderizada en el navegador se ve apagada, es probable que el perfil de color incorporado sea la causa. La solución es volver a exportar en sRGB.

El Árbol de Decisiones Previo al Vuelo

Antes de que cualquier imagen entre en un pipeline de optimización, un recorrido rápido por las siguientes preguntas toma menos de diez segundos y elimina las fuentes más comunes de peso de archivo innecesario. Este es el modelo mental que usarás instintivamente para cuando llegues a la Lección 12.

La única excepción notable a este árbol es la fotografía de alta fidelidad para archivos digitales de calidad de impresión, donde la profundidad de color de 16 bits y la codificación sin pérdida importan más que el tamaño del archivo. Para la entrega web estándar, el árbol anterior cubre todo lo que encontrarás.

Un camino que merece una mención específica: nunca uses GIF para animaciones. Un GIF animado es típicamente de 10 a 15 veces más grande que un WebP animado equivalente con la misma calidad visual. Esta no es una diferencia pequeña. La animación WebP ha tenido soporte de navegadores casi universal durante años y ya no hay una razón práctica para servir archivos GIF.

PNG no apareció como la recomendación principal en ningún lugar de este árbol, y eso es intencional. PNG es un formato sin pérdida diseñado para imágenes con transparencia y bordes nítidos, como capturas de pantalla y gráficos de UI. WebP sin pérdida maneja ambos casos de uso mientras produce archivos más pequeños. PNG sigue siendo relevante como alternativa universal cuando WebP no es una opción, pero no debería ser tu primera elección.

En Qué Se Basa Esta Serie a Partir de Estas Decisiones

Entender qué formato objetivo es el prerequisito para todo lo que sigue. Saber que quieres AVIF con WebP como alternativa es una perspectiva útil. Saber cómo producir ese AVIF dentro del navegador del usuario, sin un servidor, sin ImageMagick, y sin que el archivo sin procesar cruce la red, ese es el desafío de ingeniería que esta serie aborda.

La próxima lección presenta @jsquash, la librería de WebAssembly que lleva la codificación de AVIF y WebP de calidad Squoosh directamente a tu código de aplicación. Explica qué es WASM, cómo @jsquash envuelve librerías de códecs profesionales, y cómo se ve el pipeline de decodificación-codificación antes de que aparezca cualquier código Svelte.

Una vez que entiendas qué es la librería y por qué está diseñada de la manera en que está, construir el optimizador real se convierte en una cuestión de conectar piezas que ya entiendes en lugar de confiar en una magia de caja negra.

Conclusiones Clave

SVG es código, no píxeles. Úsalo para logos, íconos e ilustraciones. Siempre procesa los SVGs exportados con SVGO antes de implementarlos, ya que puede reducir el tamaño del archivo SVG hasta un 50%.
AVIF es el mejor formato raster disponible para fotografía en 2026, con WebP como alternativa universalmente segura. JPEG debería aparecer solo como alternativa de último recurso dentro de un elemento <picture>, nunca como tu formato principal.
Siempre exporta en sRGB y elimina los perfiles de color incorporados. Los perfiles de gama amplia como Display P3 y Adobe RGB agregan peso de archivo innecesario y pueden hacer que las imágenes aparezcan deslavadas en los navegadores. La solución es una sola casilla de verificación en tu diálogo de exportación.

Lectura Adicional

web.dev: Image Performance - La guía autorizada de Google sobre el manejo de imágenes en el navegador y el impacto en Core Web Vitals
AVIF Has Landed - El análisis detallado de Jake Archibald sobre las características de codificación AVIF y los argumentos para adoptarlo
Can I Use: AVIF - datos actuales de soporte de navegadores
Can I Use: WebP - datos actuales de soporte de navegadores
SVGO en GitHub - la herramienta estándar de optimización SVG

Ver También

Lección 1: Por Qué la Optimización de Imágenes Importa Más de lo que Crees - el caso para preocuparse por la elección de formato en primer lugar.
Lección 3: @jsquash y WebAssembly - la próxima lección, que cubre cómo los codificadores AVIF y WebP se ejecutan en el navegador a través de WASM.
Lección 8: Deja de Enviar Imágenes de 4000px a un Teléfono de 400px - usando la elección de formato y el elemento picture juntos para la historia completa de entrega responsiva.