SVGO – Node.js-based SVG optimizer with plugins

[d-_-b]

https://github.com/svg/svgo

[molf]

This is pretty cool. Compression ratios will probably vary a lot, but in a completely unscientific test just now a few SVG files saved with Illustrator were shrunk by 20-30%. The ratio was similar after gzip compression.

Speaking of gzip compression, the most obvious and effective way to reduce the size of SVG files on your website is to serve them with gzip compression. Be sure to configure your web server to do this before thinking of applying this tool.

I also see some opportunity for lossy compression. The precision of coordinates can often be reduced: 2 decimals is usually enough. Perhaps some paths can be simplified too?

[d-_-b → molf]

you can change the precision via config (3 digits by default) right now or via special command line param that will appear in the next minor version.

about lossy optimizations – there is an idea of curves simplifying with Visvalingam’s algorithm - https://github.com/svg/svgo/issues/9

[sambeau]

Don't run this over production files without backup & testing!

I have just run this over my SVG tests and I'm afraid it has broken 7 out of 25 of them.

It appears to be mangling paths and changing the order of layers.

d-_-b I can send you my tests if it will help you.

[sambeau → sambeau]

Looking at the files I can see a lot of weird looking numbers in paths and a lot of 'NaN'.

This kind of thing:

  <path d="M185 NaNl-190 NaN 212 NaN-212 NaN 7.239 NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaNz" fill-opacity="0" stroke="#000"/>

and

  <path d="M425 499h-28c-1.105 0-2-.896-2-2v-28c0-1.105 .895-2 2-2h28c1.105 0 2 .895 2 2v28c0 1.104-.895 2-2 2z" fill-opacity="0" stroke="#FF0064"/>

Hope this helps.

[sambeau → sambeau]

Here's the problem I think "-3.05176e-005":

  <path d="M 185,-3.05176e-005L 207,-3.05176e-005C 209.761,-3.05176e-005 212,2.23853 212,4.99997L 212,27C 212,29.7614 209.761,32 207,32L 185,32C 182.239,32 180,29.7614 180,27L 180,4.99997C 180,2.23853 182.239,-3.05176e-005 185,-3.05176e-005 Z " fill-rule="nonzero" fill-opacity="0" stroke="#000000" stroke-opacity="1" stroke-width="1" />

Now this could well be an error in my SVG exporter (these files are converted from XAML files). However these files do render OK and they have been fed through the SVG validator and passed.

According to the spec (See DataTypeNumber) it's perfectly OK to have an 'e' in a number.

I've added an issue: https://github.com/svg/svgo/issues/63

[d-_-b → sambeau]

thank you, I'll fix it asap.

[sambeau → d-_-b]

Thanks for the fix.

[sambeau]

This is giving us a ~40% reduction in our file sizes.