Guia do Core Web Vitals para Priorização de Recursos

Guia do Core Web Vitals para Priorização de Recursos

O mecanismo padrão de priorização do navegador opera com base em heurísticas: suposições imperfeitas baseadas nos tipos de arquivo e na localização do documento. Os recursos são enfileirados com base no momento em que são descobertos pelo preload scanner ou pelo analisador do DOM.

Revisado pela última vez por Arjen Karel em fevereiro de 2026

Isso pode se tornar um problema quando você considera que a largura de banda da rede e a CPU não são recursos ilimitados. Por exemplo: cada byte transferido para um script de rastreamento de baixa prioridade, enquanto é baixado ao mesmo tempo, compete diretamente com os bytes necessários para o seu Largest Contentful Paint (LCP).

A culpa não é do navegador: no HTML do nosso exemplo, o navegador não tinha como saber que priorizou os ativos errados, o que atrasou a renderização crítica.

Você é quem sabe o que é importante e controla esse cronograma por meio de dois mecanismos: Priorização (impulsionando sinais críticos) e Despriorização (agendando recursos não críticos para quando forem menos intrusivos).

Limitações das Heurísticas do Navegador

Os navegadores atribuem prioridade com base em uma pontuação de "prioridade computada". Essa pontuação deriva do tipo de ativo (CSS, Script, Imagem) e de sua posição no HTML/DOM. Embora geralmente eficaz para documentos simples, esse sistema falha quando os recursos não são reconhecidos precocemente (pelo preload scanner) ou quando os recursos errados são acionados para um download inicial.

Níveis de Prioridade Padrão do Chrome

O Chrome usa cinco níveis internos de prioridade: Highest (Mais alta), High (Alta), Medium (Média), Low (Baixa) e Lowest (Mais baixa). Veja como ele as atribui por padrão:

O atributo fetchpriority é suportado nos elementos <img>, <link> e <script>. Ele tem 93% de suporte global nos navegadores (Chrome 102+, Firefox 132+, Safari 17.2+, Edge 102+) e é um aprimoramento progressivo: os navegadores que não o suportam simplesmente o ignoram. De acordo com o Web Almanac de 2025, 17% das páginas mobile agora usam fetchpriority="high", mas apenas 0,3% usam fetchpriority="low". Isso significa que a despriorização é uma otimização massivamente subutilizada.

A Limitação do Preload Scanner

Para acelerar a descoberta, os navegadores empregam um "preload scanner", um analisador leve que corre à frente do analisador principal de HTML para encontrar URLs de recursos. Esse scanner tem limitações (que o tornam rápido e eficaz): Ele analisa apenas HTML. Ele não consegue ver dentro de arquivos CSS, não executa JavaScript e não renderiza (portanto, não consegue determinar se os recursos estão visíveis na viewport).

Como consequência, qualquer recurso referenciado em uma folha de estilos (como uma imagem de fundo ou uma fonte web), injetado por um script, ou carregado de forma assíncrona (lazy loaded), é ignorado até que o analisador principal baixe e processe toda a página web. Isso cria um "atraso na descoberta", onde o navegador fica efetivamente alheio à existência de ativos críticos.

Contenção de Recursos

Quando o navegador descobre os ativos, ele frequentemente tenta baixá-los simultaneamente com outras solicitações pendentes. Se uma imagem importante do LCP competir com um script de prioridade média ou imagens sem importância (como ícones de mídias sociais no rodapé), eles dividem a largura de banda disponível. Essa contenção estende o tempo de carregamento de ambos, empurrando a métrica do LCP para a zona "Needs Improvement" (Precisa melhorar).

Estratégias de Priorização Manual

Para construir um caminho de renderização rápido, você deve intervir manualmente. O objetivo é maximizar a largura de banda para o LCP e minimizá-la para todo o resto. Em sites monitorados pelo CoreDash, 82% dos sites que usam fetchpriority="high" em sua imagem LCP passam no LCP, em comparação com 61% dos sites que não o fazem.

1. Corrija a Descoberta com Preloading

Você deve expor manualmente os ativos ocultos para o preload scanner. Ao mover recursos críticos para o <head> do HTML usando rel="preload", você força o navegador a reconhecê-los imediatamente, eliminando o atraso na descoberta. Para um guia completo, veja nosso guia sobre como fazer o preload da imagem LCP.

A Implementação:

<!-- Expose the font to the scanner immediately -->
<link rel="preload" as="font" type="font/woff2" href="/fonts/inter-bold.woff2" crossorigin>

