Lazyweb, I’m going to share something with you today that I hope blows your mind. I’m going to show you how utterly awesome SVGs are for certain types of images. What I’ll be doing is recreating an image of an owl with a chevron background. Here is the source image:

As you see, the image is primarily composed of simple shapes, making it perfect for vectorization. The SVG specification has shape primitives which account for a lot of the shapes we’ll be using here, along with the more general purpose <path> . For example, we’ll use <circle> and <rect> in our final image whenever we can, instead of the generated <path> which our a drawing program — iDraw — gives us.

In part 1 of this series I’ll give a high level overview of the steps I took to recreate the original image then show just how much we save by using an SVG instead. Part 2 will break down just how I arrived at my optimized SVG and launch into a short discussion of whether it was worth it.

Enough chitchat though, let’s get to work. Our owl above is composed of six shapes:

the body - oval

the eyes/toes - circles

the leg - quadrilateral

the wings - stretched oval

the ears/nose - deformed triangle

the feathers - circle + deformed lines

We also have a chevron background which is composed of a simple shape: rectangles.

The more complicated shapes were created from simple shapes to begin with.

The nose/ears were made from equilateral triangles with anchor points dragged to create the slight curve on the sides.

The wings/hands were made from a circle with the bottom anchor dragged down to the desired point.

The feathers were created from circles and lines according to this raindrop tutorial.

The chevron was created as two pairs of rectangles at right angles (90˚), which was later rotated to 45˚.

That ends the image creation portion of our show. Here is the recreated svg image, you may notice I’ve taken some artistic license and subtly changed things.

I exported my owl as an SVG and a PNG and the file sizes are shown in the table below. Before we get to that though, a little explanation is in order.

The Optimized PNG is a 256-color png, whereas the original has the usual 16 million or so colors.

PNG is a 256-color png, whereas the original has the usual 16 million or so colors. The original SVG is the code, as given to us by iDraw. The optimized SVG has replaced the iDraw-generated code with the SVG primitives such as <circle> and <rect> where possible. It also uses <pattern> s and <defs> where possible.



Table 1. File size comparison between PNG and SVG owl image

@2x PNG PNG SVG Compressed SVG Original file size 191K 75K 16K 5.6K Optimized file size 54K 24K 5.3K 1.8K

From Table 1 we can see huge file size savings when comparing this SVG to the exported PNGs. It clearly a win to use them if only to save on size. Another advantage it that because SVGs scale so well, if we need them at larger sizes, the image quality will not suffer from pixelation or bluriness. We also don’t need to create multiple assets @2x, @3x, etc to get this improved visual fidelity.

This ends up saving us time in the creation and testing process. I mean, how many times have you delivered assets, or had them delivered to you, only to realize that you don’t have the mobile version, or the retina version you need. Having one asset we can use for all devices saves us in the design, development and testing phases of creation.

I’m not even going to touch on other advantages of SVGs such as being able to change colors and add simple animations using CSS or Javascript. But the fact that we have the option of turning a static image into a moving one, given a few lines of code is a huge advantage over any raster image format. That’s another (in the pipeline) article for another day however.

Table 2. Percent difference in SVG file size compared to @1x PNG equivalent

File type Difference compared to @1x PNG @1x PNG 0% Optimized @1x PNG 68% SVG 78.7% Compressed SVG 92.5% Optimized SVG 92.9 % Compressed and Optimized SVG 97.6%

Table 2 takes a slightly different look at the data in Table 1, this time comparing % savings to the @1x PNG file. What we see here is that compared to our optimized PNG our SVG only offers us about a 10% savings in file size. Until it’s compressed. At that point our (still unoptimized) SVG is 92% smaller than our unoptimized PNG. This is huge and shouldn’t be ignored.

For better or worse, optimizing assets is a process that takes time. This is true whether we’re optimizing raster or vector graphics. By serving compressed SVGs, which is nothing more than a simple switch at the server level, we’ve:

saved our user’s data, saved our client’s bandwidth, provided a superior visual experience, which is also responsive.

All this was basically for free once the original image is created. Even if you don’t care about high resolution/retina displays you can benefit from using SVGs.

Table 3. Percent difference in SVG file size compared to @2x PNG equivalent

File type Difference compared to @2x PNG @2x PNG 0% Optimized @2x PNG 71.7% SVG 91.6% Compressed SVG 97.1% Optimized SVG 97.2% Compressed and Optimized SVG 99.1%

Table 3 shows us that there are even more dramatic file size savings to be had when comparing SVGs to @2x assets. At this point SVGs might not look better than @2x graphics (until we get to @3x displays) but all the other advantages still stand: smaller files, compressible, scriptable, animatable.

When we look at the compressed SVG it’s 97% smaller. The optimized and compressed SVG is 99% smaller. Now, one asset might not be a huge concern, but over multiple images, and multiple users downloading those images that size difference adds up.

Now we’re not just talking savings to users’ data, but a quantifiable difference in clients’ bandwidth and therefore the money the spend on that bandwidth. 191KB-16KB is 175KB. 175KB * 365.25 days * 100 users is just over 6 GB saved per year. Now imagine if your site get ~10,000 hits per day.

Let’s say you can convert all those social icons, all those text banners, all those call to action buttons (which in 2015 are still straight up images). How much bandwidth are you saving? How much money are you saving your client now? How much time are you saving the user?

But it’ll cost too much to do it piecemeal?

Maybe, it’s time to sell your client on a redesign. If you’re pointing out the real life benfits beyond just Ooooh, prettty! they’ll want to greenlight your next redesign pitch. Did you know google boosts your search page ranking based on how fast your page loads? True story brah.

Comments? @reply to @opinion8d_logic on twitter.

Addendum

You’re website or app will include multiple images. Users now expect the apps they use and websites they visit to look good on all their devices. The 5K iMac, the 4K TV, the Retina iPad, the Retina iPhone, the hiDPI Moto X, the Kindle, the Retina Macbook Pro. And we haven’t even gotten to the windows computers or tablets yet.

Instead of delivering piecemeal assets tailored to certain devices at @2x, @1x and now @3x resolutions we should look to use scalable images where ever it makes sense. Just as we’ve moved on from using pixel measurements and pixel breakpoints, a tipping point has come where we should be looking at scalable images to deliver the kinds of visual experience our users have come to expect and our clients will be proud to deliver.

The take home message here is that whenever you have the option of using an SVG or PNG for use on the web, or even with your app (Yes. iOS and Android are both capable of rendering SVGs within native apps), seriously consider the SVG. That’s enough of me talking for now, I think the numbers speak for themselves.

Oh, and here’s the raw data used to generate the tables above. Nothing fancy here, just a list of files in a directory.