I recently worked on a project that was getting a ton of traffic but users were bouncing because the page load was too long at around 10 seconds. They called me in because the majority of the images on that site were SVGs, and they were animated. I trained the team how to decrease the file size on the SVGs while preserving the appearance and functionality, finally getting the load time to under 2 seconds. The bounce rate dropped dramatically and conversion was restored.
If I was designing these SVGs myself, I would not have run into many of these issues, but it’s a more likely scenario that the engineer and designer are not the same person on a project. In this post, I’ll chronicle some of what I trained them on to ensure stellar performance for SVGs.
Note: I use Illustrator for the creation and optimization of my SVGs because I’ve found the export and tooling superior to Sketch’s. I’ll readily admit that there might be ways that Sketch works with SVGs that I’m not aware of. But I will say I have seen it make strange <clippath></clippath>
s in the place of paths, which makes me steer clear of it. For the examples below, I’ll be using Illustrator. Use whatever works for you.
Talk Upfront
This piece is not always possible, but whenever it is, try to talk to the designer before they do a lot of the work, to explain what they should be thinking about when they are creating SVGs.
The most easy to convey piece should be that simply drawing something on paper and then tracing it in illustrator will come with a lot of junky path data and should never be used as-is. Simple shapes and pen drawing paths are preferred. Very complex objects can become large very quickly, so the less points the path has to draw, the better for performance.
This doesn’t mean that you can’t make seemingly complex shapes. But hundreds of path points can sometimes have the same appearance and interest that thousands of path points do.
Reduce Path Points
If you’re going to create a hand drawing, you can trace, it, but past that point you should use Object > Path > Simplify.

You will need to check the box that allows for preview because this can potentially ruin the image. It’s also worth it to say that the image degrades quickly, so usually the most I can get away with is 91% or so. This still gives me a good return, with a high number of path point reduction.
This is also probably the quickest way to accomplish this type of reduction. A more labor intensive way, that I will use for smaller pieces that are unnecessarily complex, is to redraw it with the pen tool.

Sometimes this is very little effort for a large payoff, but it really depends on the shape. You can also put a few shapes together, merge them with the path tool, and then modify the points with the white arrow, to simulate existing shapes.

It may seem intimidating at first, but you can use the pen tool to really quickly make more complex areas. Then take all of these shapes and use the pathfinder tool to merge them all together. If it doesn’t look quite right, don’t fear! You can still reduce the opacity on what you made by a little (helps so that you can see what you’re trying to emulate in the shape underneath). Then you can grab the direct selection tool, (A in quickkeys, the white arrow on the toolbar), and drag those small points around until you get a more refined shape. Never hurts to zoom in a bit to see the details there.

