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
<rect> in our final image whenever we can, instead of the generated
<path> which our a drawing program — iDraw1 — 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.
OptimizedPNG 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 iDraw1. The optimized SVG has replaced the iDraw-generated code with the SVG primitives such as
<rect>where possible. It also uses
<defs>3 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 bluriness4. 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.
Table 2. Percent difference in SVG file size compared to @1x PNG equivalent
|File type||Difference compared to @1x PNG|
|Optimized @1x PNG||68%|
|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 level5, 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|
|Optimized @2x PNG||71.7%|
|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.
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.
-rw-r--r--@ 1 username admin 54K Jan 27 08:26 email@example.com -rw-r--r--@ 1 username admin 24K Jan 27 08:25 owl-256-orig.png -rw-r--r--@ 1 username admin 191K Jan 27 08:19 firstname.lastname@example.org -rw-r--r--@ 1 username admin 75K Jan 27 08:18 owl-orig.png -rw-r--r--+ 1 username admin 16K Jan 27 08:23 owl-orig.svg -rw-r--r--+ 1 username admin 5.3K Jan 26 22:46 owl.svg
iDraw is without a doubt the best vector drawing app I have ever used. I do all my vector work here despite having Adobe Illustrator on my mac. I highly recommend giving both the Mac and iPad versions a shot. ↩ ↩2
<pattern>tag allows us to define a repeating portion in a
<defs>tag which is used later. ↩
<defs>tag meanwhile, is a placeholder for bits of SVG code we’ll probably use multiple times. Instead of copying it multiple times in the same document, we can define it once, and reference it in one or more
<use>tags later. It’s not actually necessary to place items which we will reference in
<defs>, all that’s necessary, is an id attribute to reference. By using the
<defs>tag, we are able to hide the snippet so that it’s not rendered until we wish to see it. Sometimes you might not want to hide first/use later, and so will just reference an id within a
Even if you’re running you’re own server and using a somewhat complicated server such as nginx, telling the server to compress all text files (which is all an svg is), is such a simple thing you have no excuse if you’re not doing this. As a matter of fact, if you aren’t doing this, I hereby revoke your right to internet. ↩