Guia de Priorização de Recursos para Core Web Vitals
Controle quais recursos carregam primeiro e quais esperam
Guia de Priorização de Recursos para Core Web Vitals
O mecanismo de priorização padrão do navegador opera com base em heurísticas: suposições imperfeitas baseadas em tipos de arquivo e localização no documento. Os recursos são enfileirados com base em quando são descobertos pelo preload scanner ou pelo parser do DOM.
Última revisão 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).
Agora, isso não é culpa do navegador: no HTML do nosso exemplo, o navegador não tinha como saber que havia priorizado os recursos errados, o que atrasou a renderização crítica.
Você é quem sabe o que é importante e controla esse cronograma através de dois mecanismos: Priorização (impulsionar sinais críticos) e Despriorização (agendar recursos não críticos para quando forem menos intrusivos).
Table of Contents!
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 recurso (CSS, Script, Imagem) e sua posição no HTML/DOM. Embora geralmente eficaz para documentos simples, esse sistema falha quando os recursos não são reconhecidos cedo (pelo preload scanner) ou quando os recursos errados são acionados para download antecipado.
Níveis de Prioridade Padrão do Chrome
O Chrome usa cinco níveis internos de prioridade: Highest, High, Medium, Low e Lowest. Veja como ele os atribui por padrão:
| Recurso | Prioridade padrão | Com fetchpriority="high" | Com fetchpriority="low" |
|---|---|---|---|
CSS (no <head>) |
Highest | (já no máximo) | High |
Script (bloqueante, no <head>) |
Highest | (já no máximo) | Low |
| Script (async / defer) | Low | High | Lowest |
| Fonte (via preload) | Highest | (já no máximo) | n/a |
| Fonte (no CSS) | High | n/a | n/a |
| Imagem (padrão) | Low | High | Lowest |
| Imagem (primeiras 5 grandes) | Medium | High | Low |
| Imagem (no viewport, após layout) | High | (já High) | n/a |
O atributo fetchpriority é suportado em elementos <img>, <link> e <script>. Ele tem 93% de suporte global nos navegadores (Chrome 102+, Firefox 132+, Safari 17.2+, Edge 102+) e é uma melhoria progressiva: navegadores que não o suportam simplesmente o ignoram. De acordo com o 2025 Web Almanac, 17% das páginas móveis agora usam fetchpriority="high", mas apenas 0,3% usam fetchpriority="low". Isso significa que a despriorização é uma otimização enormemente subutilizada.
A Limitação do Preload Scanner
Para acelerar a descoberta, os navegadores empregam um "preload scanner", um parser leve que corre à frente do parser HTML principal para encontrar URLs de recursos. Este scanner tem limitações (que o tornam rápido e eficaz): Ele analisa apenas HTML. Não consegue ver dentro de arquivos CSS, não executa JavaScript e não renderiza (portanto, não pode determinar se os recursos estão visíveis no 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 com lazy loading, é ignorado até que o parser principal baixe e processe toda a página. Isso cria um "atraso de descoberta," onde o navegador efetivamente desconhece que recursos críticos existem.
Contenção de Recursos
Quando o navegador descobre recursos, frequentemente tenta baixá-los simultaneamente com outras requisições pendentes. Se uma imagem LCP importante compete com um script de prioridade média ou imagens sem importância (como ícones de redes sociais no rodapé), eles dividem a largura de banda disponível. Essa contenção estende o tempo de carregamento para ambos, empurrando a métrica LCP para a zona "Precisa de Melhoria".
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. Nos sites monitorados pelo CoreDash, 82% dos sites que usam fetchpriority="high" na imagem LCP passam no LCP, comparado com 61% dos sites que não usam.
1. Corrija a Descoberta com Preloading
Você deve expor manualmente os recursos ocultos ao 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 de descoberta. Para um passo a passo completo, veja nosso guia para preloading da imagem LCP.
A Implementação:
<!-- Expor a fonte ao scanner imediatamente --> <link rel="preload" as="font" type="font/woff2" href="/fonts/inter-bold.woff2" crossorigin> <!-- Expor a imagem LCP de fundo imediatamente --> <link rel="preload" as="image" href="/images/hero-banner.jpg" fetchpriority="high">
Para uma descoberta ainda mais antecipada, considere o 103 Early Hints, que envia sinais de preload ao navegador antes da resposta HTML chegar.
2. Substitua as Heurísticas do LCP
Os navegadores frequentemente atribuem prioridade "Low" ou "Medium" às 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) adicionando este único atributo.
<!-- Forçar busca imediata com alta prioridade --> <img src="hero.jpg" alt="Hero Product" fetchpriority="high">
O pior erro aqui é aplicar lazy loading na imagem LCP, o que ativamente desprioriza o elemento mais importante da página.
3. Despriorize Imagens Sem Importância
Liberar largura de banda é frequentemente mais eficaz do que aumentar a prioridade. Você deve atrasar explicitamente recursos não essenciais para limpar o canal de rede para recursos críticos.
A Implementação:
- Abaixo da dobra: Use
loading="lazy"para adiar imagens fora da tela até o usuário rolar a página. - Acima da dobra, secundárias: Use
fetchpriority="low"para slides de carrossel ou visuais secundários que renderizam 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 atenção durante a primeira renderização, mas podem gerar muitas requisições de largura de banda antecipadas.
<!-- Imagem LCP: Prioridade Mais Alta --> <img src="slide-1.jpg" fetchpriority="high"> <!-- Imagem Secundária do Carrossel: Busca imediata, baixo uso de largura de banda --> <img src="slide-2.jpg" fetchpriority="low"> <!-- Bandeiras de tradução: enquanto no viewport, ocultá-las do preload scanner --> <img src="dutch-flag.jpg" loading="lazy" fetchpriority="low"> <!-- Imagem Fora da Tela: Busca adiada --> <img src="footer-promo.jpg" loading="lazy">
4. Controle a Execução de Scripts
JavaScript bloqueia o parser do DOM. Se você usar 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 o Interaction to Next Paint (INP) ao bloquear a thread principal.
A Implementação:
- defer: Use para lógica da aplicação. Baixa em paralelo (prioridade Low) e executa somente após o HTML ser completamente analisado, preservando a ordem de dependência.
- async: Use para scripts independentes de terceiros (como analytics). Baixa em paralelo e executa imediatamente após a conclusão, desconsiderando a ordem.
- async + fetchpriority="high": Use para scripts async críticos (como testes A/B) que precisam de download rápido sem bloquear a análise. Isso eleva a prioridade de download de Low para High enquanto mantém a execução não bloqueante.
- Injetar: Ignora o preload scanner para que não compita com a largura de banda inicial. Scripts injetados são tratados como async.
- Agendar + Injetar: Injete scripts em um momento posterior, por exemplo quando o evento load for disparado.
<!-- Lógica da Aplicação: Não bloqueante, preserva a ordem de execução -->
<script src="app.js" defer></script>
<!-- Consentimento de Terceiros: Não bloqueante, execução independente -->
<script src="consent.js" async></script>
<!-- Async crítico: download rápido, execução não bloqueante -->
<script src="ab-test.js" async fetchpriority="high"></script>
<script>
/* Exemplo de injeção de analytics */
const script = document.createElement('script');
script.src = 'analytics.js';
script.async = true;
document.head.appendChild(script);
/* Exemplo de injeção + agendamento para chat */
window.addEventListener('load', () => {
const chatScript = document.createElement('script');
chatScript.src = 'chat-widget.js';
document.head.appendChild(chatScript);
});
</script>
Para uma análise abrangente de todas as técnicas disponíveis, veja 16 métodos para adiar JavaScript e async vs defer JavaScript. Para orientação sobre categorização de scripts por criticidade, veja níveis de prioridade do JavaScript.
5. Desbloqueie a Renderização de CSS
CSS é bloqueante de renderização por design: o navegador não sabe como a página se parece sem CSS. Por isso, ele baixa e analisa as folhas de estilo primeiro.
Estratégias de Otimização:
- Evite @import: Cria cadeias de dependência sequenciais que devastam a performance.
- Otimize o Tamanho do Bundle: Evite arquivos CSS menores que 3kB (overhead) e maiores que 20kB (bloqueantes). Idealmente, mire em arquivos de ~15kB.
- Carregamento Assíncrono: Carregue estilos fora da tela de forma assíncrona para desbloquear o caminho crítico.
- Compensação do CSS Crítico: Embora o inline de CSS Crítico melhore a primeira visualização, ele ignora o cache do navegador, o que pode atrasar visualizações subsequentes.
A Implementação:
Elimine @import completamente. 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 mais sobre otimização de CSS, veja remoção de CSS não utilizado.
<!-- CSS Crítico: Bloqueia renderização (Correto) --> <link rel="stylesheet" href="main.css"> <!-- CSS de Impressão: Não bloqueante até o evento de impressão --> <link rel="stylesheet" href="print.css" media="print"> <!-- Padrão Assíncrono: Carrega com baixa prioridade, aplica ao carregar --> <link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">
6. Estabilize a Renderização de Fontes
Fontes são recursos pesados e bloqueantes. A priorização eficaz requer limites rigorosos sobre o que é baixado e controle sobre como é renderizado.
Estratégias de Otimização:
- Limites Rigorosos de Preload: Faça preload apenas dos 1-2 arquivos de fonte mais importantes (geralmente o texto do LCP). Fazer preload de 5+ fontes congestiona a largura de banda.
- Auto-hospedagem: Auto-hospede suas fontes web em vez de carregá-las de um CDN de terceiros. Isso elimina a configuração de conexão extra.
- Reduza o Payload: Use Fontes Variáveis (um arquivo para todos os pesos) e Subsetting (remova caracteres não utilizados) para minimizar o tamanho do arquivo.
- Estratégia de Renderização:
- Use
swappara renderização rápida (evita texto invisível). Veja garantir que o texto permaneça visível durante o carregamento de fontes web. - Use
optionalpara prevenir CLS (evita mudanças de layout em redes lentas).
- Use
A Implementação:
<!-- Preload APENAS o subset crítico (ex: Cabeçalho + Corpo) -->
<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');
/* Escolha baseado nos requisitos de estabilidade: */
font-display: optional; /* Sem mudança de layout, mas a fonte pode permanecer como fallback */
/* font-display: swap; Visibilidade mais rápida do texto, mas risco de mudança de layout */
}
</style>
7. Acelere as Conexões
Antes que um navegador possa baixar um recurso de uma origem de terceiros, ele precisa realizar uma busca 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 antecipadamente.
A Implementação:
- preconnect: Use para origens de terceiros críticas que você sabe que o navegador vai precisar. Realiza o handshake completo (DNS + TCP + TLS) antecipadamente.
- dns-prefetch: Use para origens menos críticas. Realiza apenas a resolução DNS, que é mais leve mas ainda economiza de 20 a 120ms.
<!-- Terceiro crítico: conexão antecipada completa --> <link rel="preconnect" href="https://cdn.example.com"> <!-- Fallback para navegadores mais antigos --> <link rel="dns-prefetch" href="https://cdn.example.com">
Limite o preconnect a 2 a 4 origens. Cada conexão consome CPU e largura de banda. Muitos preconnects competem com downloads reais de recursos e podem prejudicar a performance em vez de ajudá-la. De acordo com o 2025 Web Almanac, 22% das páginas usam preconnect e 24% usam dns-prefetch. Coloque ambos o mais cedo possível no <head>, antes de qualquer recurso bloqueante.
Ask AI why your INP spiked.
CoreDash is the only RUM tool with MCP support. Connect it to your AI agent and query your Core Web Vitals data in natural language. No more clicking through dashboards.
See How It Works
