Como revisar fontes web em sites criados por IA antes de publicar

Um site criado por IA pode importar seis pesos de duas famílias para renderizar um título, três parágrafos e um botão. Também pode depender de uma fonte externa que demora a responder, não cobre os acentos do português ou troca de métrica depois que a página já apareceu.

A tipografia continua bonita no computador do criador, mas o visitante recebe texto invisível, mudança de layout ou uma pilha de fallback diferente.

Revisar fontes web não significa trocar identidade por uma fonte de sistema em todo projeto. Significa saber quais arquivos são necessários, como são descobertos, o que aparece enquanto carregam e se o resultado continua legível na URL publicada.

Faça um inventário tipográfico

Comece pela build e pelo CSS que chega ao navegador.

Registre:

• famílias usadas;
• origem de cada fonte;
• formatos;
• pesos e estilos declarados;
• pesos realmente aplicados;
• tamanho de cada arquivo;
• seletores que acionam cada família;
• estratégia de font-display;
• preloads e preconnects;
• fallback configurado;
• caracteres necessários para o conteúdo.

Uma matriz expõe desperdícios:

Não procure apenas arquivos .woff2. Uma fonte pode ser carregada por @import, <link> externo, pacote JavaScript ou componente que injeta estilos.

O guia de Core Web Vitals em sites criados por IA mostra onde fontes podem afetar LCP e CLS. Este artigo aprofunda o diagnóstico tipográfico.

Decida o papel de cada família

Separe identidade de hábito gerado pelo template.

Uma família display pode diferenciar títulos. Uma família de texto pode sustentar leitura longa. Uma fonte mono pode ajudar em código. Se todas aparecem em um único card porque o agente queria “mais personalidade”, há custo sem hierarquia clara.

Pergunte:

1. esta família representa uma decisão aprovada de marca?
2. onde ela é realmente necessária?
3. uma família variável substitui vários arquivos com vantagem neste caso?
4. o fallback preserva legibilidade e largura aproximada?
5. a licença permite uso e distribuição web?

Não presuma que uma fonte encontrada na internet pode ser republicada. Confirme a licença e guarde a origem do arquivo.

O artigo sobre consistência de marca em sites gerados por IA ajuda a transformar tipografia em regra de sistema, não em escolha aleatória de cada página.

Carregue apenas pesos e estilos usados

Cada arquivo adicional pode gerar uma requisição e competir com CSS, imagem hero e outros recursos críticos.

Se o projeto usa regular, semibold e bold, não inclua automaticamente thin, light, medium, extrabold e seus itálicos. Procure no CSS e no HTML final quais valores de font-weight e font-style aparecem.

Defina as faces com propriedades coerentes:

@font-face {
  font-family: "Marca Sans";
  src: url("/assets/fonts/marca-sans-regular.woff2") format("woff2");
  font-style: normal;
  font-weight: 400;
  font-display: swap;
}

@font-face {
  font-family: "Marca Sans";
  src: url("/assets/fonts/marca-sans-semibold.woff2") format("woff2");
  font-style: normal;
  font-weight: 600;
  font-display: swap;
}

Declarar o peso errado pode fazer o navegador sintetizar negrito ou escolher um arquivo inesperado.

Fontes variáveis podem reunir intervalos de peso em um arquivo, mas não são automaticamente menores que qualquer conjunto estático. Compare o arquivo variável com os pesos que a página realmente usa.

A referência de fontes web da MDN detalha @font-face, formatos, pesos, estilos e intervalos de caracteres.

Garanta caracteres do português

Uma amostra com “Landing Page” pode esconder problemas que aparecem em “configuração”, “publicação”, “você” e “ações”.

Teste pelo menos:

á à â ã é ê í ó ô õ ú ü ç
Á À Â Ã É Ê Í Ó Ô Õ Ú Ü Ç
R$ 1.234,56 — “aspas” … %

Quando um arquivo foi reduzido por subsetting, confirme se o conjunto cobre toda a copy, campos, mensagens de erro, termos e conteúdo que pode mudar.

O navegador pode misturar a fonte escolhida com outra para glifos ausentes. Esse fallback por caractere produz acentos, símbolos ou números com aparência diferente.

Se o site tem mais de um idioma, registre os conjuntos necessários. Não restrinja unicode-range com base apenas na home atual.

Escolha conscientemente o comportamento de exibição

O descritor font-display orienta o que o navegador faz enquanto a fonte ainda não está disponível.

Valores comuns têm compromissos diferentes:

Não transforme swap em regra universal. A escolha depende do papel da fonte, da velocidade de entrega e do impacto da troca.

A documentação de font-display da MDN descreve os períodos de bloqueio, troca e falha. O guia de boas práticas para fontes do web.dev relaciona essas estratégias a carregamento e estabilidade.

Teste em rede lenta. Um valor que parece equivalente com cache quente pode produzir uma experiência completamente diferente na primeira visita.

Crie um fallback que funcione

Uma pilha de fontes deve terminar em uma família genérica:

