Webpack 4 Fundamentals

Limit Filesize Option in URL Loader

Sean Larkin

Sean Larkin

Webpack 4 Fundamentals

Check out a free preview of the full Webpack 4 Fundamentals course

The "Limit Filesize Option in URL Loader" Lesson is part of the full, Webpack 4 Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

To reduce page weight of web pages, Sean demonstrates how to set limits on what filesizes of images that should be converted to base64 encoding with the URL Loader.


Transcript from the "Limit Filesize Option in URL Loader" Lesson

>> Sean Larkin: So now, you might say, Shawn.
>> Sean Larkin: I don't want to load literally, like this probably just bloated our Java. Let's see what the size of our JavaScript is. It bloated the bundle by like 500K, because you added a ginormous data URI, and that's not good for performance.

And you're absolutely right. I completely agree. Here I'm like trying to fidget with this. Okay so what's really awesome is that the file loader or I'm sorry, the URL loader actually has an option that's called limit. And so we can jump to our config. And we'll modify this slightly so that we can pass options into it.

This is kind of a shorthand for this right here. It's the same thing but some people just like having the shorthand and it's kind of a legacy syntax as well so we keep it backwards compatible. But, If you change this to actually be an array of objects we call these loader objects or use objects.

You can now pass options to it. And so the option in this case is called limit and we can say only if the image is 5,000 bytes will we be okay with inlining it as a base, a base 64 URL. All right? Otherwise, take that file and admit it to our disk directory and instead just return the hashed URL of where that file will be.

So if we quit out of this build and we do our production build, actually no I'm sorry, we could even do our dev build and we'll see this.
>> Sean Larkin: So if we look at the assets that are output, you actually see a hashed image now, right. Now we don't see it in our disk folder because we're in depth server.

It's in memory. But what's awesome is that this is now actually being passed into, that's why I call it image URL, because you get both essentially. And so when you see here, it gives you exactly where that file's gonna be placed. Super convenient. I would say even if you don't even care about inlining, I love this capability because it's like I never have to manage injecting how that URL is gonna be placed.

There is still, so there is always gonna be trade-offs to think about. So things are, If you don't use just an image tag in the HTML, then you're kind of waiting on JavaScript to get your images. So it's important to profile for performance and make sure it's worth this kind of technique.

But in a lot of ways people are usually cramming like 40 image tags down the browser and this ends up being a lot more optimized. And you can also use things like link URL preload and for even having a service worker cache this information ahead of time which is really valuable for performance.

So yeah, this is really and behind the scenes what URL loader is actually calling to do the take this image, put it in the disk directory, return it to disk URL. That's what file loader does out of the box. And so all it's doing is it's calling another loader behind the scenes.

That's why we installed both of them. And so this is great, and its options really handle your production case and your development case. If you found other reasons, like you wanted to have, maybe you could set the limit super-high, and you're like I don't care. Just put it all on memory.

Maybe then you could move this to your dev config and then set the limit way lower in your prod config. That's also an option.
>> Sean Larkin: Does anybody have questions so far about URL loader or file loader? Anybody in chat as well?
>> Sean Larkin: If not, so, I think, like this is exciting cuz we're getting to the time.

Yeah, go ahead.
>> Speaker 2: Does that work with SVG as well?
>> Sean Larkin: It does! It works. So, like what's cool is that it's agnostic to anything. So, like, if it can be, So, so I don't know if can an SVG a URL? It can. So yes, absolutely it can.

So it can do that. There's also special SVG loaders too. Some people are like I want an SVG to write it in the normal type. But then I want it in a react component, or I want to go the other way, take a react component and then compile it to an SVG statically.

Like there is some really interesting stuff that you can do because you're doing it ahead of time and you have access to all of your assets and they are all tied together in the same graph.

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