Converter ICO para AVIF

O AVIF não é um formato de imagem que por acaso comprime bem; é o caminho de quadro isolado do codec de vídeo AV1, com um contêiner ao redor. Tudo em que ele é bom vem daí. O AV1 foi construído para prever o conteúdo de um bloco a partir dos vizinhos e descartar o detalhe residual que um olho em movimento não percebe, uma estratégia extraordinariamente eficaz em fotografia.

Um ícone não tem nada disso. É um punhado de regiões de cor chapada com bordas duras e algumas dezenas de pixels suavizados ao longo de cada borda. Não há textura para modelar, não há degradê para prever e quase nada de resíduo para jogar fora — então o mecanismo que faz o AVIF ganhar numa fotografia quase não tem trabalho a fazer, enquanto o custo fixo do formato continua o mesmo.

Em cima de arte de ícone chapada, típica de um arquivo ICO, o AVIF costuma sair mais pesado que o mesmo desenho salvo como PNG — a ordem se inverte em relação ao que aconteceria numa fotografia, onde o AVIF ganha com folga. Isso vale mesmo já contando que o PNG deste site aplica uma otimização sem perda antes de fechar o arquivo.

Para um diretório de duzentos ícones, migrar todos para AVIF tende a aumentar o que o site entrega em vez de reduzir. Vale separar os ícones da migração e mantê-los como PNG, e reservar o AVIF para o conteúdo fotográfico do mesmo diretório.

A transparência é preservada na conversão: o AVIF carrega canal alfa de verdade, e o pixel transparente de um ícone continua transparente no resultado. Isso já é uma vantagem sobre o GIF gerado por este site, cujo codificador não escreve índice transparente nenhum e transforma tudo em opaco.

A transparência funciona codificando o alfa como um plano separado, ao lado da cor — na prática, uma segunda imagem pequena dentro do contêiner. Numa fotografia esse custo se perde no meio do resto. Num ícone de 256 pixels, em que o arquivo inteiro tem poucos kilobytes, esse custo é uma fatia visível do total.

O codificador de AVIF é o módulo mais lento entre os formatos deste site, porque codificar um AVIF parado significa rodar a busca de quadro isolado do AV1. Para um arquivo é uma pausa; para uma pasta de duzentos ícones convertidos de uma vez é uma espera de verdade, e é o seu próprio processador fazendo o trabalho, não um servidor.

Vale pesar isso junto com o resultado em bytes, não separadamente. Gastar tempo real de codificação, a cada build, para deixar cada ícone mais pesado é uma troca ruim nos dois sentidos ao mesmo tempo.

Um ICO guarda a mesma marca em vários tamanhos, e um AVIF guarda uma imagem só, então algo precisa escolher qual. O decodificador de ícone do próprio navegador faz essa escolha, e costuma devolver a entrada maior do arquivo. Os desenhos menores do contêiner ficam de fora da conversão.

O teto de um ICO é 256 pixels no lado maior, imposto pelo próprio formato, enquanto o AVIF suporta imagens muito maiores. Então a entrada do codificador aqui é sempre uma imagem pequena, exatamente a condição em que qualquer formato eficiente para fotografia se sai pior frente ao PNG.

O AVIF pode guardar até doze bits por canal e uma gama de cor ampla, uma vantagem genuína sobre WebP e JPEG para fotografia e para material de alta faixa dinâmica. Um arquivo de ícone guarda oito bits por canal numa gama padrão e sempre guardou.

Então essa capacidade fica disponível e sem uso. Não custa nada diretamente, mas resume bem o par: quase tudo em que o AVIF é melhor é algo que um ícone não tem. A única propriedade que ele traz e que importa aqui — o alfa — o PNG já tinha.

Todo navegador atual decodifica AVIF, e faz isso há vários anos. Isso já basta para a maioria dos sites servir o formato direto. Ele é mais novo que o WebP, então a lista de clientes antigos que não leem é mais longa, e a resposta costuma ser um elemento de imagem com fonte alternativa em vez de uma troca direta.

Vale notar o que isso significa para um ícone: você passa a entregar dois arquivos em vez de um, e a alternativa é justamente o PNG que já era menor desde o início. A complexidade é real e a economia é negativa.

Uma regra única é atraente porque tira uma decisão de cada build futuro, e regras únicas sobre formato de imagem costumam estar certas. Este é o caso em que não estão. Separe a regra por conteúdo em vez de por diretório: fotografia e captura de tela para AVIF, arte chapada e ícone para PNG, e anote o motivo ao lado da regra para que ninguém "corrija" isso depois.

Se o processo de build genuinamente não consegue expressar duas regras, converter os ícones mesmo assim é um custo defensável em nome da uniformidade. Só saiba que é um custo, e mais ou menos de quanto: alguns kilobytes por ícone, na direção errada.

Solte a pasta inteira. Cada arquivo é decodificado e codificado por conta própria, e o resultado volta como um ZIP, com um ajuste de qualidade único para o lote todo. Espere que demore visivelmente mais que o mesmo lote convertido para PNG ou WebP, pelo motivo já explicado.

As dimensões não vão ficar uniformes a menos que o conjunto de origem já fosse. Coleções de ícone misturam arquivos com entrada de 256 pixels e arquivos que param em 32, e como o custo fixo do formato pesa mais quanto menor a imagem, os ícones de 32 pixels do conjunto são onde o AVIF sai pior de todos.

Duas coisas valem uma olhada rápida. A primeira é o peso dos dois arquivos lado a lado, porque é o número pelo qual a migração foi feita, e é o mais fácil de presumir em vez de medir de verdade. A segunda é a marca em si, no tamanho em que ela realmente vai aparecer — nem ampliada, onde defeito de compressão parece alarmante e ninguém nunca vai ver assim, nem em miniatura, onde tudo parece bem de qualquer forma.

Guarde o arquivo ICO original de qualquer forma. É o único que ainda guarda as entradas pequenas desenhadas à mão, pesa poucos kilobytes, e é o que um navegador vai continuar pedindo da raiz do site independentemente do que o build produzir.