Web Performance with Webpack

Types of Code Splitting

Sean Larkin

Sean Larkin

Web Performance with Webpack

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

The "Types of Code Splitting" 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:

After the discussing the importance of web performance, Sean reviews two types of code splitting, static and dynamic.


Transcript from the "Types of Code Splitting" Lesson

>> Sean Larkin: You might be like, Sean. Why do I care? Why is this important? And so the future of the web is mobile. Literally today, the average website takes 14 seconds to get interactive. 14 seconds. And the less load that you ship means that you can be interactive faster.

When I referred to dynamic import, I'm referring to this syntax right here. So the dynamic import is in stage three. It's part of the what WG loader spec. So whatwg/loader. And that's a web specification. And so what this allows you to do in browser land. This will allow you to just at run time dynamically fetch, any piece of JavaScript and use it like a module.

However, there's some constraints to that, which are like, you really have no control over. You can't optimize anything that you're doing dynamically. You can't, like really there's some security concerns. And there's basically no complete browser interrupt on the syntax. But for us, we saw this as an opportunity to convert before webpack three, the only way to have code splitting was to use require.ensure.

But it's not a browser specification, and so we wanted to get rid of it. And so, this syntax right here, is what I refer to when I say dynamic import. So just remember that because I'm gonna use two terms called dynamic and static code splitting, and I don't want you to confuse the two.

So, there's two types of code splitting. So there's static code splitting and then there's dynamic, heavy quotes. Super heavy quotes. When I say that because there is nothing in webpack that is purely dynamic. Everything we do has a build time, right? The number one question that I hear from people is like Sean.

Can I use code splitting and do something like this, like some bar? And the answer is no, you'll never be able to do it, and we'll never support. Because it's an anti-pattern we don't you to do anything at runtime. If you have the sources available on your code base, to be code splitting statically, right?

And so, we'll cover this in a second but I just want to clear some of the air, that's why I say heavy quotes, dynamic. So static code splitting, an example might be you'd want to use this, anytime that you have a heavy library, right? That you need to use but you might need it up front, right?

A great example is like, if you're not using three.js on your initial download, or like on your initial view of your page. Yet, like in some other lazy route you're gonna use it. Why do you wanna have that in your initial bundles? You don't want it, right? You'd only want it when it's needed.

Anything temporal, so when I say temporal, I mean like, if it's not there initially, it appears, and then goes away. So like think a modal, think a tooltip, a dialog. Anything that's not visible on your page and will conditionally load. That's what I consider temporal. Even things like as you're scrolling down the page and it comes below the fold, that's technically temporal.

And then routes. Like, any time you have routes, especially client side routing. A user's only gonna go to your first routes, right? So essentially you can code split every single route that you have to ensure that the only code that's getting delivered to this person's experience is the one for the page that they're on.

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