Font display no Lighthouse: o que ele sinaliza e como corrigir

O aviso de font-display prejudica a pontuação?

O Lighthouse sinaliza toda fonte web carregada com font-display: block, auto ou fallback no insight Font display ("Consider setting font-display to swap or optional"), chamado de "Ensure text remains visible during webfont load" antes do Lighthouse 13. Ele não tem peso na pontuação, mas quando um título é o elemento do LCP, escondê-lo atrasa o LCP no celular. Defina swap nas fontes que os visitantes veem primeiro e ajuste o fallback com metric overrides.

O que o insight Font display verifica?

No Lighthouse 13 e no PageSpeed Insights, o insight diz: "Consider setting font-display to swap or optional to ensure text is consistently visible. swap can be further optimized to mitigate layout shifts with font metric overrides." Antes do Lighthouse 13, a auditoria se chamava "Ensure text remains visible during webfont load".

O Lighthouse lê o trace do próprio Chrome durante o carregamento da página. Para cada fonte web que a página começa a baixar, o trace registra o valor de font-display usado pelo Chrome. O insight sinaliza três valores:

• block: o texto fica invisível por até 3 segundos enquanto a fonte baixa.
• auto: nenhum valor definido. O Google Fonts envia isso sem &display=, e temas mais antigos, Font Awesome 4 e Material Icons usam esse padrão.
• fallback: o texto fica invisível por apenas 100 ms. O Lighthouse 13 sinaliza mesmo assim.

Apenas dois valores passam: swap e optional. Isso mudou no Lighthouse 13. A auditoria antiga aprovava block e fallback, então um site que "corrigiu" isso anos atrás usando fallback recebe o aviso de novo. Temas de blocos do WordPress usam fallback por padrão, e o Font Awesome 5 e 6 usam block.

"Est savings" é o tempo que a requisição da fonte levou no trace, com teto de 3.000 ms. O PageSpeed Insights grava esse trace sem throttling, por isso é comum ver um número baixo por lá. O relatório abaixo vem de uma página de teste — uma página de produto de loja outdoor com fonte condensada no título —, em um celular com throttling no DevTools (Slow 4G). Nele, a fonte do corpo levou mais de 3 segundos, e a tabela mostra o teto. De qualquer forma, você não vai recuperar esse tempo: com fallback a fonte oculta o texto por no máximo 100 ms, e com auto o Chrome para de esperar por ela 2 segundos após o início da navegação.

Ao lado da descrição, o Lighthouse mostra dois rótulos. FCP é a métrica em que ele calcula a economia. Unscored significa peso 0: o insight em si nunca mexe na pontuação. Uma fonte com block afeta a pontuação por meio do Speed Index e do LCP.

Uma regra @font-face que ninguém usa nunca dispara o aviso. E como o Lighthouse lê o trace, ele agora também lista fontes que você não incluiu diretamente, como um kit do Typekit ou arquivos do Google Fonts vindos de um plugin. A auditoria antiga exibia "unable to check" para fontes de outros domínios.

O que acontece no navegador enquanto uma fonte web carrega?

O navegador não pode requisitar uma fonte até saber que um elemento visível precisa dela. Ele precisa do HTML, depois do CSS e, em seguida, do cálculo de estilo que determina que "este título usa Barlow Condensed". Só então a requisição da fonte começa. Em um celular com throttling, isso aconteceu aos 0,74 s, depois que o HTML e o CSS já tinham chegado. Uma fonte é sempre descoberta tarde. O preload só antecipa esse início: fontes já recebem a prioridade mais alta por padrão.

A partir desse momento, o valor de font-display define o que o visitante vê. Estes são os tempos no código-fonte do navegador:

O Safari e o Firefox também ocultam o texto por até 3 s com block e auto. O Firefox espera 1,5 s a mais quando 75% da fonte já foi baixada. Ambos ocultam o texto por 100 ms com fallback e optional, e o Firefox faz o mesmo com swap.

