Como hospedar fontes localmente em vez de usar o Google Fonts

Porquê hospedar localmente o Google Fonts?

O Google Fonts tornou a boa tipografia fácil. Adicionar uma folha de estilos, escolher alguns pesos, publicar a página. Durante anos, essa foi a opção sensata para equipas pequenas.

A contrapartida é que o browser de cada visitante contacta um serviço de terceiros para obter o CSS das fontes e os ficheiros das fontes. Isso tem duas consequências.

Primeiro, acrescenta uma dependência externa à renderização. Se o CSS da fonte estiver lento, bloqueado ou indisponível na região ou rede do utilizador, a sua página espera ou recorre a uma alternativa.

Segundo, cria uma questão de privacidade. Um pedido de fonte pode revelar o endereço IP do utilizador, o user agent, o contexto da política de referenciador e informações de timing a um terceiro. O Google Fonts afirma que não define cookies através da Fonts API, mas “sem cookies” não é o mesmo que “sem dados pessoais”. Ao abrigo do RGPD, um endereço IP ainda pode ser dado pessoal em determinado contexto.

Hospedar fontes localmente não é automaticamente obrigatório para todos os websites, e isto não é aconselhamento jurídico. Mas para sites europeus, sites do setor público, saúde, educação, finanças ou qualquer equipa que tente reduzir pedidos desnecessários a terceiros, o alojamento local é normalmente a opção mais limpa.

Também é muitas vezes uma melhoria de desempenho quando bem feito. O ponto-chave é “bem feito”. Copiar seis ficheiros de fontes para /assets/fonts/ e carregá-los todos em todas as páginas pode ser pior do que usar o serviço alojado. Se quiser o contexto mais amplo de desempenho, o nosso artigo anterior sobre por que as fontes web continuam a ser a melhoria de desempenho mais fácil na maioria dos sites aborda os padrões comuns de desperdício.

O que muda quando hospeda localmente

Quando usa o Google Fonts da forma habitual, a sua página faz isto:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap" rel="stylesheet">

O browser primeiro pede CSS a fonts.googleapis.com e depois descarrega ficheiros de fontes de fonts.gstatic.com.

Quando hospeda localmente, a sua página deve pedir tanto o CSS como os ficheiros de fontes a partir do seu próprio domínio:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

Isto remove o pedido de fonte a terceiros. Também o torna responsável por escolher formatos de ficheiro, cabeçalhos de cache, fontes de fallback e atualizações.

Vale a pena levar essa responsabilidade a sério. As fontes ficam no caminho crítico de renderização. Uma configuração de fontes fraca pode causar texto invisível, deslocamentos de layout e uma primeira renderização lenta.

Passo 1: Audite o que realmente usa

Antes de descarregar qualquer coisa, liste as famílias de fontes, pesos, estilos e conjuntos de caracteres de que o seu site realmente precisa.

Um site típico de marketing pode precisar de:

• Regular 400 para texto corrido
• Semibold 600 ou bold 700 para títulos e botões
• Italic 400 apenas se o design usar realmente itálicos
• Apenas o conjunto de caracteres Latin, a menos que o site suporte mais idiomas

Desconfie de predefinições antigas de sistemas de design. Muitos sites carregam 300, 400, 500, 600, 700, itálicos e vários scripts porque alguém os selecionou uma vez num seletor de fontes.

No DevTools do browser, abra o painel Network, filtre por “font”, recarregue a página e verifique que ficheiros são pedidos. Depois inspecione o seu CSS para ver a utilização de font-weight. Se o seu CSS nunca usa 300, não hospede 300.

Se estiver a rever o impacto mais tarde, o Lighthouse pode ajudar, mas não trate a sua pontuação como a história completa. Use-o como ferramenta de diagnóstico, não como juiz. Temos um guia separado sobre como ler um relatório Lighthouse sem entrar em pânico que é útil ao priorizar correções de fontes.

Passo 2: Descarregue os ficheiros de fonte certos

O Google Fonts oferece fontes open-source. Pode descarregá-las a partir do website do Google Fonts ou do repositório do projeto da fonte em questão. Verifique a licença, mas a maioria das fontes do Google Fonts é distribuída sob licenças abertas, como a SIL Open Font License ou a Apache License.

Para a web, prefira WOFF2. É amplamente suportado por browsers modernos e normalmente é muito mais pequeno do que TTF ou OTF. Em 2026, servir TTF diretamente aos browsers raramente se justifica em websites públicos.

