Convertir ICO a AVIF

AVIF no es un formato de imagen que además comprima bien: es la rama intrafotograma del códec de vídeo AV1 con un contenedor alrededor. Todo lo que hace bien se deduce de ahí. AV1 se construyó para predecir el contenido de un bloque a partir de sus vecinos y para tirar el residuo de detalle que un ojo en movimiento no va a cazar, y esa estrategia es extraordinariamente eficaz sobre fotografías y sobre grano de película.

Un icono no tiene ni lo uno ni lo otro. Es un puñado de regiones planas con bordes duros y unas decenas de píxeles suavizados a lo largo de cada contorno. No hay textura que modelar, no hay degradado que predecir y apenas hay residuo que descartar, así que la maquinaria que hace ganar a AVIF en una foto se queda casi sin trabajo mientras sus costes fijos siguen ahí.

Sobre un icono de prueba de 8.471 bytes con cuatro entradas, convertido con la calidad por defecto de 82, los resultados fueron: 1.737 bytes en PNG, 1.894 en GIF, 3.054 en WebP, 3.624 en AVIF y 4.005 en JPEG. El orden es casi exactamente el inverso del que daría la misma prueba sobre una fotografía.

No es una diferencia marginal: el AVIF es más del doble que el PNG y encima es el que pierde información. En un directorio de doscientos iconos, migrarlos a AVIF añade unos 380 kilobytes a lo que el sitio entrega en lugar de quitar nada. Saca los iconos de la migración y déjalos en PNG.

La transparencia se conserva: en el icono de prueba, el píxel de la esquina del AVIF resultante lee 0,0,0,0. No es algo que dé por sentado cualquier formato eficiente —el camino hacia GIF de este mismo sitio deja esa esquina negra y opaca—, así que si la marca es un recorte y el formato tiene que ser AVIF, al menos esta parte funciona.

Funciona codificando el alfa como un plano aparte junto al color, es decir, una segunda imagen pequeña dentro del contenedor. En una fotografía ese sobrecoste se pierde entre el ruido. En un icono de 256 píxeles, donde el archivo entero son unos pocos kilobytes, es una parte visible del total y explica en buena medida el número de arriba.

Codificar un AVIF fijo significa ejecutar la búsqueda intrafotograma de AV1, con lo que es el codificador más pesado y más lento de los que se cargan en este sitio. Para un archivo es una pausa. Para doscientos iconos soltados de golpe es una espera de verdad, y la hace tu procesador y no un servidor.

Conviene pesar eso junto al resultado en bytes y no por separado. Gastar tiempo real de codificación, en cada compilación, para que cada icono acabe pesando el doble es un mal negocio en las dos direcciones a la vez.

Un ICO guarda la misma marca a varios tamaños y un AVIF guarda una sola imagen, así que algo tiene que elegir. Elige el descodificador de iconos de tu navegador, que devuelve la entrada mayor: comprobado construyendo un archivo con dibujos de 16, 32, 48 y 256 píxeles en cuatro colores distintos y convirtiéndolo con el directorio escrito en tres órdenes diferentes.

El techo son 256 píxeles y lo impone el formato ICO, no AVIF, que llega a 65.536. Así que a la entrada del codificador llega siempre una imagen pequeña, que es justo la condición en la que cualquier formato eficiente rinde peor frente a PNG.

AVIF puede almacenar doce bits por canal y una gama de color amplia, que es una de sus ventajas reales sobre WebP y JPEG en fotografía y en material de alto rango dinámico. Un archivo de iconos guarda ocho bits por canal en gama estándar, y siempre ha sido así.

De modo que la capacidad está disponible y sin usar. No cuesta nada directamente, pero resume bien el par: casi todo aquello en lo que AVIF es mejor es algo que un icono no tiene. La única propiedad que aporta y que aquí importa —el alfa— ya la tenía PNG. Lo mismo vale para el tamaño máximo: AVIF admite imágenes enormes y la fuente nunca pasa de 256 píxeles, con lo que ni ese margen ni la mitad de las herramientas del códec entran en juego en ningún momento.

