Font display no Lighthouse: o que assinala e como corrigir

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

O Lighthouse assinala todas as web fonts que carregam com font-display: block, auto ou fallback com o insight Font display ("Consider setting font-display to swap or optional"), chamado "Ensure text remains visible during webfont load" antes do Lighthouse 13. Não tem qualquer peso na pontuação, mas quando um título é o elemento LCP, ocultá-lo atrasa o LCP no telemóvel. Defina swap nas fontes que os visitantes veem primeiro e alinhe o fallback com metric overrides.

O que avalia o insight Font display?

No Lighthouse 13 e no PageSpeed Insights, o insight indica: "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 chamava-se "Ensure text remains visible during webfont load".

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

• block: o texto fica invisível até 3 segundos enquanto a fonte descarrega.
• auto: nenhum valor definido. O Google Fonts envia este valor sem &display=, e temas mais antigos, o Font Awesome 4 e o Material Icons usam-no.
• fallback: o texto fica invisível apenas durante 100 ms. O Lighthouse 13 assinala-o de qualquer forma.

Apenas dois valores passam: swap e optional. Isso mudou com o Lighthouse 13. A auditoria antiga aprovava block e fallback, por isso um site que tenha "resolvido" isto há anos com fallback volta a receber o aviso. Os temas de blocos do WordPress usam fallback por omissão, e o Font Awesome 5 e 6 usam block.

"Est savings" é o tempo que o pedido da fonte demorou no trace, com um limite máximo de 3 000 ms. O PageSpeed Insights regista esse trace sem throttling, pelo que é frequente ver aí um número baixo. O relatório abaixo vem de uma página de teste — uma página de produto de uma loja de desporto ao ar livre com uma fonte condensada no título — num telemóvel com throttling nas DevTools (Slow 4G). Aí a fonte do corpo demorou mais de 3 segundos e a tabela mostra o valor limite. De qualquer forma, não vai recuperar esse tempo: com fallback, uma fonte oculta o texto no máximo durante 100 ms; com auto, o Chrome deixa de esperar por ela 2 segundos após o início da navegação.

Ao lado da descrição, o Lighthouse mostra duas etiquetas. FCP é a métrica em que o Lighthouse calcula que vai poupar tempo. Unscored significa peso 0: o insight em si nunca altera a pontuação. Uma fonte com block reflete-se na pontuação através do Speed Index e do LCP.

Uma regra @font-face que ninguém use nunca o ativa. E como o Lighthouse lê o trace, agora lista também fontes que não adicionou diretamente, como um kit do Typekit ou um ficheiro do Google Fonts carregado por um plugin. A auditoria antiga mostrava "unable to check" para fontes de outros domínios.

O que acontece no browser enquanto uma web font carrega?

O browser não pode pedir uma fonte antes de saber que um elemento visível precisa dela. Precisa do HTML, depois do CSS e, em seguida, de um cálculo de estilos que determine que "este título usa Barlow Condensed". Só aí tem início o pedido da fonte. Num telemóvel com throttling, isso aconteceu aos 0,74 s, depois da chegada do HTML e do CSS. Uma fonte é sempre descoberta tarde. Um preload apenas antecipa esse arranque: as fontes já recebem a prioridade mais alta.

A partir desse momento, o valor de font-display decide o que o visitante vê. Eis os tempos definidos no código-fonte do browser:

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

No Chrome, o block é mais lento do que o auto: o auto tem o limite de 2 segundos e o block não. E o optional no Chrome não tem qualquer período de tolerância de 100 ms. Sem um preload, a fonte quase nunca chega a tempo do primeiro render, mesmo a partir de um servidor rápido. Com um preload consegue, se a fonte chegar dentro de cerca de 100 ms do momento em que a página estaria pronta a renderizar. A partir da cache, na página seguinte, chega sempre.

A página de produto no respetivo first paint, aos 0,9 s num telemóvel com throttling. A caixa escura é a fotografia, ainda a carregar em ambos os casos. Página de teste em corewebvitals.io, Chrome 155, telemóvel com 412 px de largura, Slow 4G e abrandamento de 4x no CPU.

Com block, o first paint mostra o cabeçalho, os breadcrumbs e a avaliação por estrelas, com um espaço vazio no lugar do 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á a descarregar quando o Chrome deixa de esperar aos 3,7 s; até lá, não há nada por baixo da fotografia. Com swap, o nome do produto e a descrição ficam legíveis logo a partir do first paint.

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

O font-display afeta o LCP, o CLS e o FCP?

LCP

