...
logótipo de alojamento web

Porque é que o WordPress perde tempo de carregamento com muitos tipos de letra da Web: dicas de otimização

Muitos Fontes Web para WordPress carregam em paralelo, bloqueiam a renderização e, assim, prolongam o LCP e o FCP - especialmente em dispositivos móveis. Neste artigo, vou mostrar-lhe porque é que demasiados tipos de letra custam tempo, como ocorre o FOIT/FOUT e quais as medidas específicas que irão acelerar visivelmente o seu sítio.

Pontos centrais

  • Redução a alguns cortes reduz os pedidos e a transferência de dados
  • Pré-carga e Preconnect dão prioridade aos ficheiros importantes
  • exibição de fonte Evita o texto invisível (FOIT)
  • Local o alojamento poupa latências externas e CORS
  • Subconjunto remove glifos não utilizados e torna as fontes pequenas

Porque é que muitas fontes web no WordPress custam tempo de carregamento

Cada fonte adicional traz mais Pedidos, mais pesquisas de DNS e quilobytes adicionais. Várias famílias com regular, negrito e itálico somam rapidamente 500-1000 KB antes de o texto aparecer de forma limpa. Isto tem um efeito direto no Largest Contentful Paint (LCP), porque o navegador só pode renderizar quando os tipos de letra importantes estão disponíveis. Apenas três tipos de letra podem aumentar a primeira renderização em 20-50%, o que afecta fortemente os utilizadores com ligações lentas. Por isso, concentro-me em alguns cortes claramente definidos e em alternativas seguras para evitar o bloqueio de processamento.

Como é que as fontes da Web são carregadas no WordPress - e onde é que ficam presas

As fontes da Web são frequentemente fornecidas por fornecedores externos ou opções de temas, o que significa DNS-lookups e handshakes TLS. Com o FOIT (Flash of Invisible Text), o navegador espera pelos tipos de letra e mostra texto invisível até lá, o que reforça a impressão de que „nada está a acontecer“. O FOUT (Flash of Unstyled Text) é melhor, mas produz pequenos saltos na apresentação quando se muda do tipo de letra de recurso para o tipo de letra da Web. Sem definição de prioridades, pré-conexão e caching sensato, o tempo de carregamento e a sensação de TTFB aumentam. Planeio a integração de modo a que o conteúdo principal apareça sempre em primeiro lugar e que os tipos de letra fluam depois, sem gaguejar.

Auditoria e controlo: tornar visíveis todas as fontes

Antes de otimizar, obtenho uma visão geral completa. No DevTools, filtro no separador Rede por „Tipo de letra“, verificar os nomes dos ficheiros, os tamanhos de transferência e Iniciador (tema, plugin, editor de blocos). Os tempos de cascata mostram-me se os tipos de letra estão a bloquear o caminho crítico. No painel Coverage, posso ver se os blocos CSS @font-face grandes apenas mínima pode ser utilizado. Um rastreio do desempenho revela se a renderização do texto bloqueia até os ficheiros WOFF2 estarem prontos. Ao nível do WordPress, desactivei os plugins numa base de teste para identificar fontes de fontes ocultas (construtores de páginas, pacotes de ícones). As minhas principais métricas são: número de pedidos de fontes, KB total, tempo até à primeira linha legível, duração de FOUT/FOIT e impacto no LCP/FCP na película de filme.

Comparo dados de laboratório e de campo: Um ambiente de trabalho rápido através da LAN oculta problemas que só se tornam visíveis na rede 4G. É por isso que testo com baixa CPU e limitação de largura de banda para simular condições móveis realistas. Só quando as cadeias estão limpas e os fallbacks são renderizados de forma estável é que adiciono mais ajustes de erros tipográficos.

Efeitos mensuráveis nos Core Web Vitals

O LCP, o FCP e o CLS reagem de forma sensível a cargas imprudentes Fontes, porque os tipos de letra atrasados alteram as disposições e obscurecem o conteúdo. De acordo com o HTTP Archive, as páginas com fontes da Web transferem significativamente mais dados em média, o que é mais visível em dispositivos móveis. A documentação do PageSpeed Insights explica claramente que os recursos de bloqueio de processamento prolongam o caminho para a primeira visualização. Os pedidos prioritários encurtam esta cadeia e reduzem visivelmente os tempos de espera. Se quiser aprofundar a definição de prioridades, pode encontrar informações de base em Priorização de pedidos, que utilizo especificamente para temas extensos.

Causas técnicas em pormenor

