5 ms·

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 cli

by 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?
- kuschku 9y ago
  > 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. Sometimes that’s the last parts left to do. I’ve recently started working on improving the performance of https://quasseldroid.info/ https://quasseldroid.info/ (I’ve still got to optimize the images), and doing svg optimizations got some SVGs from 14kiB gzipped down to 400 bytes (which meant I could inline them into the CSS). This can be really worth it.
Theodores 9y ago
I think that SVG is best done with a 'stylesheet' of SVG definitions that then get 'used' with the use tag in inline SVG. So you make one rectangle and call it something sensible. For icons and other mono elements the 'currentColor' feature is great as that will pull your colour from whatever else is in the div that contains that particular inline SVG, e.g. a 'a' link can surround the inline SVG and get coloured accordingly. Taking the 'SVG stylesheet' approach means that the actual SVG can be generated, so it can take variables in the backend code, e.g. to localise the icons/images. This can then be ajax loaded into the DOM in such a way that all the SVG images are only loaded once in one reasonably optimised but editable file. Subsequent pageloads will be fine, no need for all of those http requests. I use SVGO a lot but I think there is a lot to be said for using 'rect' instead of a path. For some reason I decided to re-do the 18Mb Adobe file that was 'vector' that Instagram have as their definitive icon. I got this down to four lines of SVG, with the result being accurate rather than yet another kid-with-photoshop-redesign effort. Had I taken the 'let's gzip it morely' approach then I would still be waiting for my icon to download.

by ptero 9y ago

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?

kuschku 9y ago
> 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. Sometimes that’s the last parts left to do. I’ve recently started working on improving the performance of https://quasseldroid.info/ https://quasseldroid.info/ (I’ve still got to optimize the images), and doing svg optimizations got some SVGs from 14kiB gzipped down to 400 bytes (which meant I could inline them into the CSS). This can be really worth it.

Theodores 9y ago

I think that SVG is best done with a 'stylesheet' of SVG definitions that then get 'used' with the use tag in inline SVG. So you make one rectangle and call it something sensible. For icons and other mono elements the 'currentColor' feature is great as that will pull your colour from whatever else is in the div that contains that particular inline SVG, e.g. a 'a' link can surround the inline SVG and get coloured accordingly. Taking the 'SVG stylesheet' approach means that the actual SVG can be generated, so it can take variables in the backend code, e.g. to localise the icons/images. This can then be ajax loaded into the DOM in such a way that all the SVG images are only loaded once in one reasonably optimised but editable file. Subsequent pageloads will be fine, no need for all of those http requests. I use SVGO a lot but I think there is a lot to be said for using 'rect' instead of a path. For some reason I decided to re-do the 18Mb Adobe file that was 'vector' that Instagram have as their definitive icon. I got this down to four lines of SVG, with the result being accurate rather than yet another kid-with-photoshop-redesign effort. Had I taken the 'let's gzip it morely' approach then I would still be waiting for my icon to download.