Texto invisível não pode ser o elemento LCP. Com block ou auto, um LCP de texto é reportado quando o texto fica visível: quando a fonte chega ou quando o período de bloqueio termina. Numa página onde o elemento LCP seja um título ou um parágrafo, o block pode somar até 3 segundos ao LCP. O Chrome soma menos com auto e, em Slow 4G, chegou a mostrar esse texto em Arial logo de início. Com swap, o LCP corresponde à pintura na fonte de fallback, e a transição para a web font não gera uma nova entrada de LCP, mesmo que o texto da web font seja maior.

Na página de produto acima, a fotografia é o elemento LCP em todas as versões, pelo que o font-display não alterou o LCP nesse caso. É a primeira coisa a verificar nas suas páginas: o elemento LCP é texto ou uma imagem? O insight de detalhe do LCP no mesmo relatório do Lighthouse identifica-o.

CLS

Qualquer swap que altere o espaço ocupado pelo texto desloca tudo o que surge a seguir. Isso também acontece com block e auto: o texto invisível ocupa o espaço da fonte de fallback e a transição para a web font provoca o mesmo salto. As versões com block, auto e swap obtiveram todas um 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 o que está por baixo sobe 39 px: CLS de 0,031. O contorno a tracejado indica onde a fotografia estava.

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

Assim, o swap passa no insight Font display, mas mantém o layout shift. 0,031 fica abaixo de 0,1, mas numa página de produto real uma segunda fonte a chegar mais tarde, um preço noutra fonte ou uma barra fixa podem acumular desvios. Os metric overrides no fallback eliminam essa deslocação.

O Lighthouse não vai apontar diretamente para a fonte. Na versão com swap, o Layout shift culprits culpa a fotografia como "Unsized image element". No entanto, ela tem largura e altura definidas. O que a moveu foi a fonte do título, que chegou exatamente nesse momento. Compare o momento do shift com os pedidos das suas fontes antes de perder tempo à procura de dimensões que já lá estão.

FCP

O Lighthouse reporta o ganho estimado como FCP. Na maioria das páginas, é outro elemento que determina o FCP: na página de produto, o cabeçalho e a barra de portes usam uma fonte de sistema e renderizam aos 0,8 s, tanto com block como com swap. No meu próprio teste, apenas com texto em web font na página, o Chrome 155 continuou a reportar o FCP aos 112 ms enquanto o texto estava invisível. O Chrome considera o texto pintado; apenas não desenha os glifos. Por isso, o tempo que o Lighthouse apresenta como poupança de FCP não se vai refletir no seu FCP real. O que perde com block é o LCP de um elemento de texto, o Speed Index e o que o visitante vê.

Quantos sites recebem o aviso e quando o pode ignorar?

O State of CWV analisa as regras @font-face nas páginas principais de 170 706 sites que declaram web fonts. Metade dessas regras ativaria o insight caso a fonte carregasse: 39,7% não têm qualquer valor (auto), 9,6% usam block e 0,9% fallback. Apenas 471 sites usam o valor optional em algum ponto.

Sites com bom LCP em telemóveis, agrupados pelo número de ficheiros de fontes que a página principal carrega e pelos valores de font-display nas suas regras @font-face. State of CWV, outubro de 2026: 170 706 sites que declaram web fonts, CrUX p75 em telemóveis, um bom LCP é de 2,5 s ou menos.

Com um ou dois ficheiros de fontes a diferença é quase nula: 88% dos sites apenas com swap ou optional têm um bom LCP em telemóveis, contra 87% dos sites apenas com block, auto ou fallback. Com seis a dez ficheiros de fontes, a diferença é de 6 pontos percentuais; com onze ou mais, é de 9. Os sites que misturam ambos os tipos têm o pior desempenho. Declaram muito mais fontes — uma mediana de 44 regras @font-face contra 18 —, o que indicia a fonte do tema, mais a de um plugin, mais uma fonte de ícones. O CLS quase não varia entre os grupos.

Trata-se de uma correlação. Os sites que cuidam das fontes costumam ter cuidado com tudo o resto. Junte-se o comportamento dos browsers explicado acima e a minha regra é simples: elimine ficheiros de fontes primeiro, configure o font-display depois.

Pode ignorar o aviso se:

• a fonte apenas renderiza texto below the fold, como no rodapé ou nas avaliações;
• o elemento LCP for uma imagem e a fonte não provocar qualquer shift.

Como identificar problemas de fontes nos seus field data?

O Lighthouse mostra um único carregamento num telemóvel simulado. Os seus visitantes acedem através de todo o tipo de ligações e um visitante recorrente já tem a fonte na cache. No CoreDash, dois relatórios indicam se as fontes lhe estão a custar desempenho.

