Image Loading Exercise

Steve Kinney

Steve Kinney


Check out a free preview of the full Vite course

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

Steve asks students to grab a small image (favicon) and a large image and import them into their project. The learner is then asked to observe the differences in how Vite handles the two images. Vite will inline the small image, converting it into a base64 encoded image and including it directly in the file, while the large image will be split, hashed, and cached automatically.


Transcript from the "Image Loading Exercise" Lesson

>> What I want you to try to do real quick is go grab something else, right? If I gave you a suggestion, it would be go grab this favicon, which we know is tiny, right? We're gonna use that instead and you're gonna see that Vite does something kind of cool in this case.

So kinda in our next science experiment, what we're gonna do is we've got the large image, which is like, yoh, this is big, right? I'm gonna split this out as an image, but that favicon is real small, right? Do we wanna make an x-ray CGB request? No, probably not, right?

It's probably easier just to inline it. And so you can see that Vite will actually kind of look at the file itself, right? A very big image, it is gonna split out, it's gonna hash, it's gonna do all the cache stuff automatically on your behalf. If you grab a small image like any kind of the icons that you're using in your application or anything along those lines, it's gonna do something very different.

So what you're gonna do is you can move that same one that I moved, but then also go ahead and grab, for instance, this favicon, one of these smaller images, right? And so we can grab this one. I'm gonna go down, I'm just gonna put a copy of it in here, right?

And what you're gonna do is try both out and tell me what you notice between the two of what files do you end up with, whether you use the big image or the small image, and then see what the difference is. And we'll kinda take a look at it and see if we can acquiesce what happened by looking at the network tab and the sources tab and our developer tools.

It's been a few minutes. Try both out. If you have other images you wanna try, put them into the soil, anything in your soil structure is fair game. So you can use the picture of me after workshop or you can grab another one, as long as you've got a relatively small, I'll say hypothetically under 4K image and then a relatively large one.

And what you're trying to is important the both and use them and see that There's a fundamental difference both in the hashing and the way Vite treats them that will make your app perform differently. How about that? And you can probably take a lucky guess on how it's gonna go but try it out and see what the differences are.

Before I had this big image, right, and if we look, we generate a big image. And then I grabbed a small image, right? This favicon that I pulled over. It's decent small image. I'm gonna run this npm run build again and there's no image. It didn't spit out an image, right?

And if we look, we can investigate what happened, which is we can go into the, in this case, our index. And we'll do the quick little save actually, let's actually look in the developer tools. And here you can see my image loaded, right? But I didn't actually spit it out as another image.

And so in this case, actually what happens is that Vite will go ahead and go in there and actually inline it. You can see almost this import statement here. It will actually take it and make it a base64 encoded image and just include it in that file, right?

And so instead of making that additional HTTP request, it will look. It's like, hey, if this is small enough, I'm just gonna inline it in there we're not gonna make an extra request, we're not going to worry about NSF. We'll just put it directly in there. I think we can see if we go into the content, we've got the actual file in this case, but you can see cuz it's local host source, right?

If we look at the build version, let's do the NPM run preview in this case, I think that will show us what we need to see. npm run build, npm run preview. It's a npx build preview, npx build preview. And now we'll go and look at the built version.

This is where that preview becomes useful. You can see the difference between what we see in production, and you can see that actually turned it into a Base64 encoded image that it just put right into the file itself. And so it's trying to, when in doubt, optimize stuff.

Right out of the box, that is 4k. Anything out of 4K, it's just gonna try to inline and include in there. If you hate this for some reason, there is a feature in the build process when we look at the configuration, you can set assets in line to zero.

It'll never do it. You want bigger files, you want smaller files, you turn that number to whatever you want. But again, a lot of these things, you're gonna get some of these optimizations for free, right? We still have to do with that giant image and I I can either open it up in my favorite photo editor and resize it.

But what if I wanna do source sets or stuff along those lines and I wanna have multiple sizes for different viewports and stuff along those lines, all of that stuff? Especially given a deadline or something along those lines, that's time-consuming, right? It would be great if we could configure our build tools to actually be able to process the images the same way it processes CSS through PostCSS, or our TypeScript, or our JSX, or something along those lines.

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