No Chrome, block é mais lento que auto: auto tem o teto de 2 segundos e block não. E o optional no Chrome não tem período de tolerância de 100 ms. Sem preload, a fonte praticamente nunca chega a tempo do primeiro render, mesmo vindo de um servidor rápido. Com preload, ela consegue entrar se chegar dentro de cerca de 100 ms do momento em que a página poderia renderizar. Já pelo cache, na página seguinte, ela entra.

A página de produto no primeiro paint, aos 0,9 s em um celular com throttling. O quadro escuro é a foto, ainda carregando em ambos os casos. Página de teste no corewebvitals.io, Chrome 155, celular com 412 px de largura, Slow 4G e 4x CPU slowdown.

Com block, o primeiro paint mostra o cabeçalho, o breadcrumb e a avaliação por estrelas, com um espaço vazio onde fica o nome do produto. A fonte do título é leve (15 kB) e chega aos 1,7 s. A fonte do corpo tem 344 kB e ainda está baixando quando o Chrome para de esperar aos 3,7 s; até lá, não há nada abaixo da foto. Com swap, o nome do produto e a descrição ficam legíveis desde o primeiro paint.

A mesma página aos 3 s: a fonte do título e a foto já entraram; a fonte do corpo, não.

O font-display afeta LCP, CLS e FCP?

LCP

Texto invisível não pode ser o elemento do LCP. Com block ou auto, um LCP de texto só é registrado quando o texto fica visível: quando a fonte chega ou quando o período de block termina. Em uma página onde o elemento do LCP é um título ou parágrafo, block pode acrescentar até 3 segundos ao LCP. O Chrome acrescenta menos com auto e, no teste em Slow 4G, chegou a exibir o texto em Arial na hora. Com swap, o LCP é o paint com a fonte de fallback, e a troca pela fonte web não gera uma nova entrada de LCP, mesmo se o texto da fonte web for maior.

Na página de produto acima, a foto é o elemento do LCP em todas as versões, então o font-display não mexeu no LCP ali. Essa é a primeira coisa a verificar nas suas páginas: o elemento do LCP é texto ou imagem? O insight LCP breakdown, no mesmo relatório do Lighthouse, indica quem ele é.

CLS

Qualquer swap que altere o espaço ocupado pelo texto desloca tudo o que vem depois. Isso acontece também com block e auto: o texto invisível ocupa o espaço da fonte de fallback, e a troca para a fonte web causa o mesmo salto. As versões com block, auto e swap tiveram CLS de 0,031 no momento em que a fonte do título chegou.

Com swap simples, o título passa de três linhas para duas quando a Barlow Condensed chega aos 1,7 s. Tudo abaixo dele sobe 39 px: CLS de 0,031. A linha tracejada mostra onde a foto estava.

A mesma página com uma face de fallback que ajusta a Arial Bold à largura da Barlow (size-adjust: 68.32%). O título ocupa duas linhas desde o primeiro paint e nada sai do lugar: CLS 0.

Portanto, swap passa no insight Font display, mas mantém o layout shift. 0,031 fica abaixo de 0,1, mas em uma página de produto real, uma segunda fonte que chega mais tarde, um preço com outra fonte ou uma barra fixa podem se acumular. Metric overrides no fallback eliminam esse deslocamento.

O Lighthouse não vai apontar a fonte como culpada. Na versão com swap, o item Layout shift culprits culpa a foto, acusando "Unsized image element". Só que ela tem width e height definidos. O que moveu a imagem foi a fonte do título chegando exatamente naquele instante. Compare o momento do shift com as requisições de fontes antes de sair procurando dimensões que já existem no código.

FCP

O Lighthouse aponta a economia no FCP. Mas, na maioria das páginas, outros elementos definem o FCP: na página de produto, o cabeçalho e a barra de frete usam fontes do sistema e renderizam aos 0,8 s, tanto com block quanto com swap. Em um teste próprio com apenas texto em fonte web na página, o Chrome 155 ainda reportou FCP em 112 ms enquanto o texto estava invisível. O Chrome considera o texto pintado; ele apenas deixa de desenhar os glifos. Portanto, o tempo que o Lighthouse exibe como economia no FCP não vai se refletir no seu FCP real. O que você perde com block é o LCP de um elemento de texto, o Speed Index e o que o visitante vê na tela.

