What is a network dependency tree?
A browser can’t show a page the moment its HTML arrives. First it needs the files that decide how the page looks and works: stylesheets, some scripts, fonts. A request for one of these is called a critical request.
Some of these files are named right in the page’s code, so the browser can ask for all of them at once. Others are named only inside another file. A stylesheet can pull in a second stylesheet, and that one can name a font. The browser can’t know about the font until it has downloaded and read both stylesheets, one after the other. That is a chain, and every link in it is another wait before the page appears.
Draw every chain starting from the page and you get a tree. Chrome’s developer tools and Lighthouse show it as the “Network dependency tree” insight. Google’s advice there is to make chains shorter, make the files in them smaller, and put off downloading files the first view doesn’t need.
Two ways to test
The quick check reads your page’s code on our server. It takes a few seconds and shows what can be seen in the code. The sections below describe it.
The full test asks Google’s PageSpeed Insights to load your page in Chrome on an emulated phone with a slowed-down connection. It returns the tree Lighthouse itself draws: every critical request, files added by scripts included, with the moment each one ended and its size on the network. Those figures are Google’s, and they should match a Lighthouse report for the same page closely, though no two runs are identical. It takes up to a minute. The score shown with it is still Seokla’s: the same scale as the quick check, for late stylesheets, scripts and fonts.
How the quick check works
Our server downloads your page and reads its code for the files a browser treats as critical: stylesheets, scripts that are loaded without “async” or “defer”, and files the page preloads. Then it downloads each stylesheet and reads it too, looking for stylesheets pulled in with @import and for fonts. It repeats this up to four levels down.
The report draws the result as a tree. Each row is one file with the time it took to download and its size. Rows that are indented are files the browser finds only after reading the file above them. Those are tinted, because they are the ones worth fixing first.
Which files count as critical follows the rules Chrome publishes for how it ranks requests: stylesheets and early scripts are fetched with high priority and hold up the page, while scripts marked “async” or “defer” and stylesheets meant for print are not. Those are left out of the tree and counted separately in the report.
The test also checks the page’s preconnect hints, the lines that tell a browser to open a connection to another site in advance. Chrome shows these in the same insight.
What the times and sizes mean
The size is what travels over the network: the file as your server sends it, compressed if the server compresses it. Lighthouse reports sizes the same way.
The time is how long the file took to download from our server, from sending the request to receiving the last byte. Opening the connection is not counted, because a browser opens one connection to a site and reuses it for every file from there.
The time for a chain is the sum of the times along it, starting with the page: when the last file would arrive if the browser asked for each one the moment it learned about it. Lighthouse shows a figure that looks similar, the moment each request ended, but it is measured in a real browser on a slowed-down connection. Our server has a fast connection, so our times are much shorter and should not be compared with Lighthouse’s. Use them to compare files with one another and to see which chain is slowest.
What is a good result?
Chrome doesn’t give this insight a score. In Google’s words, it only fails if a critical request is not discoverable early in the page. So the aim is simple: every file the page needs at the start should be named in the page’s own code, either by the tag that uses it or by a preload hint.
The score here is Seokla’s own scale, not Google’s. A page starts with 100. Each stylesheet found only through @import takes off 15 points, or 30 if it sits three or more levels down. Each font named only inside a stylesheet and not preloaded takes off 5 points, up to 20 in all. Each stylesheet, or script in the head, beyond six takes off 3 points, up to 30 in all. A critical file that can’t be found takes off 10.
For preconnect hints, Chrome’s report warns when a page has more than four. They are meant for the few sites a page needs most.
What this test can’t tell you
We don’t run the page’s scripts. A file that a script adds to the page, or a chain that starts inside a script, isn’t in our tree, though a browser would show it. Chrome’s own tools see those because they load the page for real.
We also work out priority from the code, not from watching a browser, so a few files can be judged differently from Chrome. Fonts are the main case. A browser downloads a font only if some text on the page uses it, and we can’t tell that from the code. We list the fonts a stylesheet names for Latin text and say that they are fetched only if used.
Hints sent in the server’s reply headers and not in the page’s code are not read. To see real timings, open the Performance panel in Chrome’s developer tools and look for the same insight there.