svgpatheditor.de

Ratgeber · best practices

SVG-Pfade optimieren: kleinere Dateien, sauberer Code

Generierte SVG-Pfade sind oft unnötig groß: zu viele Nachkommastellen, überflüssige Befehle, doppelte Punkte. Wie du Pfade verkleinerst, ohne die Form zu verändern, welche Rolle die Rundung spielt und welche Werkzeuge wie SVGO dabei helfen.

Jan-Tristan Rudat
Jan-Tristan RudatRedakteur · Vektorgrafik & Frontend
Veröffentlicht am ·Zuletzt geprüft am

Wenn Du ein SVG aus Illustrator, Figma oder einem Online-Konverter exportierst, bekommst Du meistens eine funktionierende Grafik, aber selten eine schlanke. Der d-Wert eines einzelnen Pfades ist dann oft eine lange Kette aus Zahlen mit sechs oder mehr Nachkommastellen, gespickt mit redundanten Befehlen und Punkten, die niemand braucht. Die Form sieht korrekt aus, aber die Datei ist zwei- bis dreimal so groß wie nötig, und der Code ist praktisch unlesbar.

Das Gute daran: Ein Pfad lässt sich fast immer deutlich verkleinern, ohne dass sich an der sichtbaren Form etwas ändert. In diesem Ratgeber zeige ich Dir, warum generierte Pfade so aufgebläht sind, welche Stellschrauben es gibt und wie Du Rundung, kürzere Befehle und Werkzeuge wie SVGO sinnvoll kombinierst.

Warum generierte Pfade so groß sind

Design-Werkzeuge und Konverter denken nicht an Dateigröße, sondern an mathematische Genauigkeit. Das führt zu drei typischen Problemen.

Erstens: zu viele Nachkommastellen. Ein Editor rechnet intern mit Fließkommazahlen und schreibt sie dann roh in den d-Wert. Für eine Grafik, die am Ende vielleicht 24 Pixel groß dargestellt wird, ist eine Koordinate wie 12.837492 schlicht überpräzise. Jede überflüssige Ziffer kostet ein Byte, und bei hunderten Koordinaten summiert sich das schnell.

Zweitens: absolute Ketten. Viele Exporte schreiben durchgehend absolute Befehle (L, C, M mit Großbuchstaben) und wiederholen den Befehlsbuchstaben bei jedem Segment, auch wenn er identisch bleibt. Relative Befehle mit kleineren Zahlenwerten sind oft kürzer.

Drittens: redundante Befehle und Punkte. Der Konverter setzt manchmal zwei Punkte auf dieselbe Stelle, fügt eine Linie mit Länge null ein oder nutzt einen vollen Kurvenbefehl, wo eine gerade Linie genügt hätte.

Wichtig ist: Alle drei Probleme lassen sich beheben, ohne die Form zu verändern. Es geht nicht darum, die Grafik zu vereinfachen, sondern nur darum, dieselbe Form kompakter zu beschreiben.

Die Rolle der Rundung und Präzision

Die größte Hebelwirkung hat fast immer die Rundung der Nachkommastellen. Schau Dir diesen typischen Ausschnitt aus einem Illustrator-Export an.

Vorher:
M 12.837492 8.199310 L 40.116284 8.199310
  C 44.007183 8.199310 47.116284 11.308411 47.116284 15.199310

Wenn die Grafik in einem viewBox="0 0 48 48" lebt, ist die sechste Nachkommastelle völlig bedeutungslos. Ein Bildschirmpixel deckt hier einen ganzen Wertebereich ab. Gerundet auf zwei Stellen sieht der Pfad identisch aus.

Nachher:
M 12.84 8.2 L 40.12 8.2
  C 44.01 8.2 47.12 11.31 47.12 15.2

Allein durch das Runden schrumpft dieser Ausschnitt um etwa die Hälfte, und mit bloßem Auge ist kein Unterschied erkennbar.

Es gibt aber eine Grenze. Rundest Du zu grob, verzerrt sich die Form: Ecken verschieben sich sichtbar, Kurven werden eckig, feine Details brechen weg. Wie viele Stellen Du behalten solltest, hängt vor allem von der Größe der viewBox ab. Als Faustregel:

