Carregamento Responsivo de Fontes Web: Uma Estratégia Direcionada por Dispositivo

Estratégia de font display responsivo e preloading responsivo

Como um especialista em Core Web Vitals, vejo diferentes soluções criativas todos os dias. A maioria não faz muito sentido, mas de vez em quando me deparo com uma estratégia que é tão simples e elegante que faz todo sentido para determinados sites.

De acordo com o Web Almanac 2025, 88% dos sites usam fontes web, carregando uma mediana de 4 arquivos de fonte por página. No entanto, apenas 12% dos sites fazem o preload de fontes, e meros 0,5% usam font-display: optional. A maioria dos sites trata o carregamento de fontes como um problema de tamanho único. Este artigo explica uma abordagem mais inteligente: carregar fontes de maneira diferente para desktop e mobile.

A estratégia combina o preloading responsivo com font-display: optional no desktop (eliminando o Flash Of Unstyled Text) e font-display: swap no mobile (priorizando a renderização rápida do texto em vez da consistência visual).

Revisado por último por Arjen Karel em março de 2026

dica: essa estratégia funciona bem para sites com um critical rendering path maior, o que significa sites que carregam múltiplas fontes, stylesheets e scripts antes do elemento de LCP. Se o seu site carrega uma única fonte leve, a complexidade adicional não vale a pena.

O problema com o carregamento antecipado de fontes

Ao otimizar os Core Web Vitals, existe uma regra simples que sempre se aplica:
"Tudo o que você faz antes do Largest Contentful Paint vai atrasar esse Largest Contentful Paint".

Este princípio também se aplica a fontes web. Priorizar o carregamento de fontes web durante o carregamento da página pode melhorar a user experience, mas se o seu site estiver com dificuldades para atingir os limites do Core Web Vitals, especialmente em tipos de dispositivos específicos, você precisará equilibrar a UX com a melhoria do LCP.

O capítulo de Performance do Web Almanac 2025 mostra que o texto é o elemento de LCP em quase 24% das páginas mobile. Quando o texto é o elemento de LCP, a estratégia de carregamento da fonte afeta diretamente sua pontuação de LCP. Nas 76% das páginas restantes onde uma imagem é o elemento de LCP, as fontes continuam competindo pela largura de banda inicial da rede e podem atrasar o carregamento da imagem.

Vamos considerar o exemplo abaixo de um site de jornal holandês. Em um dispositivo mobile, 3 fontes são colocadas na fila antes do elemento de LCP. Isso faz com que as 3 fontes compitam por recursos iniciais da rede e atrase o tempo da imagem.

Entendendo font-display: optional vs swap

Antes de mergulhar na estratégia responsiva, você precisa entender os dois valores de font-display nos quais ela se baseia. Para uma visão geral mais ampla de font-display, veja como garantir que o texto permaneça visível durante o carregamento de webfont.

font-display: swap exibe a fallback font imediatamente e troca para a fonte personalizada assim que ela carrega. Isso é ótimo para o LCP, pois o texto fica visível desde o início. A desvantagem: quando a fonte personalizada chega e substitui a fallback, as diferentes métricas da fonte podem causar um layout shift visível, prejudicando sua pontuação de CLS. Cerca de 50% dos sites usam swap, tornando-o de longe o valor mais popular.

font-display: optional dá ao navegador cerca de 100ms para carregar a fonte. Se a fonte chegar a tempo (geralmente do cache ou de um preload rápido), ela é usada. Caso contrário, a fallback font será usada durante todo o carregamento da página e não ocorrerá nenhuma troca. Isso significa zero layout shifts, mas a fonte personalizada pode não aparecer na primeira visita. Apenas 0,5% dos sites usam optional, apesar de ser a opção mais segura para o CLS.

Desde o Chrome 83, combinar font-display: optional com <link rel="preload"> bloqueia o first paint em até ~100ms (com um máximo absoluto de 1500ms), aguardando a chegada da fonte. Se a fonte for preloaded, ela quase sempre chegará dentro dessa janela. O resultado: texto estilizado no first paint, zero FOUT, zero layout shifts. É por isso que a parte desktop da estratégia responsiva funciona tão bem.

