Qual a melhor performance: SVG inline ou SVG embedded?

[espudaro]

Olá! td bem?

Qual a melhor estratégia para a utilização de vários SVGs (uns 30) em uma página? Alguns dados importantes:

• a maioria dos SVGs, tem menos de 1kb
• os SVGs serão usados somente em 1 pagina
• os SVGs serão estáticos, não sofrerão manipulação de CSS, JS,...

Alguns pontos levantados na minha pesquisa:

SVG inline

• Economia de requests de imagem
• Manipulação do SVG

SVG embedded

• Agrupar os SVGs em um único arquivo (sprite), e usar somente um request
• Os SVGs ficam cacheados, otimizando o acesso uma 2ª vez
• O código ficam muito mais fácil de ler

O que vcs preferem utilizar? Alguém já passou por esse dilema?

[espudaro]

acho que essa issue seria mais uma [duvida]!

[ninetails]

O que o coração das cartas mandar.

Digo, acho que vc já levantou os prós e contras de usar e seu uso depende bastante do que vc vai precisar no teu site. Coisas que adiciono e levaria em conta seria:

SVG Inline

• Depois de "limpar" os SVGs, ficam enxutos e não se repetem tanto?
• Vc usa algum framework/lib que facilite chamar cada imagem como um Componente?

Embed

• As imagens se repetem a ponto de achar que o HTML fica muito sujo? Ou as imagens são grandes?
• As imagens estão difíceis para serem otimizadas (remover classes, unificar paths)?

Quando tivemos essa discussão num produto que participei, a gente optou por inline devido a ter alterações via CSS (fill etc).

[espudaro]

Então @ninetails, seria uma única pagina de catalogo de departamentos, onde cada departamento teria seu próprio ícone em SVG.

Mesmo limpando o SVG (uso o svgomg) os paths ainda ficam grandes e sujam bastante o html. Ainda não uso nenhum framework/lib para chamar cada imagem.

Uma estratégia que discuti com o @Willian_justen foi de fazer embed, porem utilizando o protocolo http2, para melhorar o carregamento. Fazer sprite dos SVGs tbm ajuda.

[ninetails]

@espudaro então talvez o embed seja a melhor solução, mesmo pq pra usar o cache do navegador... aí é ponderar se vale mais cada arquivo separado ou um único via sprite.

O sprite vai valer a pena mesmo? Digo, não vai dificutar adição de novos departamentos ou alteração de cada ícone individual?

E sei lá, vale pensar em tudo isso para uma página só? Digo otimização prévia e tão específica só para um endpoint. HTTP/2 (ou talvez também um cache de PWA) é algo que afeta todo o site, precisa ver se realmente vai ter ganho em gastar esforços por uma otimização prematura, e se for pra melhorar, que a melhoria seja para o projeto inteiro (e claro, levando em conta o gasto também).

[eliseumds]

Com SVG embedded você quer dizer usar a tag <use> pra evitar repetição? Vale a pena se eles tiverem muitas cores e precisarem ser manipulados (além de fill). No nosso projeto, a maioria dos ícones são monotone e repetidos muitas vezes em várias partes, e descobrimos que usar icon fonts trouxe uma considerável melhora de performance. Mas como o @ninetails falou... vc precisa mesmo otimizar essa parte?

[espudaro]

Vlw @ninetails seu ponto foi muito importante. Estava fazendo via sprite, mas realmente a adição de novos departamentos seria mais chato fazer.

[espudaro]

@eliseumds em um outro projeto, usei icones via fonts e não curti muito, o ícone fica quadriculado □ quando a font ainda não foi carregada.

[eliseumds]

@espudaro há formas de melhorar a experiência, por ex, com font-display: block;, ou usando Base64 Data URIs pra carregar mais rápido. Os trade-offs foram worth it pra gente.

Obs: não use Data URIs se o seu app renderizar num outro domínio, como widgets, por causa de Content Security Policy.

[espudaro]

@eliseumds muito interessante o controle de renderização do font-display, não conhecia! para alguém como eu, fica um link bacana.
Agora o Base64, já usei, mas iria cair no msm problema quando fosse dar manutenção em algum ícone ou simplesmente add um ícone novo.