48

Chrome's new version added support for <link rel="preload">. They have posted a lot of info with references to the original documentation. Can someone provide simple explanation on how it works and what is the difference compared to the case without rel="preload".

Ilya Chernomordik
  • 27,817
  • 27
  • 121
  • 207

2 Answers2

29

In it's most basic form it sets the link that has rel="preload" to a high priority, Unlike prefetching, which the browser can decide whether it's a good idea or not, preload will force the browser to do so.

===A more in-depth look:===

Here's a snippet from W3c

Many applications require fine-grained control over when resources are fetched, processed, and applied to the document. For example, the loading and processing of some resources may be deferred by the application to reduce resource contention and improve performance of the initial load. This behavior is typically achieved by moving resource fetching into custom resource loading logic defined by the application - i.e. resource fetches are initiated via injected elements, or via XMLHttpRequest, when particular application conditions are met.

However, there are also cases where some resources need to be fetched as early as possible, but their processing and execution logic is subject to application-specific requirements - e.g. dependency management, conditional loading, ordering guarantees, and so on. Currently, it is not possible to deliver this behavior without a performance penalty.

Declaring a resource via one of the existing elements (e.g. img, script, link) couples resource fetching and execution. Whereas, an application may want to fetch, but delay execution of the resource until some condition is met. Fetching resources with XMLHttpRequest to avoid above behavior incurs a serious performance penalty by hiding resource declarations from the user agent's DOM and preload parsers. The resource fetches are only dispatched when the relevant JavaScript is executed, which due to abundance of blocking scripts on most pages introduces significant delays and affects application performance. The preload keyword on link elements provides a declarative fetch primitive that addresses the above use case of initiating an early fetch and separating fetching from resource execution. As such, preload keyword serves as a low-level primitive that enables applications to build custom resource loading and execution behaviors without hiding resources from the user agent and incurring delayed resource fetching penalties.

For example, the application can use the preload keyword to initiate early, high-priority, and non-render-blocking fetch of a CSS resource that can then be applied by the application at appropriate time:

<!-- preload stylesheet resource via declarative markup -->
<link rel="preload" href="/styles/other.css" as="style">
<!-- or, preload stylesheet resource via JavaScript -->
<script>
var res = document.createElement("link");
res.rel = "preload";
res.as = "style";
res.href = "styles/other.css";
document.head.appendChild(res);
</script>

Here's a really in-depth description from the W3C spec.

Global support is good across modern browsers, at ~93% (as of June 2022).

Besworks
  • 4,123
  • 1
  • 18
  • 34
Sonny Prince
  • 1,094
  • 7
  • 15
  • Browser loads css anyway, so the only thing it does is to load the before js e.g.? Giving it higher priority than others? – Ilya Chernomordik Apr 15 '16 at 08:45
  • 1
    @IlyaChernomordik eventually everything will be loaded of course, put this just forced the file you've added `rel="preload"` to the top of that queue. – Sonny Prince Apr 15 '16 at 08:47
  • 7
    Don't really understand why it's not explained that simple everywhere, they write tons of stuff instead :) – Ilya Chernomordik Apr 15 '16 at 09:20
  • @IlyaChernomordik haha! I agree - glad i could help! – Sonny Prince Apr 15 '16 at 09:21
  • 3
    It doesn't just add it to the front of the queue, it gets it in to the queue earlier (and therefore allows the browser to start downloading it earlier). There's also no need to "be careful" about adding it, there's no downside - browsers that don't support it will ignore the link, but browsers that do will benefit. You're not going to break older browsers by supporting newer ones. – El Yobo Feb 19 '17 at 22:11
  • >Browser loads css anyway, so the only thing it does is to load the before js ? It's important to realize that yes it loads it but it doesn't do anything with it. It doesn't parse it. It won't block anything else. It won't update any styles on screen. It basically puts it in the cache. It's more `precache` than `preload`. – Simon_Weaver Aug 25 '22 at 16:10
  • Easiest way to add it to my work, came from this: https://techstacker.com/css-preload-hint/ – Dean Miranda Feb 24 '23 at 18:04
19

Google Developers suggest rel="preload" to be used to request fonts earlier to have them available when the CSSOM is ready.

Lazy loading of fonts carries an important hidden implication that may delay text rendering: the browser must construct the render tree, which is dependent on the DOM and CSSOM trees, before it knows which font resources it needs in order to render the text. As a result, font requests are delayed well after other critical resources, and the browser may be blocked from rendering text until the resource is fetched.

Use as:

<link rel="preload" href="/fonts/my-font.woff2" as="font">
<link rel="stylesheet" href="/styles.min.css">

Also, note:

Not all browsers support <link rel="preload">, and in those browsers, will just be ignored. But every browser that supports preloading also supports WOFF2, so that's always the format that you should preload.

Zanon
  • 29,231
  • 20
  • 113
  • 126