Google Fonts está destruindo o LCP da sua loja

Se a sua loja carrega devagar e você já comprimiu todas as imagens, já ativou cache e já desativou metade dos aplicativos, olhe para a fonte.

Na minha loja, um único carregamento de Google Fonts custava 1.900 milissegundos de LCP. Quase dois segundos inteiros — não para carregar a página, apenas para o texto principal aparecer na tela.

Pior: a fonte nem era minha. Vinha de dentro de um aplicativo que eu havia instalado para outra coisa.

Este artigo mostra os quatro motivos técnicos pelos quais o Google Fonts atrasa o LCP, como eu localizei o problema na prática e o passo a passo exato da correção.

A resposta curta

O Google Fonts atrasa o LCP porque força o navegador a abrir duas conexões externas e a resolver uma cadeia de três requisições em sequência antes de conseguir desenhar o texto na tela. Enquanto isso não termina, o conteúdo principal fica invisível ou trocado por uma fonte provisória.

A correção é hospedar a fonte no seu próprio domínio, em formato .woff2, com font-display: swap e preload. Na prática, isso elimina as conexões externas e reduz a cadeia de três passos para um.

O que é LCP, em uma frase

Largest Contentful Paint é o tempo até o maior elemento visível da tela terminar de ser desenhado. Na maioria das lojas, esse elemento é a imagem do banner ou o título da primeira seção.

Quando é texto, a fonte entra no caminho crítico. E aí qualquer atraso no carregamento dela é atraso direto no seu LCP.

O Google considera bom um LCP abaixo de 2,5 segundos. Se a sua fonte sozinha consome quase dois desses segundos, o resto da página nem precisa estar mal feito para você reprovar.

Os quatro motivos técnicos

1. Duas origens externas, do zero

Quando você escreve isto no <head>:

<link href="https://fonts.googleapis.com/css2?family=Maven+Pro&display=swap" rel="stylesheet">

Você não está pedindo uma fonte. Está pedindo um arquivo CSS que, lá dentro, aponta para outro domínio, onde a fonte de fato mora.

São duas origens diferentes:

Para cada uma delas, o navegador precisa fazer o ciclo completo: consulta DNS → conexão TCP → negociação TLS. Em rede móvel brasileira, cada ciclo desses custa entre 200 e 500 ms — antes de transferir um único byte útil.

2. A cadeia de requisições em sequência

Este é o ponto que a maioria dos tutoriais ignora. As três etapas não acontecem em paralelo. Elas dependem umas das outras:

1. HTML baixa
      ↓ (só então)
2. CSS do googleapis.com baixa e é interpretado
      ↓ (só então o navegador descobre a URL da fonte)
3. Arquivo .woff2 do gstatic.com baixa
      ↓ (só então)
4. Texto é desenhado

O navegador não tem como adivinhar a URL do arquivo de fonte antes de ler o CSS. É uma cadeia de profundidade 3, e cada elo espera o anterior terminar.

No PageSpeed Insights isso aparece com o nome de "Evite encadeamento de solicitações críticas". Quando a fonte está nessa cadeia, ela é praticamente sempre o elo mais caro.

3. O texto fica invisível enquanto isso

Sem instrução em contrário, o navegador adota o comportamento chamado FOIT — Flash of Invisible Text. Ele reserva o espaço do texto e simplesmente não desenha nada, esperando a fonte chegar. O período de bloqueio chega a três segundos.

Ou seja: o usuário olha para uma área em branco enquanto o servidor do Google responde. E se o seu elemento LCP for esse texto, o cronômetro do LCP continua correndo.

4. O cache compartilhado não existe mais

Aqui está o argumento que virou lenda e continua sendo repetido:

"Use Google Fonts porque o usuário provavelmente já tem essa fonte em cache de outro site."

Isso deixou de ser verdade em outubro de 2020. A partir do Chrome 86, o navegador passou a usar cache particionado por site. O Safari já fazia isso antes, e o Firefox seguiu.

Na prática, o cache é indexado pelo site que você está visitando. A cópia da fonte que o usuário baixou no site do vizinho não serve para o seu. Cada domínio baixa tudo de novo, do zero.

O único argumento técnico que sustentava o Google Fonts morreu há mais de cinco anos.