Uma estrutura de diretórios sensata tem este aspeto:

/public
  /fonts
    inter-latin-400.woff2
    inter-latin-600.woff2
    inter-latin-700.woff2

Use nomes de ficheiro descritivos. Seis meses depois, font.woff2 será irritante. inter-latin-600.woff2 é aborrecido e útil.

Se o seu site usa um sistema de build, mantenha as fontes de origem num local claro e deixe o pipeline de build copiar os ficheiros otimizados para o diretório de assets públicos.

Passo 3: Crie subconjuntos de fontes quando apropriado

Criar subconjuntos significa remover caracteres de que não precisa. Uma fonte completa pode incluir Latin, Cyrillic, Greek, Vietnamese, símbolos e muitos recursos OpenType. Se a sua landing page apenas em inglês precisa só de caracteres Latin, um subconjunto pode ser drasticamente mais pequeno.

Há duas abordagens comuns:

1. Usar um subconjunto pré-criado pelo fornecedor da fonte ou pelo repositório.
2. Gerar o seu próprio subconjunto com uma ferramenta de fontes como pyftsubset do fonttools.

Para muitas equipas, subconjuntos Latin pré-criados são suficientes. A criação de subconjuntos personalizados é útil quando tem páginas muito limitadas, como uma única página de campanha com texto restrito, ou uma interface de produto com cobertura de caracteres previsível.

Tenha cuidado com sites multilingues. Glifos em falta causam mistura de fontes de fallback, o que pode parecer avariado e prejudicar a legibilidade. Se suporta vários idiomas, associe subconjuntos de fontes a rotas de idioma em vez de impor um subconjunto minúsculo em todo o lado.

Passo 4: Escreva as suas regras @font-face

Uma configuração local mínima tem este aspeto:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-600.woff2") format("woff2");
  font-weight: 600;
  font-style: normal;
  font-display: swap;
}