Estratégia de fonte responsiva ao resgate!

Em casos como esse, onde há muita competição inicial na rede, faz sentido fazer a distinção entre tipos de dispositivos. Normalmente, dispositivos desktop mais rápidos em conexões com fio (e conexões de rede mais rápidas) conseguem lidar com mais recursos de rede iniciais ao mesmo tempo e faz todo sentido fazer o preload de alguns arquivos críticos de fonte.

Dispositivos mobile, por outro lado, podem ser usados no trajeto para o trabalho, sob condições de rede não ideais. Dispositivos mobile também costumam ter CPUs mais lentas e menos memória disponível em comparação com desktops. Essas limitações significam que tratar o carregamento de fontes de forma diferente com base no tipo de dispositivo pode fazer sentido.

• Desktop: Fazer o preloading de fontes melhora o desempenho de renderização em dispositivos com melhor largura de banda e poder de processamento. Use font-display: optional para eliminar problemas de troca de fonte. Combinado com um preload, o Chrome bloqueará brevemente a renderização (em até ~100ms) para aguardar a fonte, entregando a você um texto estilizado no first paint com zero CLS.
• Mobile: Não faça o preload da fonte por causa da competição de rede. Use font-display: swap para uma renderização de texto mais rápida. Essa abordagem exibe fallback fonts imediatamente enquanto a fonte personalizada continua carregando em background, oferecendo uma melhor experiência em dispositivos menos potentes.

Implementação usando <link rel="preload"> e media queries

Em vez de carregar a fonte universalmente, você pode usar o atributo media na tag <link> do HTML junto com CSS para aplicar diferentes estratégias de fonte com base nos tipos de dispositivos.

Implementação completa

<head>
  <!-- viewport meta DEVE vir antes dos preloads condicionais de media -->
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <!-- Preload de fonte apenas para desktop -->
  <link rel="preload" href="/fonts/custom-font.woff2"
        as="font" type="font/woff2" crossorigin
        media="(min-width: 768px)">

  <style>
    /* Mobile: swap garante a renderização rápida do texto */
    @font-face {
        font-family: 'CustomFont';
        src: url('/fonts/custom-font.woff2') format('woff2');
        font-display: swap;
    }

    /* Desktop: optional + preload = texto estilizado no first paint */
    @media (min-width: 768px) {
        @font-face {
            font-family: 'CustomFont';
            src: url('/fonts/custom-font.woff2') format('woff2');
            font-display: optional;
        }
    }

    body {
        font-family: 'CustomFont', sans-serif;
    }
  </style>
</head>

Alguns detalhes importantes sobre esta implementação:

1. Ordenação da tag meta viewport: A tag <meta name="viewport"> deve aparecer antes do link de preload. O preload scanner do navegador avalia o atributo media antes de analisar outras tags meta. Se o viewport não for definido, a media query será avaliada com dimensões incorretas em dispositivos mobile.
2. Declarações completas de @font-face: Cada bloco @font-face deve incluir tanto font-family quanto src. Ao contrário das propriedades CSS normais, os descritores @font-face não caem em cascata. Você não pode sobrescrever apenas o font-display em um segundo bloco sem redeclarar a font face completa. O navegador irá descartar uma regra @font-face incompleta.
3. O atributo crossorigin: Fontes com preloaded sem crossorigin serão buscadas duas vezes. Sempre inclua esse atributo em preloads de fonte, mesmo para fontes de mesma origem.
4. Combinando breakpoints: O atributo media no preload (768px) deve corresponder à media query do CSS (768px). Se eles não corresponderem, você fará o preload em um breakpoint e aplicará o font-display incorreto em outro.

Reduzindo layout shifts no mobile com o matching da fallback font

A estratégia mobile usa font-display: swap, o que significa que haverá um breve Flash Of Unstyled Text quando a fonte personalizada substituir a fallback. Você pode minimizar esse salto visual usando substituições de métricas de fontes no CSS:

@font-face {
    font-family: 'CustomFont Fallback';
    src: local('Arial');
    ascent-override: 105%;
    descent-override: 25%;
    size-adjust: 97%;
}

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

