Of SVG, Minification and Gzip
medium.com
medium.com
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.
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
for an even "dirtyer" version in 147 bytes check
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.
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.
I just assumed this would be part of the build process?
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-s...), does shrinking it further make any difference?
Sometimes that’s the last parts left to do.
I’ve recently started working on improving the performance of 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.
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.
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.
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.
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
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?
I found compressed size to be rather unpredictable and unintuitive, especially if the size of your file is significantly larger, than 100 bytes.
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.
Btw-- what is the history of inline svg not needing an xml namespace in HTML5?
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?
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.
On small files, the difference will be of course significant, but in big files ?
I’m impressed with brotli is within 4 bytes with the original as with the highly optimized one.
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
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...
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/
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.