The following is a guest post by Raymond Schwartz. Like it’s raster brethren, SVG should be optimized before being used on production sites. There are several great tools for that, but as Raymond is about to show you, the best results come from a deeper understanding and a little manual work. For instance, decimal precision is a big factor in SVG optimization, but it’s a rather arbitrary metric depending on the coordinate system of SVG. Alter that system, get different results. Here’s Raymond.
Three factors determine the optimized file size of an SVG: physical dimension, viewBox, and decimal precision. Arbitrarily setting any one of them can cost you valuable bytes—even kilobytes. Each SVG has a specific combination of these three properties that will yield the smallest possible file size. By understanding how each impacts the articulation of vector paths, you can discover how to adjust them to achieve the optimal optimization.
1) Physical dimension: debunking the “Scalable” in SVG (sort of)
To create an SVG, fire up your favorite vector graphics editor, setup the document, and make something visually engaging. Part of the document setup is defining physical dimensions. This may not seem critical since, by definition, vector graphics are scalable and visual dimension will vary depending on its context. While that’s true of the visual representation, the same is not true of the code representation—that remains constant. The code representation is derived, in part, from the container’s dimension (or “artboard” in Illustrator) which is described by discrete measures. By setting the dimensions, you’ve already partially determined what the file size will be.
2) viewBox and micro optimization
Dimensions, in addition to guiding path articulation, also determine the viewBox attribute’s values.
A viewBox could look like this:
viewBox="-351.7474061, 2051.85204372, 2520.3925946, 2520.13473217"This is much too long considering we can perform a micro optimization in a lossless way—without changing the image visually. First, set the top-left corner to 0,0:
viewBox="0, 0, 2872.1400007, 468.28268845"This saves 23 bytes since one character equals one byte. Next, round width and height to whole numbers—scaling artwork if needed:
viewBox="0, 0, 2872, 468"That saves another 17 bytes. Finally, scale the artboard down to reduce the number of digits:
viewBox="0, 0, 252, 252"Adding another two for an overall savings of 42 bytes. Even though the savings are small, this optimization is easy to do and has no negative effects. And now that you know, you’ll set up your files this way from the start—this should be built-in to your file setup. But more importantly, as we shall see, this method has a much greater impact saving bytes in paths.
3) Decimal precision: which one is best?
When you save an SVG, you’ll need to indicate a decimal precision—usually an integer between one and eight. It defines the number of digits after the decimal point for all numeric values. Remember, characters equal bytes and the less we have, the smaller the file will be. As decimal precision is reduced, so are the amount of bytes—potentially seven less bytes per number.
But as precision decreases, SVGs can visually break because there may not be enough numeric data to accurately describe them. As precision increases, more detail is present, but beyond a certain point, may not increase fidelity—wasting bytes. Our goal is to balance file size and visual fidelity and know precisely where that balance is perfect.
What isn’t addressed by this setting is how many significant digits we have to the left of the decimal point. That’s where adjusting dimensions and viewBox come into play. Next, we’ll examine paths—what defines the drawing—and how dimension, viewBox, and decimal precision affect the number of characters they contain.
What does a path look like?
Our example is based on the kiwi bird from Chris Coyier’s Using SVG and has two paths: one is an ellipse, the other is a kiwi. Its dimensions are 100px width by 82px height, viewBox is 0 0 100 82, and decimal precision is seven—the highest Illustrator allows.
Basic shapes have their own tags: circle, ellipse, line, polygon, polyline, and rect. Since these shapes are well-defined, the amount of code needed to describe them is minimal—all you need are some attribute/value pairs. Here’s what the code of our example’s ellipse looks like:
<ellipse fill="#C6C6C6" cx="46.3267326" cy="68.9376144" rx="42.3298607" ry="13.0623865"/>To describe anything other than basic shapes, the path tag is required. Here’s the kiwi’s path—the first bit, and the last value:
<path id="bird" d="M34.363224,0.0008523C17.0553761,0.1314738-2.0175736,13.9286251,0.1724619,34.4692345c0.7027745,6.5964966,3.0235648,10.4009247,8.5313501,12.8991089c5.9327183,2.6941185,9.315836,8.915081,8.2371655,18.4506187 … 72.8360062,22.4844837z"/>The entire value is about twenty times longer. With so many characters, non-standard shapes offer the greatest opportunity for optimization. Note all numbers have a decimal precision of seven. An optimization tool can’t add detail so if you save at a lower precision, you’re limiting your options. Always save at the highest decimal precision allowed by your editor.
How dimension and decimal precision affect paths
The first value in the kiwi’s path is: M34.363224,0.0008523
This defines where the path starts. M, means move to a spot. The comma-delimited numbers are the x and y coordinates of that spot respectively. They’re derived from the top-left corner’s coordinates (viewBox), the scale of your dimensions, and the decimal precision you’ve chosen.
From our example file, I made four more files by multiplying and dividing width and height by ten. Here’s what the first and last values of the kiwi’s path look like in each:
| Dimension | First value | Last value |
| 1×1 | M0.3436333,0.0000095 | 0.7283611,0.2248458z |
| 10×8.2 | M3.4363234,0.0000861 | 7.2836018,2.2484493z |
| 100×82 | M34.363224,0.0008523 | 72.8360062,22.4844837z |
| 1,000×820 | M343.6322327,0.0085142 | 728.3600464,224.8448334z |
| 10,000×8,200 | M3436.3222656,0.0851329 | 7283.6005859,2248.4482422z |
The lower limit of the length of a coordinate, with a decimal precision of seven, is nine characters—a decimal point, a leading zero, and seven decimals—or, at most, two more than your decimal precision. It can be less if you had something like 0.1479000—that would be reduced to 0.1479—but the nature of non-standard shapes makes values like these very unlikely.
The upper limit of the length of a coordinate is restricted only by the size of your editor’s artboard. Notice that each time dimension was multiplied by ten, another significant digit was added to the left of the decimal for each coordinate. And remember, more characters equals larger file size.
How does dimension affect file size?
See how each of our five files fared being optimized with SVGO-GUI—a port of SVGO but with a drag-and-drop GUI interface. While drag-and-drop is convenient, this convenience comes at a price. SVGO-GUI only optimizes with a decimal precision of three. This is perfect, however, to demonstrate the impact of dimension exclusively. Here are the results:
The take-away from this table is that profit (percentage of file decrease) increases as dimension decreases—the smaller your dimensions are, the smaller an optimizer will be able to make your file. Also note file size decreases before optimization as well.
I’m using SVGO-GUI to illustrate a point. It’s great for bulk optimization, super convenient, and great if you don’t have a lot of time. If you want to get the smallest file though, you’re going to need a decimal precision below three—which means we’ll have to use another tool.
Finding the best combination of dimension and decimal precision
Looking at the feedback from SVGO-GUI, there’s an incredible 50% drop in the “after” file size going from kiwi-10 to kiwi-1. And while that looks good on paper, it doesn’t look good on screen. In the next figure, kiwi-10 is on the left and looks like the original. In the middle, is kiwi-1, and you can see an overall loss of detail. On the right is kiwi-10 with its decimal precision reduced from three to one—and also not usable.
As dimension is reduced, so is the detail paths contain. Imagine a coordinate of 5.5555555. Every time dimension is reduced by a factor of 10, you lose the last digit—0.5555555, 0.0555555, 0.0055555, etc. At some point, so much detail is lost that an SVG breaks visually. Similarly, an SVG can also break as decimal precision is reduced—although in a different way. Our challenge is to find the perfect combination of dimension and decimal precision that maintains visual fidelity while yielding the smallest number of characters.
To that end, we’ll start by making a group of files, based on the kiwi, with dimensions based on powers of 2—1, 2, 4, 8, etc. The easiest way I’ve found to do this in Illustrator is to select all artwork, copy it to the clipboard, make a new document, set the dimensions, and paste. With the transform palette open and all paths selected, set x and y coordinates to 0 and set the larger of width or height to the corresponding dimension of the artboard. Be sure to select the transform pallet’s link icon to maintain aspect ratio. Keep going until you’ve reached 1024px or 2048px.
Now, it’s time to use Jake Archibald’s online optimizer, SVGOMG! It’s a fantastic, comprehensive optimizer that can be used both on and offline. Although SVGOMG! has built-in zoom capability, at smaller sizes, you’re going to have to edit the width attribute to something reasonable so you can see images clearly (500px should do it). Open the first image (1×1). Make sure “Compare gzipped,” “Prettifycode,” and “Multipass” are off. Toggle “Show original” to compare the un-optimized image with the optimized one. We’re going to start zeroing in on the best file by adjusting decimal precision. Find the lowest decimal precision you’re comfortable with before visual breakage happens, and make note of it. Here are my results after doing this for each image:
| Dimension (square in px) | Lowest Decimal Precision w/o breaking | Optimized file size (K) |
| 1 | 4 | 1.4 |
| 2 | 3 | 1.25 |
| 4 | 3 | 1.28 |
| 8 | 3 | 1.29 |
| 16 | 3 | 1.31 |
| 32 | 3 | 1.39 |
| 64 | 2 | 1.22 |
| 128 | 2 | 1.34 |
| 256 | 1 | 1.11 |
| 512 | 1 | 1.18 |
| 1024 | 1 | 1.28 |
Some of the patterns present in this chart we’ve already discussed—at smaller sizes, more decimal precision is needed to avoid visually breaking; at larger sizes, less decimal precision is acceptable; the larger the dimensions, the larger the file size.
One new pattern has emerged—a decimal precision of one will produce the smallest file. File size gets considerably smaller at each “leap” to the next smaller decimal precision. The smallest file at decimal precision 4 is 1.4k; the smallest at 3 is 1.25k; the smallest at 2 is 1.22k; and the smallest at 1 is 1.11k. What still isn’t known is the smallest dimension at which a decimal precision of one will not break.
Note the range of our targeted variations is almost .3k, or over 20% of the highest value. The range would be larger if we hadn’t selected specific values. This gives you some idea of how much arbitrary decisions can affect file size.
To find exactly what dimension/decimal precision combination yields the smallest file size, focus on the leaps in decimal precision. We can eliminate the two leaps—from 4 to 3, and from 3 to 2—since there’s a smaller file size (in the leap from 2 to 1) and any points within those leaps would be larger. This leaves only the first leap from 2 to 1 to examine.
Make a file with a width of the mid-point of the first leap—192. At a decimal precision of 1, it’s 1.06k and looks acceptable. Remember, these differences are almost imperceptible and only apparent when toggling views between original and optimized in SVGOMG!. The next mid-point—between 128 and 192—is 160. This one doesn’t look good and went up a bit to 1.07k—file size can plateau, going against the established pattern. To check, I looked at 200, which was at 1.08k—as expected, upwards again. And 190 and 194 were both 1.07k. So the best size is achieved at 192px width and a decimal precision of 1. How amazing is it that we actually know that?
More micro-optimizing
Here’s the optimized code from SVGOMG! of our winner, 192×192:
<svg xmlns="http://www.w3.org/2000/svg" width="192" height="192" viewBox="0 0 192 192"><ellipse cx="88.9" cy="132.4" fill="#C6C6C6" rx="81.3" ry="25.1"/><path d="M66 0C32.7.3-4 26.7.3 66.2 1.7 78.8 6 86.2 16.7 91c11.4 5 18 17 15.8 35.4-3 1.5-5.4 3.4-6 6.2 2.4 0 4.7 0 7 1.4 6.5 4 10 8.6 13.6 16.2.7 1 2.7 1 2.7-1 0-2.6-.6-5.5-1.6-8.4-1-2.6 1-2.5 2.3-2 2 1 5 3 9.5 4.2 1.7.4 2-1.2 1.6-2.2-.6-2.4-3.4-3.4-7.7-6-1.5-1-.2-3 1.7-2.7l6.3 1c1 0 1.5-2 .3-2.6-4.5-2-9-3-17-2.4-3.6-9.2-9.3-19.3-4.8-25.6 4-5.6 9.7-6.5 12.2 13.6-1.5 1-3.5 1.6-3.5 4 2-.8 3.4-.4 4.5 0 5.6 2.3 11.2 7 16.7 11.8 1 1 2.6-.6 2-2-.5-2-2.4-3.3-4.5-6.2-1-1.4 1.6-2.2 3.4-2 4.5 0 7.3 2.5 11.2 3.4 1.4.3 3-.7 2-2.2-1-2-4-2.8-6-4.2-1.3-1-.8-2.2 1-2 1.2 0 2.6.7 4.3.5 3-.2 2.4-2.2-.3-3-6-1.6-12.5-2-19.3-1.5-14-2.7-10-26.7 0-28.4C73 82.6 83.5 80 95 74c10.3-1.7 20.4-4 29.2-10.6 15-4.5 35 5 64 47 1.3 1.7 5 3 3-2-5-13-21.4-29.3-29-41.5C155 54.4 158 47.6 150 38.2c-6.7-7.8-15-8-24.3-5.4-7.3 2-12.3-2.3-16.6-10C100 7 83.5 0 66 0zm73.8 43.2c2 0 3.5 1.5 3.5 3.4 0 2-1.5 3.5-3.5 3.5s-3.4-1.5-3.4-3.4c0-2 1.5-3.4 3.4-3.4z"/></svg>SVGOMG! does a fantastic job at optimizing the path and removing the junk your editor injects. It also tells you the file size of the original—in this case 3.92k vs. 1.06k for a savings of 72.96%! In what’s left there are more optimization opportunities to take advantage of.
You can safely remove the xmlns attribute if you’re supporting only HTML5-compliant browsers. Within the context of an HTML document, xmlns is implied for SVG elements. For backwards compatibility of XHTML or for treating your markup like valid XML, leave this in. If removed, savings is 35 bytes.
If your image can be visually edited, rounding all attribute values of the ellipse to the nearest whole number will remove a few more bytes but reposition it slightly. Changing the color to something similar but repeating like #ccc that’s similar will cut that value in half. You could also target the SVG’s container element with CSS and remove this attribute entirely. Savings from these micro-optimizations is 23 bytes for a total savings of 58 bytes and a final file size of 1.025k—a savings of 73.85%.
Removing width and height attributes would optimize our file even further. Especially if in a responsive context, why set width and height explicitly in pixels? Responsive SVGs are accomplished with CSS which will override width and height attributes anyway. The benefits to leaving them, however, outweigh any optimization benefits removing them may have. They may remain, however, if fluidity is still desired.
Why width and height attributes should remain
If following the principle of progressive enhancement, you’ll want to test your pages with CSS missing. CSS is what made SVGs responsive and will no longer apply. What happens when an SVG without width and height attributes is rendered sans CSS? It fills up the width of the entire viewport. This may not be what you intended and can make for a difficult to read and broken looking page.
The next figure shows CSS-Tricks without said tricks. The masthead looks fine across the entire width so width and height attributes have been retained, but the search icon doesn’t. It separates the search label from the search box, is too visually prominent, and causes excessive vertical scrolling.
Here’s what happens when a width attribute with a value of 16 is added to the search icon:
This fits more closely with how the icon looked with CSS applied, makes the page more readable, and reestablishes appropriate visual hierarchy.
Be mindful of how it’s filled
In another view, this is what the top of the page looks like with CSS in effect at a mid-level media query.
Notice both “CSS-TRICKS” and “treehouse” SVGs are white on a black background, but, in the previous figure, “CSS-TRICKS” switches to black while “treehouse” remains white—and therefore invisible against the white background. Adding color can be done either through CSS or the fill attribute. In the case of the Treehouse logo (most likely supplied by Treehouse), the fill attribute was used to add fill color. When CSS is missing, the fill attribute still applies, so the Treehouse logo remained white.
It’s probably safer and more intuitive to have presentation reside in CSS rather than controlled by an attribute. If style needs to be packaged together with an SVG, use a style attribute so it’s treated the same as other CSS.
These same display issues also extend to print. Test how print style sheets handle SVGs and, if they are displayed at all, make sure they’re visible and in the right proportion. If printed, the search icon would be large and out of proportion the same as it was in our web page example—wasting paper and hurting readability.
Conclusion
Now you can choose any SVG, take it through this process, and know that you’ve come up with a version that has the smallest file size possible—given where you started. There may be a better method, I may have missed something, and the landscape will most assuredly change, but I offer this as a possible solution, and, at a minimum, hope it sparks some discussion and nudges you to create your own method.
Even if you don’t follow this method to the letter, consideration of the principles can help guide your process and workflow. Visual inspection is subjective and deciding the right balance between visual fidelity and file size savings—and how much effort you put into it—is up to you. There are many advantages to making websites performant and slimming down SVGs can contribute substantially towards that effort—most critically with inline SVG.
An automated tool would be helpful and it would most likely be best if something like SVGOMG!—that’s already in heavy use and actively under competent development—added this sort of functionality to their bag of tricks. In the meantime, I hope you determine to get the most bang for the buck out of your SVGs.
Adobe Illustrator has Object > Path > Simplify command. More often than not it helps to shave some points off.
Ooh, good point. Just as with any optimization, as long as it passes your own, objective visual muster, great. I would add to that Object > Compound Path > Make and Object > Ungroup. The point is an optimizer can only work with what you give it and the less tag elements and attributes you have, the better—except for those that are necessary.
Speaking about SVG optimization, Jake Archibald has made a pretty cool web UI for SVGO :
https://jakearchibald.github.io/svgomg/
Great writeup, Raymond. Thank you for taking the time to dive into the details like that!
One note though: I really disagree with keeping the width and height attributes of the SVG. I understand your point and yeah sure the unstyled version of the page looks more readable at first with a smaller icon.
BUT I’m having a really hard time understanding why anyone would compromise the fluidity of the SVG just because there is a kind of small possibility that the page would be rendered without styles.
Also, since we’re talking about optimisation, I think that—if the page is properly optimised—the flash of the unstyled content would not even be a problem, especially since we now have ways to deliver critical CSS (and more) that make sure we do not get these unstyled pages to begin with.
This is a great writeup and I love the thoroughness of it, but I strongly recommend against keeping the width and height attributes.
Cheers!
I’m so glad you read my post! I’ve read many of yours, some just in preparation for writing this one. And I’m flattered that you (of all people) are calling me out for diving into the details. I’m further pleased that you are only disagreeing with one small point. What I’m not seeing, and would love for you to explain, is how compromising the fluidity in the case of CSS being unavailable is somehow a bad idea. With CSS on, there is no compromise at all—SVGs are fluid. In my example, the header of CSS tricks does not have width and height so it can span the top of the page fluidly. Where I left the attributes in, was for icons that don’t necessarily need to be fluid as they’re usually just a visual cue.
I’m not concerned about FOUC, I’m concerned about CSS not loading or being intentionally left out or overridden. And in that case, the fluidity of some SVGs has questionable value and removing it seems easy to execute and doesn’t seem to have any downside, only an upside. Please convince me otherwise if I have this wrong. In re-reading it, I see that the title of the subsection “Why width and height attributes should remain” sounds absolute. But in the content of the section I mention that the masthead looks fine and I don’t have a width and height on it. I’ll edit this section to make it clear that I’m not advocating unilaterally adding width and height to every SVG—only to do it where it makes sense. Is that the point you’re making?
Hey Raymond, thanks for the reply.
Yes indeed that was the point I was making.
I was also missing the point where you override the
widthandheightattributes in CSS. (I read the article after arriving home from my travel so I was a bit tired and have therefore missed that point; I’m sorry about that.)So, yes indeed, keeping the attributes is fine as long as you make sure (and maybe emphasise that in the article?) to override these attributes in CSS, especially the
heightattribute.In most cases, I don’t specify the dimensions of the SVG in CSS, which is another reason why I missed you doing that. I usually just remove those attributes to get the fluidity, and provide the
width: 100%“hack” for IE wherever needed, OR the padding hack if I’m using an iframe.I’m all in for leaving presentation attributes in for progressive enhancement and mentioned this particular point in my last talk (but in other scenarios), but again, I missed that in your article.
Anyway, very good writeup and thanks for clarifying your point. =)
Hello, Sara! Maintainer of svgo is here. I can’t really agree on removing width and height from SVG.
The reason is because one can place svg as a background of an element. Without defined image sizes it will stretch over the element. It’s ok if it’s a separate element for an icon. But as long as someone places icon in the corner or another part of an arbitrary element it’s bad. That’s why svgo doesn’t remove those.
With width and height set in SVG you can safely place an іmage anywhere. When it’s needed to change image sizes there is
background-sizeproperty. The image size doesn’t have to correspond to an element size.Why would you set “Compare gzipped” to off in SVGOMG ? On a properly configured server, SVG’s will be gzipped so turning that on would be a fairer comparison, IMO.
Generally, less bytes means lesser gzipped file. It’s not always true, but for optimized SVGs gzipped files are roughly half a size of uncompressed images.
@Lev: true, but if SVGOMG has an option to compare gzipped sizes, why would you not use that to be sure you’re getting the smallest size possible?
@Lev, thanks for your insight and maintaining such a useful tool!
@Sander, I’m not saying never use “Compare gzipped” but for comparison to an Illustrator-generated SVG, leaving it off means you’re comparing apples to apples—the Illustrator file isn’t gzipped. Leaving “Compare gzipped” on gives you a potential best file size but also obscures the impact of our optimizations.
Not all servers are set up for gzip, and not all clients are capable of receiving it. If you’re curious about the final, gzipped size then have a look, and, I agree, I feel really good the smaller that number is. But I would say the metric that’s more universal and informs you about the optimizations you’ve made is the size with “Compare gzipped” off. That’s my primary concern—what’s the impact of the optimizations I’ve done. And with SVGOMG!, “Compare gzipped” is just a toggle flip away ;)
And Lev is right, depending on the file, gzip will perform better or worse but will generally be smaller. With a CSS file, for example, if you’ve added patterns like alphabetizing your selectors, gzip will make a smaller file. I’m not sure that kind of tweaking of an SVG is possible. So if you can’t process the file for better gzipping explicitly, assume the smaller the file, the smaller it will be gzipped according to Lev’s rule-of-thumb of about half (your mileage may vary).
Ah, thanks for the clarification, I misunderstood. I thought it was comparing the file sizes for the various image widths, but it’s comparing the size of the optimized image with the original. I agree, it makes more sense to turn “Compare gzipped” off in that case.
Very informative article!
But as far as being useful for production purposes, shouldn’t this be very low on our priority list? What is the real value in saving 1kb from an svg? You can save far more bandwidth by minifying all of your html.
Although your example is 1kb, you could be saving much more depending on how bloated your SVGs already are (which, by the way, how would you know?), how many you have, and how large they are (not all SVGs are small icons).
What’s important here is understanding how SVGs constructed and optimized so you’re better prepared to make your sites more performant. The process I’ve followed is intentionally detailed because it’s for explanatory purposes. Once you’ve gone through it a few times (like I have) you’ll get a feel for what’s best and don’t necessarily need to go through all the steps—and some of it should become inherit in your process.
I agree, however, that if you have 500 SVGs on an existing site that you want to convert with this process, you won’t be doing that. But it is a production-ready process. What if I put the CSS-Tricks logo through it? (I have Chris and you’re welcome to it). I saved a little over 300 bytes on a 3kb file (or 10%+). You might say that’s not a big deal, but if you’re shooting for the critical path goal of 14k, every byte counts. If your site only has a few SVGs that are on every page like a logo or a few icons, why not put in a little effort to save everywhere?
I’m interested in automating this process tying in to a tool like SVGO (did you hear that Lev?) in which case, if it was automatic, you would probably do it then. Keep in mind it may be difficult to automate completely as you’ll want to visually verify that SVGs didn’t break.
Yeah it’s definitely useful from a knowledge perspective. The more we know about the tools and techniques we’re using, the better equipped we are to use them.
Taking this page for example, you’re only saving 300 bytes on the logo. Maybe a few more bytes here and there if there are other svgs.
If you strip out all of the comments in the html you’d save 1294 bytes. Strip out the whitespace and you save an additional 5757 bytes.
I just don’t think file size of svgs should be anywhere near the top of our list of things to do to reduce the weight of our web pages.
Again, good article, very informative. Just not necessarily a technique that is going to make much of a difference.
You’re equating “making a difference” with some arbitrary lower limit on how many bytes a particular optimization technique can remove. Depending on the situation, you’ll get more savings from one technique one time and from another technique another time. So I’m not sure why you wouldn’t want to use all optimization methods available given any one could yield the most savings.
You site an example where the amount saved by manually improving SVG optimization is 300 bytes. The example from this post saved almost 3k from one SVG. And there are certainly examples where the savings from SVGs would be more than from removing comments or white space.
I gave the example of the 300 bytes savings from the logo to emphasize that even though the savings were small, it could not only make a difference, but a significant difference. The logo is at the top of the page and most likely something you want seen in the initial 14k chunk you would want loading for your critical path. The fact that you can actually optimize it, could mean the difference between making it under the 14K limit or having to make some other compromise to achieve it.
I’m sorry, but 300 bytes is rarely ever significant. Especially considering that stripping out comments and whitespace in html, something that is rarely ever done or even talked about, could save over 20 times as much space.
In the real world you don’t have unlimited time to make every optimization possible. It’s just not realistic. So you have to prioritize. And I would say that the technique you’re suggesting should be very low on that list.
You’re saving such a small amount on something that you’re already saving a bunch on. Simply using an svg instead of a png is already enough. And you’re losing quality. Those numbers are not random, they have a purpose, you’re reducing quality. So you need to check each svg to make sure they still look good. That’s valuable time.
Fun to talk about, good information to know, but ultimately not something that is very important in terms of actual implementation in your normal workflow.
You could be saving 300 bytes, 3k, 30k, 300k, etc. That will vary depending on what you start with—and every byte counts.
Feel free not to use this method, that’s your prerogative.
Also feel free to have the last word as this is the last reply to your comments I will be giving. And please know that, by this point, I’ve responded to you not for you but for others who will be reading through these comments.
There’s no need to take it personal.
But every byte doesn’t count. That’s not realistic at all.
And if you really do want to save every byte there are dozens of other things you can do that will take less time, have less risk of breaking things, and save more file size. If you’ve already done those, and want to go crazy, then go ahead and do this too. There’s nothing wrong with that.
But in 99% of cases in the real world this technique isn’t useful. That’s all I was saying.
But this article is about optimizing SVGs, not HTML white space. If this article was about general optimization, you comment would hold more weight. However, it is not.
It also goes a bit into the inner workings of how optimizations work. 300 bytes, incidentally, is ~2% of 14k. That could make the difference, who knows. In addition, chances are the optimizations you make on an SVG that’s on every page may be considerably greater. There is always the temptation to over-optimize, if you’re making an SVG for, say, a blog post… but for things used on every page of your site, if you’re trying to get under 14k, 10% over all savings on all the most commonly loaded SVGs may indeed be what speeds your site’s initial load.
Learning HOW and WHY SVGs can be optimized is a useful skill. This knowledge helps when you’re creating the original artwork and when you’re saving it out. And this knowledge will also help in perhaps encouraging someone to go out there and build an optimizer.
Yes, it’s about optimizing svgs. But I’m asking whether that’s something that should be important to us. I think the answer is no. If you’re worried about optimizing your site, there are plenty of other things that you should be doing before this.
I already said multiple times that this is useful knowledge. It’s just not something that should be a priority for the vast majority of people in the vast majority of real-world situations. I’m not trying to dismiss anything he wrote at all. I’m just trying to provide a little context.
Great information. Important to know. But do you need to actually do this? No.
Great read! Thanks for the share. I didn’t really take the time to improve me SVG optimization before, but now that I have time. Very helpful.
Glad you enjoyed it. Hopefully some of these steps will become inherit in your process without actually taking time. And for the rest of it, the more you practice it, the less time it will take.
Change “effect” to “affect” in these two titles:
— “How dimension and decimal precision effect paths”
— “How does dimension effect file size?”
I appreciate the correction and will make these edits. I’d love to hear any comments you have of an ungrammatical nature too.
Took me halfway through the article to realise that when you talk about “reducing the dimensions of an SVG” you really meant: “reducing the length of dimension values”
To me, the dimensions of any image are the size of the canvas…
Is there a way to stop people from downloading and editing the SVG file? As I believe this file is editable like an .AI or .PSD file? Is this true?
Yep. File > Export > PNG.
SVG is actually MORE editable than an AI or PSD. Those formats require a special piece of software. With an SVG, you can edit it in a text editor.
SVG is just a subset of XML. As such, it’s essentially code. Text instructions send over a wire that is translated by the client and rendered.
A better question is… do you have a really valid reason to prevent downloading and editing the source file?