Quantos sites recebem o aviso e quando você pode ignorá-lo?

O State of CWV mede as regras @font-face na página inicial de 170.706 sites que declaram fontes web. Metade dessas regras dispararia o insight se a fonte carregasse: 39,7% não têm nenhum valor (auto), 9,6% usam block e 0,9% usam fallback. Apenas 471 sites usam o valor optional em algum lugar.

Sites com LCP bom no celular, agrupados pela quantidade de arquivos de fontes carregados na página inicial e pelos valores de font-display nas regras @font-face. State of CWV, outubro de 2026: 170.706 sites que declaram fontes web, CrUX p75 em celulares, LCP bom em 2,5 s ou menos.

Com um ou dois arquivos de fontes, quase não há diferença: 88% dos sites apenas com swap ou optional têm um LCP bom no celular, contra 87% dos sites apenas com block, auto ou fallback. Com seis a dez arquivos de fonte, a diferença é de 6 pontos; com onze ou mais, chega a 9. Os sites que misturam os dois tipos têm o pior desempenho. Eles declaram muito mais fontes — mediana de 44 regras @font-face contra 18 —, o que tem cara de fonte do tema somada a fonte de plugin e fonte de ícones. O CLS quase não varia entre os grupos.

Isso é uma correlação. Sites que cuidam das fontes costumam cuidar de todo o resto também. Some a isso o comportamento do navegador visto acima, e minha regra é: corte arquivos de fonte primeiro; depois, defina o font-display.

Você pode ignorar o aviso quando:

• a fonte só renderiza texto abaixo da dobra, como no rodapé ou nas avaliações;
• o elemento do LCP for uma imagem e a fonte não causar deslocamento.

Como ver problemas de fontes nos field data?

O Lighthouse mede um único carregamento em um celular simulado. Seus visitantes usam todo tipo de conexão existente, e quem retorna ao site já tem a fonte em cache. No CoreDash, dois detalhamentos mostram se as fontes estão custando desempenho.

• LCP por elemento. Se o elemento do LCP no celular for um título ou parágrafo, uma fonte com block ou auto atrasa a métrica em toda visita que espera pela fonte. Se for uma imagem, a fonte não mexe no LCP.
• CLS por elemento. O swap de uma fonte move o que fica abaixo do texto: a foto, a seção seguinte, o botão de compra. O CoreDash nomeia o elemento que se moveu. Ele não vai dizer que foi a fonte: se o elemento que se move fica logo abaixo de um título ou parágrafo e tem width e height definidos, o swap da fonte é a causa provável.

O CrUX traz essas mesmas métricas no p75 para a origem ou para uma URL, nos últimos 28 dias, sem a atribuição.

LCP por elemento

CLS por elemento

CoreDash em uma loja de exemplo, acme-pagespeed.com, mobile, p75. O título do produto é o elemento do LCP em mais sessões do que qualquer outro elemento, com LCP de 3,28 s. Quando a foto do produto é o elemento do LCP, o LCP fica em 2,21 s. Na tabela de CLS, essa mesma foto, logo abaixo do título, lidera a lista: 0,07 em 1.214 sessões. Ainda com classificação boa, mas nenhum outro elemento se move em tantas sessões.

Como encontrar a fonte sinalizada no DevTools?

Abra a página no Chrome, vá até o painel Performance, defina a rede como Slow 4G e a CPU para 4x slowdown e grave um reload. A barra lateral de Insights lista Font display com cada fonte sinalizada. Clique nela e o DevTools destaca as requisições de fontes na trilha Network.

Depois, veja onde cada requisição de fonte termina, onde fica a marcação de LCP e se a trilha Layout shifts tem algum deslocamento logo após o término da fonte.

Para encontrar cada @font-face que aponta para um arquivo sinalizado, abra a aba Sources, busque pelo nome do arquivo em todos os arquivos (Ctrl+Shift+F, Cmd+Option+F no Mac) e defina o valor em cada regra encontrada.

Como corrigir o insight Font display?

A URL da fonte na tabela do Lighthouse mostra de onde ela vem, e isso determina onde você define o font-display — ou se isso é possível.

