Network dependency tree no Lighthouse: como ler e corrigir

Os ficheiros que o browser só encontra dentro de outros ficheiros fazem a página esperar por cada um deles à vez. Como ler a árvore e as tabelas de preconnect, e como encurtar as cadeias.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-11-05

O que é a Network dependency tree no PageSpeed Insights?

A Network dependency tree no Lighthouse («Avoid chaining critical requests» antes do Lighthouse 13) mostra os ficheiros de que a página precisa primeiro e por que ficheiro cada um teve de esperar: cada ficheiro encontrado dentro de outro acrescenta uma espera. Aloje os tipos de letra no próprio domínio, ligue as folhas de estilo no HTML em vez de usar @import e faça preconnect apenas se um ficheiro crítico vier de um domínio que não consiga evitar.

Quer apenas a solução rápida? Salte para web fonts, @import no WordPress, Shopify ou ficheiros que um script adiciona.

Como ler a Network dependency tree?

O Lighthouse 13 e o PageSpeed Insights descrevem o aviso como: "Avoid chaining critical requests by reducing the length of chains, reducing the download size of resources, or deferring the download of unnecessary resources to improve page load". Substituiu "Avoid chaining critical requests" (anteriormente "Minimize critical requests depth") e "Preconnect to required origins" — daí surgirem duas tabelas de preconnect por baixo da árvore.

O relatório abaixo vem da página inicial de uma clínica dentária que montei como um site WordPress: a folha de estilo do child theme importa a do tema pai, que importa as Google Fonts, e os ícones vêm do Font Awesome numa CDN.

Lighthouse 13.6 report, Network dependency tree of a dental practice home page: Maximum critical path latency 4,176 ms; under the HTML, all.min.css on cdnjs.cloudflare.com with fa-solid-900.woff2 (155.18 KiB, 4,176 ms) in orange, and the child theme style.css, the parent style.css, the Google Fonts css2 stylesheet, each indented under the one before, and three woff2 files on fonts.gstatic.com side by side under the css2 stylesheet

Lighthouse 13.6 em telemóvel, throttling do DevTools (Slow 4G, 4x CPU).

  • Uma linha com avanço indica um ficheiro que o browser só encontrou dentro do ficheiro do nível acima, pelo que teve de esperar por ele. As linhas no mesmo nível descarregam em paralelo, como os três ficheiros de tipos de letra sob a folha de estilo css2 da Google.
  • O tempo e os KiB numa linha: quando esse ficheiro chegou, a contar do início do carregamento da página, e o seu tamanho.
  • Maximum critical path latency é o tempo da cadeia mais lenta, a laranja. Na página da clínica dentária, trata-se do tipo de letra de ícones de 155 KiB a dois níveis de profundidade: chega depois das Google Fonts situadas quatro níveis abaixo.
  • LCP e Unscored: o aviso não tem peso na pontuação de Desempenho, mas as suas folhas de estilo atrasam o first paint, e o LCP nunca pode acontecer antes dele.

O PageSpeed Insights regista o carregamento sem throttling: a sua árvore apresenta tempos muito mais curtos do que esta captura de ecrã.

Porque é que uma cadeia de ficheiros atrasa a página?

Na página da clínica dentária, o visitante vê primeiro um ecrã em branco, depois o texto num tipo de letra de fallback que muda quando as web fonts chegam, com círculos vazios no lugar dos ícones.

O browser faz uma leitura antecipada do HTML (o preload scanner) e pede de imediato todos os ficheiros que aí encontra. Só encontra um ficheiro referenciado dentro de outro depois de esse outro ficheiro ter chegado: um tipo de letra numa folha de estilo, uma folha de estilo atrás de um @import, um script adicionado por outro script. Cada nível acrescenta um round trip ao servidor antes de o pedido seguinte poder começar.

Um ficheiro noutro domínio espera mais tempo: o browser tem primeiro de estabelecer uma ligação (DNS, TCP e TLS), o que numa rede móvel demora várias vezes mais do que um pedido numa ligação já aberta. Na página da clínica dentária, as Google Fonts estão quatro níveis abaixo do HTML, atrás de dois @import, com os dois últimos em novos domínios (fonts.googleapis.com, fonts.gstatic.com). Render-blocking requests explica por que razão uma folha de estilo atrasa o first paint.

Quanto mais rápida fica a página com uma árvore plana?