Muitos ficheiros individuais, estilos não combinados e subconjuntos em falta aumentam o Carga útil desnecessário. Sem HTTP/2 ou HTTP/3, os pedidos são frequentemente colocados em fila de espera e bloqueiam o caminho de renderização. Os domínios externos, como fonts.googleapis.com, acrescentam latências adicionais, que se somam para várias famílias. Os cabeçalhos CORS são necessários, caso contrário o navegador cancela os pré-carregamentos ou não os utiliza. Evito estes obstáculos através da disponibilização local, de cabeçalhos bem definidos e da limitação direcionada a dois ou três cortes.

Evitar armadilhas tipográficas: Métricas, qualidade de recurso e estilos falsos

Para além do tamanho do ficheiro puro, os detalhes da gralha influenciam a estabilidade da visualização. Se as métricas da fonte de recurso e da fonte Web forem muito diferentes, ocorrem saltos visíveis durante a troca. Eu igualo a altura por ajustar o tamanho e bloquear estilos sintéticos para evitar „falsos“ negritos/itálicos:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/Inter-roman.var.woff2') format('woff2');
  peso da fonte: 100 900;
  estilo da fonte: normal;
  font-display: swap;
  /* Ajustar as métricas para reduzir o CLS */
  size-adjust: 100%;
  ascent-override: 90%;
  substituição de descida: 20%;
  line-gap-override: 0%;
}

/* Harmonizar visualmente o tipo de letra de recurso */
corpo {
  font-family: system-ui, -apple-system, Segoe UI, Roboto, Inter, sans-serif;
  font-size-adjust: 0.5; /* Melhor ajuste da altura x */
  font-synthesis: none; /* Evita o falso negrito/itálico */
}

Defino um eixo separado ou um ficheiro estático para as variantes em itálico e evito os itálicos falsos. Também organizo peso da fonte com precisão (300/400/600/700) para que o browser não interpole. Este trabalho de precisão demora pouco tempo, mas evita alterações de layout perceptíveis quando se muda do tipo de letra de recurso para o tipo de letra da Web.

Racionalização: três medidas imediatas

Reduzo o número de famílias, substituo os cortes decorativos por alternativas e utilizo sistematicamente exibição de fonteswap. As pilhas de sistema (-apple-system, Segoe UI, Roboto, Noto Sans, Ubuntu, Cantarell) produzem texto rapidamente enquanto o tipo de letra da Web é carregado em segundo plano. Normalmente, os títulos apenas requerem um corte a negrito e o corpo do texto uma variante regular. Também removo chamadas remotas desnecessárias para gerar menos pedidos. Se quiser tirar ainda mais partido, pode Reduzir os pedidos HTTP e, assim, aliviar todo o caminho crítico.

Substituir os tipos de letra dos ícones: SVG guarda pedidos

Muitos temas vêm com fontes de ícones (por exemplo, para ícones sociais ou de IU). Um único tipo de letra de ícone pode pesar entre 30 e 80 KB e pode ser @font-face influenciam o caminho de renderização. Substituo esses tipos de letra por SVG - em linha ou como um sprite. Isto reduz os pedidos, evita o FOIT/FOUT para os ícones e garante uma visualização nítida em todos os ecrãs. Se não for possível uma mudança completa imediatamente, sub-selecciono o tipo de letra dos ícones para os pictogramas que são realmente utilizados e defino apresentação da fonte: opcional, para que a página nunca fique à espera do tipo de letra do ícone:

@font-face {
  font-family: 'ThemeIcons';
  src: url('/fonts/theme-icons-subset.woff2') format('woff2');
  font-display: opcional; /* A interface do utilizador permanece operacional, os ícones aparecem mais tarde */
}

O SVG em linha também me permite controlar as cores e os estados através de CSS sem carregar novos ficheiros. Isto encaixa perfeitamente no objetivo de manter a cadeia de renderização crítica tão curta quanto possível.

Utilizar corretamente a pré-carga, a pré-conexão e o pré-aquecimento

Utilizo o Preconnect para os momentos decisivos Domínio, para dar prioridade ao DNS, TCP e TLS. Só utilizo o pré-carregamento para ficheiros WOFF2 realmente críticos, caso contrário, desperdiço a prioridade em recursos secundários. A etiqueta tem de definir as=“font“, type=“font/woff2″ e crossorigin, caso contrário o navegador ignorará parcialmente a sugestão. Demasiados pré-carregamentos sabotam-se mutuamente e empurram conteúdos mais importantes para segundo plano. Um conjunto de sugestões simples e testadas reduz o tempo até à primeira linha legível:

Alojar localmente e manter a conformidade com o RGPD

