Web Performance with Webpack

Webpack Prefetch & Preload

Sean Larkin

Sean Larkin

Web Performance with Webpack

Check out a free preview of the full Web Performance with Webpack course

The "Webpack Prefetch & Preload" Lesson is part of the full, Web Performance with Webpack course featured in this preview video. Here's what you'd learn in this lesson:

Sean examines Webpack's native preload and prefetch support. This ability allows for non-critical assets to be loaded in the background during the browser's idle time so that they are ready when a user requests them creating a better user experience.


Transcript from the "Webpack Prefetch & Preload" Lesson

>> Sean Larkin: So I wanna talk about a feature that we just added in Webpack 4.8. So if you look, actually, I'm just gonna pull up the Medium article, because it's a great resource. And so if you don't know, I would encourage every single person here to at least subscribe to our Medium publication.

Not only does it have information about major announcements, anytime we release anything or gain or awarded money for grants and stuff. We talk about it and we try to give updates on the future of the project. And there's even like a whole section which is like, I spent four weeks in preparation for a talk to basically give a whole workshop on how webpack works under the hood.

And this is what these guides, the contributor's guide to webpack is. Kind of like the blogging version. So there's all sorts of crazy stuffs, but specifically why I'm pulling you here is, I'm sorry, it's webpack 4.6, we published like 2 minor versions in like 3 days, or a week.

So who knows what <link rel="preload"> or prefetch does? Anybody? Okay, so this is basically a resource hint to the browser that says, hey, I'm gonna need this file eventually. I'm gonna need this asset, so load it for me? Eagerly load it, right? And it fetches while there's idle time, as well.

And essentially explains it, why is this useful? And it allows you to not have to have the additional cost of network calls, right? Specifically, with code splitting, right? Cuz code splitting you are trading off having a smaller initial download for a trade of an extra network request lazily.

Which is a pretty justifiable trade off. But we can even do better, right? So we added this new feature called webpack prefetch. So it's another magic comment. Webpack prefetch and then also preload. Now, I'll admit up front I specifically don't know the browser specification around the difference between prefetch and preload.

So I'd encourage you to look at that if you want to know which one you'd wanna choose. But essentially, this API will either add link route prefetch for that chunk, or it would add link route preload for that chunk and that resource. It automatically adds it for you.

Let's add it inside of our getFooter code. We'll jump into getFooter, that module, awesome. And we don't even really have any functionality in here, but what I want to do is just to showcase what happens when the chunk is created. So let's just say
>> Sean Larkin: const we could get like a chunky library.

So like get, could get gsap from here. Well, I think I added low dash again so.
>> Sean Larkin: Okay low dash equals Import and then "loadash-es".
>> Sean Larkin: All right, so let's build this again and our time code should be updated.
>> Sean Larkin: Okay, now let's take a look,
>> Sean Larkin: There we go, okay.

So now you see some actual decorations added on to some extra comments. I just usually search for preload, so we can see it. But we get a preload map, which basically is like, okay, this is the lazy chunk and that's the ID and these are the two modules that we're loading.

And we look at the run time. Now we see we're gonna grab the head reference of your document. And we're gonna say, for each lazy loaded chunk that needs this requirement or meets it, we're going to create a link element, we're gonna sign the property pre-load and add the as attribute equal the script and then we're going to append that to the head.

So for example, when, I mean, technically we could run this in dev mode and we should be able to see that attribute added. Even when we're just getting the footer, right?
>> Sean Larkin: Cuz the point is that even if you haven't ever called that function, it's still gonna give you this behavior, because it's preparing that asset to be loaded, right?

So that you don't incur any of the network costs. So if I hit load the footer, let's just step through that and take a look back at the elements. We now should see a link rel preload, yeah, there you go, for two lazy loaded chunks.
>> Sean Larkin: Does that make sense?

And so I think the one thing that people trip up on is that If the dynamic import is in your entry point, it's not going to add that link rel preload by default. There are plugins that exist out there in the wild, like I think Chrome Developers owns a webpack preload plugin.

And so it basically just hooks into HTML webpack plugin and adds the decorations into that HTML file template, so it's generated for you.
>> Speaker 2: So just to clarify, so rather then importing it when you click on the button, it's actually kind of it's lazy loading editing. This will potentially be used, so when during idol time it will actually, that way after it's brought in the scripts and had those idle time in the browser, it'll actually preload it as opposed to.

>> Sean Larkin: Yep, and this works really well in combination with service workers. Because you could actually even load that in a service worker on demand and then save it in your service worker cache, the actual resource. And then it's literally zero cost to load it. And so I'll actually look on Twitter.

I'll just pull it up really quickly. Mike Griling, who is one of the lead engineers at GET lab, they use View and webpack as well as, I think they might use type script there. But if you look here, this is an awesome example. On the left-hand side you see a gif.

Let me see if I can try to make it bigger. So really what they are doing here, is they've loaded lazy route, right? And on click, this extra visual shows up, right? [COUGH] On the left hand side, you see that there is just a tiny little delay in loading.

And this can be because they're testing a really slow network latency or- because they do heavy performance testing. And so, when they added web pack prefetch true, you can actually see it's almost instantaneous, right? So this really solves the question like, hey, all these extra network requests are bad, right?

And it's, well, it's a trade-off in that you have to go fetch that, but webpack takes care of that. And using this, you actually remove basically any of the cost of having to wait for the network, right? Especially useful for high-latency devices or people who are accessing it from like Australia.

There's heavy latency, even though the connection's really great. So this is a really cool feature. This is what prefetch and preload will give you. So does anybody have any questions about it? I would say the best resource right now until they add on our docs is that Medium article.

Where I have it hiding, I don't. So it's medium.com/webpack, I had it there. This one here.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now