don't even necessarily need Lottie. We could accomplish this on our white background with an animated GIF and be done with it. Nonetheless, it gives us something to toy around with. So how can I solve this? How can we make the page load as quickly as possible, but then only on demand pull in the necessary library in JavaScript to render this animation in this page? The solution is to use asynchronous view components along with Webpack Dynamic Imports. It sounds kind of fancy, but don't worry. We can figure this out. I'm going to go to my routes file, and here's where we pull in that loaders view.

We can figure this out. I'm going to go to my routes file, and here's where we pull in that loaders view. Take a look. We're going to change this up by combining two different ideas here. We noted that we can register asynchronous view components. These are components that can resolve and render themselves on the fly, and that's exactly what we're doing here. But we're also adding this import function to declare a dynamic import. Think of this as a hint to Webpack that we want to, so to speak, turn on code splitting. We want to split this code here into its own bundle that should be loaded on the fly and

Think of this as a hint to Webpack that we want to, so to speak, turn on code splitting. We want to split this code here into its own bundle that should be loaded on the fly and only when you need it. So let's give it a shot. I'm going to compile everything down, but I think my build's going to blow up. And it does. Don't worry. Let's scroll up. It looks like support for dynamic import is not currently enabled. And if I scroll down here, it'll say, if you want this, you need to pull in the necessary

Now one quick thing to understand is this configuration file will be merged with the one that Mix provides by default. So you don't have to reproduce everything Mix offers. You only need to include your overrides or your new plugins. Okay, so I'm going to give that one more shot, and it should compile down. And when it does, you're now going to see multiple JavaScript files, like this. So take a look. App.js is back to 500k, what it was earlier. So that means once we do a production build, we're at about 100k. Good enough for me.

But if I open up one, and we look for it, yes, all of the Lottie logic is going to be stored exclusively here. So the great thing about this is, it solves our problem. Take a look. I'll visit my home page, hit Shift Command C to open up Chrome DevTools, and then I will visit the Network tab. Just to be safe, we'll disable the cache, and I'm only interested in XHR requests. Okay, we'll give it a refresh. So at the moment, you'll notice that if we hit the JavaScript tab, we've only pulled in App.js.

There's no need to download and pull in all of this code that may not ever be needed by the user. For example, even for something as simple as this, many people will visit the site to grab our logo, and that's it. So why pull in an animation library when they're never going to click on this page? There's no need to. Okay, so one last thing here to keep in mind. You'll notice that when using code splitting and dynamic imports, they will be given these generic ID numbers like 0, 1, 2, 3. Now it can be useful to name these, and here's how.

generic ID numbers like 0, 1, 2, 3. Now it can be useful to name these, and here's how. You use this webpack magic comment. Webpack chunk name. Call it anything you want. If this is loaders, we'll stick with that. And reformat. Okay, so now let's delete these two, and if I give it another run, now the bundles will be named accordingly. There you go.

be named accordingly. There you go. You get the loader code, which is where you will find the load animation configuration there, and then the actual vendor library. And that's it. That's all you need to know. So now, lazy loading routes is a new tool in your belt you can reach for when and if you need to.