Carregamento de fontes web responsivo: Uma estratégia consciente do dispositivo

Estratégia responsiva de exibição de fontes e pré-carregamento

Como 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 deparo-me com uma estratégia tão simples e tão elegante que faz todo o sentido para certos sites.

De acordo com o 2025 Web Almanac, 88% dos sites usam fontes web, carregando uma média 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 único para todos os casos. Este artigo explica uma abordagem mais inteligente: carregar fontes de forma 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 sobre a consistência visual).

Revisado pela última vez por Arjen Karel em março de 2026

dica: esta estratégia funciona bem para sites com um critical rendering path 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 precoce de fontes

Ao otimizar os Core Web Vitals, há 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 às fontes web. Priorizar o carregamento de fontes web durante o carregamento da página pode melhorar a experiência do usuário, mas se o seu site está lutando para atingir os limites dos Core Web Vitals, especialmente para tipos de dispositivos específicos, você pode precisar equilibrar a UX com a melhoria do LCP.

O capítulo de Performance do 2025 Web Almanac 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 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.

Vamos considerar o exemplo abaixo de um site de jornal holandês. Em um dispositivo móvel, 3 fontes são colocadas na fila antes do elemento LCP. Isso faz com que as 3 fontes competiam pelos recursos de rede iniciais 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 nos quais ela se baseia. Para uma visão mais ampla do font-display, veja como garantir que o texto permaneça visível durante o carregamento da webfont.

font-display: swap mostra a fonte de fallback imediatamente e troca pela fonte personalizada assim que ela carrega. Isso é ótimo para o LCP porque o texto fica visível desde o início. A desvantagem: quando a fonte personalizada chega e substitui a de fallback, as diferentes métricas da fonte podem causar um desvio de layout 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 fonte de fallback é usada para todo o carregamento da página e nenhuma troca ocorre. Isso significa zero desvios de layout, 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 a primeira pintura por até ~100ms (com um máximo absoluto de 1500ms), esperando que a fonte chegue. Se a fonte for pré-carregada, ela quase sempre chega dentro dessa janela. O resultado: texto estilizado na primeira pintura, zero FOUT, zero desvios de layout. É por isso que o lado desktop da estratégia responsiva funciona tão bem.

Estratégia de fonte responsiva para o resgate!

Em casos como este, 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) podem lidar com mais recursos de rede iniciais de uma só vez e faz todo o sentido fazer o preload de alguns arquivos de fonte críticos.

Dispositivos móveis, por outro lado, podem ser usados no trajeto para o trabalho sob condições de rede menos que ideais. Dispositivos móveis 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: O preloading de fontes melhora a performance 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 (até ~100ms) para esperar pela fonte, fornecendo texto estilizado na primeira pintura com zero CLS.
• Mobile: Não faça o preload da fonte devido à competição de rede. Use font-display: swap para uma renderização de texto mais rápida. Esta abordagem exibe fontes de fallback imediatamente enquanto a fonte personalizada continua a carregar em segundo plano, oferecendo 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 diferentes estratégias de fonte com base nos tipos de dispositivos.

Implementação completa

<head>
  <!-- viewport meta DEVE vir antes dos preloads condicionais por mídia -->
  <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 na primeira pintura *\/
    @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 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 analisar outras meta tags. Se o viewport não estiver definido, a media query será avaliada contra as dimensões erradas em dispositivos móveis.
2. Declarações @font-face completas: Cada bloco @font-face deve incluir tanto font-family quanto src. Ao contrário das propriedades CSS regulares, os descritores @font-face não se aplicam em cascata. Você não pode substituir apenas o font-display em um segundo bloco sem redeclarar toda a fonte. O navegador descartará uma regra @font-face incompleta.
3. O atributo crossorigin: Fontes pré-carregadas sem crossorigin serão buscadas duas vezes. Sempre o inclua em preloads de fontes, mesmo para fontes de mesma origem.
4. Breakpoints correspondentes: 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 errado em outro.

Reduzindo desvios de layout no mobile com correspondência de fonte de fallback

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 de fallback. Você pode minimizar esse salto visual usando sobreposições de métricas de fonte CSS (font metric overrides):

@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ê combine as dimensões da fonte de fallback com a fonte personalizada. Quando a troca acontece, o texto mal se move. Esses descritores são suportados em todos os navegadores modernos. Bibliotecas como Capsize podem calcular os valores de sobreposição corretos para suas fontes específicas automaticamente.

Benefícios desta abordagem

• UX de Desktop: O desktop renderiza com a fonte web na primeira pintura, evitando tanto o FOUT quanto o FOIT. Zero desvios de layout causados pelo carregamento de fontes.
• Performance Mobile: font-display: swap garante que os usuários vejam o texto imediatamente, mesmo que a fonte personalizada ainda não tenha sido carregada. Sem preload significa que as fontes não competem com a imagem LCP por largura de banda.
• Simplicidade declarativa: HTML e CSS puros. Sem JavaScript, sem bibliotecas de carregamento de fontes, sem dependências de framework. 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

Esta estratégia é baseada em um exemplo real que encontrei ao auditar um site de e-commerce. O site carregava 3 fontes personalizadas: uma fonte de título, uma fonte de corpo 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 estavam competindo com a imagem hero e empurrando o LCP bem acima do limite de 2,5 segundos.

Após implementar a estratégia responsiva (preloading apenas no desktop, removendo preloads de fontes no mobile):

• Desktop: Melhoria no CLS e UX com fontes estilizadas aparecendo na primeira pintura. A combinação de preload + font-display: optional eliminou todos os desvios de layout 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 imagem hero carregou sem disputa.

Pesquisas do DebugBear confirmam 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 pré-carregadas), o preloading piora as coisas. A abordagem responsiva oferece o benefício do preloading no desktop sem o custo no mobile.

Em sites monitorados pelo CoreDash, cerca de 82% dos carregamentos de páginas mobile passam no LCP quando as fontes são pré-carregadas estrategicamente, em comparação com 70% para páginas que carregam todas as fontes da mesma forma, independentemente do tipo de dispositivo. No desktop, onde a combinação de preload + optional funciona melhor, a diferença é 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 personalizada
• Mobile e desktop têm perfis de performance de Core Web Vitals diferentes (comum em sites onde o mobile luta com o LCP enquanto o desktop passa)
• Fontes estão competindo com outros recursos críticos (imagens hero, CSS crítico) no mobile
• Você está auto-hospedando suas fontes (esta estratégia funciona com qualquer hospedagem de fontes, mas a auto-hospedagem dá controle total sobre o caminho do preload)

Ignore esta estratégia quando:

• Você carrega apenas uma fonte WOFF2 leve (menos de 20 KB). O overhead 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 tem.
• Você depende de fontes do sistema. Se você já está usando 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 seus dados de campo. Testes de laboratório podem perder a variabilidade nas condições reais de rede que torna esta estratégia valiosa em primeiro lugar.