Corrigir "Avoid Chaining Critical Requests" no Lighthouse

Como a prioridade de download é determinada

Os recursos críticos 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 asset (recurso). Quais elementos recebem a maior prioridade no final depende da estrutura da página. Os elementos que o seu navegador acredita serem necessários para a primeira renderização da página recebem a maior prioridade.

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

Você pode anular essas prioridades com o atributo fetchpriority. Definir fetchpriority="high" informa ao navegador que um recurso é mais importante do que ele supunha normalmente. Definir fetchpriority="low" faz o oposto. Este atributo agora tem suporte de 93% dos navegadores. Para um guia completo, veja a Priorização de Recursos e os Core Web Vitals.

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

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

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

Um navegador não começará a renderizar a página (totalmente) 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 precisará fazer para exibir o primeiro conteúdo na tela, e menor será a competição pela CPU e por outros recursos.

De acordo com o Web Almanac de 2025, apenas 15% das páginas móveis passam na auditoria de recursos de bloqueio de renderização. Isso significa que 85% da web ainda tem problemas de cadeia crítica para resolver. Este é um dos principais motivos pelos quais apenas 55% das origens móveis pontuam como "boas" no First Contentful Paint. Em sites monitorados pelo CoreDash, origens com menos de 3 requisições de cadeia crítica têm um FCP mediano de 1,2 segundos, comparado a 2,4 segundos para origens com 8 ou mais requisições na cadeia.

Nota: A partir do Lighthouse 13 (Outubro de 2025), esta auditoria foi renomeada para o insight "Network Dependency Tree" (Árvore de Dependência de Rede). 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 de requisiçõ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 do caminho crítico faz com que eles sejam baixados mais rapidamente. Compressão Gzip ou Brotli, tree shaking de JavaScript, otimização de imagens e font subsetting (subconjunto de fontes) ajudam.
3. Melhore a ordem de download do caminho crítico. Use resource hints (dicas de recursos) como o preloading 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 pré-carregar recursos antes mesmo do HTML chegar.

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

1. HTML

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

Carregamento retardado 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 busca, por exemplo, partes do conteúdo que não são necessárias de imediato só são carregadas posteriormente via uma requisição AJAX.

Minificar: 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 atinge uma compressão de 15 a 20% melhor que o Gzip.

2. Folhas de estilo (Stylesheets)

As folhas de estilo no cabeçalho (head) da página são sempre críticas. Sem os estilos, um navegador não sabe como a página se parecerá. As folhas de estilo são, portanto, uma parte padrão da cadeia de solicitações críticas.

Critical CSS: A forma mais eficaz de quebrar a cadeia do CSS é colocar o seu Critical CSS (CSS crítico) in-line diretamente numa tag <style> no <head>. Isso elimina inteiramente a requisição de rede que bloqueia a renderização. Você pode gerar Critical CSS através de ferramentas NodeJS ou através do Gerador de Critical CSS. Coloque o CSS crítico in-line e carregue o resto numa prioridade mais baixa:

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

Observe o que acontece de estranho na página agora. Primeiro a página é exibida sem estilos, e apenas depois de carregar o CSS o estilo é aplicado. Todo o conteúdo piscará (flash) de não estilizado para estilizado. É por isso que você precisa do Critical CSS: as regras CSS para a parte visível da página ficam in-line, para que a página pareça correta de imediato, e o restante do CSS é carregado sem bloquear a renderização.

Evite as cadeias de @import do CSS: Se seus arquivos CSS usam @import para carregar outros arquivos CSS, você cria uma cadeia onde o navegador precisa 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 compilação (build). Esta é uma das causas mais comuns de cadeias críticas desnecessariamente profundas.

Media queries (Consultas de mídia): Carregue apenas os estilos de que seu dispositivo precisa. Se um visitante estiver no celular, ele não precisa baixar os estilos para desktop ou para impressão. Use o atributo media para fazer com que as folhas de estilo não bloqueiem para os 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 as folhas de estilo cujo atributo de mídia corresponde ao dispositivo atual. As folhas de estilo que não correspondem são baixadas numa baixa prioridade e não bloqueiam a renderização.