Após a correção, a página da clínica dentária faz o first paint um segundo mais cedo e apresenta os seus tipos de letra quase dois segundos antes. Medi três versões. A versão Antes tem os dois @import. A versão Links tem os mesmos ficheiros ligados no HTML, tal como o WordPress os gera com wp_enqueue_style. A versão Depois junta as folhas de estilo do tema pai e do child theme num único ficheiro, aloja os tipos de letra no domínio do próprio site, todos os três com preload, e usa os ícones em SVG inline.

AntesLinksDepois
Níveis421
Cadeia mais
lenta
4,183,251,21
First
paint
2,361,431,35
Todos os
tipos de letra
3,572,611,72
LCP2,361,731,96

Tempos em segundos, num telemóvel com throttling (Slow 4G, CPU 4x mais lento). Níveis e cadeia mais lenta (Maximum critical path latency no relatório) obtidos no Lighthouse 13.6 com o mesmo throttling.

Phone screen two seconds into loading the dental practice home page before the fix: still completely white

Antes

The same moment after the fix: the logo, the heading Your family dentist in Riverside and the text in their own fonts, the Book an appointment button with its calendar icon, the photo of the treatment room and a treatment card with its icon

Depois

Dois segundos após o início do carregamento no mesmo telemóvel com throttling.

A versão Links já garante a maior parte do ganho no first paint, porque os dois níveis de @import foram eliminados, enquanto os tipos de letra e os ícones continuam à espera dos respetivos domínios. O LCP — a foto principal — surge 0,4 s mais cedo na versão Depois. A versão Links tem o LCP mais rápido porque aí a foto tem a largura de banda quase toda para si; na Depois, os três tipos de letra com preload partilham essa largura de banda, pelo que a correção passa por fazer o preload de apenas um ou dois.

Para verificar se os visitantes reais esperam pela cadeia, divida o LCP em telemóvel nas suas fases no CoreDash: folhas de estilo e tipos de letra atrasados traduzem-se num longo render delay — o tempo de espera após a chegada da imagem de LCP ou, no caso do texto, do primeiro byte.

CoreDash LCP subparts on mobile, element filter Text, p75 per phase: Time To First Byte, Load Delay, Load Time and Render Delay, each with its time and its share of the total

CoreDash em telemóvel, p75, texto como elemento LCP: compare o Render Delay com o Time To First Byte.

O que significam Preconnected origins e Preconnect candidates?

Um preconnect (<link rel="preconnect">) abre a ligação a um domínio antes de o browser precisar de um ficheiro desse domínio. A secção Preconnected origins lista os domínios aos quais a página faz preconnect; a Preconnect candidates lista domínios cujo ficheiro ainda teve de estabelecer uma ligação, com o tempo que um preconnect poderia poupar (Est LCP savings).

Preconnected origins with five domains: fonts.googleapis.com, fonts.gstatic.com, cdnjs.cloudflare.com with the warning Unused preconnect. Check that the crossorigin attribute is used properly, maps.googleapis.com and www.youtube.com each with Unused preconnect. Only use preconnect for origins that the page is likely to request; Preconnect candidates: cdnjs.cloudflare.com, Est LCP savings 320 ms

A mesma página da clínica com uma fotografia principal grande com lazy loading, Lighthouse 13.6 com throttling do DevTools.

  • "Unused preconnect. Only use preconnect for origins that the page is likely to request." A página não carregou nada desse domínio — aqui maps.googleapis.com e www.youtube.com. Remova-o depois de confirmar que nenhum outro template, como o checkout, o utiliza.
  • "Unused preconnect. Check that the crossorigin attribute is used properly." Um tipo de letra precisa de uma ligação aberta com crossorigin; uma folha de estilo ou script precisa de uma ligação sem esse atributo. O domínio cdnjs.cloudflare.com envia para a página a folha de estilo do Font Awesome e o respetivo tipo de letra: a folha de estilo usou o preconnect e o tipo de letra abriu uma segunda ligação. Aloje o tipo de letra no próprio domínio; apenas quando não for possível, adicione um segundo preconnect a esse domínio com crossorigin.
  • "More than 4 preconnect connections were found." Cada preconnect estabelece uma ligação em paralelo com os ficheiros de que a página precisa primeiro. Aloje o que puder no próprio domínio e mantenha o preconnect apenas para um ficheiro crítico num domínio inevitável.
  • Um domínio em Preconnect candidates. Mova esse ficheiro para o próprio domínio; se não for possível e o ficheiro for crítico, faça preconnect a esse domínio.