Os descritores ascent-override, descent-override e size-adjust permitem combinar as dimensões da fallback font com as da fonte personalizada. Quando o swap acontece, o texto quase não se move. Esses descritores são suportados em todos os navegadores modernos. Bibliotecas como Capsize podem calcular os valores corretos de override para suas fontes específicas automaticamente.

Benefícios dessa abordagem

• UX no Desktop: O desktop renderiza com a fonte web no first paint, prevenindo tanto o FOUT quanto o FOIT. Zero layout shifts provenientes do carregamento da fonte.
• Desempenho mobile: font-display: swap garante que os usuários vejam o texto imediatamente, mesmo que a fonte personalizada ainda não esteja carregada. Nenhum preload significa que as fontes não competem com a imagem de LCP por largura de banda.
• Simplicidade declarativa: Puro HTML e CSS. Sem JavaScript, sem bibliotecas de carregamento de fontes, sem dependências de frameworks. Isso também significa que funciona com qualquer estratégia de priorização de recursos que você já tenha em vigor.

Impacto no mundo real

Essa estratégia baseia-se em um exemplo do mundo real que encontrei ao auditar um site de e-commerce. O site carregava 3 fontes personalizadas: uma fonte de título, uma fonte de texto principal e uma fonte de ícones. No desktop, tudo carregava rápido o suficiente para que as fontes raramente causassem problemas. Mas no mobile via 4G, os três preloads de fontes competiam com a hero image e empurravam o LCP bem acima do limite de 2,5 segundos.

Após implementar a estratégia responsiva (fazer preloading apenas no desktop, remover os preloads de fonte no mobile):

• Desktop: Melhoria no CLS e na UX com fontes estilizadas aparecendo no first paint. A combinação de preload + font-display: optional eliminou todos os layout shifts relacionados a fontes.
• Mobile: First Contentful Paint e Largest Contentful Paint mais rápidos porque as fontes não competiam mais pela largura de banda inicial. A hero image carregava sem disputa.

A pesquisa da DebugBear confirma o impacto: o preloading de fontes pode melhorar o LCP em cerca de 30% (de 1.82s para 1.24s) quando aplicado corretamente. Mas, quando usado em excesso (um site tinha 38 fontes em preloaded), o preloading piora as coisas. A abordagem responsiva fornece a você o benefício do preloading no desktop sem o custo no mobile.

Em sites monitorados pelo CoreDash, cerca de 82% dos carregamentos de página no mobile passam no LCP quando as fontes recebem um preload estratégico, em comparação com 70% das páginas que carregam todas as fontes da mesma forma, independentemente do tipo de dispositivo. No desktop, onde a combinação preload + optional funciona melhor, a lacuna é ainda maior.

Quando usar esta estratégia (e quando não usar)

Use esta estratégia quando:

• Seu site carrega 2 ou mais arquivos de fonte personalizadas
• Mobile e desktop possuem diferentes perfis de performance nos Core Web Vitals (comum em sites onde o mobile sofre com o LCP enquanto o desktop passa)
• As fontes estão competindo com outros recursos críticos (hero images, CSS crítico) no mobile
• Você está hospedando suas fontes localmente (essa estratégia funciona com qualquer hospedagem de fontes, mas hospedá-las localmente fornece a você o controle total sobre o caminho do preload)

Ignore esta estratégia quando:

• Você carrega apenas uma fonte WOFF2 leve (abaixo de 20 KB). O custo adicional do carregamento responsivo não vale a pena.
• Seu site já passa em todos os Core Web Vitals tanto no mobile quanto no desktop. Não adicione complexidade a um problema que você não possui.
• Você utiliza fontes do sistema. Se você já estiver usando font-family: system-ui, sans-serif, não há nada para otimizar.

Após implementar essa ou qualquer outra estratégia de carregamento de fontes, monitore o impacto com Real User Monitoring para confirmar se a mudança realmente melhorou seus dados de campo. Testes de laboratório podem perder a variabilidade nas condições reais de rede que tornam essa estratégia valiosa em primeiro lugar.