AVIF define un modo sin pérdida y este conversor no lo pide nunca: pasa al codificador el valor de calidad y nada más, con 82 como valor por defecto. Es una precisión que importa en una migración, porque quien mueve activos gráficos a un formato moderno suele suponer que puede pedir una copia exacta cuando la necesite.

Aquí no puede. Si el icono tiene que llegar bit a bit al otro lado —porque hay una comparación automatizada, o porque es la fuente de la que se derivan otros tamaños—, el destino correcto es PNG, que en este par además es el archivo más pequeño de los dos.

Todos los navegadores mayoritarios actuales descodifican AVIF y llevan años haciéndolo. Para la mayoría de sitios eso basta para servirlo directamente. Es más nuevo que WebP, así que la cola de clientes que no lo leen es más larga, y la respuesta habitual es un elemento picture con una fuente alternativa en lugar de una sustitución directa.

Fíjate en lo que eso significa para un icono: ahora entregas dos archivos en vez de uno, y el de reserva es el PNG que ya era más pequeño de entrada. La complejidad es real y el ahorro es negativo.

Una regla única es atractiva porque elimina una decisión de cada compilación futura, y las reglas únicas sobre formatos de imagen suelen ser acertadas. Este es el caso en que no lo es. Divide la regla por contenido y no por carpeta: fotografías y capturas a AVIF, dibujo plano e iconos a PNG, y escribe el motivo al lado de la regla para que nadie venga después a «arreglarla».

Si la cadena de compilación de verdad no admite dos reglas —hay transformaciones de CDN que no lo permiten—, convertir los iconos es un coste defendible a cambio de uniformidad. Sabiendo que es un coste y sabiendo su tamaño aproximado: un par de kilobytes por icono, en la dirección equivocada.

Suelta la carpeta. Cada archivo se descodifica y se codifica por su cuenta, los resultados vuelven en un ZIP y el valor de calidad es el mismo para toda la tanda. Cuenta con que tarde bastante más que la misma tanda hacia PNG o WebP, por el motivo de más arriba. El plan gratuito acepta cien archivos por tanda y 100 MB por archivo, cifra que ningún icono roza.

Las dimensiones no serán uniformes salvo que lo fuera el conjunto de origen. Las colecciones de iconos mezclan archivos que llevan una entrada de 256 píxeles con otros que se quedan en 32, y como los costes fijos del codificador pesan más cuanto menor es la imagen, los miembros de 32 píxeles son donde AVIF sale peor parado de todos.

Dos cosas, y ninguna lleva tiempo. La primera es el recuento de bytes de los dos archivos uno al lado del otro, porque ese es el número por el que se emprendió la migración y el que más se supone en vez de medirse. La segunda es la marca al tamaño al que se va a mostrar de verdad: ni ampliada, donde los artefactos con pérdida asustan y nadie los verá nunca, ni como miniatura, donde todo parece correcto.

Conserva el archivo de icono original en cualquier caso. Es lo único que sigue guardando las entradas pequeñas dibujadas a mano, ocupa unos pocos kilobytes y es lo que un navegador va a seguir pidiendo a la raíz del sitio con independencia de lo que produzca la compilación.

El descodificador de iconos y el codificador de AV1 corren dentro de la pestaña como WebAssembly, así que una conversión lenta es tu procesador trabajando y no una cola ajena. El archivo no se sube en ningún momento.

En un flujo de compilación eso tiene una consecuencia práctica más allá de la privacidad: no hay límite diario que agotar ni servicio del que depender cuando dentro de dos años haya que rehacer los activos. La página seguirá haciendo el trabajo con el procesador de quien la abra. Y para un repositorio privado importa además que los iconos de marca de un producto sin anunciar no pasen por la infraestructura de nadie, aunque el archivo ocupe dos kilobytes y parezca que da igual.