<!-- Expose the LCP background image immediately -->
<link rel="preload" as="image" href="/images/hero-banner.jpg" fetchpriority="high">

Para uma descoberta ainda mais antecipada, considere 103 Early Hints, que envia sinais de preload ao navegador antes que a resposta HTML chegue.

2. Sobrescreva as Heurísticas do LCP

Navegadores frequentemente atribuem prioridade "Low" ou "Medium" a imagens porque não conhecem as dimensões finais do layout durante a busca inicial. O navegador não consegue determinar se uma imagem é o LCP até que a árvore de renderização seja construída, o que é tarde demais.

A Implementação:

Force o status de prioridade "High" no elemento LCP usando fetchpriority="high". Isso ignora as heurísticas internas e coloca a imagem na frente da fila de download. O Google Flights melhorou seu LCP de 2,6 segundos para 1,9 segundos (uma melhoria de 0,7 segundos) ao adicionar este único atributo.

<!-- Force immediate high-priority fetch -->
<img src="hero.jpg" alt="Hero Product" fetchpriority="high">

O pior erro aqui é o lazy loading da imagem LCP, que ativamente desprioriza o elemento mais importante da página.

3. Despriorize Imagens Sem Importância

Liberar a largura de banda é frequentemente mais eficaz do que aumentar a prioridade. Você deve atrasar explicitamente os ativos não essenciais para liberar o canal de rede para recursos críticos.

A Implementação:

• Abaixo da dobra (Below the fold): Use loading="lazy" para adiar imagens fora da tela até que o usuário role a página.
• Acima da dobra, secundário: Use fetchpriority="low" para slides de carrossel ou elementos visuais secundários que são renderizados inicialmente, mas são menos importantes que o LCP.
• Acima da dobra, visualmente sem importância: Ignore o preload scanner usando loading="lazy" e atribua uma prioridade de largura de banda baixa. Útil para imagens pequenas, como bandeiras ou ícones, que nunca chamam a atenção durante a primeira renderização, mas que podem acionar muitas solicitações iniciais de largura de banda.

<!-- LCP Image: Highest Priority -->
<img src="slide-1.jpg" fetchpriority="high">

<!-- Secondary Carousel Image: Immediate fetch, low bandwidth usage -->
<img src="slide-2.jpg" fetchpriority="low">

<!-- Translation flags: while in the viewport hide them from the preload scanner -->
<img src="dutch-flag.jpg" loading="lazy" fetchpriority="low">

<!-- Off-screen Image: Deferred fetch -->
<img src="footer-promo.jpg" loading="lazy">

4. Controle a Execução de Scripts

O JavaScript bloqueia o analisador do DOM. Se você usa tags <script> padrão, o navegador interrompe a análise do HTML para baixar e executar o arquivo. A execução descontrolada de scripts também prejudica diretamente a Interaction to Next Paint (INP) bloqueando a thread principal.

A Implementação:

• defer: Use para a lógica do aplicativo. Ele é baixado em paralelo (prioridade Baixa) e é executado apenas após o HTML ser totalmente analisado, preservando a ordem de dependência.
• async: Use para scripts de terceiros independentes (como analytics). Ele é baixado em paralelo e é executado imediatamente após a conclusão, desconsiderando a ordem.
• async + fetchpriority="high": Use para scripts assíncronos críticos (como testes A/B) que precisam de download rápido sem bloquear a análise. Isso aumenta a prioridade de download de Low para High, mantendo a execução sem bloqueio.
• Inject: Ignora o preload scanner para que ele não compita com a largura de banda inicial. Scripts injetados são tratados como async.
• Schedule + Inject: Injete scripts em um momento posterior, por exemplo, quando o evento de carregamento (load) for acionado.

<!-- Application Logic: Non-blocking, preserves execution order -->
<script src="app.js" defer></script>

<!-- Third-party Consent: Non-blocking, independent execution -->
<script src="consent.js" async></script>

<!-- Critical async: fast download, non-blocking execution -->
<script src="ab-test.js" async fetchpriority="high"></script>

<script>
  /* Inject example analytics */
  const script = document.createElement('script');
  script.src = 'analytics.js';
  script.async = true;
  document.head.appendChild(script);

  /* Inject + schedule example for chat */
  window.addEventListener('load', () => {
    const chatScript = document.createElement('script');
    chatScript.src = 'chat-widget.js';
    document.head.appendChild(chatScript);
  });