@font-face próprio

Uma fonte no seu próprio domínio sem /wp-content/, /cdn/fonts/ ou /_next/ na URL vem do seu próprio CSS. Adicione font-display: swap a cada regra @font-face dessa fonte, incluindo cópias em um segundo arquivo CSS. A exceção são fontes de ícones, como veremos abaixo.

@font-face {
  font-family: "Barlow Condensed";
  src: url(/fonts/barlow-condensed-700.woff2) format("woff2");
  font-weight: 700;
  font-display: swap;
}

Google Fonts

A tabela mostra fonts.gstatic.com, mas a configuração vai no link de fonts.googleapis.com/css2 que carrega a fonte. Adicione &display=swap a ele:

<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Barlow+Condensed:wght@700&display=swap">

Mais rápido ainda é hospedar a fonte por conta própria: nenhuma conexão extra e você controla o preload.

Adobe Fonts

Fontes em use.typekit.net puxam o font-display do projeto web em fonts.adobe.com: escolha Edit Project e defina na barra lateral. O padrão da Adobe é auto, e um parâmetro na URL não tem efeito algum.

WordPress

Fontes do tema trazem /wp-content/themes/ na URL. Em um tema de blocos, defina fontDisplay por face no theme.json:

"fontFace": [{
  "fontFamily": "Barlow Condensed",
  "fontWeight": "700",
  "fontStyle": "normal",
  "fontDisplay": "swap",
  "src": ["file:./assets/fonts/barlow-condensed-700.woff2"]
}]

Em um tema clássico, adicione &display=swap à URL do Google Fonts no wp_enqueue_style ou coloque font-display nas próprias regras @font-face do tema. Fontes em /wp-content/plugins/ pertencem a um plugin ou page builder: procure primeiro nas configurações de fonte deles. Para as fontes do Google Fonts que um page builder carrega, a opção do Elementor fica em Elementor, Editor, Settings, na aba Advanced: Google Fonts Load. O OMGF hospeda o Google Fonts localmente e pode forçar swap nelas. O guia de WordPress traz o restante das otimizações de fontes e CSS.

Shopify

Fontes de temas da Shopify trazem /cdn/fonts/ na URL, no domínio da sua loja. Elas entram pelo filtro font_face no theme.liquid e, sem font_display, nenhum font-display é gerado:

{{ settings.type_header_font | font_face: font_display: 'swap' }}

O Dawn já faz isso por padrão.

Next.js

O next/font usa display: 'swap' por padrão, faz o preload da fonte e cria um fallback com metric overrides (adjustFontFallback). Suas fontes trazem /_next/static/media/ na URL. Uma fonte sinalizada com esse caminho recebeu outro valor na chamada de next/font (display: 'block'): altere lá. Uma fonte sinalizada sem esse caminho foi carregada de outra forma: uma tag <link> para o Google Fonts no layout ou um arquivo CSS de alguma biblioteca de componentes.

Fontes que você não pode ou não deve alterar

• Fontes de ícones (fa-solid-900.woff2, bootstrap-icons.woff2, eicons.woff2): com swap, elas exibem letras ou caixas vazias onde deveriam ficar os ícones. Substitua fontes de ícones por SVG sempre que puder; caso contrário, mantenha em block.
• Um plugin ou app sem configuração de fonte (um plugin do WordPress, uma fonte inserida por app da Shopify): peça ao desenvolvedor para definir swap.
• Um script de terceiros que adiciona uma fonte à página (domínio do fornecedor): foge do seu controle. Carregue o script depois que a página renderizar ou ignore essa linha.

Carregue menos arquivos de fontes

Descarte os pesos e estilos que você não usa e adote uma fonte variável em vez de seis arquivos estáticos. Cada arquivo de fonte removido é uma requisição a menos, um swap a menos e uma linha a menos nesse insight.

swap ou optional: qual escolher?

Use swap nas fontes que carregam a identidade da marca, como títulos e o logo, com um fallback alinhado. Use optional no texto do corpo quando a fonte do sistema também servir, e faça o preload dessa fonte para que ela tenha chance de entrar na primeira página:

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
<style>
@font-face {
  font-family: "Inter";
  src: url(/fonts/inter-var.woff2) format("woff2");
  font-weight: 100 900;
  font-display: optional;
}
</style>

