 Hey, everyone. It's Sam here. On this very short episode of today's Santa Trucker Developer Diary, I want to talk about SVGs. These are the lovely responsive images that we use all over the place in Santa Trucker. Our houses, our elves, our cute little scenes are all SVGs, with only a few PNGs to sort of round out the edges. Now, a disclaimer. I'm not a designer. I didn't make these SVGs. And what I want to tell you today is about how I, as an engineer, will work with these SVGs to make them smaller and better for your users. So let's have a look. So when you think of SVGs, this is what you might expect. You'll see an SVG tag, you'll see a few other things, and this is basically XML. SVG is really two things. It's markup and content. So this is very normal. The markup looks very structured. However, when we actually ship our assets to users, we use a tool called SVGO, and there's an online version which is in the resources below, to convert these files to something that's very small. What's important to remember is this really just shrinks the markup. It doesn't shrink the content in any way. So if you have too much content, which I'll explain in a second, your file size will go down, but not enormously. The sort of assets we deal with are reasonably large SVGs. Quite simply, when I try to think about my SVGs and how I can make them smaller, I'll just sort by size and maybe pick on the biggest file. So in this case, we've got two Easter Egg trees here. And actually, the old one is the one we had last year, and the new one, the lower one, is the one we had this year. They look exactly the same. So why are they different in size? Let's have a look at the old version. So on my Mac, I've got Sketch, but you might be using some other tool on a different platform. This asset looks fine. It looks the same as the new one. And actually, it's still reasonably small. It's about 150K, which for a complicated asset with lots of small detail does make sense. But it's worth looking at your SVGs, especially considering that the tools that generate these, you know, their computer programs too, right? And they also make mistakes. So let's look at this tree we've now opened. So it looks pretty good. It's about 150K, which makes sense. It's a complicated tree and there's a lot of fine detail on the bottom with the different elves and so on. But if we dig around this XML file, we can actually see that these dots at the bottom here, the totems, I guess you'd call them, are actually made up of a lot of dots. So that's kind of weird. Well, you noticed this last year and we actually could delete most of them. And now you'll see that we have one blue dot and one gray dot. And so rather than showing what was about 30 different dots, I think, times however many totems were around the circle, we then shrunk that image by just modifying those gray dots manually to make them big, to make them lines. And so that was the way we shrunk that asset, almost by half, just by simplifying some detail that didn't really matter for users looking at that tree in the middle of their village. The next thing we often look at is things like storyboards. And what does that mean? So if we load up a different asset, in this case it's the road image that sits at the back of our village here, you'll see that while the main part of the image is to the right here, we have this kind of storyboard in the very top left. Now, as an engineer, you might think, oh, I should delete that, it'll save me space. But interestingly enough, this is a case where actually getting rid of them doesn't really help you very much. So these assets up here are all found in the village itself. And the way this SVD was written is that this is actually like a symbol. So it's duplicated in two places. So if I delete this, which is totally possible if I go toggle click through, select and delete, you'll find that the exported version doesn't really get much smaller because it's really just a duplication of that asset. And that's a value that SVG has in terms of markup. Unlike a PNG, that doesn't take up space. But it's something that you can simplify, but it doesn't really help you. Another thing I want to call out is that if I was to export this image, and this is a complicated asset, it's about 136K as we discovered, it actually ends up being about 1.5 meg. So in this case that makes total sense. This is a very large asset which lives across the entire site and we use it at multiple screen sizes. So an SVG is perfect, we really never want to convert this to a PNG. However, if you have very fine detail like small assets, this is the case where a PNG is really useful. And this is the reason we use it in a few places like our new today cards, for instance, are all PNGs because this has a lot of very solid colors that is always used at a one consistent screen size. So one last thing, you can compress your SVGs. You can use GZIP to convert your SVGs to an SVGZ file, which kind of makes sense, right? Your PNGs are fundamentally compressed, so why not your SVGs? But the reality is, is that nearly every web server is GZIPing your files anyway. And so most clients will receive your files, whether they be HTML, PNG or SVGs, GZIP down so there are already fewer bytes for your clients anyway. That was SVGs, done with Santa Tracker. I'll see you next time. You can subscribe to the Google Chrome Developer Channel down here. Or check out some other great videos along here.