What the Critical Request Chain Visualizer does
This visualizer builds the dependency tree of a page load - which request caused which - and highlights the chains where one download has to finish before the next can even start: HTML to stylesheet to @import to web font, or HTML to script to lazily loaded chunk to API call. It measures the longest chain and tells you which link to break.
From a HAR file it uses the initiator Chrome recorded for every request, so the chains and times are those of one real load (read in your tab, never uploaded). From a URL it derives the chains from the HTML and up to four stylesheets, and labels the result as a static estimate with server-measured times.
How to use it
- Record a HAR in Chrome or Edge DevTools (Network panel, reload, Export HAR) and drop it here - or enter a public URL for a quick static check.
- Press Find the chains.
- Read the longest chain first: every arrow in it is a round trip the browser could not start earlier.
- Work through the Break the chain list. Each item says which link to remove and how - preload, link directly, inline, or bundle.
- Open the full tree to see every branch, with render-blocking requests,
@importlinks and preloaded files marked.
Reading the results
Depth is how many requests stand between the HTML and a file. Depth 1 means the HTML asked for it directly; depth 3 means three downloads had to complete in sequence first. Each level usually costs at least one network round trip plus download time.
For a HAR, the chain cost is the time from the HTML request starting to the last response in the chain. The longest chain is often not the deepest one - a two-link chain ending in a slow API call can take longer than a three-link font chain.
Stylesheets reached through another stylesheet and fonts discovered only inside CSS are the classic critical chains: the browser cannot see them until the parent CSS has downloaded and been parsed.
The URL mode's cost adds up server-measured fetch times along the chain as if fetched one after another. It shows the structure of the problem, not how long your visitors wait.
Worked example: a shop home page with a font chain and a late API call
In the sample HAR the deepest chain is the HTML, then main.css, then fonts.css (reached through main.css), then two Inter WOFF2 files - three links, so the fonts cannot start until 874 ms even though the HTML had arrived by 777 ms.
The longest chain by time is the HTML, then app.js, then chunk-reviews.js, then /api/recommendations, whose response ends at 2,237 ms. That API call is discovered only after two scripts download and run.
Breaking the chains means linking fonts.css directly from the HTML (or merging it into main.css), preloading the regular-weight font with crossorigin, and starting the recommendations request earlier - from the server-rendered HTML or with fetchpriority - instead of from a lazy chunk.
Formulas and scoring rules
- Chain cost (HAR)
cost = end of the last request in the chain - start of the document requestend = start + request time; the longest chain is the one with the greatest cost.- Depth
depth(HTML) = 0; depth(child) = depth(initiator) + 1- Chain cost (URL mode)
cost = sum of server fetch times along the chainAn upper-bound style estimate assuming each link starts after the previous one finishes.
How to break each kind of link
CSS behind CSS. Replace @import with separate <link rel="stylesheet"> tags, or concatenate the files at build time, so the browser discovers all stylesheets in the HTML.
Fonts behind CSS. Preload the one or two font files used above the fold: <link rel="preload" as="font" type="font/woff2" href="..." crossorigin>. The crossorigin attribute is required even for same-origin fonts, or the preload is wasted.
Scripts behind scripts. Code-split chunks and dynamic imports are discovered late. If a chunk is needed during load, add <link rel="modulepreload"> or include it in the first bundle. API calls made from those chunks can often be started earlier or rendered on the server.
Limitations: what the result does not prove
- Chains need initiator data. HARs from browsers that do not record it show every request hanging off the HTML, and the tool says so.
- A HAR is one load on one machine; chains are stable across loads but their times are not.
- The URL mode reads the HTML and at most four stylesheets from the a2z.tools server. Resources added by JavaScript are invisible to it.
- Not every chain matters: requests for below-the-fold images or analytics can sit at the end of long chains without delaying anything the visitor sees.
Privacy: where your data goes
The analysis runs in your browser. If you choose to load a public URL instead of pasting, a2z.tools fetches that address read-only and returns the text to your tab; private and internal addresses are refused and nothing is stored. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- W3C HTTP Archive (HAR) format - checked 19 Sep 2026
- W3C Resource Hints / HTML preload - checked 19 Sep 2026
- Chrome for Developers - Avoid chaining critical requests
- web.dev - Preload critical assets
Frequently asked questions
What is a critical request chain?
A series of dependent requests needed to render the page, where each is discovered only after the previous one has loaded - for example HTML, then a stylesheet, then a font it references. Lighthouse reports these under "Avoid chaining critical requests".
Why is CSS @import bad for performance?
The browser only sees the imported file after downloading and parsing the file that imports it, adding a full round trip before rendering can start. Linking both stylesheets from the HTML lets them download in parallel.
Should I preload every web font?
No. Preload only the font files used in above-the-fold text, usually one or two. Preloading too many competes with the HTML, CSS and LCP image for bandwidth and can make the page slower.
How does the tool know what requested each file?
Chrome and Edge store an initiator for every request in the HAR - the document, a stylesheet or a script, with its URL. The tool links each request to the entry with that URL; requests without one are attached to the document.
Is the longest chain always the one to fix first?
Fix the longest chain that ends in something visible: render-blocking CSS, the fonts for your headings, the LCP image or the data for the first screen. A long chain that ends in an analytics beacon rarely affects what users see.
Last reviewed by the A2Z.Tools team against the sources listed above.
