Convertir WebP a AVIF

Este sitio mantiene tres escenas de muestra y las codifica por la misma tubería que usa esta página, así que las cifras son lo que produce este conversor y no lo que informa un banco de pruebas ajeno. A 480 por 320 y con la calidad por defecto: el gráfico plano ocupa 4.428 bytes como WebP y 3.494 como AVIF; la escena tipo captura de pantalla, 10.830 frente a 5.081; y la fotografía, 14.700 frente a 17.599.

La fotografía es la que importa, porque una fotografía es de lo que está hecho casi todo presupuesto de imágenes. Ahí el AVIF perdió por un veinte por ciento. Eso no convierte al formato en malo —con ajustes de calidad más bajos y con imágenes mayores el orden se invierte con frecuencia, y la ventaja del AV1 crece con la resolución—, pero sí convierte «el AVIF es un treinta por ciento más pequeño» en una afirmación que hay que probar sobre tus propios archivos. Convierte cinco imágenes antes de convertir cinco mil.

El patrón de esas cifras no es casual. La predicción intra del AV1 es especialmente buena con regiones amplias de color casi constante separadas por fronteras duras, y tiene más particiones de bloque y más modos de predicción que gastar en clavar un borde de los que tiene la codificación del WebP, heredada del VP8.

Eso describe capturas de interfaz, diagramas, gráficas, ilustraciones, fotos de producto sobre fondo liso y cualquier cosa con texto dentro, que en un sitio corriente es una parte grande del número de imágenes aunque sea una parte pequeña de los bytes. Son las primeras que hay que convertir, y la conversión se paga dos veces: encogen mucho y eran justamente aquellas en las que los defectos del WebP se veían más. Las fotografías de portada son las que hay que medir una por una.

La conversión descodifica el WebP a píxeles y codifica esos píxeles como AVIF. Si el WebP era con pérdida, sus propios defectos —zonas planas alisadas, timbre a lo largo de los bordes duros— forman parte de la imagen ahora, y el codificador de AVIF gasta bits en describirlos fielmente mientras añade una capa propia encima.

A calidad 82 eso no es dramático y tampoco es gratis, y casi siempre es evitable. La mayoría de los sitios conserva el PNG o el JPG original en el repositorio, en la herramienta de diseño o en un gestor de activos, y codificar el AVIF desde esa fuente produce un archivo más limpio y con frecuencia más pequeño. Esta página existe para el caso en que el WebP es de verdad la única copia que queda —un archivo convertido por una CDN, un sitio heredado, una carpeta que alguien ordenó— y en ese caso hace el trabajo.

El WebP lo admite cualquier navegador actual. El AVIF lo admiten los modernos, que es una frase distinta: un dispositivo antiguo, un equipo corporativo bloqueado, el navegador incrustado de una aplicación o un cliente poco común pueden aterrizar en la página y no recibir nada, porque una imagen que no se puede descodificar no es una imagen degradada sino un hueco vacío.

La solución se conoce bien y es barata. Un elemento picture con una fuente AVIF y otra WebP o JPG de reserva cuesta dos líneas de marcado y elimina el riesgo por completo: el navegador escoge la primera fuente que entiende y nada más cambia. Eso sí implica conservar los dos archivos, cosa que conviene recordar si el motivo de la migración era reducir almacenamiento y no tráfico.

El AV1 compra su compresión con análisis, y el codificador que corre aquí es libavif compilado a WebAssembly. Convertir un WebP a AVIF es notablemente más lento que cualquier otra pareja de esta familia: la descodificación es rápida y la codificación no, y con una imagen grande hablamos de segundos y no de milisegundos.

El coste cae donde debe: una vez, en tu máquina, en el momento que tú elijas, y no en cada visita. Pero cambia cómo se organiza una migración. Una carpeta de varios cientos de activos es un trabajo que se arranca y se deja, y hacerlo desde un móvil no tiene sentido. Es también un argumento para convertir primero las imágenes que más ganan —las planas— antes de gastar una tarde en fotografías que pueden salir más grandes.

La transparencia sobrevive limpia: los dos formatos llevan un canal alfa completo de 8 bits, y el AVIF es eficiente con él, así que los recortes de producto y los logotipos están entre los activos donde gana con más fiabilidad. Los bordes suaves siguen suaves y no aparece ninguna orla.

Lo que no ocurre es ninguna ganancia de profundidad ni de gama. El AVIF puede guardar doce bits por canal y color de gama amplia; esta tubería descodifica todo a RGB de 8 bits, y el WebP ya era de 8 bits, así que no hay nada que promover. Quien quiera llevar una biblioteca hacia HDR o Display P3 tiene que hacerlo desde las capturas originales y con herramientas que entiendan perfiles, no desde un conjunto de activos web de 8 bits.

El control va de 1 a 100 y arranca en 82, y el mismo número no significa lo mismo para dos codificadores distintos. Como el origen ya es un WebP con pérdida, hay un argumento real para ponerlo algo más alto de lo que lo pondrías desde un original: el codificador está intentando reproducir una imagen que ya trae estructura que él no puso.

El método práctico es convertir tres imágenes representativas a 78, 82 y 88 y comparar los bytes y el aspecto al tamaño en que la página las muestra realmente. Son diez minutos y resuelven la cuestión para toda la biblioteca mucho mejor que una regla de andar por casa. Con imágenes que llevan texto, tira hacia arriba: el texto sobre un fondo es lo primero que degrada cualquier codificador con pérdida y lo primero que nota quien mira.

Un WebP puede llevar un bloque EXIF y otro XMP incrustados. No llegan al AVIF: la conversión descodifica a píxeles crudos y vuelve a codificar, así que esos bloques desaparecen sin que haya casilla alguna que los conserve. Para activos de web es lo deseable, y de paso ahorra unos bytes por archivo.

La animación es otra historia y conviene saberla antes de soltar una carpeta. El descodificador que se usa aquí lee WebP fijos, así que un WebP animado se rechaza con un mensaje legible en vez de devolver el primer fotograma disfrazado de imagen completa. En una carpeta mixta eso produce unos cuantos errores y termina el resto, que es el comportamiento que quieres cuando la alternativa es un conjunto de fotogramas sueltos que nadie pidió.

Si los activos ya son WebP y la página cumple su presupuesto de rendimiento, la recomendación honesta es no hacer nada. El salto de JPG o PNG a WebP es el que produjo el ahorro grande; el salto de WebP a AVIF es una ganancia de segundo orden, a veces negativa, que cuesta tiempo de codificación y añade una alternativa que mantener.

Los casos que claramente lo justifican son las imágenes planas grandes, las páginas cargadas de imágenes donde el ahorro agregado se mide, y los sitios con muchas capturas o diagramas. Los que no lo justifican son los iconos pequeños, las imágenes que ya pesan pocos kilobytes y las fotografías en las que una medición muestra que el AVIF sale mayor. Si lo que buscas es compatibilidad y no menos bytes, WebP a PNG y WebP a JPG son las páginas para eso.

Los dos codificadores corren en la pestaña como WebAssembly y solo se descargan cuando se suelta un archivo de ese tipo, así que un lote de cien imágenes descarga el codificador una vez. Nada de esos archivos cruza la red, cosa que importa cuando los activos son de un cliente o de un sitio que todavía no ha salido.

El límite gratuito es de 100 MB por archivo, muy por encima de cualquier activo de web, y el tope por tanda son cien archivos: si sueltas más, los que sobran se descartan sin decirlo, así que conviene contar la carpeta antes. Cada archivo se convierte por turno con su propia fila de progreso y los resultados vuelven en un ZIP.