
Of SVG, Minification and Gzip - mmastrac
https://medium.com/@subzey/of-svg-minification-and-gzip-21cd26a5d007
======
speps
I thought it was mostly interesting because of the gzthermal tool really:
[https://encode.ru/threads/1889-gzthermal-pseudo-thermal-
view...](https://encode.ru/threads/1889-gzthermal-pseudo-thermal-view-of-Gzip-
Deflate-compression-efficiency)

~~~
simonw
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
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
Yeah I figured that gzthermal binary was a good match for a Docker container
:)

------
ptero
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_
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
>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?

------
RazrFalcon
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)

------
chrismorgan
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
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.

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

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

------
tomgp
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

~~~
Already__Taken
> 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
The problem with a transform like that is that it would also scale line
strokes.

------
zzzcpan
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
It’s covered in the “Trial and Error” section.

~~~
zzzcpan
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.

------
franciscop
I wrote about my learnings on GZIP for a JS library on here:
[https://medium.com/@fpresencia/understanding-gzip-
size-836c7...](https://medium.com/@fpresencia/understanding-gzip-
size-836c74b66c0b)

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.

------
jancsika
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
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?

------
JeanMarcS
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_
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.

------
jrobn
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.

------
baybal2
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

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

~~~
proaralyst
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)

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

~~~
chrismorgan
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.

------
xchaotic
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_
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)

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

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

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

------
vortico
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
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.

