About resource hints
Resource hints can be used to hint the browser about important resources, needed in the current or subsequent navigation. You can preload assest or perform DNS lookups ahead of time. For example:
- when referencing to font-files hosted on other domains, preloading could be used;
- resources needed for later navigation, could be prefetched;
- when pulling in Google Analytics using Google Tag Manager, use preconnect or dns-prefetch.
Read more about resource hints on w3.org.
Preloading is relatively new, Chrome being the first browser to support preloading in version 50, as of April 2016. And it's purpose speaks for itself. But what happened is that we, developers, started to preload literally every asset. From performance perspective, this could become counterproductive.
One use case of preloading assets, is when you are lazyloading your stylesheet. Obviously, you only want to lazyload your stylesheet in combination with applying critical CSS, otherwise, the visitor would see an unstyled page for a while. In this use-case, the Critical CSS portion contains styling for main element above the fold.
Within the LightBolt CMS, we liked such an approach, to enable the browser to start rendering a styled page, without any render blocking resources in it's way. Our solution looked like the loadCSS solution, as introduced by Filament Group. But since July 2019, they advice to use another lazyloading CSS approach, where no preloading is involved.
preloadfetches files very early, at the highest priority, potentially deprioritizing other important downloads, and that may be higher priority than you actually need
Two advantages I see:
- You, as a developer, isn't getting in the way of what the browser thinks is important. They are cleaver enough, no need to get in it's way!
Browser are even smarter; meet its look-ahead pre-parser
So, browser are pretty smart themselves and are build to do work as optimal as possible (but only if you as a developer did a great job as well). Browsers are even equipped with a so-called look-ahead pre-parser, or just pre-loader. As of 2008.
Internet Explorer, WebKit and Mozilla all implemented pre-loaders in 2008 as a way of overcoming the low network utilisation while waiting for scripts to download and execute.a 2013 article describing the pre-loader at andydavies.me
The latter might be a bit confusing, as we talked about the preload resource hint before. But at the same time, that's exactly what it does as well. We don't and even shouldn't preload everything we as developers consider important. Let browsers decide for themselves, instead of getting in the way of what we think is important.
No need to preload resources
With this knowledge, we now know we don't always have to preload our assets. When you are have references to external script files, but maybe placed them at the bottom of your HTML, you don't have to preload them.
And as always, to answer the question if preload will or will not improve performance: it depends! Always keep testing, combine the use of Lighthouse with WebPageTest.org
DNS prefech and preconnect
Wondering how this relates to using dns-prefetch and preconnect? Basically the same; often there is no need to do dns-prefecting or preconnecting for origins already present in the initially received HTML document.