7 ms·

Of SVG, Minification and Gzip

217 points by mmastrac 9y ago

speps 9y ago
I thought it was mostly interesting because of the gzthermal tool really: https://encode.ru/threads/1889-gzthermal-pseudo-thermal-view-of-Gzip-Deflate-compression-efficiency https://encode.ru/threads/1889-gzthermal-pseudo-thermal-view...
- douglasfshearer 9y ago
  To save others time, the output of GZThermal is a PNG image called gzthermal-output.png.
  - ilogik 9y ago
    had to run strace to figure that out :)
- sjmulder 9y ago
  That's an awesome tool. I wish it would output to the terminal, too. Thinking about that, as an exercise in Unix philosophy, how would you add hex output to such a tool? One could add a -x option or such that would output like xxd(1), but then you might want to go and implement more of xxd's options like maximum line width and such, leading to the duplication that composition of tools is supposed to prevent. But how would you make it composable? Either gzthermal would need to understand xxd's output, or xxd would need to know about terminal escape codes to properly map the coloured output.
- simonw 9y ago
  I just deployed a quick web application wrapper around that tool to make it easier to try out: https://gzthermal.now.sh/ https://gzthermal.now.sh/
  - NelsonMinar 9y ago
    Nice, thanks for stopping me from running an unknown Linux binary from a 3 year old Russian forum thread :-) Undocumented feature in your webapp; append &w=1 to get a wider image. I wish there was a "make the image square" option in gzthermal.
    - simonw 9y ago
      Yeah I figured that gzthermal binary was a good match for a Docker container :)
  - mxfh 9y ago
    Should add that to some live editing environment. once managed to push a valid SVG to under 500 bytes resembling the Google logo by watching it repacked as you type. This might have helped. https://codepen.io/mxfh/pen/yYyybB https://codepen.io/mxfh/pen/yYyybB for an even "dirtyer" version in 147 bytes check https://twitter.com/wojtekmaj91/status/640126119291785216 https://twitter.com/wojtekmaj91/status/640126119291785216
pjc50 9y ago
Nice tools, but using such a small example will give unrepresentative numbers since it's dominated by constant overhead.
- chrismorgan 9y ago
  The examples given are completely representative of the sorts of changes you can make to reduce size, and frankly fairly representative of the sorts of compression ratio improvements you’ll get (though for some types of things you can definitely do way better). When talking about optimisation for gzip, you are mostly talking about 1–2% over general uncompressed byte count minification. And in practice a lot of your minification is of small things, e.g. SVG icons in an app or site—they’re easier to minify because of their reduced scope.
chrismorgan 9y ago
I love manually minifying SVG, JavaScript and HTML to shave off a few bytes here, a few bytes there. I’d really like a tool like gzthermal, but editable and showing compressed size, so that you can make changes and easily see immediately. Bonus points if it comes with a clever diffing technique so that you can minify parts separately and combine them in the most efficient way. As it is, I just run something like `watchexec -f "*/the-filename" "gzip -c9 < x | wc -c"` in a terminal and it shows me the size whenever I save the file.
- supermdguy 9y ago
  How about gamifying it and creating a web app where anyone can submit an SVG and then users will compete to minimize it as much as possible.
baybal2 9y ago
On bigger files, the biggest size saver is use of css to replace attribute styles.
- deleted 9y ago
  [deleted]
zzzcpan 9y ago
Since the article touches Huffman encoding, wouldn't "#f00" and "#00f" compress better, than "red" and "#00f"? Minimizing uncompressed size is not what you want to pursue.
- chrismorgan 9y ago
  It’s covered in the “Trial and Error” section.
  - zzzcpan 9y ago
    Oh, thanks, didn't notice it. I found compressed size to be rather unpredictable and unintuitive, especially if the size of your file is significantly larger, than 100 bytes.
- gpvos 9y ago
  They try it at the end, and it apparently doesn't help for gzip, but it does for brotli in this case.
