Corrigir "Avoid Chaining Critical Requests" no Lighthouse

Como a prioridade de download é determinada

Solicitações críticas são os recursos baixados com alta prioridade durante o carregamento inicial da página. Como essa prioridade é determinada?

A prioridade de download é determinada pelo próprio navegador. O navegador segue um conjunto de regras para determinar a prioridade de cada ativo. Quais elementos recebem a prioridade mais alta depende da estrutura da página. Os elementos que o seu navegador considera necessários para a primeira renderização da página recebem a prioridade mais alta.

O seu navegador faz inicialmente uma estimativa de quais elementos são mais importantes. De modo geral, a prioridade de download funciona assim: o HTML sempre tem a prioridade mais alta, depois os stylesheets (folhas de estilo), JavaScript síncrono, fontes, solicitações AJAX, imagens no topo da página, imagens mais abaixo na página e, em seguida, JavaScript assíncrono.

Você pode substituir essas prioridades com o atributo fetchpriority. Definir fetchpriority="high" diz ao navegador que um recurso é mais importante do que ele normalmente imaginaria. Definir fetchpriority="low" faz o oposto. Este atributo agora tem 93% de suporte dos navegadores. Para um guia completo, veja Resource Prioritization and the Core Web Vitals.

Você pode ver quais recursos recebem alta prioridade na sua página. Abra o DevTools com Ctrl+Shift+J. Navegue até a aba Network, clique com o botão direito nos nomes das colunas e selecione 'Priority'.

Como a cadeia de solicitações críticas afeta o tempo de carregamento da página?

Ao carregar uma página, um navegador começa no modo de "bloqueio de exibição" (display blocking). Neste modo, os recursos mais importantes são baixados com alta prioridade. Esses são os recursos críticos.

Um navegador não começará (totalmente) a renderizar a página até que todos os recursos críticos tenham sido baixados. Portanto, qualquer recurso crítico pode bloquear a primeira renderização de uma página.

Quanto menos recursos críticos uma página tiver, menos trabalho o navegador terá que fazer para colocar o primeiro conteúdo na tela, e menor será a competição pela CPU e outros recursos.

De acordo com o Web Almanac de 2025, apenas 15% das páginas mobile passam na auditoria de recursos de bloqueio de renderização (render-blocking). Isso significa que 85% da web ainda tem problemas de cadeias críticas para resolver. Esta é uma das principais razões pelas quais apenas 55% das origens mobile obtêm a pontuação "good" no First Contentful Paint. Entre os sites monitorados pelo CoreDash, origens com menos de 3 solicitações de cadeia crítica têm um FCP mediano de 1,2 segundos, em comparação com 2,4 segundos para origens com 8 ou mais solicitações na cadeia.

Nota: A partir do Lighthouse 13 (outubro de 2025), esta auditoria foi renomeada para a percepção "Network Dependency Tree". O conceito é o mesmo: o Lighthouse analisa a cadeia de solicitações de rede de alta prioridade e sinaliza quando ela é muito profunda.

Como corrigir "Avoid Chaining Critical Requests" no Lighthouse

Você pode reduzir o impacto das solicitações críticas de três maneiras:

1. Reduza o número de recursos críticos. Converta recursos críticos em recursos não críticos, removendo-os ou adiando-os.
2. Reduza o número de bytes críticos. Reduzir o tamanho dos recursos no caminho crítico faz com que sejam baixados mais rapidamente. Compressão Gzip ou Brotli, tree shaking de JavaScript, otimização de imagens e subsetting de fontes ajudam.
3. Melhore a ordem de download do caminho crítico. Use resource hints como o preload para pular a descoberta de recursos e garantir que os recursos críticos sejam baixados o mais rápido possível. Use HTTP 103 Early Hints para começar a fazer o preload de recursos antes mesmo de o HTML chegar.

A melhor opção depende do tipo de arquivo do recurso:

1. HTML

O próprio HTML é sempre baixado com a maior prioridade. A página é sempre parte da cadeia de solicitações críticas. É por isso que a própria página é a primeira coisa a considerar ao otimizar.

Carregamento atrasado de conteúdo: Muitos sites grandes, como o próprio Google, usam essa técnica para reduzir a cadeia de solicitações críticas. Na página de resultados de pesquisa, por exemplo, partes do conteúdo que não são imediatamente necessárias são carregadas posteriormente via uma solicitação AJAX.

