Ich habe ja aus irgendeinem Grund enorm viel Spaß daran, SVG-Dateien in ihrer Größe zu optimieren. Zum Beispiel Napstablook, das curl-Logo oder neulich Graphen mit Blogstatistiken. Das geht oft weit über das hinaus, was ökonomisch sinnvoll wäre, aber ich werde ja sowieso nicht für dieses Blog bezahlt, also kann ich mir das auch leisten.
Nur habe ich glaube ich nie genauer beschrieben, wie ich das eigentlich mache. Nur ein paar Andeutungen hier und da, und ein Verweis auf svgo. Also dachte ich mir, ich könnte mal eine Anleitung dazu schreiben. Ich habe mir also ein einfaches Beispiel gesucht, und zwar die Blogstatistik von Schafe sind bessere Rasenmäher (CC BY-NC-SA 4.0 Robert Lützner):
Ich gehe hier Schritt für Schritt vor. Wenn nicht anders erwähnt, sind die Umwandlungen verlustfrei, zumindest was die Anzeige der Grafik angeht. Die vollständigen Dateien nach jedem Schritt habe ich in ein Repo auf codeberg gepackt. Los geht's!
Schritt 0: Originaldatei
Größe: 1561 Byte
Naja, nicht ganz Original. Die Datei war eingebettet in das HTML der Ursprungsseite. Ich habe sie herausgetrennt, das ID-Attribut entfernt (ist hier nicht wichtig) und ein namespace-Attribut (xmlns="http://www.w3.org/2000/svg") hinzugefügt, damit die Datei von z.B. Firefox richtig erkannt wird, wenn es keine anderen Hinweise auf den Typ gibt.
Die Datei ist maschinell erstellt und hat deswegen wenige oder keine unnötigen Leerzeichen.
Schritt 1: svgo
Größe: 1003 Byte
Ein Standardtool zur Optimierung von SVG-Dateien ist svgo. Das läuft schnell durch und in den meisten Fällen ist es auch die ökonomischste Variante, es dabei zu belassen. Aber nicht hier. Ich habe die Datei mit svgo --multipass --pretty optimiert. --multipass, damit Optimierungsmaßnahmen, die beim ersten Durchlauf übersehen wurden, auch gemacht werden. --pretty, um es beim Bearbeiten leichter zu haben. Das fügt zwar eine Menge Leerzeichen ein, die alle Platz brauchen, aber es lohnt sich trotzdem schon. Die Datei ist um ein gutes Drittel kleiner.
Wie geht das? Nun, die Originaldatei enthält ein <polyline>-Element für den Graphen selber und mehrere line-Elemente für die Markierung der Jahreszahlen. Das ist nicht falsch, aber beide Elemente können mit dem generischen <path>-Element deutlich effizienter dargestellt werden. Und deutlich schwerer lesbar. So wird zum Beispiel aus diesem Element:
<line x1="7" x2="7" y1="150" y2="210" style="stroke:#000;stroke-width:1"></line>
dieses hier (und ohne explizites End-Tag ist es auch noch einmal ein bisschen kürzer).
<path style="stroke:#000;stroke-width:1" d="M7 150v60"/>
Schritt 2: Gruppieren
Größe: 905 Byte
Der Output von svgo ist gut, aber wir können noch ein bisschen mehr optimieren. Und zwar indem wir die Elemente ein bisschen umsortieren und gruppieren.
Nun ist die Reihenfolge der Elemente in SVG-Dateien eigentlich nicht egal. Was zuerst kommt, wird zuerst gemalt, was danach kommt übermalt eventuell das, was vorher kommt. In diesem konkreten Fall aber brauchen wir uns darum keine Sorgen machen, da die einzigen Überschneidungen schwarz auf schwarz sind und man so nicht sieht, wenn sich etwas überschneidet.
Wir können also aus diesem Block hier:
<path style="stroke:#000;stroke-width:1" d="M7 150v60"/>
<text font-size="20" transform="rotate(-90 116 89)">2022</text>
<path style="stroke:#000;stroke-width:1" d="M187 150v60"/>
<text font-size="20" transform="rotate(-90 206 -1)">2023</text>
<path style="stroke:#000;stroke-width:1" d="M367 150v60"/>
<text font-size="20" transform="rotate(-90 296 -91)">2024</text>
<path style="stroke:#000;stroke-width:1" d="M547 150v60"/>
<text font-size="20" transform="rotate(-90 386 -181)">2025</text>
<path style="stroke:#000;stroke-width:1" d="M727 150v60"/>
<text font-size="20" transform="rotate(-90 476 -271)">2026</text>
den code hier machen:
<g style="stroke:#000;stroke-width:1">
<path d="M7 150v60"/>
<path d="M187 150v60"/>
<path d="M367 150v60"/>
<path d="M547 150v60"/>
<path d="M727 150v60"/>
</g>
<g font-size="20">
<text transform="rotate(-90 116 89)">2022</text>
<text transform="rotate(-90 206 -1)">2023</text>
<text transform="rotate(-90 296 -91)">2024</text>
<text transform="rotate(-90 386 -181)">2025</text>
<text transform="rotate(-90 476 -271)">2026</text>
</g>
Hier sind drei Dinge passiert. Erstens habe ich die Elemente umsortiert, wie schon angekündigt. Dann habe ich Elemente mit gleichen Attributen in <g>-Elemente, also Gruppierungselemente gesteckt. Drittens habe ich dann die Attribute in das <g>-Element verschoben. Gruppenattribute gelten nämlich für alle Elemente der Gruppe. Dadurch spart man Wiederholungen und somit Platz.
In diesem Fall hebt der gesparte Platz sogar die Codeeinrückung wieder auf. Die kommt zwar am Ende sowieso weg, fügt aber in diesem Zwischenschritt noch ein bisschen an Dateigröße hinzu.
Schritt 3: Style-Attribut
Größe: 882 Byte
Viele Eigenschaften von SVG-Elementen kann man sowohl mit dedizierten Attributen als auch mit dem style-Attribut abbilden. Rein vom Geschmack her bevorzuge ich die dedizierten Attribute, und in vielen Fällen sind sind die auch kürzer als ein Style-Attribut.
So kann man zum Beispiel statt
style="fill:none;stroke:#000;stroke-width:2"
folgendes machen:
fill="none" stroke="#000" stroke-width="2"
Zugegeben, das sind nur zwei Byte. Häufig kann man aber auch manche Attribute vollständig weglassen, weil sie der Standardeinstellung entsprechen, z.B.
style="stroke:#000;stroke-width:1"
vs.
stroke="#000"
Dieser Schritt bringt nicht immer etwas, aber oft genug, und besonders, wenn man mit Exports von Programmen wie inkscape arbeitet, die gerne einen ganzen Haufen unnützer Styles an ein Element hängen. svgo übrigens kann das auch, wenn man es mit einer Konfigurationsdatei konfiguriert, aber dazu später mehr.
Schritt 4: Zusammenfassen von Pfaden
Größe: 777 Byte
Das path-Element hat den Vorteil, dass es beliebig lange, auch unterbrochene Pfadteile aufnehmen kann. svgo ist gut darin, das zu erkennen und Pfade zusammenzufügen, die ansonsten gleiche Eigenschaften haben.
Warum hat svgo das dann hier noch nicht gemacht? Weil die Pfade, die man zusammenhängen könnte durch andere Elemente (die Jahreszahlen) getrennt waren und svgo nicht erkennen kann, dass das kein Problem ist (wie gesagt: Reihenfolge ist in SVG-Datein grundsätlich erst einmal relevant).
Wir haben aber in Schritt 2 umsortiert, also kann svgo die Pfade jetzt ohne Probleme zusammenfügen. Auch die Gruppe können wir uns dann sparen. Damit wird aus dem hier:
<g stroke="#000">
<path d="M7 150v60"/>
<path d="M187 150v60"/>
<path d="M367 150v60"/>
<path d="M547 150v60"/>
<path d="M727 150v60"/>
</g>
dieses deutlich kürzere Stück code:
<path stroke="#000" d="M7 150v60M187 150v60M367 150v60M547 150v60M727 150v60"/>
Aber hey, da ist doch noch ein Pfad, der eigentliche Graph! Warum werden die beiden nicht zusammengefügt? Der erste Pfad hat eine andere Linienstärke als der zweite, deswegen müssen sie getrennt bleiben.
Schritt 5: Whitespace entfernen
Größe: 706 Byte
Zum Schluss lassen wir noch einmal svgo über das Ganze laufen. Dieses Mal nur mit --multipass, ohne --pretty. Damit werden auch die überschüssigen Leerzeichen entfernt.
Wir haben es also in diesem Beispiel geschafft, eine Datei von 1561 byte auf 706 Byte zu reduzieren, das sind fast 55% weniger. In anderen Fällen, wie den Outputs von gnuplot, habe ich es sogar um Faktor 6 reduziert. Das hier war ein einfaches Beispiel. Es gibt noch ein paar andere Wege, die Größen zu optimieren.
Weitere Optimierungsmöglichkeiten
Da wäre zunächst die Präzision der Kommazahlen, z.B. in Pfaden. Hier nicht relevant, weil wir nur Ganzzahlen haben. Auch ist diese Technik nicht verlustfrei. Man muss also nach Augenmaß vorgehen. In vielen Fällen konnte ich aber mit einer Präzision von zwei Nachkommastellen keinen Unterschied zum Original erkennen, auch stark hereingezoomed nicht. svgo kann das mit der Option --precision, z.B. --precision 2 für maximal zwei Nachkommastellen.
Überhaupt bietet svgo noch einige Plugins an, um Dateien weiter zu optimieren. Manche davon sollte man aber mit Vorsicht genießen, weil sie nicht in jedem Fall ein korrektes Ergebnis liefern. Die Liste der Plugins kann man mit --show-plugins anzeigen. Die Plugins zu konfigurieren ist ein bisschen umständlich. Man muss eine JS-Datei anlegen, in der dann die aktiven Plugins aufgelistet werden. Die Datei kann z.B. so aussehen:
module.exports = {
plugins: [
{
name: 'convertTransform',
params: {
},
},
],
};
Hier wird das convertTransform-Plugin aktiviert. Das rechnet Transformationen auf Pfaden so um, dass die Tansformation verschwindet und die Pfade selbst Koordinaten haben, die sie nach der Transformation gehabt hätten. Wegen Rundungsfehlern ist auch das nicht ganz verlustfrei.
Eine wichtige Information bezüglich der Konfigurationsdateien: Wenn man eine nutzt, dann sind nur die aufgelisteten Plugins aktiv. Also auch nicht die, die sonst standardmäßig aktiv sind (es sei denn, sie sind in der Datei aufgelistet). Also entweder alle lugins hinzufügen oder die Konfigurationsdatei nur selektiv (mit der --config-Option) verwenden.
Wichtig: Wenn die Konfigurationsdatei svgo.config.js heißt, wird sie automatisch angewandt (so lange sie im aktuellen Verzeichnis oder in einem darüberliegenden Verzeichnis liegt). Wenn man dann nicht alle Standardplugins in dieser Datei hat, kriegt man unter Umständen schlechte Ergebnisse mit svgo.
Ansonsten kann ich svgo nur sehr empfehlen, aber es schadet auch nicht, ab und zu mal zu schauen, was man noch von Hand optimieren kann. Zumindest nicht, wenn man so verrückt ist wie ich.