franciscop 9y ago
I wrote about my learnings on GZIP for a JS library on here: https://medium.com/@fpresencia/understanding-gzip-size-836c74b66c0b https://medium.com/@fpresencia/understanding-gzip-size-836c7... Mind you, it is not as well written nor with such cool tools/graphics. On the other hand my article more practical for real projects IMHO since I focus more on the code structure and general patterns. I love reading about those crafted tiny files and micro-optimizations though.
tomgp 9y ago
I'd add a couple of things. 1. as sizes grow you'll be better off using CSS to style rather than attributes -- this will often be a much bigger win than fiddling around with #00f vs blue. 2. I think replacing rect's etc. with paths can be problematic esp if you want to animate elements based on attributes i.e. much easier to interpolate from width=10 to width=20 than figure out what the intermediate path commands might look like. Also, if you want people to be able to edit the resulting SVG keeping with semantically meaningful higher level features such as rect and circle will help editors to understand what's going on and provide the power tools for modifying those shapes
- tomgp 9y ago
  oh, also, in my experience the best optimization tends to be reducing the number of decimal places in complex path commands to one or two.
- Already__Taken 9y ago
  > i.e. much easier to interpolate from width=10 to width=20 I know it's specific example but don't browser rules apply here? i.e this should be a scale transform not an element property modification to take advantage of the gpu?
  - a_e_k 9y ago
    The problem with a transform like that is that it would also scale line strokes.
vortico 9y ago
What use cases are there for minifying SVG? It never struck me as something that was large enough to be worth compressing its filesize in any way. It's the CPU/GPU that you usually want to worry about, since only a few characters can cause a lot of time to be spent drawing the frame.
- garethrees 9y ago
  The case for reducing the size of SVG is the same as for any kind of web asset: it reduces the initial transmission time (and improves the likelihood of a cache hit) and so reduces the time taken to load the page. I doubt if it's worthwhile squeezing the last couple of bytes of gzip compression out of an image (other than as a fun and informative exercise), but when programmatically generating SVGs it's easy to do so naïvely and in these cases you can get big savings in file size. Here's a worked example where I was able reduce a generated image to about 17% of its original size through simple fixes: http://garethrees.org/2013/08/02/svg/ http://garethrees.org/2013/08/02/svg/ Similarly, tools like Inkscape need to represent information for editing the image (such as its layer or grouping structure; or style information maintained on a per-object basis) which is not necessary for displaying it, and this can amount to a large proportion of the SVG file size.
xchaotic 9y ago
Would the compression work better if you inlined the SVG and served the whole HTML+SVG as one gzipped file? I also think that depending on the SVG complexity, you might shave a few bits, but at the expense of more complex processing - polygon-path vs two square in this example...
- Cthulhu_ 9y ago
  That is another thing to consider. Google's mod_pagespeed, iirc, analyzes image/css/js file size and whatnot and determines whether it's more effective to inline it or to load it separately (and does so automatically)
- bufferoverflow 9y ago
  Not if you expected multiple pageviews with that image. In which case it gets loaded once and gets cached.
JeanMarcS 9y ago
Probably dumb question, but I always ask myself if it's changing size significantly to gzip (or brotli) a minified file instead of the original, as space and CR will be the most present character and so will be very well compressed. On small files, the difference will be of course significant, but in big files ?
- Cthulhu_ 9y ago
  Big files the difference is also significant; minification removes and rewrites large chunks in the source code, which also compress to a smaller size. The dictionary for example contains a lot less data. See https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size for an example of a library, compressed / minified / zopflied (?), and a comparison in file size. The most recent version in there (3.0.0-alpha-1) is 75 kb "just gzipped", 29KB gzipped + minified. Just minified is 84KB, so gzipping the minified file only shaves off an additional 9 KB compared to just minifying.
ptero 9y ago
It is an interesting article, but IMO the author is barking up a wrong tree. Compromising clarity to reduce by a few percent the number of bytes sent to the client is unlikely to work well beyond small examples. For complex objects such local optimizations encourage moving closer to final image representation instead of leveraging higher level capabilities of SVG for vector graphics. If final file size is of utmost importance for a complex object taking a high level view and refactoring as needed will likely work much better than replacing rectangles with path, absolute motions with relative, etc. "Premature optimization is the root of all evil". Just my 2c, YMMV.
- Cthulhu_ 9y ago
  It's more digging into what tools like svgo and gzip actually do to a file, and how changes in implementation change the compression behaviour; in 99.9% of circumstances it's something you wouldn't want to do manually as a developer, have it done by an image optimizer instead. Not sure if readable SVG is an objective in the delivered end-result; I don't think so, just like readable html, js, css etc is not required. Maybe add a source map if you really need to, or put the original svg right next to a `.min.svg` file which the user sees. But it's a bit of a silly thing really, what really needs to happen is the ability to compile a webapp to an efficiently compressed and easily runnable binary file, instead of this silly minified text that still needs to be parsed client-side.
  - mholmes680 9y ago
    >Maybe add a source map if you really need to, or put the original svg right next to a `.min.svg` file which the user sees. I just assumed this would be part of the build process?
