O Otimizador SVG (SVGO) é uma ferramenta de código aberto popular usada para reduzir arquivos SVG. Ele funciona “removendo com segurança os metadados do editor, comentários, elementos ocultos [e] valores padrão ou não ideais”. Olhando para os Números de dependência do Github , SVGO é uma ferramenta amplamente usada em 4,6 milhões de repositórios. Para referência, React é usado em 7 milhões de repositórios.
SVGO é um projeto bem mantido que, na maioria dos casos, irá remover todos os caracteres desnecessários que pode com segurança. No entanto, por mais que ajude a reduzir o peso da página, o que importa em última análise é se pode ou não fazer uma diferença visível no desempenho. É exatamente por isso que Lighthouse prioriza métricas como primeira pintura significativa (FMP) , primeiro pintura com conteúdo (FCP) e pintura com maior conteúdo (LCP) , em vez do tamanho dos ativos estáticos e do número de solicitações.
A pergunta que precisamos fazer é: o SVGO realmente causa um impacto visível no desempenho? Vejamos os detalhes.
Quantos bytes o SVGO pode salvar?
O número de bytes salvos pelo SVGO depende muito do arquivo que está sendo minimizado e de como foi criado. Em alguns casos, pode reduzir o tamanho do arquivo em uma porcentagem baixa de um dígito e, em alguns casos, o número pode chegar a 90 por cento. É especialmente eficaz contra arquivos vetoriais criados com ferramentas como Sketch e Adobe Illustrator que têm valores, espaços, nomes longos e comentários muito precisos.
Para colocá-lo à prova, tentei SVGO em vários pacotes SVG e comparou seus tamanhos de arquivo antes e depois de minimizar sob os padrões padrão de SVGO. Se estiver interessado, você pode visualizar os dados brutos de minha análise .
Flagkit
Flagkit é um ícone SVG-conjunto de bandeiras do país criado com Sketch. Como dissemos anteriormente, o SVGO é muito eficaz contra arquivos exportados com esta ferramenta.
Depois de executar o SVGO em todos os ícones do conjunto, veja como fica a distribuição das porcentagens de compressão:
Distribuição de compressão percentagens para Flagkit
Em média, o SVGO reduziu o tamanho do arquivo em 54,8 por cento. Cumulativamente, para todos os arquivos, ele economizou cerca de 446 KB, ou 56 por cento. Se fôssemos usar todos os ícones do FlagKit em nosso aplicativo, economizaríamos um pouco menos de meio megabyte com SVGO.
Ilustrações
Vamos fazer uma análise semelhante em algo maior. Illlustrations é um lindo pacote de ilustrações SVG desenvolvido por Vijay Verma no Adobe Illustrator.
Distribuição de porcentagens de compressão em Illlustrations
A taxa de compressão é menos estelar quando comparada ao Flagkit, mas isso é esperado porque o SVG os arquivos neste pacote são muito maiores. Nesse caso, o SVGO economizou cerca de 24,2% em média e cumulativamente, 824kB ou 23,7%.
Mapa mundial (HD)
Finalmente, vamos tentar um único arquivo SVG grande. Um mapa vetorial HD do mundo de amCharts tem cerca de 1,3 MB de tamanho.
Aqui, o SVGO reduziu o tamanho do arquivo para 880kB, economizando cerca de 420kB, ou 31,5 por cento.
Em resumo
A economia entre os pacotes não minimizados e minimizados chegou a:
FlagKit: Unminified=793kB Minified=346kB Poupança=447kB Illlustrations: Unminified=3.4MB Minified=2.6MB Savings=805kB World Map: Unminified=1.3MB Minificado=880kB Economia=420kB
Componente ausente: compactação
Você deve ter notado que está faltando uma etapa importante acima: compactação. A maioria dos ativos estáticos e páginas HTML na Internet são entregues usando compactação GZIP. O algoritmo brotli mais eficiente já é usado por 30 por cento dos sites , de acordo com W3 Techs. Ambos os algoritmos de compactação são capazes de reduzir significativamente o tamanho do ativo estático.
Devemos, portanto, comparar os tamanhos de arquivo antes e depois da compactação. Nesta seção, verificarei o tamanho dos pacotes minimizados e não minimizados quando atendidos por meio do Cloudflare CDN.
Observação: com base em minhas observações, o Cloudflare CDN usa compactação Brotli nível 3 por padrão, que é inferior em comparação com a compactação máxima de nível 11, mas ainda é bom o suficiente para testar os tamanhos finais dos arquivos. Se o seu CDN usar a melhor compactação disponível, a diferença no tamanho seria ainda menor.
Aqui está a diferença entre o tamanho dos pacotes pós-compactação (usei a ferramenta brotli-size-cli ):
Flagkit: Unminified + brotli-3=127kB Minificado + brotli-3=55kB Economia=72kB Ilustrações: Não Minificado + brotli-3=592kB Minificado + brotli-3=470kB Economia=122kB Mapa Mundial: Não Minificado + brotli-3=503kB Minificado + Brotli-3=370kB Economia=132kB
Como podemos ver, a diferença de tamanho é muito maior. Agora vamos ver o que isso significa no contexto de desempenho da web.
Testando nossas descobertas no aplicativo
Para nosso experimento, tentaremos carregar todos esses arquivos de uma vez e veja como esse delta é significativo.
Usei svg-sprite para agrupar todos os nossos SVGs como sprites CSS para evitar que várias solicitações afetem os dados de velocidade. Eu carreguei os sprites como um pacote npm chamado test-svgo e usei o unpkg.com CDN para atendê-los. Portanto, todos os arquivos foram testados por meio do Cloudflare CDN, semelhante a como você serviria arquivos em uma configuração de produção.
Para suas auditorias de desempenho, o Google Lighthouse, sem dúvida a ferramenta de pontuação de desempenho mais popular, usa uma conexão regulada de 1,6 Mbps ↑/750Kbps ↓ , que representa os 25 por cento inferiores de 4G e os 25 por cento principais das conexões 3G. Isso é equivalente ao modo Fast 3G no Google Chrome DevTools. Testei todos os três pacotes no mesmo modo e observei o tempo que levou para baixá-los. Aqui estão os resultados:
Flagkit: Unminified + brotli-3=700ms Minified + brotli-3=309ms Poupança=400ms Illlustrations: Unminified + brotli-3=3,28s Minified + brotli-3=2.94s Poupança=620ms Mapa mundial: Unminified + brotli-3=2.78 Minified + brotli-3=2.05s Poupança=730ms
A diferença aqui é suficientemente significativa para causar um impacto? Sim, ele é! No entanto, existem grandes advertências para isso.
Advertência 1: SVG não bloqueia a renderização
Imagens SVG geralmente são recursos não bloqueadores, a menos que você as tenha embutido em seu CSS. Ao contrário do CSS e, geralmente, do JS, eles não bloquearão a renderização da página e podem ser carregados em paralelo.
Google Lighthouse prioriza amplamente as métricas relacionadas às interações do usuário.
Gráfico de métricas extraído do Página do relatório de desempenho do Google Lighthouse
Portanto, a prioridade deve ser fazer a primeira renderização o mais rápido possível e, em seguida, carregar sequencialmente todo o resto da página.
Por esta definição , descobrir o que precisa ser renderizado primeiro e priorizar esses recursos é uma maneira muito melhor de melhorar o desempenho do que a otimização de SVG. A otimização de SVGs faria uma diferença real apenas se ambos fossem grandes em tamanho e absolutamente precisassem ser carregados na primeira dobra.
Advertência 2: o agrupamento geralmente não é preferível
Sim, é era verdade na era do HTTP1.1 que o empacotamento era a melhor maneira de melhorar o desempenho, mas com o HTTP2, a sobrecarga de uma solicitação significativamente reduzido . Ao agrupar SVGs, você também carrega arquivos que não são necessários imediatamente.
Dê uma olhada nessas duas páginas de amostra do projeto test-svgo, página A e página B . A página A carrega as ilustrações usando um pacote, enquanto a página B as carrega diretamente. A página A é melhor para carregá-los todos de uma vez, mas a página B começa a renderizar as ilustrações muito mais rápido-proporcionando uma melhor experiência do usuário.
Nos pacotes que criamos, a minificação criou uma diferença significativa, mas com mais frequência do que não, queremos usar nossos arquivos individualmente e, quando carregados individualmente, a minificação dificilmente prejudica o desempenho. Você pode ver isso por si mesmo em minificado e versões não minimizadas do mesmas páginas que acabamos de ver.
Advertência 3: é raro alguém precisar de tantos SVGs em uma única página
Fizemos nossos testes presumindo que teremos que carregar muitos arquivos (ou um grande) para testar as capacidades do SVGO. É possível que você tenha várias ilustrações grandes na página e o uso de SVGO pode fazer a diferença, mas na maioria dos casos, esses SVGs tendem a ser ícones, logotipos e ilustrações simples.
Vão de 1,2 MB para 880kB é significativo, mas ir de 2kB para 1,2kB não faz muita diferença, mesmo se você tiver dezenas de ícones na página. Isso ocorre porque, na forma agregada, a economia seria bem menor, mesmo se o SVGO reduzisse em 50 por cento.
Conclusão
O SVGO é uma ótima ferramenta que pode reduzir significativamente o tamanho de arquivos SVG , mas a economia costuma ser limitada porque os arquivos SVG costumam ser minúsculos-e diferentes de carregamento imagens em CSS ou JS, que podem bloquear a renderização da página, SVGs podem carregar em paralelo.
SVGO faz sentido para arquivos muito grandes, como o mapa-múndi que testamos neste artigo, mas se você tiver Se tiver um número limitado de SVGs menores em sua página, o SVGO não aumentará seu desempenho. Além disso, se você precisar de vários SVGs, é provável que não precise carregá-los todos imediatamente.
Um impacto maior no desempenho pode ser impulsionado por pensar cuidadosamente sobre quais recursos precisam ser renderizados primeiro.
Outro caso contra o SVGO é seu impacto na manutenção. Se você mantém dois conjuntos de SVGs, isso é ótimo. Mas se você estiver executando o SVGO em todos os seus arquivos, será mais difícil fazer coisas simples como modificar preenchimentos e traços.
No geral, não devemos nos preocupar em economizar kilobytes se acabarmos perdendo de vista o quadro geral-as métricas que realmente importam, como FMP, FCP e LCP. Para concluir, na maioria dos casos, minimizar SVGs não deve ser uma prioridade ao otimizar o desempenho.