Se ainda não puder alojar as Google Fonts no próprio domínio, ligue a respetiva folha de estilo no HTML e faça preconnect a fonts.gstatic.com com crossorigin; o browser liga-se a fonts.googleapis.com assim que lê o link. Mesmo assim, fica uma cadeia.

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

As definições de preconnect nos plugins nem sempre tratam o crossorigin corretamente: a opção DNS Preconnect da LiteSpeed Cache não o inclui em nenhum domínio e o Perfmatters só o coloca onde marcar a respetiva caixa. Verifique o código-fonte da página: apenas os domínios de tipos de letra precisam dele.

Como corrigir a Network dependency tree?

Comece pela cadeia mais lenta — a que o Lighthouse assinala a laranja — na sua linha mais profunda. Para cada ficheiro dessa cadeia, pergunte-se: este ficheiro pode ser referenciado no HTML ou vir do meu próprio domínio?

Google Fonts e outras web fonts

Sem código, ative a opção que aloja as Google Fonts no próprio domínio: Self-host Google Fonts no WP Rocket ou no FlyingPress, Local Google Fonts no Perfmatters, Load Google Fonts Locally no Elementor (Definições, Desempenho) ou o plugin OMGF. A opção do WP Rocket não deteta um @import das Google Fonts na folha de estilo do tema: se fonts.googleapis.com ainda aparecer na árvore a seguir, remova o @import (secção seguinte). Qualquer opção que carregue as Google Fonts de forma "assíncrona" através de um script de font loader, como na LiteSpeed Cache e no Autoptimize, acrescenta um nível à cadeia: aloje os tipos de letra no próprio domínio.

Manualmente, coloque as regras @font-face na própria folha de estilo, com os ficheiros woff2 numa pasta fonts ao lado:

@font-face {
  font-family: "Poppins";
  font-style: normal;
  font-weight: 700;
  font-display: swap;
  src: url("fonts/poppins-v24-latin-700.woff2") format("woff2");
}

Um tipo de letra só pode ser referenciado dentro de uma folha de estilo, pelo que apenas um preload encurta esta cadeia. Reduza o número de ficheiros de tipos de letra e faça o preload de um ou dois — começando pelo tipo de letra do maior texto visível no ecrã inicial — e confirme o LCP a seguir:

<link rel="preload" href="/wp-content/themes/acme-smile/fonts/poppins-v24-latin-700.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/wp-content/themes/acme-smile/fonts/open-sans-v44-latin.woff2" as="font" type="font/woff2" crossorigin>
<link rel="stylesheet" href="/wp-content/themes/acme-smile/style.css?ver=2.5.0">

O preload precisa de crossorigin, mesmo no próprio domínio; caso contrário, o tipo de letra é descarregado duas vezes. Font display explica o preload de tipos de letra.

No Next.js, o next/font já aloja e faz o preload dos tipos de letra: substitua qualquer @import url(https://fonts.googleapis.com/...) manual num ficheiro CSS pelo next/font.

Temas WordPress com @import

Um @import de Google Fonts apagado do tema pai regressa com a atualização seguinte: procure uma opção de tipografia no tema ou peça ao programador para fazer o enqueue dos tipos de letra.

Um @import da folha de estilo do tema pai no style.css de um child theme acrescenta um nível. Peça ao criador do tema um child theme sem essa instrução ou envie a um programador a árvore do relatório e este código para o functions.php do child theme, que substitui o @import:

add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
} );

Verifique o código-fonte da página a seguir: a folha de estilo do tema pai deve carregar apenas uma vez.

Tipos de letra de ícones

O Font Awesome e os ícones do Elementor carregam uma folha de estilo que, por sua vez, carrega um tipo de letra com todos os ícones. No Elementor, ative a opção Inline Font Icons: ela substitui a folha de estilo e o tipo de letra por SVG inline. Noutros casos, substitua os ícones utilizados na página por SVG inline ou aloje o Font Awesome no próprio domínio.

Shopify