- nathan_long 9y ago
  > IMO the author is barking up a wrong tree That's what I thought, too. Using SVG at all instead of images is a huge win for bandwidth. Adding gzip is painless and makes the deliverable tiny. Any further optimization effort would likely be better spent on another part of the site. Don't get me wrong - it's a great article with very interesting techniques that would be great for very large SVGs. But if your SVG already fits into a single TCP packet (~1500 bytes, according to https://stackoverflow.com/questions/2613734/maximum-packet-size-for-a-tcp-connection https://stackoverflow.com/questions/2613734/maximum-packet-s...), does shrinking it further make any difference?
stesch 9y ago
By the way: Firefox 57 still can't view local *.svgz
- proaralyst 9y ago
  Wow, this bug is 17 years old! https://bugzilla.mozilla.org/show_bug.cgi?id=52282 https://bugzilla.mozilla.org/show_bug.cgi?id=52282
baybal2 9y ago
Another hint: When you use CSS to style an SVG, use attribute selector instead of class to save some space. Also, it some times makes sense to use arcs and quadratic curves instead of Bezier curves. Qaudratic curves save you one argument, and are easier to use with T path element. Arcs are let you save on geometrically correct ellipsis fragments: to render a correct ellipsis, you need 8 quadratic curves that each need 3 arguments. With arc, you only need 8 arguments
bufferoverflow 9y ago
And none of it likely matters, because it all fits into one frame of 1500 bytes.
- bastawhiz 9y ago
  True! If you're inlining your SVG on a page or in a stylesheet, though, it could make a fair difference.
jrobn 9y ago
I optmzd ths sntce to sve 8 byts. I’m impressed with brotli is within 4 bytes with the original as with the highly optimized one.
RazrFalcon 9y ago
SVG is not a colored paths container. There are far more things that it can do and far more ways to optimize it. Instead of SVGO you can use svgcleaner[1] with zopfli, which is a bit better. Yes, nothing compares to manual optimizations, but if you created an SVG using a vector editor - there is no point in manually removing all the garbage it adds in. 1: https://github.com/RazrFalcon/svgcleaner https://github.com/RazrFalcon/svgcleaner
jancsika 9y ago
That xml namespace is a significant portion of the total. At least for inline svg you don't need it. Btw-- what is the history of inline svg not needing an xml namespace in HTML5?
- ygra 9y ago
  Likely the requirement to be handled by a non-XML parser and to ease adoption. In practice the namespace will always be copied from somewhere because no one ever types it from memory. Still, IMHO inline SVG is a horrible mess as it is parsed as sort-of XML, has its own weird rules, doesn't show up as written in the DOM Explorer, and breaks on completely strange "errors" like not naming the XLink namespace prefix "xlink". Can I still wish for XHTML?
- jrochkind1 9y ago
  HTML5 is not xml-based, and does not require or use xml namespaces anywhere, I think?
- xg15 9y ago
  From what I read, it goes back to the HTML5 vs XHTML disputes. I think the story was something like this: One of the proposed advantages of XHTML was the plan that at some point you'd be able to embed other XML dialects into XHTML - such as SVG. HTML5 is famously not XML or SGML but a grammar of its own - and the ability to embed other languages was consciously dropped. However, the use-case of defining SVG images inline was considered important enough that it should be kept. How to do so if HTML5 is not even XML? Just make a special exception for SVG and declare xml-that's-a-valid-svg a part of the HTML grammar. Because it's a special case built into the language, there is no need for generic namespace declarations like in XML - so they can be dropped.
