Gerador de incorporação Base64 para WOFF2 | Uma requisição HTTP de fonte a menos
Uma fonte web auto-hospedada carregada como um arquivo .woff2 separado dispara uma requisição HTTP extra depois do processamento do CSS. É exatamente nesse intervalo, entre o fim do parsing do CSS e a chegada da fonte, que aparece o FOUT (Flash of Unstyled Text). Incorporar a fonte como Data URI em base64 dentro do @font-face fecha os dois problemas: o navegador já tem a fonte em mãos no momento em que a regra é avaliada.
Esta ferramenta codifica o .woff2 em base64 no navegador, deixa você ajustar font-family, font-weight, font-style e font-display, e gera um bloco @font-face pronto para colar com src: url(data:font/woff2;base64,…) format('woff2'). Acima da saída fica o resumo de tamanho original versus base64 para tornar o custo da inflação visível, com um aviso quando o arquivo passa de 100 KB.
💡 Sobre esta ferramenta
Por que embutir a fonte em vez de servir por CDN? Por muito tempo Google Fonts era a resposta padrão no mercado brasileiro. Em janeiro de 2022, o Tribunal Regional de Munique decidiu (LG München I, Az. 3 O 17493/20) que carregar Google Fonts a partir de um domínio europeu transmitia o IP do visitante a um terceiro nos EUA, em violação do RGPD; por aqui a discussão sobre privacidade no carregamento de fontes externas reapareceu sob a ótica da LGPD. Resultado: muitas equipes migraram para auto-hospedagem — o que reintroduz a requisição HTTP extra. Essa é exatamente a requisição que o base64 inline remove sem abrir mão da auto-hospedagem.
O caminho manual seria rodar base64 -i fonte.woff2 na linha de comando, colar o resultado num bloco @font-face, e montar à mão a URL src com format('woff2'). Funciona uma vez, mas o ciclo se repete sempre que a fonte, o nome font-family ou alguma das quatro propriedades font-* muda. A ferramenta automatiza esse ciclo. Aspas simples no nome font-family são escapadas automaticamente, então nomes como 'JetBrains Mono' ou 'IBM Plex Sans Var' colam sem quebrar a sintaxe.
🧐 Perguntas frequentes
Q. Quando é melhor NÃO incorporar um .woff2?
A. Acima de uns 100 KB brutos, a incorporação começa a prejudicar o First Contentful Paint em vez de ajudar: o bundle de CSS incha e passa ele próprio a bloquear o render. A ferramenta avisa ao passar de 100 KB. Para fontes maiores, é preciso fazer subset com unicode-range (remover glifos que você não usa) ou manter uma referência url() externa com preload.
Q. Por que o base64 aumenta ~33% no tamanho?
A. O base64 usa 4 bytes ASCII para representar cada 3 bytes binários (6 bits por caractere × 4 = 24 bits = 3 bytes). Pelo cabo, a compressão Brotli ou gzip sobre o bundle CSS recupera quase toda a inflação — normalmente sobram 10–15% de overhead líquido após compressão — mas a carga sem compressão continua maior que o .woff2 binário.
Q. Qual valor de font-display usar?
A. Para corpo de texto e títulos, swap é a escolha segura padrão: uma fonte de fallback aparece imediatamente e é substituída quando a web font chega. Para fontes de ícone, prefira block (curto período de bloqueio, depois fallback). Para títulos decorativos onde uma chegada tardia é pior do que não carregar, optional autoriza o navegador a desistir se a fonte perder um orçamento de uns 100 ms.
Q. Como lidar com variantes (negrito, itálico)?
A. Gere um bloco @font-face separado para cada arquivo .woff2, mantenha o mesmo nome font-family em todos, e varie apenas font-weight e font-style. O navegador escolherá o correto quando o CSS pedir font-weight: 700 ou font-style: italic. Para uma fonte variável que embute vários pesos num único .woff2, escreva um único bloco com font-weight: 100 900 (sintaxe de intervalo).
Q. A fonte incorporada é cacheada separadamente?
A. Não — ela fica embutida dentro do arquivo CSS, então compartilha a vida útil de cache do CSS. Se você faz deploy de CSS com frequência e a fonte muda pouco, uma referência url() externa com Cache-Control longo pode render mais em visitas repetidas. A incorporação brilha no primeiro paint para visitantes com cache frio.
Q. format('woff2') é obrigatório no src:?
A. Não estritamente, em sites 100% WOFF2, mas ele permite ao navegador pular o Data URI caso .woff2 não fosse suportado (praticamente nenhum navegador moderno hoje, mas a dica é inofensiva e a ferramenta a gera).
📚 Curiosidades
Os formatos de fonte web evoluíram na sequência .eot → .ttf → .woff → .woff2, e a versão 2.0 usa compressão classe Brotli, o que a deixa cerca de 30% menor que .woff para o mesmo conjunto de glifos. O Web Open Font Format 2.0 alcançou o status de W3C Recommendation em março de 2018, e desde o fim de 2022 é o único formato necessário — a Microsoft removeu o IE11 do Microsoft 365 em agosto de 2021, e todos os outros navegadores suportam .woff2 desde 2015.
O truque de Data URI base64 para fontes é anterior ao próprio .woff2. Rascunhos de CSS3 de 2009 já descreviam src: url(data:application/x-font-ttf;base64,…) para .ttf, e kits pioneiros de icon-fonts como o Fontello já ofereciam desde o primeiro dia uma opção de download "base64 dentro do CSS". O que mudou com .woff2 foi o orçamento de tamanho: pesando um terço de um .ttf, incorporar uma fonte de corpo finalmente passou a ser razoável em vez de absurdo.