Minificar: Remova o CSS não utilizado. Muitos sites usam bibliotecas de CSS como o Bootstrap. Essas bibliotecas muitas vezes são excessivamente completas e nem todas as declarações de estilo são usadas. Edite essas bibliotecas através de um pré-processador de CSS (como o Sass) para remover os grupos de estilos não utilizados. Os pré-processadores também minificam seu CSS ao remover todos os espaços e quebras de linha. Veja também como corrigir 'remover CSS não utilizado'.

Compressão: Comprima as folhas de estilo 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. Portanto, o JavaScript é uma parte padrão da cadeia de solicitações críticas.

Defer e Async: Ajuste a prioridade dos arquivos JavaScript carregando-os assincronamente através do atributo async ou defer. Os scripts async são baixados paralelamente com menor prioridade. Os scripts deferidos (deferred) também são baixados paralelamente e a sua execução é adiada até depois do HTML ter sido analisado. Para uma comparação completa, veja async vs defer e como eles afetam os Core Web Vitals.

// bloqueia carregamento e 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 nem durante a execução
<script defer src="deferscript.js"></script>

Para mais técnicas sobre o adiamento do JavaScript, veja 16 métodos para adiar ou programar o JavaScript. Se você possui JavaScript não utilizado que não pode ser adiado, veja como reduzir o JavaScript não utilizado.

Code splitting (Divisão de código) e preloading: Se a página não permitir que o JavaScript seja carregado assincronamente, divida o JavaScript em múltiplos arquivos. Coloque a parte que é crítica durante o carregamento da página num arquivo pequeno e pré-carregue-o (preload). Coloque o JavaScript não crítico em outro arquivo e deixe que carregue diferido (defer) ou de forma async.

Minificar: Reduza a quantidade de bytes por meio de um minificador de JavaScript. Bundlers modernos, como webpack, Rollup e Vite utilizam o terser sob o capô para analisar o JavaScript e deixá-lo o menor possível.

Compressão: Reduza a quantidade de bytes comprimindo o JavaScript através de Gzip ou Brotli.

4. Web fonts (Fontes da web)

Fontes da web costumam ser os últimos arquivos na cadeia de requisições críticas. Isso ocorre porque as web fonts dependem de serem descobertas: elas são carregadas apenas quando o navegador descobre que são necessárias. Para isso, o navegador deve primeiramente analisar o HTML e procurar na folha de estilos qual fonte é utilizada.

Preloading (Pré-carregamento): Quando você souber que vai utilizar uma fonte, é mais rápido pré-carregar (preload) essa fonte. Com isso, a fonte é baixada o mais cedo possível, reduzindo ao máximo a influência sobre a cadeia de solicitações críticas. Pré-carregue uma fonte adicionando este código o mais cedo possível no head (cabeçalho) da página:

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

Estratégia para Fontes: Há muitas outras formas para fazer as fontes carregarem com mais rapidez. Consulte como hospedar suas próprias Google Fonts (self-host) e como garantir que o texto permaneça visível durante o carregamento da webfont.

• Sempre utilize web fonts hospedadas por conta própria (self-hosted), nunca utilize fontes com hospedagem remota, como as Google Fonts.
• Redimensione a fonte utilizando font subsetting (subconjunto de fontes).
• Carregue as fontes não críticas por meio da FontFace API.
• Utilize font-display: swap a fim de evitar que as fontes bloqueiem a renderização inicial.
• Permita aos navegadores que eles gerem suas variantes particulares de fontes (font synthesis).

5. Imagens

As imagens que se revelam na viewport que está visível perante o carregamento processual da página, por regra, também recebem elevada prioridade e estão sujeitas a interferir em seu caminho crítico. Na situação em que você tiver a absoluta certeza quanto ao surgimento permanente condizente daquela imagem ao longo da região ou da dobra visível pelo utente no website, efetue o preload da referida imagem. Aplique a regra associando o fetchpriority="high" com o fito de anunciar o apontamento ao navegador de tal sorte indicando configurar à dita imagem no predicado na categoria da imagem referencial com o status mais relevante correspondente na referida página:

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