Minificação: Menor é sempre mais rápido. Use a minificação de HTML para remover comentários, espaços e linhas em branco da página.

Compressão: Comprima seu HTML com Brotli ou Gzip. O Brotli normalmente alcança uma compressão de 15 a 20% melhor que o Gzip.

2. Stylesheets

Stylesheets no cabeçalho (head) da página são sempre críticos. Sem estilos, um navegador não sabe como será a aparência da página. Stylesheets são, portanto, uma parte padrão da cadeia de solicitações críticas.

CSS Crítico: A maneira mais eficaz de quebrar a cadeia de CSS é colocar seu CSS crítico inline diretamente em uma tag <style> no <head>. Isso elimina completamente a solicitação de rede de bloqueio de renderização. Você pode gerar CSS crítico através de ferramentas NodeJS ou através do Critical CSS Generator. Coloque o CSS crítico inline e carregue o resto com uma prioridade menor:

<link rel="preload"
      href="css.css"
      type="text/css"
      as="style"
      onload="this.onload=null;this.rel='stylesheet';"/>

Observe que algo estranho agora acontece na página. Primeiro, a página é mostrada sem estilos e, somente após o carregamento do CSS, o estilo é aplicado. Todo o conteúdo piscará de sem estilo para estilizado. É por isso que você precisa de CSS crítico: as regras CSS para a parte visível da página ficam inline, para que a página pareça correta imediatamente, e o resto do CSS carrega sem bloquear a renderização.

Evite cadeias de @import no CSS: Se os seus arquivos CSS usam @import para carregar outros arquivos CSS, você cria uma cadeia onde o navegador deve baixar o arquivo A antes mesmo de descobrir que precisa do arquivo B. Substitua as declarações @import por tags <link> separadas ou concatene os arquivos no momento da build. Esta é uma das causas mais comuns de cadeias críticas desnecessariamente profundas.

Media queries: Carregue apenas os estilos que seu dispositivo precisa. Se um visitante estiver no celular, ele não precisa baixar os estilos de desktop ou de impressão. Use o atributo media para tornar os stylesheets não bloqueantes para dispositivos que não correspondem:

<link href="all.css" rel="stylesheet" media="all">
<link href="print.css" rel="stylesheet" media="print">
<link href="desktop.css" rel="stylesheet" media="screen and (min-device-width: 1024px)">

O navegador apenas baixa com alta prioridade os stylesheets cujo atributo media corresponde ao dispositivo atual. Os stylesheets que não correspondem são baixados com prioridade baixa e não bloqueiam a renderização.

Minificação: Remova o CSS não utilizado. Muitos sites usam bibliotecas CSS como o Bootstrap. Estas bibliotecas são frequentemente super completas e nem todas as declarações de estilo são usadas. Edite estas bibliotecas via um pré-processador CSS (como o Sass) para remover grupos de estilo não utilizados. Pré-processadores também minificam seu CSS removendo todos os espaços e quebras de linha. Veja também como corrigir 'remove unused CSS'.

Compressão: Comprima stylesheets com compressão Brotli ou Gzip.

3. JavaScript

Arquivos JavaScript no cabeçalho (head) da página são baixados com alta prioridade por padrão e bloqueiam a renderização da página enquanto estão sendo baixados e executados. JavaScript é, portanto, uma parte padrão da cadeia de solicitações críticas.

Defer e Async: Ajuste a prioridade dos arquivos JavaScript carregando-os de forma assíncrona através dos atributos async ou defer. Scripts async são baixados em paralelo com prioridade menor. Scripts defer também são baixados em paralelo e sua execução é adiada até depois que o HTML for analisado (parsed). Para uma comparação completa, veja async vs defer e como eles afetam o Core Web Vitals.

// bloqueia o carregamento e a execução
<script src="normalscript.js"></script>
// async não bloqueia durante o carregamento, mas bloqueia durante a execução
<script async src="asyncscript.js"></script>
// defer não bloqueia durante o carregamento ou a execução
<script defer src="deferscript.js"></script>

Para mais técnicas de adiar o JavaScript, veja 16 métodos para adiar ou agendar JavaScript. Se você tem JavaScript não utilizado que não pode ser adiado, veja como reduzir o JavaScript não utilizado.

