A Tale of Two Logos (or, Now Let’s SVG All the Things)
There are many reasons for refreshing your logo. Maybe your logo’s design has grown long in the tooth and you want to make it more appealing to a new generation or market. Maybe your organization is undergoing massive changes and you want your logo to reflect those changes. Maybe your CEO just got bored with it one morning and wants something with a little more razzle-dazzle.
Or, in my case, maybe you want your website to load more quickly.
I’ve become pretty obsessed with website performance in the last few months. Much of that is due to disgust at the fact that websites keep getting more and more bloated, and wanting to do my part to combat that disappointing trend. One of the easiest ways to improve website performance is to optimize your website’s images, something I’ve been doing for awhile with my content images. But what about my design images?
Opus’ current design is pretty minimal, as is my wont, but the design does include a handful of images and icons, with the most prominent being Opus’ venerable logo. Two versions of the logo are actually used in the design: one in the header that’s black with a subtle gradient, and one in the footer that’s reversed with no gradient. Each logo used to be its own transparent PNG file, and weighed in at 9 KB and 4 KB, respectively.
Now, 13 KB (and two HTTP connections) doesn’t sound like all that much, and relatively speaking, it’s not. But two files still seemed redundant since the two logos are basically the same image (color and visual effects notwithstanding). I wanted to find a more efficient way to display the logo in the design.
Enter Scalable Vector Graphics (SVG).
You down with SVG?
Most images on the web are saved in one of three formats: GIF, JPEG, or PNG. These are “raster” formats, which means they’re a collection of pixels arranged on a rectangular grid (which becomes visible if you zoom in really close using graphics software like Photoshop). SVG, on the other hand, is a “vector” format. In a vector image, the shapes you see aren’t the result of clumps of pixels but rather, determined by sets of coordinates contained within XML. In other words, an SVG file is a glorified text file that, when loaded in a browser, is rendered as an image.
For the right image (e.g., icons, line art, logos), SVG offers several advantages over raster formats: they can be resized without any loss in quality; their file sizes can be very small since they’re text files; and they can be modified and adjusted with CSS. Since Opus’ logo is pretty simple — it’s basically a lot of curves — SVG made a lot of sense.
I won’t go into the details of creating SVG files — I’ll point you to Chris Coyier’s thorough SVG introduction for that — but with SVG, not only was I able to replace Opus’ two logo files with a single 3.5 KB SVG file, but I was also able to replace the various icons with SVG equivalents. (I highly recommend IcoMoon for this.)
Furthermore, by inlining the SVG code directly into my template rather than reference external “.svg” files, I was able to reduce the number of HTTP requests to zero. But the party — and, by “party,” I mean “series of experiments to make my website faster” — was just getting started.
Ain’t No Party Like an SVG Party!
Remember that an SVG file is just a collection of coordinates. These were the coordinates used to create Opus’ logo:
(I’ve added line-breaks to the SVG code to make it more readable.)
If you want to make a text file smaller, you start removing text. Similarly, if you want to make an SVG file smaller, you start removing coordinates, which effectively redesigns the image. Since we’re not computers, coordinate sets are gibberish to us; we still need to use something like Illustrator to update the image. I’m not an Illustrator guy, but fortunately, my Firespring comrade Bennett Holzworth is one, and with his help, Opus’ logo was streamlined to what you see at the top of this post.
The new logo was simpler and cleaner, lacking several curves and filigrees. Code-wise, the logo’s coordinates were reduced to this:
The result was a reduction in file size from 3.5 KB to 1.1 KB. However, SVGs can be reduced even more with a tool called SVGOMG, which gives you a number of options for optimizing and streamlining SVG files. By applying a pretty severe level of optimization, I was able to simplify the coordinates even more, to this:
This resulted in a file size of 610 bytes, or a file size reduction of approximately 82% of the original logo. GZIP compression — remember, SVG files compress really well, too, since they’re text files — reduced that even more, to 366 bytes.
To sum up, through a combination of streamlining Opus’ logo, optimizing it, and running it through GZIP compression, I was able to reduce its file size by nearly 90%.
What’s more, since I’m using the same SVG code for both instances of the logo and I’ve inlined the SVG code to reduce HTTP requests — you can see it if you view this page’s source (just search for “svg”) — I’ve further optimized Opus beyond just reducing image file size.
And it doesn’t hurt that the refreshed Opus logo looks pretty slick, too. A win-win all around.
Obviously, this is a rather extreme example. You don’t always have the luxury of redesigning your logo simply to make your website faster. (Your marketing department might have a word or two to say about that.) Even so, I hope it’s obvious that switching from a raster image to optimized SVG can have significant benefits.
Not every image will work as an SVG; if your logo includes elements that can’t easily be converted to coordinates (I’ve seen logos that contain full color photos, for instance), then stick with JPEG or PNG. But if your logo can be converted easily, I highly recommend doing so. The benefits in terms of website speed and image flexibility are considerable, and well worth the time it takes to figure out SVG if you’re used to working with raster images.
For more information on working with SVG files, check out “A Practical Guide to SVGs on the web,” “Tips for Creating and Exporting Better SVGs for the Web,” and the aforementioned Chris Coyier article.