Check out a free preview of the full JavaScript Performance course

The "Lazy Loading" Lesson is part of the full, JavaScript Performance course featured in this preview video. Here's what you'd learn in this lesson:

Steve introduces Lazy Loading. Lazy Loading is a technique to delay initialization of an object until the point at which it is needed.


Transcript from the "Lazy Loading" Lesson

>> Steve Kinney: We're going to move into what I think is the crown jewel of a lot of stuff we've been talking about today. Imagine first the JavaScript performance and the network performance. If I said, you can fix both dramatically with one weird trick, right? You'd click that link bait article, you totally would, right?

So let's talk about that, which is lazy-loading and pre-loading with React and webpack. We know that there's a cost to Javascript, right? We know that there is a cost to the network, right? It'd be cool if we could reduce that a little bit. First, just to kinda make my point I'm gonna go out for the two golden rules again.

Not doing stuff is faster than doing stuff. This is I think a reworded version of the first one. Doing stuff later is a way to not do it now, and is thereby faster, right? Cuz it's a version of not doing it now. So there's a tweet from Sean Larkin who works in the Webpack team.

It's kind of setting a goal of bundles, all bundles, all JavaScript being less than 300 kilobytes. You're like, but you showed me a graph, and the graph is big, [LAUGH] right? My application when fully loaded is I think like five megabytes of stuff, the whole way through. But notice there, there's a word kind of lazily or not.

What if you don't need everything all at once. So, I think about the app I working on is InGrid, right? There's a full editor for manipulating campaigns, and there's a code editor and there's all of these crazy things. There's a thing for uploading your contacts and a bunch of different features.

I don't know what the person came there to do, so I send them everything, right? They might not need that entire DragonDrop editor and the WizzyWig text editor like wake and style stuff. They might not need the code editor if they're using that. They might not need either of those if they're just uploading some new context.

They might not need even that if they are just going and tweaking some settings or dealing with some alert that we sent them, or checking on the stats of their most recent campaign, right? But right now, and I'm working on fixing this, but right now, we send them absolutely everything, right?

And they receive all this code, they have to parcel this code. Like they pay that cost, that's a giant yellow slug that I showed you on the screen shot of our application. In fairness that is our drag and drop editor on that page. But considering I said in the same bundle no matter what, they're paying that cost regardless.

So if I can send them less code, they have to like, less code has to go through the tube. Less code shows up at the other side of the tube which means they have to parse less code, all right? If they parse less code, that's gonna be faster, cuz all the crazy stuff we saw earlier, not doing that is faster than doing it, right?

And then we can show them, then if they want to go to the editor, I'll send them that code later, right? And I won't send them the model space code editor, the context uploading thing. As they need stuff, I will send them small bits more that they actually need as they go through the application, right?

Cuz doing it later is a way to not do it now, and not doing it now is faster.

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