SVG optimieren, ohne die Darstellung zu verändern

SVG-Dateien aus Designprogrammen enthalten häufig mehr Code als für die Darstellung nötig ist: Kommentare, Editorinformationen, überflüssige Gruppen, sehr viele Dezimalstellen oder feste Abmessungen.

Eine gute Optimierung reduziert diese Daten, ohne den sichtbaren Inhalt oder die Wiederverwendbarkeit zu beschädigen.

Mit dem SVG-Optimierer von Bethemesh lassen sich typische Bereinigungsschritte direkt im Browser durchführen.

Erst verstehen, dann optimieren

Der Leitfaden SVG: das Vektorformat verstehen erklärt die Grundstruktur.

Wichtige Bestandteile können sein:

• viewBox,
• Formen und Pfade,
• Gruppen,
• IDs und Klassen,
• <defs>,
• Verläufe,
• Masken,
• Clip-Pfade,
• Filter,
• Texte.

Eine Optimierung darf Referenzen zwischen diesen Elementen nicht zerstören.

Kommentare entfernen

Kommentare sind für den Browser meist nicht nötig:

<!-- exported from ... -->

Sie können in Produktionsdateien entfernt werden, sofern sie keine bewusst benötigte Dokumentation enthalten.

Metadaten entfernen

Editoren speichern teilweise Metadaten über Anwendung, Version, Dokument oder Bearbeitung.

Für die reine Webausgabe sind solche Informationen oft entbehrlich.

Das Entfernen kann Dateigröße und Informationsleck reduzieren.

Editor-spezifische Daten

Programme wie Illustrator, Inkscape oder andere Vektoreditoren können eigene Namespaces und Attribute hinzufügen.

Wenn das SVG nur ausgeliefert und nicht wieder im Originaleditor weiterbearbeitet werden soll, können viele dieser Angaben entfernt werden.

Wichtig: Bewahre eine Originaldatei für die Bearbeitung separat auf.

Leerzeichen minimieren

XML kann für Menschen formatiert sein:

<path
  d="..."
  fill="#2563eb"
/>

Für die Übertragung kann unnötiger Whitespace reduziert werden.

Die Einsparung ist bei kleinen Icons gering, bei vielen Dateien aber kumulativ.

Dezimalstellen reduzieren

Exportierte Koordinaten enthalten oft unnötig hohe Präzision:

12.3456789123

Eine begrenzte Rundung kann die Datei verkleinern.

Aber: Zu aggressive Rundung kann:

• Kurven verändern,
• Kanten verschieben,
• kleine Details zerstören,
• Pfade sichtbar voneinander trennen.

Deshalb sollte die Präzision schrittweise reduziert und visuell geprüft werden.

viewBox unbedingt verstehen

Ein SVG kann beispielsweise enthalten:

width="512"
height="512"
viewBox="0 0 512 512"

Für responsive Verwendung können feste width und height häufig entfernt werden, wenn viewBox korrekt vorhanden bleibt.

Ohne viewBox kann die Skalierung dagegen problematisch werden.

Feste Abmessungen nicht blind löschen

In manchen Komponenten sind feste Maße bewusst Teil des Layouts. Eine allgemeine Optimierungsregel sollte nicht automatisch jede Dimension entfernen.

Die richtige Entscheidung hängt von der Einbettung ab.

Gruppen vereinfachen

Mehrere verschachtelte <g>-Elemente können redundant sein.

Eine Gruppe darf aber Eigenschaften wie:

• transform,
• opacity,
• clip-path,
• filter,
• fill

an ihre Kinder vererben.

Darum ist Zusammenführen nur sicher, wenn die Semantik erhalten bleibt.

Redundante Attribute

Wenn ein Attribut bereits geerbt wird oder dem Standardwert entspricht, kann es möglicherweise entfernt werden.

Beispiel: Wiederholtes fill auf vielen Kind-Elementen könnte auf eine Gruppe verschoben werden.

Solche Strukturänderungen sind wirkungsvoll, aber komplexer als das Entfernen von Kommentaren.

Farben verkürzen

Manche Farbwerte können kompakter dargestellt werden:

#ffffff → #fff

Auch unnötige Präzision in numerischen Farbwerten kann reduziert werden.

Der sichtbare Farbwert muss dabei identisch bleiben.

Pfade zusammenführen?

Mehrere Pfade mit gleichen Eigenschaften lassen sich manchmal kombinieren. Das kann Markup reduzieren.

Es kann jedoch die spätere Bearbeitung, Animation oder individuelle Ansprache erschweren.

Für eine Produktionsdatei kann das sinnvoll sein; für eine Designquelle möglicherweise nicht.

IDs vorsichtig behandeln

IDs werden oft referenziert:

