The Opportunities section of your Lighthouse report flags the third level of requests in your critical request chain as preload candidates:
How Lighthouse flags determines preload candidates
Suppose your page's critical request chain looks like this:
index.html file declares
<script src="app.js">. When
app.js runs , it calls
fetch() in order to download
ui.js. The page doesn't appear complete
until those last 2 resources are downloaded, parsed, and executed.
Using the example above, Lighthouse would flag
ui.js as candidates.
The potential savings are based on how much earlier the browser would be able
to start the requests if you declared preload links.
For example, if
app.js takes 200ms to download, parse, and execute,
the potential savings for each resource is 200ms since
app.js is no longer a bottleneck for each of the requests.
Preloading requests can make your pages load faster.
The problem here is that the browser only becomes aware
of those last 2 resources after it downloads, parses, and executes
But you know that those resources are important and
should be downloaded as soon as possible.
Declare your preload links
Declare preload links in your HTML to instruct the browser to download key resources as soon as possible.
<link rel="preload" href="styles.css" as="style">
<link rel="preload" href="ui.js" as="script">
See also Preload critical assets to improve loading speed for more guidance.
As of June 2020 preloading is supported in Chromium-based browsers. See Browser compatibility for updates.
Build tool support for preloading
See Tooling.Report's Preloading Assets page.