Em se tratando no cômputo da totalidade das outras respectivas imagens em compassos ou nas localizações ali invisíveis aos olhos, aplique na referida conduta aos trâmites em lazy load nessas imagens. Adote a correspondente inserção do loading="lazy" objetivando o retardo do referido carregar pertinente à referida amostragem daquela respectiva imagem condicionando esse fato pontual no preceito estrito e exato lapso de amostragem perante o exato piscar em sua transição logo anterior a se avistar como visível:

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

6. Requisições AJAX

Requisições originadas nas adjacências inerentes do AJAX comumente recebem a atribuição e delegação propalada no patamar alocado em alta prioridade. Ante o exposto postergue por via de regra e via preceito das requisições na malha do AJAX remetendo para depois da conclusão pertinente cabível com o término alusivo atinente do procedimento correspondente ao rendering pertinente perante aquela modelagem de página. Aguardando dessa forma as vias afetas nas correspondentes instâncias à remessa atinente cabível afeta aos eventos relativos a "load":

window.addEventListener('load', (event)=>{
  console.log('este é o instante premente mais benéfico afeto a prospecção da requisição ao parâmetro de AJAX');
});

Face as raras esporádicas instâncias em não figurar tangível ali postergar os chamamentos requeridos pertinentes oriundos na formatação em vias de requerimento alusivas à requisição perante os preceitos de AJAX, far-se-á lícito outrossim a dita efetuação na retaguarda preceituada relativa afeta ao preload concernente ao propalado referencial na malha correspondente da base dotada a recursos de vias e ferramentas de preceito consubstanciado ao escopo em prol de ofertar os insumos propícios alocando ao escopo da base do provedor nos expedientes em navegador consubstanciadas sob estrito compasso e via com antecedência referenciada.

7. Iframes

Iframes figuram costumeiramente a vias em ser o correspondente ao decurso afeto às prospecções de baixas preceituadas via formatações no arranjo condizente atinente da alta prioridade. Sendo em decorrência preceituada afeta por atrelar a si e perfazer afinal no escopo em si da base estrita de página atrelada inserida subjacente com um correspondente outro contorno afetando preceitos modeladores condizentes oriundos atinentes na respectiva outrem similar (uma página alocada sob uma outra referida e contida na formatação preceituada página), redundaria por fim à citada ferramenta atinente ao propalado iframe no condão inerente focado a deflagrar percalços significativos repletos de morosidade ali incrustada nos ditames balizadores no aspecto dos compassos temporais aos referidos fluxogramas processuais referentes ali da carga no arranjo de (page loading times). As ditas vias pertinentes e referenciadas provindas nos canais atrelados aos itens adstritos com valias propaladas à sua respectiva serventia por intermédio das requisições submetidas oriundas da plataforma por iframe outrossim recebem da dita e igual delegação condizente de baixarem estipuladas sob instâncias afetas em preceituadas amarras na conformação ao patamar atinente a chancelas propaladas relativas da priorização referida da base de alta prioridade gerando via de consequência em decurso a própria e preestabelecida autêntica amarração condizente com a cadeia de prospecções alusivas à restrita via correspondente em requisição na base e escopo submetida sob fardo do perfil na seara da crítica de ordem da modelagem (critical request chain). A outorga ao preceito afeto nas formatações pelo propalado intermédio alocado aos iframes poderá consubstanciar face isto a respectiva estirpe originária no modelo de abalos significativos no reduto cabível e a calhar afetando a propalada valia das intercorrências de bases dos Core Web Vitals.

Você pode atrasar (delay) o carregamento de um iframe por meio do atributo loading="lazy". Isso costuma fazer uma grande diferença quando o iframe não está imediatamente visível durante o carregamento. Para um controle maior sobre o momento (timing), injete o iframe usando JavaScript para garantir que ele não acabe na cadeia de requisições críticas. Veja como incorporar o Google Maps sem prejudicar seu PageSpeed e como incorporar o YouTube com Core Web Vitals perfeitos como exemplos dessa técnica.

Verifique suas melhorias

Após otimizar sua cadeia crítica, verifique a melhoria com o Real User Monitoring. Seu FCP e o seu LCP devem ambos apresentar melhoria. Ferramentas de laboratório como o Lighthouse oferecem feedback instantâneo, mas são os dados de campo (field data) de usuários reais que realmente importam para os Core Web Vitals.