url(#gradient1)
url(#clip1)

Wer IDs umbenennt oder entfernt, muss jede Referenz aktualisieren.

Bei Inline-SVG können außerdem ID-Kollisionen mit anderen SVGs im selben Dokument auftreten.

Verläufe und <defs>

Unbenutzte Definitionen können entfernt werden. Ob eine Definition wirklich ungenutzt ist, muss aber zuverlässig analysiert werden.

Ein Gradient kann indirekt über mehrere Ebenen referenziert sein.

Masken und Clip-Pfade

Diese Elemente beeinflussen die sichtbare Geometrie. Eine Optimierung, die ihre Referenzen beschädigt, kann große Teile der Grafik verschwinden lassen.

Darum gehören komplexe SVGs nach Optimierung immer in eine visuelle Regression.

Filter

SVG-Filter können sehr umfangreich sein. Einige Designprogramme exportieren komplexe Filterketten für Schatten oder Unschärfe.

Vereinfachung kann Dateigröße sparen, ist aber deutlich riskanter als reine Markup-Bereinigung.

Texte und Schriften

Wenn <text> verwendet wird, hängt das Ergebnis unter Umständen von einer Schrift ab.

Wird Text in Pfade umgewandelt, steigt die Pfadmenge, aber die Darstellung wird unabhängiger von der Schrift.

Eine Optimierung sollte nicht automatisch zwischen diesen Ansätzen wechseln.

currentColor nutzen

Icons profitieren oft davon, feste fill-Farben durch currentColor zu ersetzen, wenn sie sich an die Textfarbe anpassen sollen.

Das ist eher eine Komponentenoptimierung als reine Dateikompression, kann aber die Wiederverwendbarkeit stark erhöhen.

CSS-Klassen oder Inline-Attribute?

Beides kann sinnvoll sein. Bei sehr kleinen eigenständigen SVGs sind Attribute oft kompakt. Bei großen Illustrationen mit wiederkehrenden Stilen können Klassen redundanten Code reduzieren.

Gzip/Brotli nicht vergessen

SVG ist Text und komprimiert sich auf HTTP-Ebene meist sehr gut mit gzip oder Brotli.

Eine Einsparung im Quelltext führt deshalb nicht immer eins zu eins zur gleichen Einsparung bei der Übertragung.

Trotzdem verbessert sauberes Markup Wartbarkeit und häufig auch die komprimierte Größe.

Sicherheit und Optimierung

Optimierung ist nicht automatisch Sanitization.

Ein SVG kann potenziell aktive Inhalte enthalten. Das Entfernen von Kommentaren oder Metadaten reicht nicht, um eine nicht vertrauenswürdige Datei sicher zu machen.

Sicherheitsbereinigung muss gezielt gefährliche Elemente, Attribute und externe Referenzen behandeln.

Originaldatei behalten

Ein stark optimiertes SVG ist für die Auslieferung gedacht. Für spätere Bearbeitung sollte eine ursprüngliche Quelldatei erhalten bleiben.

Das gilt insbesondere, wenn Pfade zusammengeführt oder Editorinformationen entfernt werden.

Ein sicherer Optimierungsworkflow

1. Original sichern.
2. Kommentare entfernen.
3. unnötige Metadaten entfernen.
4. Editor-Daten entfernen.
5. Whitespace reduzieren.
6. Dezimalpräzision moderat reduzieren.
7. feste Abmessungen nur bei passendem viewBox prüfen.
8. Datei visuell vergleichen.
9. Masken, Verläufe und Interaktionen testen.
10. finale Datei im Browser und im Zielkontext prüfen.

Vorher und nachher messen

Vergleiche nicht nur Bytes, sondern auch:

• DOM-Komplexität,
• sichtbare Darstellung,
• Skalierbarkeit,
• Ladezeit,
• Wartbarkeit.

Ein um wenige Byte kleineres SVG ist kein Erfolg, wenn es schwieriger zu pflegen oder sichtbar verändert ist.

Verbindung zur Webperformance

Bei vielen Icons oder großen Illustrationen kann SVG-Optimierung Teil einer umfassenderen Strategie sein.

Der Leitfaden Bilder für Webperformance optimieren verbindet Dateigröße, Format, Abmessungen und Ladeverhalten.

Fazit

SVG-Optimierung beginnt mit risikoarmen Bereinigungen: Kommentare, Metadaten, Editor-Daten und unnötige Formatierung. Danach können Präzision, Gruppen und Pfade vorsichtig vereinfacht werden.

viewBox, Referenzen und visuelle Kontrolle sind dabei zentral. Die beste optimierte Datei ist nicht die kürzeste, sondern die kleinste Version, die ihre Darstellung, Skalierbarkeit und Funktion zuverlässig erhält.