Browser Priority, Preloading, & Prefetching

[00:00:00]
>> Jon Kuperman: Another thing to cover is this idea of browser priority. This has kind of been established more and more over the years, but it's like most of our websites will have more assets to download than the browser could possibly do in parallel at one time. And so in order to solve for the problem of downloading unnecessary things before necessary things.

[00:00:18]
There's this kind of standardized rubric of what types of assets and where they're called determines their priority, right? And so you could say, okay, well, the document must be the highest priority, cuz you can't do anything, it doesn't make any sense to download CSS or JavaScript before we have the HTML.

[00:00:33]
And then you could do all sorts of stuff, right? You could do, well, fonts are those high, are they low? What about images? What about images below the fold, all sorts of different options that you kind of have here. So the Dev tools provide you with the priority that they were given, and then we as developers have some APIs, which I'll cover which allow us to override the default priority.

[00:00:53]
But the important thing is that, if you have more than, I can't remember if it's like five or eight concurrent downloads, which we all do. Then the browser is gonna have to start making some priority decisions here. And so you can kind of see here different screenshots of different Dev tools, downloading different things, and then on the right side is the priority that they were given.

[00:01:12]
We have these APIs where we can say, I know what's best for my app and you can kind of go in and you can do things like preloading and prefetching. Have you heard of these APIs at all? So these are kind of more advanced APIs where you're communicating with the browser to help tell it, which things are high priority or which things are low priority.

[00:01:29]
The example I always give is, let's say you have some Google font, and when you refresh your website it loads in the fallback. And then it flickers and you see the Google font come in on top, and to you, that's super unacceptable. And so one thing that you can do is that, you can preload that Google font by just giving it an HTML attribute.

[00:01:48]
So you would do like the link to the font, and then it's preload, right? And by preload, it's saying, okay, this should be done at the highest priority, and it can be done during the same time the document's coming in. So you can really change the way that your app renders, where you can see here before preload the font there, which is that one where the arrow is pointing, just came at its organic spot.

[00:02:08]
So the HTML 1 and the CSS 1, eventually it hits the font and it's cool, I'll download it. You can say no, no, no, this font is vital for the experience of my application, I don't want that flash of content. So you add the preload to it and you see the font shifts all the way to the left, everything else sticks the same way that it was.

[00:02:24]
Similarly for prefetch, this kinda gets into more subtle magic. You can prefetch where you think the next page is going to be, so you can prefetch a whole page. So you can think about this for search, like Google's done some cool stuff here, we do a Google search.

[00:02:40]
They get the results back, and then they do some machine learning to be like, okay, let's look at the results we gave him. Which one do we think he's gonna click on? And they can make a bet, right? They'd be like, that third one sounds really good to me.

[00:02:50]
So they can add this prefetch tag to that third link and the browser will go out in the background and fetch the entire thing in anticipation of the user clicking it. And then if I do click that one, boom, I get this instant transition experience. If I don't click that one, it just falls back to the normal loading.

[00:03:06]
So I suppose the negative thing to do here is that you can do unnecessary work, right? If I mark the third link as prefetch you never click the third link, then we fetch the whole page perhaps for no reason. The benefit is you can have these magical feeling fast sites that are, if you only have one next page.

[00:03:24]
You can imagine a slideshow presentation, 90% of the time I'm gonna hit next slide, right? You could prefetch that next slide and then you could have like this really amazing. So these are simple HTML tags, preload and prefetch, you can add them anywhere you want. But would caution that it's like that if you opt to optimize everything, you optimize nothing kind of concept, right?

[00:03:42]
So if you just have ten links and you add prefetch on all of them, the browser's just gonna be out there working so much in the background blocking things. But they are really cool and I hope to see more and more of this stuff where application developers are allowed to sort of communicate some hints to the browser about how your specific app works, yeah.

[00:04:01]
>> Male Student 1: Does it work like the defer in Angular?
>> Jon Kuperman: This is a great question, it's sort of defer. Yeah, so it's a very similar thing in the sense that it's those are import attributes, but it's the same world, right? These are full document attributes. Those are JavaScript import attributes, the exact same thing.

[00:04:18]
They're sort of compiler hints or whatever you wanna call it to say. This is okay to come asynchronously or in this case this needs to come early. They're very much in the same kind of wheelhouse of things, yeah. And in TZ39 there's all sorts of new raw javascript imports now can be deferred.

[00:04:38]
Or it's the same the kind of thing where I think what we have by default works for most people but it's really cool to offer these more advanced things.
>> Male Student 2: I was just gonna to ask around profiling in terms of the total compute or just the ability of a network connection.

[00:04:52]
Can you build a profile with scenario where if a browser is not utilizing resources you can pretty much more?
>> Jon Kuperman: This is a really good question. Yeah, can you do more intelligent things of waiting for essentially an idle block and then prefetching in there. Yeah, there are some really cool ways you can do that.

[00:05:09]
It gets a little bit tricky because what you wanna be doing work but giving the main thread a chance to breathe periodically in order to receive things. But yeah, you can do this all with application land code. So you could have some big amount of work, and you kinda chunk it up.

[00:05:24]
And then in between chunks, you could do a promise for zero seconds, which will technically give control of the main thread back to the application. So you can do some quite fancy things where you're not just blocking the whole time, but you are constantly doing work. So yeah, you can try to detect idle blocks in your code and fill that with time basically.

[00:05:42]
As long as you don't fill it with things that take so much time that you lose interactivity. Yeah, you can get really fancy with this stuff.
>> Male Student 3: Can preloading or prefetching apply to something like fetch request coming from an API?
>> Jon Kuperman: I think what you would have to do there is you would want to try to preload the JavaScript that does the fetch request itself.

[00:06:04]
So I don't think you can't mark a fetch request itself as being preloaded. But you could put your fetch request in a single file called API calls.js, then you could preload that, right? So you can blockingly, you can kind of indirect control it. And again, I think that please measure.

[00:06:23]
These let you get in all these areas that sound good, but you can quickly get into things that do block the UI from loading. Before the UI even load, you can quickly get yourself into some bad territory. So I would say, play with these but then make sure you definitely measure that you're not blocking the initial render of your page, which is kind of vital.

[00:06:42]
>> Male Student 4: I'll just add to that, since we're kinda focused on the dev tools side of this. You can really dive deeper into these performance topics with Todd Gardner's web performance fundamentals course.
>> Jon Kuperman: Yeah, please do check that out. Yeah, I think that hopefully these give you that using the dev tools to signal that there is that thing, and then when you wanna go fix that thing.

[00:07:00]
Please check out that course, that's awesome. A little note too, on some of the differences between HTTP/2 and HTTP/3. I think we sort of had this thing that even I was guilty of for a while teaching that as we got to HTTP/3, we wouldn't need bundling. And there'd be no limit to the amount of synchronous requests and all this stuff.

[00:07:18]
And I think in truth, some of that has come true and some of that has not come true. As of right now, we live in this bundled world. We do have cool tools like frameworks and compilers, provide tools to break out chunks of your code, differ certain things or preload certain things.

[00:07:35]
But we're definitely not at the point where you can just serve all of your files and hope that they get figured out the right way. So I think it's really cool to be able to profile and use these APIs where applicable.