viewBox-GrößeEmpfohlene Nachkommastellen
klein (0 bis ca. 24)2 bis 3
mittel (0 bis ca. 100)1 bis 2
groß (0 bis 1000+)0 bis 1

Der Gedanke dahinter: Je größer der Koordinatenraum, desto weniger relative Genauigkeit brauchst Du pro Punkt, weil ein einzelner Nachkommaschritt einen kleineren Anteil der Gesamtgröße ausmacht. Bei einer winzigen viewBox ist es umgekehrt, dort können zwei Nachkommastellen tatsächlich einen sichtbaren Unterschied machen.

Genau hier hilft der Rundungs-Regler im Editor. Du kannst die Präzision schrittweise reduzieren und sofort sehen, ab wann die Form leidet. Statt blind auf einen festen Wert zu runden, findest Du so den Punkt, an dem die Datei minimal bleibt und die Form noch stimmt. Mein Vorgehen in der Praxis: die Präzision so weit herunterdrehen, bis ich eine erste sichtbare Veränderung erahne, und dann eine Stufe zurückgehen.

Kürzere Schreibweisen für Pfadbefehle

Neben der Rundung lässt sich Code sparen, indem man den passenden, kürzeren Befehl wählt. Das SVG-Pfadformat kennt für viele Situationen eine Kurzform. Wenn Du die Befehle noch nicht sicher unterscheidest, hilft die Übersicht der SVG-Path-Befehle.

H und V statt L bei geraden Linien. Eine horizontale Linie braucht keine y-Koordinate, eine vertikale keine x-Koordinate.

Vorher:  L 40 8
Nachher: H 40      (wenn y unverändert 8 bleibt)

S und T statt C und Q bei glatten Übergängen. Der Befehl S (glatte kubische Kurve) und T (glatte quadratische Kurve) leiten den ersten Kontrollpunkt automatisch aus der vorherigen Kurve ab. Wenn Deine Kurven ohnehin glatt ineinander übergehen, sparst Du damit einen kompletten Koordinatensatz.

Vorher:  C 44 8 47 11 47 15  C 47 19 44 22 40 22
Nachher: C 44 8 47 11 47 15  S 44 22 40 22

Relative statt absolute Befehle. Kleinbuchstaben (l, c, m) beziehen sich auf den vorherigen Punkt. Bei nah beieinanderliegenden Koordinaten werden die Zahlen dadurch kleiner und damit kürzer. Ob absolut oder relativ im Einzelfall wirklich kompakter ist, hängt vom Pfad ab. Wie die beiden sich genau unterscheiden, erklärt der Ratgeber zu absoluten und relativen Pfadbefehlen.

Ein weiterer Trick, den optimierende Werkzeuge nutzen: Ein wiederholter Befehl muss nicht neu genannt werden. Nach einem L dürfen weitere Koordinatenpaare folgen, die alle als L interpretiert werden. Aus L 10 10 L 20 20 L 30 30 wird schlicht L 10 10 20 20 30 30.

Doppelte und überflüssige Punkte entfernen

Generierte Pfade enthalten oft Punkte, die nichts zur Form beitragen. Typische Fälle sind eine Linie zurück auf den Ausgangspunkt, obwohl Z den Pfad ohnehin schließt, oder zwei identische aufeinanderfolgende Koordinaten.

Vorher:  M 0 0 L 10 0 L 10 10 L 0 10 L 0 0 Z
Nachher: M 0 0 H 10 V 10 H 0 Z

Im Beispiel oben ist gleich mehreres passiert: Das explizite L 0 0 vor dem Z ist entfallen, weil Z automatisch zum Startpunkt zurückführt, und die geraden Kanten sind zu H und V geworden. Die Form, ein Quadrat, bleibt exakt gleich, aber der Code ist deutlich kürzer und klarer zu lesen.

Solche Aufräumarbeiten von Hand zu machen ist mühsam und fehleranfällig. Genau dafür gibt es automatische Werkzeuge.

SVGO und SVGOMG für die automatische Optimierung

Das Standardwerkzeug für SVG-Optimierung ist SVGO (SVG Optimizer), ein quelloffenes Node.js-Werkzeug, das Du unter github.com/svg/svgo findest. SVGO arbeitet mit einer Reihe von Plugins, die jeweils eine bestimmte Optimierung übernehmen: Nachkommastellen runden, Pfaddaten zusammenfassen, kürzere Befehle wählen, überflüssige Attribute und Metadaten entfernen, leere Gruppen auflösen und vieles mehr. Für ganze Dateien oder ganze Ordner ist das die zuverlässigste Methode.