body {
  font-family: "Inter", system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

Alguns detalhes importam aqui.

Use font-display: swap para a maioria dos sites de conteúdo. Isto indica ao browser para mostrar rapidamente o texto de fallback e depois trocar para a fonte web quando ela chegar. Assim evita a pior versão de FOIT: flash de texto invisível.

Defina uma pilha de fallback explícita. Se a fonte personalizada falhar, os utilizadores ainda devem obter texto legível. As alternativas não são um detalhe secundário; fazem parte do design. Se precisar de rever tamanhos, comprimento de linha e escolhas de texto corrido, comece com um guia prático para tipografia legível na web moderna.

Faça corresponder os pesos corretamente. Se o seu CSS pede font-weight: 500 mas só define 400 e 700, o browser pode sintetizar um peso intermédio. Isso nem sempre é terrível, mas pode parecer inconsistente.

Passo 5: Remova as chamadas externas ao Google Fonts

Depois de adicionar CSS de fontes locais, remova as chamadas remotas antigas dos seus templates.

Procure por:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?..." rel="stylesheet">

Verifique também:

• Definições de tema em plataformas CMS
• Painéis de tipografia de page builders
• Widgets de terceiros
• Gestores de tags
• Importações CSS antigas, como @import url('https://fonts.googleapis.com/...')

Este último caso é comum. CSS @import para fontes é normalmente pior para o desempenho porque atrasa a descoberta. Se hospedar localmente, defina as fontes diretamente no seu CSS principal ou num ficheiro CSS de fontes carregado cedo.

O trabalho de privacidade falha muitas vezes porque as equipas corrigem o template óbvio mas não veem scripts, widgets e embeds antigos. O mesmo padrão aparece no trabalho de consentimento; o nosso guia sobre o que mudou nos cookies em 2026 é um complemento útil se estiver a reduzir a superfície de terceiros de forma mais ampla.

Passo 6: Configure cabeçalhos de cache

Os ficheiros de fontes são assets estáticos. Devem ser colocados em cache de forma agressiva se os seus nomes de ficheiro forem versionados ou tiverem hash de conteúdo.

Um bom cabeçalho de produção é:

Cache-Control: public, max-age=31536000, immutable

Use caching imutável de longa duração apenas se o URL mudar quando o ficheiro mudar. Por exemplo:

inter-latin-400.a8f3c2.woff2

ou um caminho versionado:

/fonts/v2/inter-latin-400.woff2

Se substituir /fonts/inter-latin-400.woff2 sem alterar o URL, alguns utilizadores podem manter o ficheiro antigo durante muito tempo. Isso está bem até deixar de estar. O versionamento evita o problema.

Sirva também as fontes com o tipo MIME correto:

Content-Type: font/woff2

A maioria das plataformas de alojamento modernas trata disto automaticamente, mas vale a pena verificar.

Passo 7: Considere fazer preload apenas da fonte crítica

O preload pode ajudar o browser a descobrir mais cedo uma fonte importante:

<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin>

Use isto com moderação. Faça preload da fonte principal do texto above-the-fold, não de todos os pesos de fonte. Preload em excesso compete com CSS, imagens e JavaScript.

Mesmo para fontes same-origin, inclua crossorigin nos preloads de fontes. A obtenção de fontes usa modo CORS, e omiti-lo pode causar descarregamentos duplicados em algumas configurações.

Se não tiver a certeza, teste. Não copie preloads de forma acrítica só porque uma checklist o disse.

Passo 8: Teste privacidade e desempenho

Testar é simples.

Abra o DevTools, recarregue a página com a cache desativada e filtre o painel Network por:

• fonts.googleapis.com
• fonts.gstatic.com
• .woff2
• font

Deve ver ficheiros de fontes servidos a partir do seu próprio domínio e nenhum pedido ao Google Fonts.

Depois teste com cache fria e cache quente. Na primeira visita, as fontes devem descarregar uma vez. Em visitas posteriores, devem vir da cache de memória ou de disco, dependendo do browser.

Verifique se há deslocamento de layout quando a fonte é trocada. Se os títulos saltam, as métricas da sua fonte de fallback diferem demasiado da fonte web. Pode reduzir o deslocamento visível escolhendo uma alternativa mais próxima ou usando substituições mais recentes de métricas de fonte em CSS, como size-adjust, ascent-override, descent-override e line-gap-override. Estas opções são mais avançadas, mas úteis para interfaces polidas.

Por fim, teste páginas em navegação privada ou com bloqueadores de conteúdo ativados. Uma vantagem de hospedar localmente é que ferramentas de privacidade têm menor probabilidade de bloquear acidentalmente a sua tipografia.

Erros comuns a evitar

Hospedar demasiados pesos

Este é o erro mais comum. Dois pesos são muitas vezes suficientes. Três costumam chegar. Cinco é um sinal de alerta no sistema de design, a menos que tenha uma razão forte.

Esquecer itálicos

Se o seu conteúdo usa ênfase real, carregue um ficheiro itálico real. Itálicos sintéticos podem ter mau aspeto, especialmente em conteúdo editorial longo.

Manter o link antigo de CSS do Google

Isto anula o objetivo. Depois da migração, nenhum pedido de fonte deve ir para o Google, a menos que outro componente o esteja a injetar.

Servir fontes sem caching de longo prazo

Hospedar localmente dá-lhe controlo. Use-o. As fontes são candidatas ideais para tempos de cache longos.

Ignorar trabalho jurídico e de documentação

Se a sua política de privacidade mencionava anteriormente o Google Fonts ou o carregamento de fontes por terceiros, atualize-a depois da migração. Se mantém um inventário de tratamento de dados, atualize-o também. A alteração técnica e o registo de conformidade devem estar alinhados.

<!-- tool-cta:start -->

💡 Experimente isto: Converta os arquivos TTF que você baixou do Google Fonts em WOFF2 auto-hospedável mais CSS com Webfont Generator.

<!-- tool-cta:end -->

Uma checklist simples de migração

1. Liste as famílias de fontes, pesos, estilos e scripts que realmente usa.
2. Descarregue ficheiros WOFF2 e confirme a licença.
3. Crie subconjuntos de fontes se o site tiver necessidades linguísticas limitadas.
4. Adicione regras locais @font-face com font-display: swap.
5. Remova todas as referências link, preconnect e @import do Google Fonts.
6. Sirva fontes a partir do seu próprio domínio com cabeçalhos de cache de longa duração.
7. Faça preload apenas da fonte above-the-fold mais importante, se os testes o justificarem.
8. Verifique no DevTools que não restam pedidos ao Google Fonts.
9. Atualize a documentação de privacidade, se necessário.

Hospedar fontes localmente não é um trabalho glamoroso. É o tipo de pequena limpeza de infraestrutura que reduz o risco de dependências, melhora a postura de privacidade e lhe dá uma renderização mais previsível. Normalmente, isso vale a hora ou duas que demora.