Ferramentas de desenvolvedor · Codificador e decodificador Base64
Imagens Base64 inline em CSS: quando os dados: URIs ajudam e quando prejudicam
· Por que é importante
base64 desempenho
Incorporar uma imagem como dados Base64: URI remove uma solicitação, mas aumenta o arquivo e anula o cache. Esta postagem explica quando a negociação vale a pena e quando um arquivo separado é mais rápido.
A folha de estilo que cresceu para centenas de kilobytes — o hábito de inlining de uma equipe e como ele apareceu nos tempos de carregamento
Uma equipe de desenvolvimento decidiu que incorporar pequenos ícones como dados Base64: URIs em seu CSS reduziria as solicitações HTTP e melhoraria a velocidade de carregamento da página. Com o tempo, à medida que mais ícones foram adicionados, a folha de estilo cresceu para 400 kilobytes.
O pacote CSS, que deveria conter regras de estilo, agora é dominado por dados de imagem. A equipe mediu o tempo de carregamento e descobriu que a página estava mais lenta do que antes do inlining, e não mais rápida. O problema ficou claro: a folha de estilo 400-kilobyte é baixada a cada carregamento de página e armazenada em cache por página, enquanto que se os ícones fossem arquivos separados, um único arquivo de ícone seria armazenado em cache e compartilhado em cada página.
Que dados: URI inlines e por que é Base64 — a sintaxe, o tipo de mídia e a penalidade de tamanho
Adicionar mais páginas ao site piorou o problema, já que cada página baixa novamente a mesma folha de estilo com todas as imagens embutidas. Esta postagem explica o que é data: URI, por que é Base64, como o inlining afeta o cache e o desempenho e as regras básicas para decidir quando vale a pena compensar. Um dado: URL é uma forma de incorporar um recurso diretamente em um arquivo HTML ou CSS em vez de vincular a um arquivo externo. A sintaxe é data:mediaType;base64,encoded_bytes.
O mediaType declara que tipo de recurso segue, como image/svg+xml para SVG, image/png para PNG ou text/plain para texto. O sinalizador ;base64 indica que a carga útil é codificada em Base64 em vez de texto codificado em porcentagem. Os encoded_bytes são os dados reais. Quando um navegador encontra dados: URL em uma propriedade href, src ou background-image, ele decodifica o Base64 e renderiza o recurso embutido. Nenhuma solicitação HTTP acontece porque o recurso já está lá, incorporado no documento pai. Isso salva uma ou algumas solicitações HTTP, o que é importante em um mundo HTTP/1.1 onde cada solicitação tem sobrecarga.
Cache e o caminho crítico — por que os bytes embutidos são baixados novamente com cada página que inclui a folha de estilo
Em um mundo HTTP/2 ou HTTP/3 onde muitas solicitações podem ser multiplexadas em uma conexão, as economias são menores. A penalidade de tamanho da codificação Base64 é imediata e significativa. Um ícone SVG que tem 3 quilobytes quando salvo como um arquivo XML se torna 4 quilobytes quando codificado em Base64 e incorporado como dados: URI. O aumento de 33% no tamanho da codificação deve ser adicionado a cada página que inclui a folha de estilo. Se o ícone for usado em dez páginas, a folha de estilo será baixada dez vezes, cada vez incluindo a mesma imagem codificada de 4-kilobyte.
Se o ícone fosse um arquivo separado, o original de 3-kilobyte seria baixado uma vez e armazenado em cache, e então usado no cache em todas as dez páginas. A escolha econômica é clara para a maioria dos ícones: arquivos separados são menores no geral. O benefício inlining se aplica apenas quando um ícone é usado em exatamente uma página ou em muito poucas páginas, e o ícone é genuinamente crítico para essa página. Um favicon que aparece em todas as páginas é um mau candidato para inlining; é melhor como um arquivo em cache separado.
Custos de análise no cliente — quão grandes strings inline são tratadas pelos analisadores CSS e HTML, descritos qualitativamente
Uma ilustração única usada apenas em uma página de destino pode se beneficiar do inlining para salvar uma solicitação. O cache anula a maioria dos benefícios dos dados embutidos: URIs em folhas de estilo. Uma folha de estilo normalmente fica armazenada em cache por dias ou semanas. Quando a folha de estilo é baixada, todos os recursos embutidos nela são baixados novamente, mesmo que o navegador já tenha essa imagem armazenada em cache. Se a folha de estilo for atualizada, todos os dados embutidos deverão ser revalidados ou baixados novamente, mesmo que apenas uma regra CSS tenha sido alterada.
Isso causa inchaço: alterações nas cores ou no espaçamento acionam um novo download completo da folha de estilo, incluindo kilobytes de dados de imagem que não foram alterados. Um arquivo de imagem separado pode ser armazenado em cache de forma independente com seus próprios cabeçalhos de expiração, atualizado separadamente e reutilizado em folhas de estilo e páginas. O cache do navegador é muito mais eficiente quando os recursos são arquivos separados do que quando estão incorporados em documentos maiores. Os custos de análise e renderização aumentam quando grandes strings Base64 são incorporadas em folhas de estilo. Um analisador CSS deve ler toda a folha de estilo antes de aplicar as regras.
Exemplo resolvido: incorporar um pequeno ícone SVG como texto - colar a marcação no codificador e montar os dados: URI manualmente
Uma folha de estilo de 400 quilobyte com Base64 embutido tem 400 quilobytes de texto que deve ser analisado antes que qualquer regra possa ser aplicada. Um analisador HTML que renderiza uma página com dados grandes: URI em um atributo de estilo ou uma propriedade de imagem de fundo deve decodificar o Base64 e construir a imagem antes que o elemento possa ser renderizado. Para ícones SVG simples, isso é trivial. Para imagens mais complexas ou ícones maiores, a decodificação e a renderização acontecem no thread principal, potencialmente bloqueando a interatividade. O custo qualitativo é real, mas difícil de medir sem traçar um perfil.
Como regra, se a imagem embutida for maior que alguns kilobytes, os arquivos separados serão mais rápidos. Um exemplo prático mostra a compensação exata. Pegue um simples ícone de seta SVG, 1.2 kilobytes de XML. Codificado em Base64, ele se torna 1600 caracteres ou cerca de 1.6 kilobytes com o prefixo data: URL. Uma regra CSS separada com imagem de fundo: url(/icons/arrow.svg) adiciona talvez 40 bytes à folha de estilo. O arquivo de ícone é baixado uma vez, armazenado em cache e reutilizado. Inlining salva uma solicitação HTTP para aquele ícone, mas adiciona 1.6 kilobytes a cada carregamento de folha de estilo.
Regras práticas que se mantêm – ativos minúsculos, críticos e de uso único em linha; todo o resto como um arquivo
Se a folha de estilo tiver 50 quilobytes e for compartilhada em 20 páginas, inserir esse ícone aumentará o download total em 32 quilobytes por visita ao site. A solicitação HTTP salva tem no máximo algumas centenas de bytes de sobrecarga. A solicitação também é multiplexada automaticamente em HTTP/2, eliminando a diferença de sobrecarga. A negociação inlining perde muito, a menos que a folha de estilo seja pequena, o ícone seja enorme ou o ícone apareça exatamente em uma página e em nenhum outro lugar. As regras práticas que sobrevivem ao escrutínio são limitadas e específicas.
Ativos minúsculos, críticos e de uso único podem ser incorporados. Uma seta 200 byte SVG que aparece apenas em uma página incomum pode ser incorporada para economizar a sobrecarga da solicitação. Todo o resto deve ser separado. A lógica crítica do caminho de renderização é importante: se um ícone precisar ficar visível imediatamente e cada milissegundo de tempo de carregamento custar conversão, o inlining pode vencer. Para páginas típicas com ícones típicos, arquivos separados são quase sempre melhores. Teste ambas as abordagens com seus ativos reais e meça o carregamento da página, as taxas de acerto do cache e a cascata de solicitações.
O que isso não cobre - HTTP/2 e HTTP/3 detalhes de multiplexação e compactação de formato de imagem
Não presuma que o inlining é uma otimização sem medição. A maneira mais fácil de acabar com uma folha de estilo inchada é inline gradativamente, sem medir se cada adição é realmente mais rápida. O codificador e decodificador Base64 ajuda você a tomar essa decisão antes de se comprometer com o inlining. Cole sua marcação SVG ou outra fonte de ícone na ferramenta como texto. Clique em Codificar e defina as opções para gerar dados: URI. A ferramenta mostra o comprimento exato dos dados: URL. Compare isso com o tamanho de uma regra CSS separada e do próprio arquivo de ativos.
Calcule quantas páginas seriam necessárias para comcomcompartilhar a folha de estilo para equilibrar o inlining versus arquivos separados. Reúna os dados: URI e teste-os em uma página HTML real antes de enviá-los para a folha de estilo. Se URI tiver mais de algumas centenas de caracteres, o custo da incorporação será provavelmente maior do que o benefício de salvar uma solicitação. Use a ferramenta para testar seus ícones e ativos reais e, em seguida, meça o impacto nas métricas reais de carregamento da página antes e depois do inlining.
Conclusão: inline com moderação e meça - como o codificador e decodificador Base64 permite codificar a marcação SVG e ver o tamanho exato antes de confirmar
A abordagem de desempenho é ser seletivo quanto ao inlining. Os ícones usados em todas as páginas ou em muitas páginas são arquivos separados em cache. Ícones usados em exatamente uma página ou verdadeiramente críticos para a primeira pintura podem ser incorporados. Meça a compensação para seus ativos e páginas reais, em vez de seguir conselhos genéricos. Use o codificador e decodificador Base64 para ver o tamanho exato de qualquer ativo embutido antes de adicioná-lo a uma folha de estilo. A penalidade de tamanho é real e se multiplica a cada visualização de página.
O cache e a multiplexação de solicitações tornaram o benefício original do inlining menos importante. Para a maioria dos aplicativos modernos, folhas de estilo menores e melhor eficiência de cache de arquivos separados compensam a sobrecarga da solicitação. Inline com moderação, meça o resultado e confie na medição em vez da intuição.