Remove Repeated Gradient Defs
By default, Illustrator and other vector editing tools will, at best, create a gradient and put them in defs
, but at worst, create jpgs of the gradient or add many separate gradients even though just one can be reused. In the latter case, use Jake Albaugh’s gradient optimizer. It’s a smart tool that will collapse multiple unused gradients into only what’s necessary. I’ve seen it reduce the file size of an SVG by half, though that was a file with an unusual amount of similar gradients.
In the case of the former, you might find you can write the gradient by hand instead of using the png or jpg that the editor provides. Here are the values that SVG needs to create a gradient:
- It needs to be contained within a linearGradient block, and needs to have an id so that you can reference it in the CSS to apply it to SVG elements
- It uses stop offsets from 0-1 with stop-color attributes where you specify what colors you want at which points.
<defs>
<lineargradient id="linear-gradient" y1="75" x2="150" y2="75" gradientunits="userSpaceOnUse">
<stop offset="0" stop-color="#fff33b">
<stop offset=".5" stop-color="#f17b3e">
<stop offset="1" stop-color="#e93e3a">
</stop></stop></stop></lineargradient>
</defs>
.path-class { fill: url(#linear-gradient); }
Reduce the size of your Canvas
Making your canvas not too large but not too small helps with the weight of the file because the larger the number, the larger the number of all of the path points. Too small, and you might get a lot of decimals, that when trimmed, warp the image. If you have a nice range (I prefer somewhere like 100 x 100- but this is worth experimenting with), your path points will be small as well without breaking into decimals.
To quickly change the size of the artboard in Illustrator (the viewBox in SVG), you can go to Object > Artboards > Fit to Artwork Bounds. Sometimes you will want to be a little more precise about it, and in that case go to File > Document Setup > Edit Artboards. This will allow you to hand-tweak the visible area or even specify the units you want precisely. You may have to change the size of the artwork within a little after doing so as well.
Export, then Optimize
I prefer to use Illustrator because the export settings for SVG are more advanced than Sketch. I don’t use Inkscape but I know some people love it. If you are using Illustrator, use Export As > SVG not Save As > SVG for better results. Even after that step, though, I optimize. Here are some options:
- SVGOMG– this is a web-based editor that uses SVGO, it also offers service workers for offline capability
- SVGO/SVGO-GUI– this NodeJS-based tool is extremely well done with a lot of options. I recommend using the GUI with it, though, because SVG export can change its appearance.
- Peter Collingridge’s SVG Editor– I’m still a fan of this one even though it’s not quite as fancy. I also like playing with the experimental editing tab.
Be mindful of the toggles here. The ones that I find myself checking and unchecking the most are:
- Clean IDs– this will remove any carefully named layers you may have.
- Collapse useless groups– you might have grouped them to animate them all together, or just to keep things organized.
- Merge paths– nine times out of ten this one is ok, but sometimes merging a lot of paths keeps you from being about to move elements in the DOM around independently.
- Prettify– This is only necessary when you need to working within the SVG, for animation or other manipulation purposes.
Finally, make sure you’re gzipping your files (I usually do this as part of the overall build process), but it makes a huge difference in terms of SVG filesize.
Use SVG Filters instead of Appearance Effects
A few times while working with an SVG from another designer, we discovered that using the effects in the appearance panel, such as drop shadow, produced a monster base64 file that was cumbersome and expensive. This problem can be solved by using an SVG filter instead, available at Effect > SVG Filters and then choosing one from the dropdown. It’s worth mentioning that these will be available to you only when the file is in .ai format, not once it’s in .svg format (which is why I recommend always keeping the .ai source file). By swapping these out, not only did we improve the appearance of the SVG, but we decreased the filesize from a whopping 1.8MB to 1.2KB!

Create a Large Background Shape
When tracing an image, oftentimes you will be handed an image with pattern or multiple images “on top of” a background. But Illustrator will not understand these shapes as one large shape beneath a pattern or many other shapes – it will break the base color into the shapes between the pattern.

Here is an example of an easy win because you can remove all of these shapes and replace it with one big background image. I find it easiest to trace around the whole containing unit first before removing anything. Remember to make this layer a different color from everything else.
Many times the shapes behind can be grabbed all at once by using Select > Same > Fill Color (or Fill and Stroke). This allows you to grab many shapes at once and delete them all at once very quickly.

Conclusion
These aren’t the only ways out there to work with SVGs for better performance, but the main key takeaway is that the less path data you have the better. Being mindful of what you’re loading in your SVG files – double check the SVG DOM for cruft and remember to optimize. Going the extra mile designing for performance can shave vital seconds off of the page load of your site.
I would guess pixel preview and then tweaking to line up on a pixel grid would help. Far less fractions and a good idea of how much detail is enough.
Some great info here! A quick tip for manual tracing in Illustrator: make your sketch/source image a Template layer (go to Layer options or double click on the layer). This locks and dims it so you can put your path layers underneath and see what you’re doing.
A plugin for Illustrator I found to be indispensable for optimizing SVGs – Vector Scribe (http://astutegraphics.com/software/vectorscribe/). It’s a bit pricey but the amount of time it saves me when working with SVGs for web was well worth it.
This GIF is pretty wild:
Wow, that’s pretty unreal!
This is why I write most of my SVGs by hand. Most WYSIWYG editors will bloat things up real quick. Other points of bloat : paths that can very often be expressed as predefined shape elements; path points are frequently floating point numbers that have an absurd level of precision (think 10-20 decimal places), Round people!; Many vector clients will export namespaces and attributes that are only meaningful to that client (like inkscape and sodipodi elements/attributes that can almost always be removed to save 20-30% of file size. And lastly, because it’s an easy trick worth mentioning when serving up SVGs directly as image files (versus embedding them in html directly or as data URL format) : XML based content gzip compresses like a mfing boss. There’s even a designated file extension for compressed svg files that most browsers will handle without having to fuss with HTTP headers or Apache settings : svgz. Use this, and that awesome drop from 1.8MB to 1.2KB drops to .5KB (note: I mention compression last because it’s an easy fix, but should be the final step in optimization after actually cleaning up the svg content itself.
Oh, another pet peeve: don’t define text elements and draw the text on top it as well. 99 times out of 100, the text element alone will be fine and save a huge amount of effort drawing letters that your client can already handle via these things called fonts.
Gzipping is certainly where it’s at and I should have mentioned that- I was writing from the point of assumption that people are already doing this as part of their build process but that’s sometimes not the case.
In terms of the text- I have seen a lot of really funky cross browser inconsistencies with SVG text (I’m looking at you, Safari), so I tend to take that on a case-by case basis, after doing a lot of checks.
The rounding is part of the export process in Illustrator, as well as what SVGOMG is good at, so I didn’t get too granular in my explanation of that, but a good thing to point out nonetheless.
Thanks for all the good info!
You might be interested in trying Boxy SVG editor which generates much cleaner SVG files than Inkscape.
It does support opening and saving SVGZ files and allows you to configure geometry precision. It uses proprietary bx: namespace, but only when absolutely necessary to preserve editing capabilities.
Oh, and also:
Can you share the final SVG of the spidertocat image? I’d love to look at the raw XML directly.
Thanks Sarah for this information.
Actually, it doesn’t.
<defs>
purpose is to place reference elements without rendering. Non-rendered elements like gradients can be totally safe placed anywhere. There is no need to add<defs>
element just to place gradients and other non-rendered content.Regarding SVGO(MG): without Clean IDs it will not remove unused elements, since it judges whether element is being used on the presence of
id
. Clean IDs removes non-referenced IDs.In the whole the article is superb!
Oh good call, I’ll update the article. Thanks!
As of SVG 2, gradients can be safely placed almost everywhere, though browsers don’t support the SVG 2 content model yet which means you can’t put them inside e.g. shape elements.
Wonderful article. Illustrator is the way to go for me, too. Sometimes I use Sketch but I’m more of a PC guy. Moreover, Illustrator works better for the web as far as I’m concerned.
How i use external svg sprite with JavaScript accessibility.
Great tips, Thanks a lot.
What about using symbols for repeated elements? Does this provide any performance gains? It definitely makes working with the resulting code a lot simpler.
You know, a while ago I did a perf benchmark for SVG with symbols and didn’t see any significant performance gains, but that was over two years ago and specifically for animation, so I could stand to rerun that and do a more official test. Or, you’re welcome to as well. One commenter on CSS-Tricks saw a big perf gain between rendering in symbol over rendering in React, if that helps in the meantime.