Descarrego os tipos de letra de que necessito, subconjunto-os e sirvo-os diretamente a partir do meu próprio Servidor. Isto poupa pesquisas externas de DNS, reduz os problemas de CORS e dá-me controlo total da cache. Uma abordagem local facilita longos tempos de execução da cache e garante uma disponibilidade consistente. Para clareza jurídica e implementação prática, o meu guia para Google Fonts local. É assim que mantenho a tecnologia e a proteção de dados limpas sem sacrificar a tipografia.

Subconjunto e fontes variáveis: efeito máximo com tamanho reduzido

Em vez de carregar pacotes de idiomas completos, mantenho apenas os Glifos e remover conjuntos exóticos. O latim sem extensões poupa frequentemente 40 a 70% do tamanho do ficheiro, o que é particularmente notório em dispositivos móveis. As fontes variáveis substituem vários ficheiros estáticos por um único recurso com eixos para peso e itálico. Isto reduz os pedidos e melhora a definição de prioridades se eu só pré-carregar um ficheiro WOFF2. Ao mesmo tempo, a diversidade visual é mantida sem ter de transferir cinco secções individualmente.

Fontes variáveis na prática: utilização orientada dos eixos

Na realização, evito áreas de eixo desnecessariamente largas. Limito peso por exemplo, para 400-700 se forem utilizados apenas Regular e Negrito. Isto reduz a complexidade da renderização e mantém a consistência visual. Para tipografia reactiva, utilizo sistematicamente pesos numéricos e não palavras-chave:

@font-face {
  font-family: 'InterVar';
  src: url('/fonts/Inter-roman.var.woff2') format('woff2');
  peso da fonte: 400 700; /* Gama estreita em vez de 100-900 */
  estilo da fonte: normal;
  font-display: swap;
}

h1, h2 { font-family: 'InterVar', system-ui, sans-serif; font-weight: 700; }
p { font-family: 'InterVar', system-ui, sans-serif; font-weight: 400; }

:root { font-optical-sizing: auto; }
/* Casos especiais por eixo, se for caso disso:
.element { font-variation-settings: 'wght' 650; } */

Isto mantém a flexibilidade de uma fonte variável sem sobrecarregar o sistema com fases intermédias desnecessárias.

Que otimização traz quanto? (Visão geral)

A visão geral que se segue mostra o que utilizo na prática para obter os melhores resultados. Poupança e aquilo a que presto atenção. Os valores são intervalos empíricos e dependem do estado inicial, do tema e do número de edições. Testo todas as alterações com o PageSpeed Insights e uma execução do WebPageTest para reconhecer efeitos secundários. Em seguida, faço ajustes direcionados aos valores limite e ao armazenamento em cache. Isto aumenta a certeza de que cada medida ganha em tempo real.

Abordagem de otimização Poupanças típicas Nota importante
Redução para 2 cortes 150-400 KB Limpo Recuos definir
apresentação da fonte: swap + texto de leitura rápida Aceitar FOUT em vez de FOIT
Alojamento local + cache longo 2-3 pedidos a menos Controlo da cache/ETag correto
Pré-conexão + pré-carga direcionada 50-200 ms Apenas crítico Arquivos
Subconjunto (base latina) 40-70 % mais pequeno Expansível numa data posterior
Tipo de letra variável em vez de 4 ficheiros -3 Pedidos Utilizar apenas WOFF2

Utilizar os plugins de forma sensata - sem sobrecargas

O OMGF carrega as fontes do Google localmente, faz automaticamente subconjuntos e encurta fontes desnecessárias Sinal sair. O Asset CleanUp permite-me desativar os tipos de letra página a página se um modelo específico não precisar deles. O Autoptimise combina CSS, minifica e pode extrair fontes para que os estilos críticos venham primeiro. Testo as combinações cuidadosamente porque a agregação excessiva sob HTTP/2 pode ser contraproducente. O objetivo continua a ser uma cadeia estável e curta até ao primeiro conteúdo visível.

Implementação prática no WordPress: exemplos de código

Muitos temas ou construtores de páginas incluem fontes automaticamente. Removo fontes duplicadas, mudo para ficheiros locais e defino prioridades claras - de preferência no tema filho.

1) Remover as fontes externas do tema e carregar fontes locais

/* functions.php no tema filho */
add_action('wp_enqueue_scripts', function() {
  /* Personalizar/encontrar exemplos de identificadores do tema/construtor */
  wp_dequeue_style('google-fonts');
  wp_deregister_style('google-fonts');

  /* Incluir os seus próprios estilos de letra locais */
  wp_enqueue_style('local-fonts', get_stylesheet_directory_uri() . '/assets/css/fonts.css', [], '1.0', 'all');
}, 20);

2) Pré-carga direcionada para o WOFF2 crítico