Code splitting e preload: Se a página não permitir que o JavaScript carregue de forma assíncrona, divida o JavaScript em vários arquivos. Coloque a parte que é crítica durante o carregamento da página em um arquivo pequeno e faça o preload dele. Coloque o JavaScript não crítico em outro arquivo e deixe-o carregar como defer ou async.

Minificação: Reduza o número de bytes por meio de um minificador de JavaScript. Bundlers modernos como webpack, Rollup e Vite usam o terser sob o capô para analisar o JavaScript e torná-lo o menor possível.

Compressão: Reduza o número de bytes comprimindo o JavaScript via Gzip ou Brotli.

4. Web fonts

Web fonts geralmente são os últimos arquivos na cadeia de solicitações críticas. Isso ocorre porque as web fonts dependem da descoberta: elas só são carregadas quando um navegador descobre que são necessárias. Para isso, o navegador deve primeiro analisar o HTML e procurar no stylesheet qual fonte é usada.

Preload: Quando você sabe que usará uma fonte, é mais rápido fazer o preload desta fonte. A fonte é então baixada o mais cedo possível, minimizando a influência na cadeia de solicitações críticas. Faça o preload de uma fonte adicionando este código o mais cedo possível no cabeçalho (head) da página:

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

Estratégia de fontes: Existem muitas outras maneiras de fazer com que as fontes carreguem mais rápido. Veja como fazer self-host do Google Fonts e como garantir que o texto permaneça visível durante o carregamento da webfont.

• Sempre use web fonts hospedadas por você (self-hosted), nunca fontes hospedadas remotamente como o Google Fonts.
• Redimensione a fonte com subsetting de fonte.
• Carregue fontes não críticas através da FontFace API.
• Use font-display: swap para evitar que fontes bloqueiem a renderização inicial.
• Deixe os navegadores gerarem suas próprias variantes de fonte através da síntese de fontes (font synthesis).

5. Imagens

Imagens que aparecem na viewport visível durante o carregamento da página também podem receber alta prioridade e interferir no caminho crítico. Quando você tiver certeza de que uma imagem sempre aparecerá na parte visível do site, faça o preload desta imagem. Adicione fetchpriority="high" para informar ao navegador que é a imagem mais importante na página:

<link rel="preload" as="image" href="important-image.webp">

Para todas as imagens que não são imediatamente visíveis, faça o lazy load destas imagens. Use loading="lazy" para atrasar o carregamento da imagem até pouco antes dela se tornar visível:

<img loading="lazy" src="lazy-image.webp" width="20" height="20" alt="...">

6. Solicitações AJAX

Solicitações AJAX sempre recebem alta prioridade. Portanto, adie as solicitações AJAX até que a página termine a renderização. Espere até que a página envie o evento "load":

window.addEventListener('load', (event)=>{
  console.log('este é um bom momento para uma solicitação AJAX');
});

Se não for possível adiar a solicitação AJAX, você pode fazer o preload do recurso para disponibilizá-lo ao navegador mais cedo.

7. Iframes

Iframes são geralmente baixados com alta prioridade. Como um iframe é na verdade uma página dentro de uma página, ele pode causar um atraso significativo nos tempos de carregamento da página. Os recursos que o iframe requer também podem ser baixados com alta prioridade e formar sua própria cadeia de solicitações críticas. O uso de iframes pode, portanto, afetar significativamente o seu Core Web Vitals.

Você pode atrasar o carregamento de um iframe por meio do atributo loading="lazy". Isso geralmente faz uma grande diferença quando o iframe não é imediatamente visível durante o carregamento. Para ter mais controle sobre o tempo, injete o iframe através do JavaScript para garantir que ele não acabe na cadeia de solicitações críticas. Veja como incorporar o Google Maps sem prejudicar o seu PageSpeed e como incorporar o YouTube com Core Web Vitals perfeitos para exemplos desta técnica.

Verifique suas melhorias

Após otimizar sua cadeia crítica, verifique a melhoria com o Real User Monitoring. O seu FCP e LCP devem melhorar. Ferramentas de laboratório como o Lighthouse fornecem feedback instantâneo, mas os dados de campo de usuários reais são o que contam para o Core Web Vitals.