O atributo crossorigin é obrigatório, mesmo para uma fonte no seu próprio domínio: sem ele, o navegador baixa a fonte duas vezes. O preload de fontes no Chrome pode segurar o primeiro render em até 100 ms; portanto, faça preload de uma ou duas fontes, nunca de todas. No Slow 4G, as fontes com preload ainda chegaram depois do primeiro paint, e a página manteve o fallback.

Elimine o layout shift com metric overrides

Faça a fonte de fallback ocupar o mesmo espaço da fonte web. Você faz isso com uma segunda regra @font-face que aponta para uma fonte local e ajusta a escala dela:

@font-face {
  font-family: "Barlow Fallback Arial";
  src: local("Arial Bold"), local("Arial-BoldMT");
  font-weight: 700;
  size-adjust: 68.32%;
  ascent-override: 146.37%;
  descent-override: 29.27%;
  line-gap-override: 0%;
}
h1 {
  font-family: "Barlow Condensed", "Barlow Fallback Arial", Arial, sans-serif;
}

size-adjust é a largura do texto na fonte web dividida pela largura no fallback. ascent-override e descent-override são o ascent e o descent da própria fonte web divididos por esse mesmo size-adjust. Ferramentas como Fontaine e Capsize calculam esses valores a partir dos arquivos de fonte.

O mesmo vale para a fonte do corpo; nesse caso, meça no seu próprio texto, na largura de tela de celular e no tamanho de fonte que você usa. A Inter varia de largura conforme o tamanho da fonte: vai de cerca de 98% da Arial em tamanhos de títulos a cerca de 105% a 18 px. Um size-adjust de 97,6% quebrou a descrição do produto em cinco linhas no fallback contra seis na Inter, e o botão de compra continuou se movendo. A 101%, ambos quebram no mesmo ponto. Para testar, bloqueie o arquivo da fonte no DevTools (Network, botão direito, Block request URL), recarregue na largura de celular e compare as quebras de linha com um carregamento normal. Altere o size-adjust até coincidirem.

O local() só encontra fontes instaladas no dispositivo: Arial está no Windows, no macOS e no iPhone; celulares Android têm Roboto. Para visitantes no Android, adicione uma segunda face de fallback para a Roboto com seus próprios números:

h1 {
  font-family: "Barlow Condensed", "Barlow Fallback Arial", "Barlow Fallback Roboto", sans-serif;
}

O local() pula a face cuja fonte não estiver instalada, então cada dispositivo usa a primeira que tiver. O Safari tem suporte a size-adjust, mas ainda não aos overrides de ascent e descent; a largura se alinha nele, mas com line-height: normal a altura da linha pode variar um pouco. O WordPress e o Shopify não oferecem opções para nada disso. Exige um desenvolvedor.

Como verificar se a correção funcionou?

Execute o Lighthouse de novo no celular: Font display passa para os insights aprovados. Na página de produto, a pontuação foi de 97 para 98, impulsionada pelas métricas pontuadas: Speed Index de 1,9 s para 1,3 s porque o texto aparece antes, e CLS de 0,031 para 0 com os overrides. Depois, olhe o CLS no seu próprio relatório: se a página ainda se mover quando a fonte chegar, o fallback precisa de metric overrides.

Lighthouse 13.5.0, mobile, throttling no DevTools.

Se você escolheu optional, a captura de tela do Lighthouse geralmente mostra a fonte de fallback. O Lighthouse carrega a página a frio, e isso é o optional fazendo o papel dele.

O CoreDash mostra o efeito por dispositivo a partir da próxima visita. O CrUX e o Search Console mostram os últimos 28 dias; portanto, duas semanas após o fix, metade do que eles exibem ainda é do site antigo.

Quer saber se uma fonte é o que mantém seu LCP ou CLS no vermelho no mobile? Em uma Core Web Vitals power hour, analisamos juntos seus field data e um trace da página, e você sai sabendo qual regra de fonte alterar no tema.