Menu
<body>
<link rel="preload" href="/fonts/Roboto-Regular.woff2" as="font" />
<style>
@font-face {
font-family: "Roboto";
src: url("/fonts/Roboto-Regular.woff2") format("woff2");
}
* {
font-family: "Roboto", sans-serif;
}
</style>
<section>
<h2>Hello World</h2>
</section>
</body>
Roboto-Regular.woff2 gets downloaded once. The second access should take <5ms since it's reading from cache.
Roboto-Regular.woff2 gets fully downloaded twice. The second access took as much time as the first one.
The blue bar here is Content Download.
The solution suggested here: preloaded images get loaded again. But I quickly realised my issue has nothing to do with cache. I have configured serverside cache-control, as seen here in the response header for the file:
The previous waterfall screenshot is taken after a hard refresh (ctrl F5); this one is taken after a soft refresh:
This time both requests simply got their response from cache, which shows that cache has nothing to do with the whole situation.
Windows 10 Pro N 1909
Google Chrome 78.0.3904.108 x64
263
In all processes, you will find preload, check if it is on or not. If it is on then preload is working and if it is off then preload is not working (you can turn it on).
The preload is competing with the render-blocking file for bandwidth. As a result, the download takes longer and the page renders more slowly. The page renders 0.9s faster without the preload. The downside of this change is that the JavaScript file will now finish loading later.
Preloading CSS files # Waiting for JavaScript to execute before loading non-critical CSS can cause delays in rendering when users scroll, so it's a good idea to use <link rel="preload"> to initiate the download sooner.
The preload attribute specifies if and how the author thinks that the media file should be loaded when the page loads. The preload attribute allows the author to provide a hint to the browser about what he/she thinks will lead to the best user experience.
I accidentally stumbled across the answer today when I noticed several new warnings in the console that weren't there before.
These warnings basically described my issue exactly as they are. I did a quick Google search and landed here: Preloading content with rel="preload", which said:
One interesting case where this applies, even if the fetch is not cross-origin, is font files. Because of various reasons, these have to be fetched using anonymous mode CORS.
As suggested, I simply threw in crossorigin to my preload declaration:
<link rel="preload" href="/fonts/Roboto-Regular.woff2" as="font" crossorigin />
And my preload worked.
If you are preloading a resource with MIME type of fetch such as .json, you also need to include the crossorigin attribute in your preload declaration for similar reasons (I assume) (Reference).
101
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