Escolha os tipos de letra no editor de temas (Theme settings, Typography) em vez de colar código das Google Fonts no theme.liquid: o tema passa a servi-los a partir do domínio da própria loja, e o Dawn e os temas nele baseados fazem o respetivo preload. Os app embeds que adicionam folhas de estilo aparecem na árvore: desative-os um a um e execute o Lighthouse novamente. O Shopify envia os seus próprios preconnects nos cabeçalhos da página — para a sua CDN e para os três primeiros domínios externos de onde vêm os ficheiros bloqueadores — e o Lighthouse contabiliza-os no seu limite de quatro. Remova qualquer preconnect antigo para cdn.shopify.com do theme.liquid e adicione um preconnect próprio apenas para um domínio de que a árvore ainda necessite; cada app embed desativado pode eliminar um dos preconnects do Shopify. Se o aviso "More than 4 preconnect connections" se mantiver quando restarem apenas os do próprio Shopify, deixe-o estar.

Ficheiros que um script adiciona e serviços que não pode alterar

Uma folha de estilo adicionada por um script espera por esse script: se o primeiro ecrã precisar dela, coloque a ligação no HTML; se não, use defer no script. Uma ferramenta de consentimento que tenha de correr primeiro continua a ser bloqueadora; quando carregar ficheiros de um segundo domínio inevitável, faça preconnect a esse domínio. Se o servidor demorar tempo a gerar o HTML, os 103 Early Hints enviam o preconnect e o preload dos tipos de letra antes do próprio HTML.

Porque é que a árvore continua vermelha após a correção?

O Lighthouse assinala o aviso a vermelho assim que o HTML carrega uma folha de estilo, pelo que uma página sem qualquer cadeia continua a vermelho. Esse é o vermelho que pode manter: o HTML e os ficheiros que ele próprio referencia. Cada linha com avanço sob outro ficheiro é uma cadeia a corrigir:

  • Tipos de letra sob a própria folha de estilo. Use menos ficheiros e faça o preload de um ou dois. Um tipo de letra que o ecrã inicial não mostre é a única cadeia que pode permanecer.
  • Ficheiros adicionados por um serviço. O Email Obfuscation (email-decode.min.js) e o beacon do Web Analytics da Cloudflare, ou o guest.vary.php do Guest Mode da LiteSpeed Cache. Desative a funcionalidade.

Um bug conhecido do PageSpeed Insights por vezes coloca pedidos de outros sites na árvore: volte a executar o teste.

Network dependency tree after the fix, still red: Maximum critical path latency 1,211 ms; only the HTML and acme-smile/style.css, one level, both on www.acme-dental.test; No origins were preconnected; No additional origins are good candidates for preconnecting

A página da clínica dentária sem qualquer cadeia, Lighthouse 13.6 com throttling do DevTools.

Como confirmar que a árvore encurtou?

Execute o Lighthouse novamente e compare primeiro os níveis e a cadeia mais lenta, já que o Maximum critical path latency varia ligeiramente de execução para execução. A coluna Initiator no painel Network do Chrome DevTools mostra que ficheiro pediu cada um dos ficheiros. Para visitantes reais, acompanhe o FCP e o LCP em telemóvel no CoreDash a partir das visitas seguintes; o Search Console demora até 28 dias.

A sua cadeia mais longa vem de um tema ou page builder que não pode editar, ou de uma aplicação que carrega os seus próprios tipos de letra? Numa power hour de Core Web Vitals, analisamos a sua árvore em conjunto, ficheiro por ficheiro, e decidimos que ficheiros devem passar para o domínio do site, quais entram diretamente no HTML e que domínio ainda precisa de um preconnect.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

 
Arjen Karel

Precisa de um site mais rápido?

Sou o Arjen e há 17 anos que corrijo sites lentos. Se tem problemas que não consegue resolver sozinho, envie-me o seu URL e falamos.

Envie-me o seu URL
Arjen Karel
Arjen Karel, Consultor de web performance desde 2009

Porque é que o nosso fix não está a funcionar?

Por vezes a CDN ainda serve o HTML antigo, ou o fix foi feito no template de desktop e o mobile usa outro. Envie-me o seu URL e o problema, e respondo com alguns horários. Primeiro analiso os seus field data, depois dedicamos uma hora ao seu site, e no prazo de um dia tem as minhas notas por escrito. 350 € sem IVA.

Envie-me o seu URL

Sem programador para fazer o fix? Faço eu o trabalho, numa cópia do seu site.

Network dependency tree no Lighthouse: como ler e corrigir Core Web Vitals Network dependency tree no Lighthouse: como ler e corrigir