partycoder 9y ago
If it's due to size, remember that most HTTP servers support gzip compression.
labster 9y ago
Reduce site assets by 10kB, add 10MB of advertising and telemetry.

217 points by mmastrac 9y ago

I thought it was mostly interesting because of the gzthermal tool really: https://encode.ru/threads/1889-gzthermal-pseudo-thermal-view-of-Gzip-Deflate-compression-efficiency https://encode.ru/threads/1889-gzthermal-pseudo-thermal-view...

douglasfshearer 9y ago
To save others time, the output of GZThermal is a PNG image called gzthermal-output.png.
- ilogik 9y ago
  had to run strace to figure that out :)
sjmulder 9y ago
That's an awesome tool. I wish it would output to the terminal, too. Thinking about that, as an exercise in Unix philosophy, how would you add hex output to such a tool? One could add a -x option or such that would output like xxd(1), but then you might want to go and implement more of xxd's options like maximum line width and such, leading to the duplication that composition of tools is supposed to prevent. But how would you make it composable? Either gzthermal would need to understand xxd's output, or xxd would need to know about terminal escape codes to properly map the coloured output.
simonw 9y ago
I just deployed a quick web application wrapper around that tool to make it easier to try out: https://gzthermal.now.sh/ https://gzthermal.now.sh/
- NelsonMinar 9y ago
  Nice, thanks for stopping me from running an unknown Linux binary from a 3 year old Russian forum thread :-) Undocumented feature in your webapp; append &w=1 to get a wider image. I wish there was a "make the image square" option in gzthermal.
  - simonw 9y ago
    Yeah I figured that gzthermal binary was a good match for a Docker container :)
- mxfh 9y ago
  Should add that to some live editing environment. once managed to push a valid SVG to under 500 bytes resembling the Google logo by watching it repacked as you type. This might have helped. https://codepen.io/mxfh/pen/yYyybB https://codepen.io/mxfh/pen/yYyybB for an even "dirtyer" version in 147 bytes check https://twitter.com/wojtekmaj91/status/640126119291785216 https://twitter.com/wojtekmaj91/status/640126119291785216

pjc50 9y ago

Nice tools, but using such a small example will give unrepresentative numbers since it's dominated by constant overhead.

chrismorgan 9y ago
The examples given are completely representative of the sorts of changes you can make to reduce size, and frankly fairly representative of the sorts of compression ratio improvements you’ll get (though for some types of things you can definitely do way better). When talking about optimisation for gzip, you are mostly talking about 1–2% over general uncompressed byte count minification. And in practice a lot of your minification is of small things, e.g. SVG icons in an app or site—they’re easier to minify because of their reduced scope.

chrismorgan 9y ago

I love manually minifying SVG, JavaScript and HTML to shave off a few bytes here, a few bytes there. I’d really like a tool like gzthermal, but editable and showing compressed size, so that you can make changes and easily see immediately. Bonus points if it comes with a clever diffing technique so that you can minify parts separately and combine them in the most efficient way. As it is, I just run something like `watchexec -f "*/the-filename" "gzip -c9 < x | wc -c"` in a terminal and it shows me the size whenever I save the file.

supermdguy 9y ago
How about gamifying it and creating a web app where anyone can submit an SVG and then users will compete to minimize it as much as possible.

baybal2 9y ago

On bigger files, the biggest size saver is use of css to replace attribute styles.

deleted 9y ago
[deleted]

zzzcpan 9y ago

Since the article touches Huffman encoding, wouldn't "#f00" and "#00f" compress better, than "red" and "#00f"? Minimizing uncompressed size is not what you want to pursue.

chrismorgan 9y ago
It’s covered in the “Trial and Error” section.
- zzzcpan 9y ago
  Oh, thanks, didn't notice it. I found compressed size to be rather unpredictable and unintuitive, especially if the size of your file is significantly larger, than 100 bytes.
gpvos 9y ago
They try it at the end, and it apparently doesn't help for gzip, but it does for brotli in this case.

franciscop 9y ago

I wrote about my learnings on GZIP for a JS library on here: https://medium.com/@fpresencia/understanding-gzip-size-836c74b66c0b https://medium.com/@fpresencia/understanding-gzip-size-836c7... Mind you, it is not as well written nor with such cool tools/graphics. On the other hand my article more practical for real projects IMHO since I focus more on the code structure and general patterns. I love reading about those crafted tiny files and micro-optimizations though.

