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"
.
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).
rel="preload"
to the top of that queue. –
Olympiaolympiad precache
than preload
. –
Consternation 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.
© 2022 - 2024 — McMap. All rights reserved.