• LCP by element. Se o elemento LCP no telemóvel for um título ou um parágrafo, uma fonte em block ou auto atrasa-o em qualquer visita que fique à espera da fonte. Se for uma imagem, a fonte não toca no LCP.
• CLS by element. Um swap de fontes move o que está por baixo do texto: a fotografia, a secção seguinte, o botão de compra. O CoreDash identifica o elemento que se moveu. Não vai afirmar que a culpa foi da fonte: se o elemento deslocado estiver logo abaixo de um título ou parágrafo e tiver largura e altura definidas, o swap de fontes é a causa provável.

O CrUX fornece as mesmas métricas no p75 para a sua origem ou para um URL específico, referentes aos últimos 28 dias, sem a respetiva atribuição.

LCP by element

CLS by element

CoreDash numa loja de exemplo, acme-pagespeed.com, mobile, p75. O título do produto é o elemento LCP em mais sessões do que qualquer outro, com um LCP de 3,28 s. Quando a fotografia do produto é o elemento LCP, o valor é de 2,21 s. Na tabela de CLS, essa fotografia, logo abaixo do título, surge na primeira linha: 0,07 em 1 214 sessões. Continua classificada como good, mas nenhum outro elemento se desloca em tantas sessões.

Como encontrar a fonte assinalada nas DevTools?

Abra a página no Chrome, vá ao painel Performance, configure a rede para Slow 4G e o CPU para 4x slowdown, e grave um recarregamento. A barra lateral Insights lista o Font display com todas as fontes assinaladas. Clique nele e as DevTools destacam os pedidos de fontes na faixa Network.

Em seguida, veja onde termina o pedido de cada fonte, onde fica o marcador de LCP e se a faixa Layout shifts regista algum shift logo após o carregamento da fonte terminar.

Para encontrar todas as regras @font-face que apontam para um ficheiro assinalado, abra o painel Sources, pesquise em todos os ficheiros (Ctrl+Shift+F ou Cmd+Option+F no Mac) pelo nome do ficheiro e defina o valor em cada regra encontrada.

Como corrigir o insight Font display?

O URL da fonte na tabela do Lighthouse indica a sua origem, o que determina onde configurar o font-display — ou se isso é sequer possível.

@font-face próprio

Uma fonte no seu próprio domínio sem /wp-content/, /cdn/fonts/ ou /_next/ no URL tem origem no seu próprio CSS. Adicione font-display: swap a todas as regras @font-face dessa fonte, incluindo duplicados numa segunda folha de estilos. A exceção são as fontes de ícones (ver 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 definição deve ser feita no link de fonts.googleapis.com/css2 que carrega a fonte. Adicione-lhe &display=swap:

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

Ainda mais rápido é alojar a fonte no próprio servidor: poupa uma ligação adicional e passa a controlar o preload.

Adobe Fonts

As fontes alojadas em use.typekit.net obtêm o font-display a partir do projeto web em fonts.adobe.com: selecione Edit Project e altere o valor na barra lateral. O valor por omissão da Adobe é auto e qualquer parâmetro no URL é ignorado.

WordPress

As fontes de temas incluem /wp-content/themes/ no URL. Num tema de blocos, configure o fontDisplay para cada face no theme.json:

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

Num tema clássico, adicione &display=swap ao URL do Google Fonts no wp_enqueue_style ou inclua o font-display nas próprias regras @font-face do tema. As fontes em /wp-content/plugins/ pertencem a um plugin ou page builder: comece por procurar a definição de fontes aí. Quanto às Google Fonts carregadas por um page builder, a opção no Elementor fica em Elementor, Editor, Settings, no separador Advanced: Google Fonts Load. O plugin OMGF aloja as Google Fonts localmente e permite forçar o valor swap. O guia de WordPress detalha o restante trabalho de fontes e CSS.

Shopify

As fontes dos temas Shopify têm /cdn/fonts/ no URL, sob o domínio da loja. São injetadas através do filtro font_face no theme.liquid e, sem o parâmetro font_display, não geram qualquer font-display:

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

O tema Dawn já inclui esta definição.

Next.js

O next/font utiliza display: 'swap' por omissão, faz o preload da fonte e gera um fallback com metric overrides (adjustFontFallback). As suas fontes incluem /_next/static/media/ no URL. Uma fonte assinalada com esse caminho recebeu outro valor na chamada ao next/font (display: 'block'): altere-o aí. Uma fonte assinalada sem esse caminho foi carregada de outra forma: através de uma tag <link> para o Google Fonts no layout ou através de um ficheiro CSS de uma biblioteca de componentes.

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

• Uma fonte de ícones (fa-solid-900.woff2, bootstrap-icons.woff2, eicons.woff2): com swap, apresenta letras ou retângulos vazios no lugar dos ícones. Substitua as fontes de ícones por SVG sempre que possível; caso contrário, mantenha-as com block.
• Um plugin ou app sem definições de fontes (um plugin do WordPress, uma fonte adicionada por uma app Shopify): peça ao programador respetivo para definir swap.
• Um script de terceiros que adiciona uma fonte à página (no domínio do fornecedor): foge ao seu controlo. Carregue o script após a renderização da página ou simplesmente ignore essa linha.

Carregue menos ficheiros de fontes

Elimine os pesos e estilos que não utiliza e adote uma única fonte variável em vez de seis ficheiros estáticos. Cada ficheiro de fonte removido é menos um pedido, menos um swap e menos uma linha neste insight.

swap ou optional: qual escolher?

Use swap para as fontes que sustentam a identidade da marca, como títulos e o logótipo, com um fallback ajustado. Use optional para o corpo de texto quando a fonte de sistema também for aceitável, e faça o preload dessa fonte para que tenha hipótese de carregar 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 browser descarrega a fonte duas vezes. No Chrome, o preload de uma fonte pode atrasar o primeiro render até 100 ms, por isso faça o preload de uma ou duas fontes, nunca de todas. Em Slow 4G, as fontes com preload continuaram a chegar após o first paint e a página manteve o fallback.

Elimine o layout shift com metric overrides

Ajuste o tamanho da fonte de fallback ao da web font. Consegue isso através de uma segunda regra @font-face que aponta para uma fonte local e altera a sua escala:

@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;
}