tomgp 9y ago

I'd add a couple of things. 1. as sizes grow you'll be better off using CSS to style rather than attributes -- this will often be a much bigger win than fiddling around with #00f vs blue. 2. I think replacing rect's etc. with paths can be problematic esp if you want to animate elements based on attributes i.e. much easier to interpolate from width=10 to width=20 than figure out what the intermediate path commands might look like. Also, if you want people to be able to edit the resulting SVG keeping with semantically meaningful higher level features such as rect and circle will help editors to understand what's going on and provide the power tools for modifying those shapes

tomgp 9y ago
oh, also, in my experience the best optimization tends to be reducing the number of decimal places in complex path commands to one or two.
Already__Taken 9y ago
> i.e. much easier to interpolate from width=10 to width=20 I know it's specific example but don't browser rules apply here? i.e this should be a scale transform not an element property modification to take advantage of the gpu?
- a_e_k 9y ago
  The problem with a transform like that is that it would also scale line strokes.

vortico 9y ago

What use cases are there for minifying SVG? It never struck me as something that was large enough to be worth compressing its filesize in any way. It's the CPU/GPU that you usually want to worry about, since only a few characters can cause a lot of time to be spent drawing the frame.

garethrees 9y ago
The case for reducing the size of SVG is the same as for any kind of web asset: it reduces the initial transmission time (and improves the likelihood of a cache hit) and so reduces the time taken to load the page. I doubt if it's worthwhile squeezing the last couple of bytes of gzip compression out of an image (other than as a fun and informative exercise), but when programmatically generating SVGs it's easy to do so naïvely and in these cases you can get big savings in file size. Here's a worked example where I was able reduce a generated image to about 17% of its original size through simple fixes: http://garethrees.org/2013/08/02/svg/ http://garethrees.org/2013/08/02/svg/ Similarly, tools like Inkscape need to represent information for editing the image (such as its layer or grouping structure; or style information maintained on a per-object basis) which is not necessary for displaying it, and this can amount to a large proportion of the SVG file size.

xchaotic 9y ago

Would the compression work better if you inlined the SVG and served the whole HTML+SVG as one gzipped file? I also think that depending on the SVG complexity, you might shave a few bits, but at the expense of more complex processing - polygon-path vs two square in this example...

Cthulhu_ 9y ago
That is another thing to consider. Google's mod_pagespeed, iirc, analyzes image/css/js file size and whatnot and determines whether it's more effective to inline it or to load it separately (and does so automatically)
bufferoverflow 9y ago
Not if you expected multiple pageviews with that image. In which case it gets loaded once and gets cached.

JeanMarcS 9y ago

Probably dumb question, but I always ask myself if it's changing size significantly to gzip (or brotli) a minified file instead of the original, as space and CR will be the most present character and so will be very well compressed. On small files, the difference will be of course significant, but in big files ?

Cthulhu_ 9y ago
Big files the difference is also significant; minification removes and rewrites large chunks in the source code, which also compress to a smaller size. The dictionary for example contains a lot less data. See https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size for an example of a library, compressed / minified / zopflied (?), and a comparison in file size. The most recent version in there (3.0.0-alpha-1) is 75 kb "just gzipped", 29KB gzipped + minified. Just minified is 84KB, so gzipping the minified file only shaves off an additional 9 KB compared to just minifying.

ptero 9y ago

It is an interesting article, but IMO the author is barking up a wrong tree. Compromising clarity to reduce by a few percent the number of bytes sent to the client is unlikely to work well beyond small examples. For complex objects such local optimizations encourage moving closer to final image representation instead of leveraging higher level capabilities of SVG for vector graphics. If final file size is of utmost importance for a complex object taking a high level view and refactoring as needed will likely work much better than replacing rectangles with path, absolute motions with relative, etc. "Premature optimization is the root of all evil". Just my 2c, YMMV.

