Como funciona o sourcing de fontes para projetos web e os problemas que ninguém conta
Vim direto ao assunto porque tenho pouco tempo. O tema é prático: fontes visuais, o que são, como baixar, instalar e, principalmente, onde elas travam no dia a dia.
O que é fonte visual e por que isso importa no seu fluxo de trabalho
Fonte visual é qualquer arquivo tipográfico que você pode carregar e usar em um projeto — seja em código, em design ou na impressão. Não é um conceito avançado, mas a forma como você lida com ele determina se seu trabalho leva 10 minutos ou duas horas. A diferença entre ter uma fonte da internet e ter uma fonte que realmente funciona no projeto é pequena na teoria e enorme na prática. Quando eu comecei a mexer com isso, achava que era só pegar o arquivo TTF e colocar no projeto. Errado. Na maioria das vezes, o problema não está na fonte em si, mas na forma como ela é servida, na variabilidade de pesos e na compatibilidade entre plataformas.
Agora vou explicar o que é fonte visual de verdade, sem rodeios. Fonte visual é basicamente um arquivo com a coleção completa de glifos de uma família tipográfica. Pode estar em formato OTF, TTF, WOFF ou WOFF2. Cada formato tem um uso específico. WOFF2 é o padrão atual para web. OTF e TTF são mais comuns para design gráfico e impressão. Se você está montando um site, vai usar WOFF2. Se está preparando um PDF para impressão, vai usar OTF.
Como baixar fontes visuais de forma segura e correta
Existem três caminhos principais. O primeiro é usar repositórios gratuitos como o Google Fonts, Fontshare e a biblioteca aberta do Google. O segundo é sites como Behance, Dribbble e o forum de tipografia do Creative Market. O terceiro é comprar licenças diretamente dos foundries, como a Typotheque, House Industries ou Indian Type Foundry. O download em si é trivial. O problema é saber o que fazer depois. Eu já vi gente baixar uma fonte, extrair os arquivos e simplesmente jogar tudo numa pasta do projeto sem verificar se os formatos estão corretos. Resultado: a fonte funciona no navegador de desenvolvimento mas quebra no celular de um cliente. A culpa nunca é da fonte. É da falta de variedade de formatos.
Para fazer isso direito, o fluxo é simples: Pegue o arquivo .ttf ou .otf original. Use uma ferramenta como o Transfonter ou o Font Squirrel Generator para converter para WOFF e WOFF2. Certifique-se de que pelo menos os pesos regular, bold e italic estejam presentes. Anexe cada variação no seu CSS com @font-face. Teste no Chrome, no Safari e no Firefox. Verifique se o fallback está configurado.
Se você está usando um framework como Next.js ou Vite, existe o plugin next/font ou o plugin vite-plugin-fonts que automatiza parte disso. Mas cuidado: a automação também esconde problemas. Eles costumam servir apenas WOFF2 e confiar no fallback nativo do navegador, o que pode falhar em IE11 ou em dispositivos mais antigos.
O erro que eu cometi e a solução que funcionou
Há dois anos atrás, fiz um projeto para um cliente que usava uma fonte chamada "DM Sans" com pesos variáveis. Baixei direto do Google Fonts, usei @import no CSS e tudo parecia funcionar. Dois dias depois, o cliente ligou dizendo que no iPhone a fonte aparecia completamente quebrada, com espaçamento absurdo entre as letras. Eu olhei o código, revirei o CSS, verifiquei o cache, desativei o minificador. Nada. Aí lembrei que o DM Sans tem um subconjunto latino padrão, mas o cliente usava caracteres especiais como cedilha e til que não estavam no subset padrão. O navegador simplesmente não carregava os glifos corretos e substitua por caracteres genéricos, gerando o espaçamento estranho.
👉 Clique no botão abaixo para saber mais sobre o assunto!
A solução foi simples, mas levou uma hora pra eu perceber: eu precisava adicionar o subset correto no @font-face, especificando o range de caracteres que a fonte realmente usaria. No final, o código ficou assim: @font-face { font-family: 'DM Sans'; font-style: normal; font-weight: 400; font-display: swap; src: url('/fonts/dm-sans-latin-ext.woff2') format('woff2'); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; }
Com o unicode-range ajustado, o navegador passou a carregar os glifos corretos e o problema sumiu. Aprendi que sempre verificar o subset de caracteres antes de aplicar uma fonte em produção.
Onde a coisa realmente quebra
Vou ser direto aqui. A maioria dos problemas com fontes visuais acontece por três motivos: Primeiro, layout shift. Quando a fonte não carrega a tempo, o texto aparece com a fonte padrão do sistema e depois troca repentinamente para a fonte desejada. Isso gera um movimento visível que incomoda o usuário e pode atrapalhar a acessibilidade. A solução é usar font-display: swap ou font-display: optional no @font-face, e medir o CLS com ferramentas como Lighthouse.
Segundo, performance. Arquivos de fonte podem pesar de 50KB a 5MB dependendo da família e dos pesos incluídos. Um site que carrega três fontes pesadas pode levar até três segundos a mais para exibir o conteúdo principal. A solução é usar apenas os pesos necessários, gerar variantes WOFF2 com subset otimizado e hostar a fonte no mesmo domínio do site para evitar DNS prefetch desnecessário. Terceiro, licenciamento. Muitas pessoas não percebem que uma fonte baixada gratuitamente para uso pessoal pode ter restrições para uso comercial. Já vi projetos inteiros sendo retirados do ar por problemas de licença. Sempre leia o termo de uso antes de usar qualquer fonte em um projeto que gere receita.
Insiights que aprendi na prática e que poucos mencionam
Um insight importante: fonte visual não é só sobre estética. Ela define o tempo de leitura, a hierarquia visual e até a percepção de confiança do usuário. Uma fonte ruim pode fazer um site de fintech parecer amador, enquanto uma fonte bem escolhida pode transmitir credibilidade instantânea. Eu já vi designers trocarem fontes inteiras apenas para melhorar a taxa de conversão de um checkout. Outro ponto: a maioria das pessoas não sabe que fontes variáveis são a tendência atual. Em vez de carregar cinco arquivos diferentes para cada peso (regular, light, medium, bold, black), você carrega um único arquivo que abrange todo o range de pesos. Isso reduz drasticamente o número de requisições HTTP e melhora a performance. O suporte a fontes variáveis no navegador já é amplo — Chrome, Firefox, Safari e Edge todos suportam desde 2021.
Porém, há um problema comum que eu vejo constantemente: desenvolvedores que usam fontes variáveis sem testar em dispositivos móveis mais antigos. O iOS 13 e o Android 10 têm suporte limitado a algumas propriedades de fontes variáveis. Se você não testar nesses dispositivos, pode ter fontes quebradas ou pesos incorretos em uma fatia significativa do seu público.
Alternativas quando fontes visuais tradicionais não funcionam
Se o problema de layout shift estiver crítico e você não conseguir resolver com font-display, existe a alternativa de usar SVG icons para caracteres específicos. Alguns desenvolvedores substituem caracteres especiais por ícones vetoriais, eliminando a dependência de fontes customizadas para esses casos. Não é elegante, mas funciona. Outra alternativa é usar a API @property do CSS para animações de fonte, que permite definir propriedades customizadas e animá-las de forma mais controlada. Isso é mais avançado, mas útil para projetos que precisam de transições suaves entre pesos de fonte.
Se nenhuma solução funcionar, o fallback mais seguro é usar uma fonte do sistema como fallback. As fontes do sistema são gratuitas, instantâneas e consistentes entre plataformas. Uma combinação como system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif cobre a maioria dos cenários com qualidade aceitável. O básico sobre o que é fonte visual já cobrimos. Agora resta aplicar com critério, testar em múltiplos dispositivos e não assumir que o que funciona no seu computador vai funcionar no do cliente.
