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
app.js. 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.
Browser compatibility #
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.
Stack-specific guidance #
Preload routes ahead of time to speed up navigation.
Modify your themes's layout and add
<link rel=preload> tags.