That's all? No tricks with the upload or anything else? So just the more intensive editing of the file.
I still have one question:
What saves the most kilobytes? Color layers, nodes or the combination of several things?
Combination of several things, I'm copy/pasting a post I made a couple of years ago on the subject:
_______
SVG's can be opened as text files in notepad, or similar;
In the above example something like -0.247214,-1.48906 represents one node and is 18 characters, so that's 18 bytes. Nodes on curves may also contain an extra character.
If you have 1000 nodes, each at 18 bytes, lets say you end up with an 18kb file (broadly speaking). You could then delete ~160 nodes to get it to the right size, or if you reduced the accuracy of each node, by 1 decimal place, you'd be down to 16kb, then you'd only have to delete ~50-60 nodes. In practice the accuracy of the above example is way more than is needed.
The point is file size equates mostly to
Number of nodes × number of numbers in the node. You have to allow for other stuff (fill data etc.) so it's not exactly that straight forward, but it's close enough.
________
... so, that's what SVGOMG does a lot of... it rounds the numbers that make the co-ordinates.
"Layers" are pretty much groups, to define a group, you'd actually be using <g> and </g>, so 7 bytes - in practice most editors will add a an id to that, so it'll probably be more like 12 bytes. If you made a ludicrously complicated image with 100 groups, you'd be using 1.2kb just to have groups/layers, that's nearly 10% of the file.
If you have lots of different parts to decal (paths), and you give each one a colour (doesn't have to be a different colour, just a colour> it's going to use something like
fill="#000000", that's 14 bytes - so, if you have 100 elements, that's another 1.4 k. That example uses the hex code for Black
fill="black" would also work, and is only 11 bytes. So, in practice, it doesn't matter how many different colours there are, it's how many objects have a colour. Lets say you had the word "RACING", you could end up with 6 different objects/paths (one for each letter)... that would use 6 different fill tags (i.e.
fill="black"), so that's 66 bytes just for the colour data (and then all the node data on top of that). If you combine all the paths into one in the editor, it'll only use the fill data once - so that saves 55 bytes.
.. now, this is by no means all there is to it, but this kind of thing is how you make really efficient SVG's... but, there's no bigger kb-saver, than using as few nodes as possible. SVGOMG won't remove nodes... it just reduces the decimal accuracy.
edited to add:
Even just fonts... the top example is a font used on number plates... the font data itself contains nodes... some fonts use a lot more than others. In the lower example, I've removed a bunch of nodes myself/using features in my software.. this has gone from 108 nodes, to 60... so that 45% smaller file size (roughly)