Como eu descobri o problema na prática

Este é o passo a passo que eu realmente segui. Ele funciona em qualquer plataforma, não só na minha.

Passo 1 — Confirmar que o problema é fonte, e não imagem

Abra o PageSpeed Insights e rode a análise na versão mobile. É onde os problemas aparecem, porque simula rede lenta.

Na seção de diagnóstico, procure por:

• "Elimine recursos que bloqueiam a renderização" — se fonts.googleapis.com aparece aqui, você já achou.
• "Evite encadeamento de solicitações críticas" — abra e veja se há uma cadeia terminando em fonts.gstatic.com.
• "Verifique se o texto permanece visível durante o carregamento" — falha aqui significa que falta font-display.

Passo 2 — Medir o custo real no seu site

O PageSpeed dá o diagnóstico, mas não o número. Para saber quanto a fonte custa na sua página, use a aba Network do navegador:

1. Abra o DevTools com F12 e vá em Network
2. Marque Disable cache
3. Em Throttling, escolha Slow 4G — sem isso, seu Wi-Fi mente para você
4. Recarregue com Ctrl + Shift + R
5. No campo de filtro, digite fonts

Agora olhe a coluna Waterfall das duas linhas que aparecerem. Passe o mouse por cima e você verá a divisão do tempo: Queueing, DNS Lookup, Initial connection, SSL, Waiting, Content Download.

Some o tempo total das duas linhas. Esse é o custo bruto da sua fonte externa. No meu caso, esse número passava de 1,9 segundo em Slow 4G.

Passo 3 — Descobrir quem está pedindo a fonte

Este passo é o que separa uma correção rápida de uma investigação frustrante. Muitas vezes você não colocou aquela fonte lá.

Ainda no DevTools, na aba Network:

1. Clique com o botão direito no cabeçalho das colunas
2. Ative a coluna Initiator
3. Olhe o que aparece na linha do fonts.googleapis.com

O Initiator mostra qual arquivo disparou a requisição. Se apontar para o seu tema, é seu — e você corrige direto. Se apontar para um arquivo de aplicativo de terceiro, o problema é outro.

Foi exatamente o que aconteceu comigo. O initiator apontava para o script de um aplicativo de avaliações que eu havia instalado meses antes. Ele injetava Google Fonts por conta própria, sem nenhuma opção de desativar no painel.

Passo 4 — Confirmar com bloqueio

Antes de mexer em qualquer coisa, confirme que a fonte é mesmo a culpada. O DevTools permite bloquear uma URL e medir de novo:

1. Na aba Network, clique com o botão direito na linha do fonts.googleapis.com
2. Escolha Block request domain
3. Recarregue

Se o LCP despencar, confirmado. Se não mudar quase nada, o gargalo está em outro lugar e você acabou de economizar horas de trabalho na direção errada.

O caso real: quando o culpado é um aplicativo

No meu caso, a fonte vinha de um app de avaliações de produtos. E aqui está a parte desconfortável: não existia solução limpa.

Testei todas as saídas antes de tomar a decisão final:

Sobrescrever com CSS é a tentativa mais comum e a mais inútil. Você troca a família aplicada, mas o navegador já baixou o arquivo. O custo de rede permanece intacto. Você só escondeu o sintoma.

A conclusão foi que o problema não era a fonte. Era o aplicativo.

Substituí o app por um sistema de avaliações próprio: um arquivo JSON estático servido pelo CDN da própria loja, renderizado por JavaScript puro. São 332 avaliações de 118 produtos em cerca de 14 KB comprimidos, sem nenhuma requisição externa.

Resultado: 1.900 ms a menos de LCP.

Escrevi o processo completo desse sistema em Construí meu sistema de reviews e cortei a mensalidade — mas a lição que interessa aqui é mais geral:

Às vezes a otimização certa não é otimizar. É remover a coisa que está causando o problema.

O passo a passo da correção

Para a fonte que é sua — a que o seu tema carrega — a correção é direta.

Passo 1 — Descubra o que você realmente usa

Antes de baixar qualquer coisa, responda: quais pesos e estilos aparecem de fato na página?

A maioria dos sites carrega de quatro a seis pesos e usa dois. Cada peso é um arquivo separado, com custo de rede próprio.

