Carregamento Responsivo de Fontes Web: Uma Estratégia Sensível ao Dispositivo

Estratégia responsiva de font display & preloading

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

De acordo com o Web Almanac 2025, 88% dos sites usam web fonts. Eles carregam uma mediana de 4 arquivos de fonte por página. Porém, apenas 12% dos sites fazem o preload de fontes. Míseros 0,5% usam font-display: optional. A maioria dos sites trata o carregamento de fontes como uma solução única que serve para tudo. Este artigo explica uma abordagem mais inteligente: carregar fontes de forma diferente para desktop e mobile.

A estratégia combina 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).

Última revisão por Arjen Karel em março de 2026

dica: esta estratégia funciona bem para sites com um caminho crítico de renderização maior. Ou seja, sites que carregam múltiplas fontes, folhas de estilo e scripts antes do elemento 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, uma regra simples 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 às web fonts. Priorizar o carregamento de web fonts durante o carregamento da página pode melhorar a UX. Mas se o seu site tem dificuldade em atingir os limites dos Core Web Vitals, especialmente em tipos de dispositivos específicos, você precisa equilibrar a UX com a melhoria do LCP.

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

Considere o exemplo abaixo de um site de notícias holandês. Em um dispositivo mobile, 3 fontes entram na fila antes do elemento LCP. Isso faz com que as 3 fontes compitam por recursos iniciais da rede e atrasem 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 em que ela se baseia. Para uma visão geral mais ampla sobre font-display, veja como garantir que o texto continue visível durante o carregamento de webfonts.

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

font-display: optional dá ao navegador cerca de 100ms para carregar a fonte. Se a fonte chega a tempo (geralmente do cache ou de um preload rápido), ela é usada. Se não, a fonte de fallback é usada durante todo o tempo de carregamento da página e nenhuma troca ocorre. Isso significa zero layout shifts. Porém, a fonte customizada 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 por até ~100ms (com um máximo absoluto de 1500ms), esperando a fonte chegar. Se a fonte tem um preload, ela quase sempre chega dentro dessa janela. O resultado: texto estilizado no first paint, zero FOUT, zero layout shifts. É por isso que o lado desktop da estratégia responsiva funciona tão bem.

Estratégia responsiva de fontes ao resgate!

Em casos como esse, onde há muita competição inicial na rede, faz sentido distinguir entre tipos de dispositivos. Normalmente, dispositivos desktop mais rápidos em conexões cabeadas (e mais rápidas) conseguem lidar com mais recursos iniciais de rede de uma vez. Faz todo o sentido fazer o preload de alguns arquivos de fontes críticos.

Dispositivos mobile, por outro lado, podem ser usados no trajeto para o trabalho sob condições de rede não ideais. Eles também costumam ter CPUs mais lentas e menos memória disponível em comparação aos 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 preload de fontes melhora a performance de renderização em dispositivos com mais largura de banda e poder de processamento. Use font-display: optional para eliminar problemas de troca de fontes. Em combinação com um preload, o Chrome bloqueia a renderização brevemente (até ~100ms) para esperar a fonte. Isso entrega texto estilizado no first paint com zero CLS.
• Mobile: Não faça o preload da fonte devido à competição na rede. Use font-display: swap para uma renderização de texto mais rápida. Essa abordagem exibe fontes de fallback imediatamente enquanto a fonte customizada continua carregando em segundo plano. Isso oferece uma experiência melhor 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 estratégias de fontes diferentes com base nos tipos de dispositivos.

Implementação completa

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

  <!-- Preload da 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 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. Ordem da meta tag viewport: A tag <meta name="viewport"> deve aparecer antes do link de preload. O preload scanner do navegador avalia o atributo media antes de processar outras meta tags. Se o viewport não estiver definido, a media query será avaliada em relação às dimensões erradas em dispositivos mobile.
