Browser Hints: Prefetch & Preload

[00:00:00]
>> So the first browser hints or a browser hint is a hint that the browser uses in order to or that we can use to tell the browser like, hey, these resources are important, make sure to fetch this maybe before the user requested it or something just to have that faster navigation or faster load.

[00:00:19]
So one of them is prefetch. And a prefetch is an attribute that we can use to fetch those resources in the background and cache them. So whenever a user actually request them, we can as quickly get it from cache instead of having to make a request all the way to the server.

[00:00:37]
So the browser will prefetch a resource whenever the browser is idle and it's also calculated that it's got enough bandwidth to actually prefetch that resource. So for example, I think I'm showing it here. So if we have that route-based splitting and we've seen maybe from our analytics that most of our users after going to the website are going to the about page.

[00:00:59]
I don't know, maybe there's just something trendy there. So although we don't want to have that in our initial bundle, we can still prefetch it. So when the browser is idle, has the resources to do that, it'll cache it. So when the user then actually clicks on it, it can just quickly get it from cache and we don't have to go all the way to the server.

[00:01:16]
Now, of course this is just based on the route-based splitting example that we saw before. But prefetching could be for anything, maybe images that will show up a bit later below the fold or any components, maybe that the search input component that we saw before. If we know that most users will click there even though it's still its own bundle we can just prefetch that to make sure it's already cached.

[00:01:38]
Yeah, so we can either use that with just an html prefetch or in Webpack we can actually use another magic comment called webpackPrefetch. And what this does is when it bundles the code, it will just create a link like this with that prefetch. Yeah, so the trainers are pretty good because if we have a resource that should be prefetched, we can deliver very fast loading time because that request doesn't have to go all the way to a server, get this giant bundle, instead they could just get it from cache.

[00:02:06]
But of course, we have to make sure that we only prefetch the resources that are actually required cuz we don't want to unnecessarily fetch all this data, use our users bandwidth to fetch the data and then cache it if they never end up using it. So don't use this everywhere, just use this for the resources that are likely to be requested soon.

[00:02:23]
Now the next one is preload and this one is a bit more aggressive than prefetch because with prefetch, the browser will be like, okay, do I have enough bandwidth, I'm idle, can I request this? But with a preload, it will download the resource, it will get it. Actually your browser will, at least Chrome will show you a warning, it'll be like, hey, you preloaded this resource but it wasn't visible in the viewport within three seconds.

[00:02:48]
You should not be preloading this cuz it wasn't that important. But for example, if for some reason we wanted to have a landing page and the search flyout was always open. Yeah, so it wasn't based on a user click or just always there but it still should be its own bundler.

[00:03:08]
In that case we could preload that and even though in this animation it's pretty slow of course, this will happen super fast. So in that case this bundle request will be in parallel with the main bundle request. So when it's fetching the main bundle, it'll use it, it will cache it and then instantly use that bundle as well.

[00:03:30]
Yeah, so the implementation is pretty similar. So you can instead of using prefetching use preload and also use a Webpack magic comment with what that preload instead of prefetch. This is only after Webpack 4.3 I believe before that you had to use some plugins and preload plugin. Yeah, so a preload you will often use for maybe images that are instantly available like a banner image that might usually take a while to fetch.

[00:03:54]
We can preload it to make sure that that has already been fetched or fonts stuff like that. Just anything that's important on the initial render. Yeah, of course the performance here, it's just important to make sure that you're only preloading the stuff that's actually necessary. All right, lots to take in but that was the last thing up for that performance pattern.

[00:04:19]
So maybe they will make a bit more sense when we talk about rendering patterns.
>> For the browser hints, the implementation examples you showed with the link, you already know the bundler name.
>> Yeah.
>> I guess would you normally if you're using Webpack as bundler, would you just do the magic comments?

[00:04:40]
>> Exactly.
>> [INAUDIBLE], okay.
>> Like in this case if we're also using the magic comment with the chunk name, we do know the bundle name but in most cases you don't or you're not going to add this chunk name for all these bundles. So yeah, in most cases you would just use these magic comments so to let Webpack automatically do that, but not if you're using images or something.

[00:05:00]
If you know your banner image wants to prefetch or preload that actually or font stuff like that, so.