No DevTools, aba Fonts dentro de Rendering, ou simplesmente inspecionando os elementos, liste os pesos usados de verdade. Normalmente são: 400 (regular) e 700 (bold). Se você usa itálico, some mais um.

Passo 2 — Baixe já em subconjunto

Não baixe a fonte inteira do site do Google. Ela vem com grego, cirílico, vietnamita — alfabetos que a sua loja brasileira nunca vai usar.

Use o google-webfonts-helper. Ele permite escolher:

• Charsets: marque apenas latin e latin-ext
• Styles: só os pesos que você listou no passo 1
• Formato: woff2

O subconjunto costuma cortar de 60% a 80% do tamanho do arquivo. Uma fonte de 180 KB vira 35 KB.

Sobre formatos: woff2 é suficiente. Ele tem suporte universal em navegadores modernos e a melhor compressão. Tutoriais que mandam gerar woff, ttf, eot e svg estão desatualizados em quase uma década.

Passo 3 — Hospede no seu próprio domínio

Suba o arquivo .woff2 para o mesmo domínio do site. Isso elimina as duas conexões externas de uma vez.

Se você está no Shopify, envie para os assets do tema e referencie com o filtro asset_url. Se está no WordPress, coloque em uma pasta do tema. O princípio é o mesmo: mesma origem que o HTML.

Passo 4 — Declare com @font-face e font-display

