Reduza o trabalho de fontes que cada rota pede ao navegador
Faça o inventário das requisições de fonte com cache frio na página inicial, páginas de conversão, vistas autenticadas e templates com diferentes sistemas de design. Anote a família, peso, estilo, arquivo, origem, tamanho transferido e seletor. Uma regra @font-face declarada por si só não aciona download; um navegador normalmente busca uma face quando o layout atual a usa. Isso torna pesos e estilos globais não usados um bom alvo de remoção inicial.
Use tipografia customizada onde ela carrega valor real de marca, frequentemente em headings display, e considere uma pilha de fontes do sistema para o corpo quando o design permitir. Não presuma que uma fonte variável seja sempre menor: ela pode substituir vários arquivos estáticos, mas pode ser maior que uma face estática isolada. Compare os ativos comprimidos efetivamente solicitados pela rota.
Remova famílias, pesos, itálicos e fontes de ícones que não têm uso testado a nível de rota.
Verifique que a licença permite entrega web, subsetting e self-hosting antes de alterar o build.
Use WOFF2 e faça subsetting sem remover caracteres necessários
Comece com WOFF2 como baseline para navegadores modernos. A Recomendação do W3C descreve o WOFF2 como um pacote de fonte para web projetado para compressão melhorada e descompressão rápida, e ele é implementado nos principais navegadores. Mantenha outro formato apenas para um requisito documentado de navegadores legados; caso contrário, um fallback bem planejado é o caminho de compatibilidade mais seguro.
Subsetting cria um arquivo menor contendo glifos selecionados, ou formas de caracteres. unicode-range pode associar subsets a intervalos de caracteres para que o navegador escolha um arquivo relevante enquanto faz o match com o texto. Construa subsets a partir de páginas reais e dos idiomas que você suporta, incluindo pontuação, moedas, nomes, texto legal e scripts inseridos por usuários. Glifos ausentes são um problema de correção, não uma economia de bytes aceitável.
Teste páginas localizadas representativas e entradas de formulário, não apenas amostras de design em inglês.
Garanta que unicode-range e o intervalo de peso/estilo de cada subset correspondam ao arquivo implantado.
Projete o fallback e a política font-display juntos
Uma fonte fallback é o que os usuários veem quando a face customizada não está pronta. Escolha-a por proporções semelhantes e compare headings reais, botões multiline, navegação, tabelas, formulários e strings localizadas longas. Larguras diferentes mudam quebras de linha; ascent, descent ou line-gap diferentes mudam a altura de blocos. Ambos podem mover conteúdo já visível na página.
font-display define o comportamento de renderização enquanto uma face está indisponível. optional tem um período de block extremamente curto e nenhum período de swap, então pode servir para texto de corpo quando um fallback estável for preferível na primeira visita. swap mostra o fallback prontamente e pode depois aplicar a fonte web, mas use-o apenas onde uma substituição tardia não causará reflow disruptivo. Block ou fallback devem servir a uma razão de design testada, não ser um padrão global. CSS size-adjust pode ajudar a ajustar métricas do fallback, mas verifique visualmente cada script e viewport suportados.
Não faça texto de pagamento, recuperação, conta, segurança ou navegação depender de uma fonte customizada tardia.
Uma letra fallback pode transmitir o significado errado; ícones SVG são geralmente mais seguros para símbolos de interface.
Melhore a descoberta, mas contenha preload e avalie o fluxo de dados
Uma face declarada apenas em uma stylesheet externa pode ser descoberta depois que essa stylesheet fizer download e parsing. CSS crítico inicial manutenível pode expor uma declaração necessária mais cedo; não inliner o binário da fonte, o que aumenta o documento. Para uma origem de terceiros, preconnect pode estabelecer a conexão mais cedo. Requisições de fontes são recursos CORS, então entrega cross-origin e preloads exigem tratamento crossorigin correto.
Preload é uma sobreposição de prioridade, não um interruptor global de velocidade. Pode competir com outros trabalhos críticos e pode baixar uma face que uma rota nunca precisa; também contorna a seleção por unicode-range. Corrija descoberta tardia primeiro, então preloade no máximo um arquivo comprovado de primeira-visualização usando a URL exata, as=font e crossorigin. Google Fonts informa que as requisições da API incluem o endereço IP do visitante, URL solicitada, headers HTTP e referer; também informa que sua API não define nem registra cookies e não usa a informação coletada para perfis ou publicidade direcionada. Self-hosting impede que o Google receba dados dessas cargas. Avalie entrega, aviso de privacidade, jurisdição, contratos e obtenha aconselhamento qualificado quando necessário.
Compare traces com cache frio e confirme que o arquivo preloaded é consumido na rota.
Pese estabelecimento de conexão, capacidade de cache e CDN, manutenção de ativos e fluxo de dados do visitante.
Versione ativos de fonte e retenha uma configuração de CSS fallback testada.
Teste comportamento renderizado e opere fontes como uma dependência de resiliência
Com cache frio, use as ferramentas de rede do navegador para inspecionar a cadeia CSS→requisição de fonte, tempos, origem, cache e falhas. Repita em conexão controlada e então limite ou bloqueie a fonte. Sucesso significa texto legível, controles utilizáveis, símbolos corretos e layout coerente antes da face customizada aparecer. Teste layouts realistas estreitos e desktop, strings longas, erros, texto de consentimento, preços e cada script suportado.
No Chromium, registre um reload no painel Performance e inspecione a trilha Layout Shifts; o DevTools pode identificar elementos movidos e animar o shift. Carregamento de fontes é um culpado conhecido, mas um elemento movido não é necessariamente a causa raiz, então correlacione o trace com a aplicação da fonte. A Layout Instability API é exclusiva do Chromium, o que torna verificações visuais entre navegadores importantes. Inclua ativos de fonte, comportamento CORS, política de cache, fallbacks e rollback na revisão de release. O modo degradado pretendido é texto legível, não conteúdo em branco ou navegação quebrada.
Um cache aquecido pode ocultar a requisição inicial e o problema de renderização.
Repita a checagem quando arquivos, CMS, templates, provedores ou regras de CDN mudarem.