Last modified: 2014-09-17 21:57:28 UTC
This comes from bug 34810... Which could use this feature to dynamically do it (or the simpler older method of creating .min files) SVG are used as non page content files, they contain a lot of whitespace. Minify and serve!
There's several possible things to do here: * transparent HTTP gzip compression (can be enabled at webserver-level) * stripping comments and whitespace (traditional 'minification', could be done as a pre-processing step) * intelligent collapsing of redundant attributes and styles (harder!) * rounding coordinates to fewer digits * decimating points in overly-detailed polygons/curves Depending on just what you're trying to do, you could do some or all of those... For SVG fonts I'd recommend that they be relatively sane to begin with (if they're full of whitespace and comments as output assets, that's kinda lame -- they should be small/clean to begin with), and use transparent gzip compression on the web server configuration.
I think we can apply the same as PNG files. I don't know of any SVG files we have in our repository that we manually edit to the level that can't aren't already be minified (they might have some indentation, but that's about it, and we could actually minify those in the repository, like we optimise PNG files). I know SVG is text where PNG is not, but unless we actually edit them, it should be fine. As for solving this bug, if we want to minify SVGs in separate requests (e.g. fonts), that would get quite tricky. They'd need a url to be served from. As for SVGs we embed in CSS (SVGs for icons like we do in VisualEditor), those could be easily minified before being base64 encoded (that is, once we have an xml minifier).
*** Bug 63491 has been marked as a duplicate of this bug. ***