@font-face {
  font-family: 'Maven Pro';
  src: url('/assets/mavenpro-regular.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: 'Maven Pro';
  src: url('/assets/mavenpro-bold.woff2') format('woff2');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

Duas coisas importantes aqui:

Declare font-weight corretamente em cada bloco. Se você declarar dois arquivos com o mesmo peso, o navegador usa um e ignora o outro — e o seu negrito vira falso negrito, sintetizado pelo navegador, feio e mais largo.

font-display: swap manda o navegador mostrar imediatamente uma fonte de sistema e trocar quando a sua chegar. O texto aparece na hora. Acabou o FOIT.

Passo 5 — Faça o preload da fonte crítica

O @font-face sozinho ainda cria uma cadeia: o navegador só descobre a fonte depois de interpretar o CSS. O preload resolve isso, mandando buscar em paralelo desde o início:

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

Três detalhes que fazem esta linha funcionar ou falhar:

• crossorigin é obrigatório, mesmo na mesma origem. Fonte é sempre buscada em modo anônimo. Sem esse atributo, o navegador baixa duas vezes — e você piora o que veio consertar.
• Faça preload só da fonte usada acima da dobra. Normalmente é uma, no máximo duas. Precarregar tudo compete por banda com a imagem do LCP e atrasa justamente o que você quer acelerar.
• Coloque o preload antes do CSS no <head>.

Passo 6 — Remova o <link> do Google

Parece óbvio, mas é o passo mais esquecido. Muita gente adiciona a fonte local e deixa a linha antiga lá, carregando as duas.

Busque no seu tema por fonts.googleapis.com e apague todas as ocorrências — incluindo preconnect e dns-prefetch que apontem para os domínios do Google, que agora não servem mais para nada.

Passo 7 — Meça de novo, do mesmo jeito

Repita exatamente o Passo 2: Slow 4G, cache desativado, recarga forçada. Comparar medição com throttling contra medição sem throttling não prova nada.

Quando swap não é a melhor escolha

O font-display: swap resolve o LCP, mas cria outro efeito: o texto aparece em uma fonte e troca quando a sua carrega. Essa troca desloca o layout e pode piorar o seu CLS — a métrica de estabilidade visual.

As opções, em ordem de agressividade:

Se a sua fonte é muito diferente da fonte de sistema em largura, a troca vai ser visível e incômoda. Duas saídas:

Usar optional. O navegador desiste da fonte se ela não chegar rápido e mantém a de sistema naquele carregamento. Zero deslocamento. O custo é que alguns visitantes não veem a sua tipografia na primeira visita.

Ajustar as métricas do fallback. Você declara uma família de fallback com métricas corrigidas para ocupar o mesmo espaço:

@font-face {
  font-family: 'Maven Pro Fallback';
  src: local('Arial');
  size-adjust: 96%;
  ascent-override: 92%;
  descent-override: 24%;
}

body {
  font-family: 'Maven Pro', 'Maven Pro Fallback', sans-serif;
}

Os valores exatos variam por fonte e você acerta por tentativa, comparando as duas lado a lado. Dá trabalho, mas elimina o deslocamento sem abrir mão da fonte.

Bônus: existe um risco jurídico

Em janeiro de 2022, o Tribunal Regional de Munique condenou o responsável por um site a indenizar um visitante por carregar Google Fonts a partir dos servidores do Google.

O raciocínio: ao requisitar a fonte, o navegador do visitante envia o endereço IP dele para um servidor nos Estados Unidos, sem consentimento e sem necessidade — já que a fonte poderia ser hospedada localmente. A indenização foi simbólica, mas abriu precedente e gerou uma onda de notificações na Europa.

No Brasil, a LGPD trata endereço IP como dado pessoal quando permite identificar alguém. Não há jurisprudência consolidada sobre esse ponto específico, e eu não sou advogado — mas o raciocínio é o mesmo, e o remédio é gratuito.

Hospedar a fonte você mesmo resolve a performance e remove a transferência de dados. Não há nenhum lado em que você perca.

Checklist

Antes de considerar resolvido:

• Nenhuma ocorrência de fonts.googleapis.com no código do site
• Nenhum preconnect ou dns-prefetch apontando para domínios do Google
• Fonte servida do mesmo domínio do site
• Formato .woff2, com subconjunto latin e latin-ext apenas
• Somente os pesos realmente usados
• font-weight declarado corretamente em cada @font-face
• font-display definido, com o valor certo para o seu caso
• preload apenas na fonte acima da dobra
• crossorigin presente na tag de preload
• Medição refeita em Slow 4G, com cache desativado
• CLS verificado depois da mudança, não só o LCP

Perguntas frequentes

Google Fonts realmente deixa o site lento?

Sim, quando carregado a partir dos servidores do Google. O custo vem de duas conexões externas e de uma cadeia de três requisições em sequência antes de o texto aparecer. Hospedando a mesma fonte no seu domínio, o custo cai para uma única requisição na mesma conexão que já está aberta.

Não é melhor deixar no Google por causa do cache do navegador?

Não. Desde o Chrome 86, em outubro de 2020, o cache é particionado por site. A fonte baixada em outro domínio não é reaproveitada no seu. Esse argumento deixou de valer há mais de cinco anos.

Qual formato de fonte eu devo usar?

Apenas woff2. Tem suporte em todos os navegadores modernos e a melhor compressão disponível. Gerar woff, ttf ou eot só adiciona peso ao seu repositório sem benefício real.

Quantos pesos de fonte eu devo carregar?

Somente os que aparecem na tela. Na prática, quase sempre dois: regular e negrito. Cada peso adicional é um arquivo a mais competindo por banda com a imagem do seu LCP.

E se a fonte vier de um aplicativo que eu instalei?

Sobrescrever por CSS não resolve — o arquivo continua sendo baixado. As saídas reais são pedir a mudança ao fornecedor, encontrar a opção no painel do aplicativo, ou substituir o aplicativo. Na minha loja, substituir foi o que funcionou e rendeu 1.900 ms de LCP.

Hospedar a fonte eu mesmo dá mais trabalho de manutenção?

Praticamente nenhum. Fonte é arquivo estático que não muda. Você sobe uma vez e esquece. O único cuidado é lembrar de incluí-la no processo de deploy do tema.

Resumindo

O Google Fonts custa caro por um motivo estrutural: ele coloca duas origens externas e uma cadeia de três requisições no caminho crítico do seu texto. O argumento do cache compartilhado, que justificava esse custo, morreu em 2020.

A correção leva menos de uma hora: baixar em subconjunto, hospedar no seu domínio, declarar com font-display: swap e precarregar a fonte da primeira dobra.

E se a fonte vier de um aplicativo de terceiro, encare a possibilidade de que a otimização certa seja remover o aplicativo. Foi o que me devolveu 1.900 milissegundos.

Continue lendo em Performance:

• Como remover um app de avaliações cortou 1.900 ms do meu LCP
• Checklist de performance para tema customizado
• O custo real, em milissegundos, de cada app instalado na sua loja