2. Declarações completas de @font-face: Cada bloco @font-face deve incluir font-family e src. Ao contrário das propriedades normais de CSS, descritores @font-face não têm cascata. Você não pode sobrescrever apenas font-display em um segundo bloco sem redeclarar toda a font face. O navegador descarta uma regra @font-face incompleta.
3. O atributo crossorigin: Fontes com preload sem crossorigin são baixadas duas vezes. Sempre o inclua em preloads de fontes, mesmo para fontes da mesma origem.
4. Breakpoints correspondentes: O atributo media no preload (768px) deve bater com a media query do CSS (768px). Se não baterem, você fará o preload em um breakpoint e aplicará o font-display errado em outro.

Reduzindo layout shifts no mobile ajustando a fonte de fallback

A estratégia mobile usa font-display: swap. Isso significa que haverá um breve Flash Of Unstyled Text quando a fonte customizada substituir o fallback. Você pode minimizar esse salto visual usando sobrescritas 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 que você iguale as dimensões da fonte de fallback à fonte customizada. 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 as suas fontes específicas automaticamente.

Benefícios desta abordagem

• UX no desktop: O desktop renderiza com a web font no first paint, evitando tanto o FOUT quanto o FOIT. Zero layout shifts pelo carregamento de fontes.
• Performance no mobile: font-display: swap garante que os usuários vejam o texto imediatamente, mesmo que a fonte customizada ainda não tenha carregado. A ausência de preload significa que as fontes não competem com a imagem LCP pela largura de banda.
• Simplicidade declarativa: HTML e CSS puros. 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á utilize.

Impacto no mundo real

Esta estratégia se baseia em um exemplo do mundo real que encontrei ao auditar um site de e-commerce. O site carregava 3 fontes customizadas: uma fonte de títulos, uma fonte de texto e uma fonte de ícones. No desktop, tudo carregava tão rápido que as fontes raramente causavam problemas. Mas no mobile no 4G, os três preloads de fontes competiam com a hero image. Isso empurrava o LCP para muito além do limite de 2,5 segundos.

Após implementar a estratégia responsiva (fazendo preload apenas no desktop, removendo os preloads de fonte no mobile):

• Desktop: CLS e UX melhorados 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 competem mais por largura de banda inicial. A hero image carregou sem disputa.

A pesquisa da DebugBear confirma o impacto: o preload 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 com preload), o preload piora a situação. A abordagem responsiva entrega o benefício do preload no desktop sem o custo no mobile.

Entre os sites monitorados pelo CoreDash, cerca de 82% dos carregamentos de página mobile passam no LCP quando as fontes recebem preload de forma estratégica. Isso é comparado a 70% das páginas que carregam todas as fontes da mesma maneira, independentemente do tipo de dispositivo. No desktop, onde a combinação preload + optional funciona melhor, a diferença é ainda maior.

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

Use esta estratégia quando:

• O seu site carrega 2 ou mais arquivos de fontes customizadas
• O mobile e o desktop têm perfis de performance de Core Web Vitals diferentes (comum em sites onde o mobile sofre com o LCP enquanto o desktop passa)
• As fontes competem com outros recursos críticos (hero images, CSS crítico) no mobile
• Você faz o self-host das suas fontes (esta estratégia funciona com qualquer hospedagem de fontes, mas o self-hosting dá controle total sobre o caminho do preload)

Ignore esta estratégia quando:

• Você carrega apenas uma fonte WOFF2 leve (abaixo de 20 KB). O overhead do carregamento responsivo não vale a pena.
• O 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 tem.
• Você depende de system fonts. Se você já usa font-family: system-ui, sans-serif, não há nada para otimizar.

Após implementar esta ou qualquer estratégia de carregamento de fontes, monitore o impacto com Real User Monitoring para confirmar que a mudança realmente melhorou a sua field data. Os testes de laboratório podem não captar a variabilidade nas condições reais de rede que torna esta estratégia valiosa desde o princípio.