Otimizar um ficheiro SVG sem alterar a apresentação

Um SVG pode parecer mínimo no ecrã e conter centenas de linhas de código, coordenadas com oito casas decimais, grupos aninhados, metadados do editor e identificadores gerados automaticamente.

Otimizar consiste em procurar uma representação mais simples do mesmo resultado, e não em destruir cegamente tudo o que não parece visível.

Porque otimizar?

Um SVG otimizado pode ser mais leve, mais rápido de analisar, mais simples de versionar e menos carregado de dados próprios do software de criação.

Mas nem todos os ficheiros precisam do mesmo esforço. Poupar 150 bytes numa pequena ícone já limpa raramente justifica trabalho manual; uma ilustração de centenas de kilobytes com milhares de pontos merece uma análise maior.

Compreender o conteúdo primeiro

Abra o ficheiro num editor de texto. Pode encontrar algo muito compacto:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">
  <path d="..." fill="currentColor"/>
</svg>

ou metadados, <defs>, grupos, transformações e muitos paths.

Separe aquilo que produz a imagem, o comportamento, a acessibilidade ou a atribuição daquilo que é apenas um resíduo de produção.

Conservar uma fonte master

Não transforme o SVG otimizado na única cópia. O ficheiro de trabalho pode guardar nomes de camadas, grupos lógicos, guias, objetos ocultos e precisão útil para futuras alterações.

Uma cadeia segura é:

fonte de trabalho
→ SVG exportado
→ otimização
→ SVG de produção

Criar uma referência antes de otimizar

Registe tamanho, viewBox, contexto de integração e comportamento esperado. Abra o SVG isoladamente e no componente real, em fundos relevantes e em tamanhos pequenos e grandes.

Depois de cada alteração importante, compare com esta referência.

Remover comentários e metadados inúteis

Comentários, informação do editor, espaços e atributos duplicados são frequentemente os ganhos mais seguros.

Não elimine, porém, dados de licença, atribuição ou acessibilidade que o projeto precise de conservar.

Reduzir a precisão com cuidado

Paths exportados podem conter coordenadas com muitas casas decimais. Arredondá-las reduz o tamanho, sobretudo em desenhos complexos.

Mas cada arredondamento altera a geometria. Em curvas grandes pode ser invisível; em ícones pequenos, traços finos ou figuras precisas pode causar deformações.

Teste vários níveis e compare visualmente.

Simplificar grupos e transformações

Editores gráficos produzem por vezes muitos <g> e transformações aninhadas. Ferramentas automáticas conseguem combiná-los em muitos casos.

No entanto, CSS, seletores ou scripts podem depender de IDs e grupos. Algo aparentemente redundante no ficheiro isolado pode ter função no componente real.

IDs e referências internas

Gradientes, máscaras, clip paths, filtros e <use> podem referenciar elementos por ID. Remover ou renomear identificadores sem atualizar as referências pode quebrar a imagem.

viewBox e dimensões

Não elimine viewBox para poupar alguns bytes. É muitas vezes essencial ao comportamento responsive e à relação entre coordenadas internas e dimensões de apresentação.

Remover width e height pode fazer sentido quando o CSS controla tudo, mas não deve ser uma regra automática.

Acessibilidade

Um otimizador não conhece necessariamente a intenção de um <title> ou descrição. Se o SVG inline comunica informação, confirme que a alternativa acessível foi preservada.

Para elementos puramente decorativos, aplique a semântica adequada para que não criem ruído.

Segurança

Otimização não é sanitização. Um SVG pequeno pode ainda conter elementos indesejados. Conteúdo proveniente de fontes não confiáveis deve passar por uma política de sanitização apropriada antes de ser inserido inline.

Verificação final

Teste apresentação em vários tamanhos, viewBox, cores, currentColor, gradientes, masks, acessibilidade, eventuais animações e tamanho final.

O ficheiro mais pequeno não é automaticamente o melhor. A otimização é bem-sucedida quando mantém tudo o que o projeto precisa com menos complexidade e menos dados.