Cthulhu_ 9y ago
It's more digging into what tools like svgo and gzip actually do to a file, and how changes in implementation change the compression behaviour; in 99.9% of circumstances it's something you wouldn't want to do manually as a developer, have it done by an image optimizer instead. Not sure if readable SVG is an objective in the delivered end-result; I don't think so, just like readable html, js, css etc is not required. Maybe add a source map if you really need to, or put the original svg right next to a `.min.svg` file which the user sees. But it's a bit of a silly thing really, what really needs to happen is the ability to compile a webapp to an efficiently compressed and easily runnable binary file, instead of this silly minified text that still needs to be parsed client-side.
- mholmes680 9y ago
  >Maybe add a source map if you really need to, or put the original svg right next to a `.min.svg` file which the user sees. I just assumed this would be part of the build process?
nathan_long 9y ago
> IMO the author is barking up a wrong tree That's what I thought, too. Using SVG at all instead of images is a huge win for bandwidth. Adding gzip is painless and makes the deliverable tiny. Any further optimization effort would likely be better spent on another part of the site. Don't get me wrong - it's a great article with very interesting techniques that would be great for very large SVGs. But if your SVG already fits into a single TCP packet (~1500 bytes, according to https://stackoverflow.com/questions/2613734/maximum-packet-size-for-a-tcp-connection https://stackoverflow.com/questions/2613734/maximum-packet-s...), does shrinking it further make any difference?

stesch 9y ago

By the way: Firefox 57 still can't view local *.svgz

proaralyst 9y ago
Wow, this bug is 17 years old! https://bugzilla.mozilla.org/show_bug.cgi?id=52282 https://bugzilla.mozilla.org/show_bug.cgi?id=52282

baybal2 9y ago

Another hint: When you use CSS to style an SVG, use attribute selector instead of class to save some space. Also, it some times makes sense to use arcs and quadratic curves instead of Bezier curves. Qaudratic curves save you one argument, and are easier to use with T path element. Arcs are let you save on geometrically correct ellipsis fragments: to render a correct ellipsis, you need 8 quadratic curves that each need 3 arguments. With arc, you only need 8 arguments

bufferoverflow 9y ago

And none of it likely matters, because it all fits into one frame of 1500 bytes.

bastawhiz 9y ago
True! If you're inlining your SVG on a page or in a stylesheet, though, it could make a fair difference.

jrobn 9y ago

I optmzd ths sntce to sve 8 byts. I’m impressed with brotli is within 4 bytes with the original as with the highly optimized one.

RazrFalcon 9y ago

SVG is not a colored paths container. There are far more things that it can do and far more ways to optimize it. Instead of SVGO you can use svgcleaner[1] with zopfli, which is a bit better. Yes, nothing compares to manual optimizations, but if you created an SVG using a vector editor - there is no point in manually removing all the garbage it adds in. 1: https://github.com/RazrFalcon/svgcleaner https://github.com/RazrFalcon/svgcleaner

jancsika 9y ago

That xml namespace is a significant portion of the total. At least for inline svg you don't need it. Btw-- what is the history of inline svg not needing an xml namespace in HTML5?

ygra 9y ago
Likely the requirement to be handled by a non-XML parser and to ease adoption. In practice the namespace will always be copied from somewhere because no one ever types it from memory. Still, IMHO inline SVG is a horrible mess as it is parsed as sort-of XML, has its own weird rules, doesn't show up as written in the DOM Explorer, and breaks on completely strange "errors" like not naming the XLink namespace prefix "xlink". Can I still wish for XHTML?
jrochkind1 9y ago
HTML5 is not xml-based, and does not require or use xml namespaces anywhere, I think?
xg15 9y ago
From what I read, it goes back to the HTML5 vs XHTML disputes. I think the story was something like this: One of the proposed advantages of XHTML was the plan that at some point you'd be able to embed other XML dialects into XHTML - such as SVG. HTML5 is famously not XML or SGML but a grammar of its own - and the ability to embed other languages was consciously dropped. However, the use-case of defining SVG images inline was considered important enough that it should be kept. How to do so if HTML5 is not even XML? Just make a special exception for SVG and declare xml-that's-a-valid-svg a part of the HTML grammar. Because it's a special case built into the language, there is no need for generic namespace declarations like in XML - so they can be dropped.

partycoder 9y ago

If it's due to size, remember that most HTTP servers support gzip compression.

labster 9y ago

Reduce site assets by 10kB, add 10MB of advertising and telemetry.