</script>

Para um detalhamento completo de todas as técnicas disponíveis, consulte 16 métodos para adiar o JavaScript e JavaScript async vs defer. Para orientação sobre como categorizar scripts por criticidade, consulte Níveis de prioridade de JavaScript.

5. Desbloqueie a Renderização de CSS

O CSS é um recurso que bloqueia a renderização por padrão: o navegador não sabe como a página se parece sem o CSS. Portanto, ele baixa e analisa as folhas de estilo primeiro.

Estratégias de Otimização:

• Evite @import: Ele cria cadeias de dependência sequenciais que devastam o desempenho.
• Otimize o Tamanho do Bundle: Evite arquivos CSS menores que 3kB (overhead) e maiores que 20kB (bloqueadores). Idealmente, vise arquivos de ~15kB.
• Carregamento Assíncrono: Carregue estilos fora da tela de forma assíncrona para desbloquear o caminho crítico.
• Trade-off do Critical CSS: Embora a injeção inline de Critical CSS melhore o primeiro pageview, ela ignora o cache do navegador, o que pode atrasar os pageviews subsequentes.

A Implementação:

Elimine totalmente o @import. Use tags <link> para carregamento paralelo. Para CSS não crítico (como estilos de impressão), use o atributo media para desbloquear a thread principal. Para saber mais sobre otimização de CSS, consulte remoção de CSS não utilizado.

<!-- Critical CSS: Blocks rendering (Correct) -->
<link rel="stylesheet" href="main.css">

<!-- Print CSS: Non-blocking until print event occurs -->
<link rel="stylesheet" href="print.css" media="print">

<!-- Async Pattern: Loads with low priority, applies on load -->
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">

6. Estabilize a Renderização de Fontes

As fontes são recursos pesados de bloqueio. Uma priorização eficaz exige limites rígidos sobre o que é baixado e controle sobre como ocorre a renderização.

Estratégias de Otimização:

• Limites Rígidos de Preload: Faça o preload de apenas 1 a 2 dos arquivos de fonte mais importantes (geralmente o texto do LCP). O preload de 5+ fontes obstrui a largura de banda.
• Self-host: Faça o self-host (hospedagem própria) de suas web fonts em vez de carregá-las de uma CDN de terceiros. Isso elimina a configuração de conexão extra.
• Reduza o Payload: Use Variable Fonts (um arquivo para todos os pesos) e Subsetting (remover caracteres não utilizados) para minimizar o tamanho do arquivo.
• Estratégia de Renderização:
  • Use swap para renderização rápida (evita texto invisível). Veja como garantir que o texto permaneça visível durante o carregamento de fontes da web.
  • Use optional para evitar o CLS (evita mudanças de layout em redes lentas).

A Implementação:

<!-- Preload ONLY the critical subset (e.g. Header + Body) -->
<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>

<style>
  @font-face {
    font-family: 'Inter Variable';
    src: url('/fonts/inter-var.woff2') format('woff2-variations');
    /* Choose based on stability requirements: */
    font-display: optional; /* No layout shift, but font might stay fallback */
    /* font-display: swap;     Fastest text visibility, but risks layout shift */
  }
</style>

7. Acelere as Conexões

Antes que um navegador possa baixar um recurso de uma origem de terceiros, ele precisa realizar uma pesquisa de DNS, estabelecer uma conexão TCP e negociar a criptografia TLS. Isso leva tempo. Você pode eliminar esse atraso dizendo ao navegador para configurar as conexões com antecedência.

A Implementação:

• preconnect: Use para origens críticas de terceiros das quais você sabe que o navegador precisará. Ele realiza o handshake completo (DNS + TCP + TLS) com antecedência.
• dns-prefetch: Use para origens menos críticas. Ele apenas realiza a resolução DNS, o que é mais leve, mas ainda economiza de 20 a 120 ms.

<!-- Critical third-party: full early connection -->
<link rel="preconnect" href="https://cdn.example.com">

<!-- Fallback for older browsers -->
<link rel="dns-prefetch" href="https://cdn.example.com">

Limite o preconnect a de 2 a 4 origens. Cada conexão consome CPU e largura de banda. Muitos preconnects competem com os downloads de recursos reais e podem prejudicar o desempenho em vez de ajudá-lo. De acordo com o Web Almanac de 2025, 22% das páginas usam preconnect e 24% usam dns-prefetch. Coloque ambos o mais cedo possível no <head>, antes de quaisquer recursos de bloqueio.