/* functions.php */
add_action('wp_head', function() {
  echo '';
}, 1);

3) Definir a colocação em cache e o cabeçalho CORS para os tipos de letra

# .htaccess (Apache)

  AddType font/woff2 .woff2



  Header set Cache-Control "public, max-age=31536000, immutable"
  Header set Access-Control-Allow-Origin "*"
# Nginx (bloco do servidor)
localização ~* .(woff2|woff)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
  add_header Access-Control-Allow-Origin "*";
  types { font/woff2 woff2; }
}

4) Exemplo de fonts.css com subconjuntos e troca

@font-face {
  font-family: 'Inter';
  src: url('/fonts/InterLatin-400.woff2') format('woff2');
  peso da fonte: 400;
  estilo da fonte: normal;
  exibição da fonte: swap;
  unicode-range: U+000-5FF; /* Base latina */
}

@font-face {
  font-family: 'Inter';
  src: url('/fonts/InterLatin-700.woff2') format('woff2');
  peso da fonte: 700;
  estilo da fonte: normal;
  exibição da fonte: swap;
  unicode-range: U+000-5FF;
}

Páginas multilingues: Carregar subconjuntos por localidade

Para projectos internacionais, carrego apenas as fontes necessárias. No WordPress, posso carregar por Localidade registam estilos diferentes. Por exemplo, o alemão/inglês mantém-se com um subconjunto latino fino, enquanto uma variante polaca ou turca recebe glifos alargados - mas somente onde é necessário.

/* functions.php */
add_action('wp_enqueue_scripts', function() {
  $locale = get_locale();

  if (in_array($locale, ['de_DE','en_US','en_GB'])) {
    wp_enqueue_style('fonts-latin', get_stylesheet_directory_uri().'/assets/css/fonts-latin.css', [], '1.0');
  } elseif (in_array($locale, ['pl_PL','tr_TR'])) {
    wp_enqueue_style('fonts-latin-ext', get_stylesheet_directory_uri().'/assets/css/fonts-latin-ext.css', [], '1.0');
  }
});

Importante: Certifico-me de que o corpo do texto tem sempre uma cadeia de recurso sólida do sistema. Isto garante que a página se mantém legível mesmo que um ficheiro de idioma falhe ou uma cache deixe de funcionar.

Alojamento, cache e CDN como multiplicadores

SSDs NVMe rápidos, HTTP/3 e um CDN encurtam o TTFB e fornecem Fontes mais rápido a nível global. Uma cache do lado do servidor reduz os pedidos de backend, enquanto a cache do browser vai buscar as fontes à cache local durante meses. O Brotli para WOFF2 quase não traz mais nada, mas para CSS com @font-face ainda vale a pena. Também dou prioridade às partes críticas das CSS em linha para que o texto apareça imediatamente. Isto cria uma cadeia: backend fixo, entrega limpa, ficheiros de fontes mais pequenos - e no final um texto visível mais rápido.

Plano de teste e implementação: entrar em funcionamento em segurança

Introduzo as optimizações de fontes passo a passo para minimizar os riscos. Em primeiro lugar, documentei o status quo (pedidos, KB, LCP/FCP/CLS). Depois, reduzo as famílias e os cortes, substituo os ícones e mudo para ficheiros WOFF2 locais com uma cache longa. Em seguida, adiciono Preconnect/Preload - deliberadamente com moderação. Depois de cada passo, verifico a película de filme para ver se o FOIT foi reduzido e se os saltos de disposição desapareceram. Só quando não são visíveis mais regressões é que aplico as alterações a todos os modelos.

As páginas com títulos invulgares (tamanhos de letra muito grandes, rastreio) ou com uma forte utilização de itálico são particularmente críticas. Aqui testo especificamente se ajustar o tamanho e as substituições métricas apanham realmente os saltos de recurso. O meu objetivo mantém-se constante: a primeira linha legível o mais cedo possível - sem actos de adestramento devido a fontes tardias.

Breve resumo: tempo de carregamento reduzido, legibilidade aumentada

Demasiados tipos de letra custam muito dinheiro Segundos, porque aumentam os pedidos, bloqueiam a renderização e aumentam o volume de dados. Mantenho os tipos de letra reduzidos, dou prioridade específica e confio na troca, no subconjunto e no alojamento local. Isto diminui de forma fiável o LCP e o FCP e reduz os saltos visuais. Com a monitorização através do PageSpeed Insights e testes repetidos, asseguro o efeito e recolho valores históricos. Isto mantém a tipografia forte sem que os utilizadores tenham de esperar - que é exatamente o que eu quero alcançar.

Artigos actuais