:root {
  --font-body: "Marca Sans", "Helvetica Neue", Arial, sans-serif;
  --font-display: "Marca Display", Georgia, serif;
}

O fallback precisa ser legível e próximo o suficiente em proporção para reduzir mudanças quando a web font chega.

Compare:

• largura do título em uma e duas linhas;
• altura dos botões;
• quebra de cards;
• campos de formulário;
• números e preços;
• acentos;
• zoom;
• tamanhos pequenos.

CSS Fonts oferece descritores para ajustar métricas de fallback em casos avançados, mas não adicione calibração sem medir. Primeiro escolha uma pilha sensata e observe o deslocamento real.

Faça preload com parcimônia

Preload pode antecipar a descoberta de uma fonte crítica:

<link
  rel="preload"
  href="/assets/fonts/marca-sans-regular.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

Ele também consome prioridade de rede. Precarregar todos os pesos pode atrasar a imagem hero, o CSS ou recursos mais importantes.

Use preload somente quando:

• a fonte participa do conteúdo inicial;
• o navegador a descobriria tarde;
• o arquivo corresponde exatamente ao usado;
• a medição mostra benefício;
• o atributo crossorigin está correto para a requisição.

A referência de preload da MDN explica os tipos de recurso e os requisitos específicos para fontes.

Se a fonte vem de outro domínio, a página pode depender de conexão, cache e disponibilidade de terceiros. Auto-hospedar pode dar mais controle, mas só faça isso quando a licença permitir e o pacote estiver configurado para incluir os arquivos.

Evite cadeias de descoberta desnecessárias

Uma fonte declarada em um @import dentro de outro CSS pode ser descoberta depois de várias etapas:

HTML → CSS principal → CSS importado → arquivo da fonte

Prefira uma estrutura em que os estilos críticos sejam encontrados cedo. Não adicione JavaScript só para iniciar uma fonte que o CSS consegue declarar.

Verifique o painel de rede:

• quando o arquivo começou;
• qual recurso o iniciou;
• prioridade;
• cache;
• redirecionamentos;
• status;
• duração;
• se houve download duplicado.

Uma fonte “pequena” ainda pode aparecer tarde porque foi descoberta tarde.

Dê ao agente um contrato de revisão

Um pedido específico reduz mudanças cosméticas e mantém a decisão auditável:

Audite as fontes web da build antes de editar.

Liste famílias, origem, formato, peso, estilo, tamanho,
font-display, preload, seletores de uso e cobertura dos
caracteres do português.

Identifique arquivos sem uso, pesos duplicados, descoberta tardia,
texto invisível e trocas que alteram o layout. Preserve a hierarquia
tipográfica e a identidade aprovada. Proponha a menor correção por
problema e mostre a evidência.

Depois, gere a build e registre os testes que ainda precisam ser
feitos no navegador e na URL publicada.

Peça uma mudança por rodada. Remover pesos, trocar família, alterar escala tipográfica e redesenhar componentes ao mesmo tempo impede saber o que resolveu o carregamento.

Valide legibilidade e layout

Teste a página com:

• cache vazio;
• conexão lenta simulada;
• fonte bloqueada;
• zoom de 200%;
• largura pequena e grande;
• conteúdo em português;
• mensagens de erro e sucesso;
• modo escuro, se existir;
• preferências de acessibilidade do projeto.

Observe:

• texto invisível;
• troca abrupta;
• título pulando de uma para duas linhas;
• botão mudando de largura;
• card crescendo;
• ícones dependentes de fonte desaparecendo;
• glifos ausentes;
• peso sintetizado;
• contraste e legibilidade.

O guia de acessibilidade em sites criados por IA complementa a revisão com zoom, contraste, foco e movimento. Tipografia performática que não pode ser lida continua sendo uma falha.

Confirme o pacote e a publicação

Antes do deploy:

1. rode os checks do projeto;
2. gere uma build limpa;
3. confirme os arquivos de fonte na saída;
4. abra o HTML e o CSS finais;
5. procure referências a arquivos ausentes;
6. teste sem cache;
7. compare as métricas antes e depois;
8. aprove o artefato exato.

A documentação de Publicação explica como o agente edita os arquivos dentro de public/. Se a fonte não estiver no repositório do Site ou o caminho mudar, o navegador usará fallback mesmo que o preview local esteja perfeito.

Depois de publicar, abra a URL real e repita o teste de primeira visita. Confira status, tipo de conteúdo, cache e carregamento em celular.

Quando houver correção, preserve o Site ID e use o fluxo de republicação com agente de IA. Assim, a nova versão mantém URL e contexto de comparação.

Tipografia precisa sobreviver fora do editor

A fonte certa é aquela que sustenta a identidade e ainda deixa o conteúdo aparecer, quebrar e responder bem nas condições do visitante.

Inventarie famílias e pesos, valide licença e caracteres, escolha font-display com intenção, limite preloads, teste o fallback e confirme a Version publicada. O resultado não é apenas uma página mais leve: é uma identidade tipográfica que continua íntegra quando sai do ambiente ideal.