Auf der Kommandozeile reicht ein einzelner Aufruf.

npx svgo icon.svg -o icon.min.svg

Die Präzision für Pfaddaten steuerst Du dabei gezielt.

npx svgo icon.svg -o icon.min.svg --precision=2

Wer keine lokale Installation möchte, nutzt SVGOMG, die Web-Oberfläche von Jake Archibald unter jakearchibald.github.io/svgomg. SVGOMG ist im Grunde SVGO im Browser: Du ziehst eine Datei hinein, schaltest einzelne Optimierungen über Regler und Schalter zu oder ab und siehst live, wie viele Bytes Du sparst und ob die Vorschau noch stimmt. Der Präzisions-Regler dort entspricht genau der --precision-Option von SVGO. Für einzelne Grafiken ist das oft der schnellste und anschaulichste Weg.

Beide Werkzeuge verarbeiten komplette SVG-Dateien inklusive aller Pfade, Attribute und Definitionen. Das unterscheidet sie von einem reinen Pfad-Editor, der sich auf den d-Wert konzentriert.

Lesbarkeit gegen minimale Größe abwägen

Maximale Optimierung ist nicht immer das Ziel. Ein durch SVGO gejagtes SVG ist minimal groß, aber praktisch nicht mehr von Hand editierbar: keine Zeilenumbrüche, keine Leerzeichen, extrem kurze Zahlen. Für Dateien, die im Build-Prozess ausgeliefert werden und die niemand mehr anfasst, ist das genau richtig.

Wenn Du einen Pfad aber noch weiterbearbeiten willst, etwa in CSS animieren oder per JavaScript verändern, lohnt sich ein Mittelweg mit etwas mehr Präzision und lesbarer Formatierung. Wie Pfade in Stylesheets und Skripten eingesetzt werden, behandelt der Ratgeber zu SVG-Pfaden in CSS und JS. Ein guter Kompromiss ist, die Arbeitsversion lesbar zu halten und erst beim finalen Export durch SVGO zu schicken.

Mein praktischer Ablauf sieht meistens so aus:

  1. Pfad im Editor bearbeiten oder aufräumen und mit passender Rundung exportieren, damit die Nachkommastellen schon vernünftig sind.
  2. Wo sinnvoll, gerade Linien auf H/V und glatte Kurven auf S/T umstellen.
  3. Das fertige SVG einmal durch SVGO oder SVGOMG schicken, um Metadaten, Gruppen und die letzten redundanten Punkte automatisch zu entfernen.

Was der Editor kann und was nicht

Damit hier keine falschen Erwartungen entstehen: Der Editor auf dieser Seite ist kein vollautomatischer Optimierer wie SVGO. Er fasst nicht auf Knopfdruck die gesamte Datei zusammen, löst keine leeren Gruppen auf und entfernt keine Metadaten. Sein Fokus liegt auf dem d-Wert und darauf, dass Du die Form visuell verstehst und kontrolliert veränderst.

Was er aber sehr gut kann, ist den Grundstein für einen schlanken Pfad zu legen: Über den Rundungs-Regler steuerst Du die Präzision direkt und siehst sofort, was Du damit an der Form riskierst. Und weil Du die Befehle einzeln siehst, erkennst Du leichter, wo sich eine kürzere Schreibweise anbietet. Das Ergebnis exportierst Du dann in einem Zustand, der bereits deutlich kleiner ist als der Rohexport und der sich anschließend ideal durch SVGO für den letzten Schliff schicken lässt.

Kurz gesagt: Rundung und kürzere Befehle im Editor legen die Grundlage, SVGO und SVGOMG holen automatisch das Letzte heraus. Zusammen bekommst Du kleine Dateien und sauberen Code, ohne dass sich an der Form etwas ändert.

Quellen

  • https://github.com/svg/svgo
  • https://developer.mozilla.org/de/docs/Web/SVG/Attribute/d
  • https://jakearchibald.github.io/svgomg/

Korrekturen oder bessere Quellen? Schreib an info@akara-solutions.de. Änderungen landen mit Datum auf /korrekturen.