O size-adjust corresponde à largura do texto na web font dividida pela largura na fonte de fallback. O ascent-override e o descent-override são o ascent e descent próprios da web font divididos por esse mesmo size-adjust. Ferramentas como o Fontaine e o Capsize calculam estes valores a partir dos ficheiros das fontes.

O mesmo princípio aplica-se à fonte do corpo de texto; aí deve medir com o seu próprio texto, na largura de um telemóvel e no tamanho exato que utiliza. A Inter altera a sua largura consoante o tamanho da fonte: passa de cerca de 98% da Arial em tamanhos de título para 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 a mover-se. A 101%, ambas quebram exatamente da mesma forma. Para testar, bloqueie o ficheiro da fonte nas DevTools (Network, clique com o botão direito, Block request URL), recarregue a página na largura de um telemóvel e compare as quebras de linha com um carregamento normal. Ajuste o size-adjust até coincidirem.

A função local() apenas encontra fontes instaladas no dispositivo: a Arial existe no Windows, macOS e iPhones; os telemóveis Android têm a Roboto. Para os visitantes em Android, adicione uma segunda face de fallback para a Roboto com os seus próprios valores:

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

A função local() ignora uma face cuja fonte não esteja instalada, pelo que cada dispositivo utiliza a primeira que encontrar. O Safari é compatível com size-adjust, mas ainda não com os overrides de ascent e descent; a largura coincide, mas com line-height: normal a altura da linha pode variar ligeiramente. O WordPress e o Shopify não têm qualquer configuração para nada disto. Exige a intervenção de um programador.

Como confirmar se a correção funcionou?

Execute novamente o Lighthouse no telemóvel: o Font display passa para os insights aprovados. Na página de produto, a pontuação subiu de 97 para 98, exclusivamente devido às métricas com peso: o Speed Index passou de 1,9 s para 1,3 s porque o texto surge mais cedo, e o CLS desceu de 0,031 para 0 com os overrides. Depois, analise o CLS no seu próprio relatório: se a página continuar a deslocar-se quando a fonte chega, o fallback precisa de metric overrides.

Lighthouse 13.5.0, telemóvel, throttling nas DevTools.

Se optou por optional, a captura de ecrã do Lighthouse costuma mostrar a fonte de fallback. O Lighthouse carrega a página a frio e isso é o optional a cumprir a sua função.

O CoreDash reflete o impacto por dispositivo logo a partir da visita seguinte. O CrUX e a Search Console mostram os últimos 28 dias; por isso, duas semanas após a correção, metade dos dados ainda reflete o site antigo.

Quer saber se é uma fonte que mantém o seu LCP ou CLS no vermelho no telemóvel? Numa power hour de Core Web Vitals, analisamos em conjunto os seus field data e um trace da sua página, e fica a saber exatamente que regra de fonte deve alterar no seu tema.