Converter ICO para WebP

Um ICO existe para responder uma pergunta que o sistema operacional faz: me dê essa marca no tamanho que eu preciso agora. Ele responde guardando vários desenhos num arquivo só, com um índice na frente. Um WebP não responde pergunta nenhuma assim — é uma imagem, num tamanho, feita para ser posicionada por uma folha de estilo.

Então a conversão é uma troca de papel tanto quanto de formato. O que você ganha é um recurso de imagem que se comporta como qualquer outra imagem da página: pode receber uma largura, entrar num conjunto de fontes responsivas, ser cacheado com nome fixo. O que você perde é a capacidade do sistema operacional de escolher um tamanho para você, o que numa página web ele nunca estava fazendo mesmo.

WebP carrega canal alfa completo de oito bits, então uma marca recortada, um bloco arredondado ou uma sombra suave chegam intactos e se encaixam sobre qualquer fundo da página. Num ícone de teste, o pixel do canto do resultado lê totalmente transparente. O arquivo escrito é a forma estendida do formato, que é o que abre espaço para o dado alfa junto da cor.

Essa única propriedade descarta o JPEG inteiramente para este trabalho, e vale dizer porque os dois formatos são parentes próximos em como comprimem. Se o ícone não tem nenhum pixel transparente — um bloco quadrado com fundo sólido — o argumento fica bem mais fraco e qualquer um dos dois serve.

O ajuste de qualidade começa em 82, um meio-termo sensato para uma fotografia e um pouco baixo para arte feita de preenchimento plano e borda dura. Compressão com perdas funciona descartando detalhe que o olho dificilmente notaria, e numa fotografia esse detalhe é textura. Num ícone é a borda de uma letra.

A 256 pixels o arquivo inteiro tem poucos kilobytes, então quase não há nada a defender mantendo a qualidade baixa. Suba para 95 ou mais e os contornos ficam nítidos por um custo de poucos kilobytes.

O argumento comum para WebP é que produz cerca de um quarto a um terço menos bytes do que a alternativa na mesma qualidade. Esse argumento é construído sobre fotografia, e não se aplica a arte plana pequena, onde a combinação de filtro e compressão do PNG é muito difícil de superar.

Medido no mesmo ícone de teste a 256 pixels: o WebP saiu maior que o PNG equivalente, e o WebP ainda é o com perdas. Se o motivo desta conversão era economizar banda, ela não vai fazer isso. Se o motivo é o pipeline de build gerar WebP e o ícone precisar acompanhar, é um bom motivo e os poucos kilobytes não importam.

O navegador decodifica o ícone e devolve sua maior entrada, que é o que é codificado. Isso foi checado construindo um arquivo com desenhos de 16, 32, 48 e 256 pixels em cores distintas e convertendo com o índice em ordens diferentes — o desenho de 256 pixels saiu sempre.

O teto é 256 pixels e pertence ao formato ICO: uma entrada guarda sua largura num único byte, com zero representando 256. O próprio WebP alcança 16.383 pixels, então nada do lado de destino está limitando você. Se precisar de uma imagem maior, o arquivo de ícone não é onde ela mora.

A decepção mais comum com esta conversão é uma marca que fica boa numa aba de navegador e borrada num cabeçalho de 200 pixels. Isso não é o codificador; é que o ícone foi desenhado para abas. Entradas de ícone pequenas costumam ser redesenhadas em vez de escaladas — traços alinhados a pixels inteiros, detalhe removido —, então ampliar uma delas dá um desenho simplificado em baixa resolução.

Confira as dimensões em pixel do resultado antes de posicioná-lo. Se forem 32 pixels, as opções honestas são exibir a 32 pixels ou procurar a arte original; o ajuste de largura máxima aqui só reduz, e nenhum conversor consegue adicionar detalhe que nunca foi guardado.

Consistência é um benefício de engenharia de verdade mesmo quando a contagem de bytes não é. Um site que serve um formato só para todo recurso raster tem uma política de cache, uma etapa de build e um conjunto de regras para testar. Acrescentar uma exceção em PNG para seis ícones custa mais em complexidade do que economiza em kilobytes.

O outro caso genuíno é um conjunto grande de ícones. Sessenta blocos de integração a três kilobytes cada somam 180 kilobytes, e se carregam juntos a diferença contra o equivalente PNG é mensurável — mas nessa comparação o PNG está na frente, então o motivo de padronizar é o pipeline, não a aritmética.

Converter não significa apagar. Navegadores continuam pedindo `/favicon.ico` da raiz de todo site, seja o que for que o HTML declare, então mantenha o original onde está e trate o WebP como um recurso separado com outra função. Eles não são duas versões de um arquivo; são dois arquivos que por acaso mostram a mesma marca.

Na marcação, o WebP entra num elemento de imagem comum como qualquer outra, e o ícone continua num elemento de link no cabeçalho do documento. Misturar os dois — apontar o link de favicon para um WebP — funciona em navegadores atuais e falha em ferramentas o suficiente para não valer a economia.

Solte a pasta inteira e cada arquivo é decodificado e codificado individualmente, com os resultados devolvidos como ZIP. O ajuste de qualidade se aplica a todos, o que é o que você quer para uma grade de blocos onde um único item mais suave chamaria mais atenção do que todos levemente imperfeitos.

As dimensões não vão ficar uniformes a menos que o conjunto de origem já fosse. Coleções de ícones montadas ao longo dos anos misturam arquivos com entrada de 256 pixels e arquivos que param em 32, e os WebPs herdam essa variação sem aviso — vale conferir no ZIP antes de encaixar num layout que assume um tamanho só.