Inline SVG: perfekt für ein Icon, Gift für eine Illustration

Man hat Ihnen gesagt, SVG sei leicht und gestochen scharf, also setzen Sie es überall ein und fügen den Code direkt in die Seite ein. Dieser Instinkt ist richtig, für eine Suchlupe oder einen kleinen Pfeil. Es wird zur Performance-Falle, sobald das Bild komplex wird, und zu einem echten Fehler, wenn das, was Sie eingefügt haben, nicht einmal ein echter Vektor ist.

Am Ende dieses Leitfadens können Sie sich jeden Block SVG-Code ansehen und auf einen Blick sagen: der ist inline in Ordnung, der gehört in eine externe Datei, oder das ist nicht einmal ein SVG. Dieser eine Reflex bewahrt Seiten davor, sich ohne Grund im Gewicht zu verdoppeln.

Was "Inline-SVG" wirklich bedeutet

Es gibt zwei Möglichkeiten, ein Bild auf eine Seite zu bringen. Erstens ein Bild-Tag, das auf eine Datei verweist, wie <img src="logo.svg">. Der Browser liest das Tag und holt dann die Datei separat. Zweitens ein Inline-SVG: Die Zeichnung wird vollständig ausgeschrieben, direkt im Seitencode selbst, jeder Strich wird zu einer Codezeile.

Eine Analogie. Ein Bild-Tag ist ein Zettel, auf dem steht "das Foto liegt in der Schublade". Ein Inline-SVG kopiert das gesamte Rezept des Fotos, Strich für Strich, mitten in Ihren Text.

"Inline" ist also für sich genommen weder gut noch schlecht. Alles hängt von der Größe des Rezepts ab.

Warum ein kleines Icon inline genau richtig ist

Der berechtigte Fall: eine Suchlupe, ein Pfeil, ein Häkchen, ein kleines Piktogramm. Ein paar Striche, eine Handvoll Knoten. Inline glänzt hier.

• Keine zusätzliche Netzwerkanfrage. Kein Hin und Her, um eine 300-Byte-Datei zu holen, die Zeichnung ist bereits da.
• Per CSS gestaltbar. Ändern Sie die Farbe beim Hover mit currentColor, animieren Sie es, alles kostenlos.
• Sichtbar ab dem allerersten Paint, nichts, worauf man warten müsste.

Der Kipppunkt, wenn Inline zum Problem wird

Das ist der Kern der Sache. Drei versteckte Kosten häufen sich an, sobald die Zeichnung kein einfaches Icon mehr ist, sondern zu einer vollständigen Illustration wird.

1. Das DOM explodiert

Das DOM (Document Object Model) ist die Liste jedes Elements, das der Browser im Speicher halten und bei jeder Interaktion neu berechnen muss. Stellen Sie es sich als das laufende Inventar der Seite vor.

Ein einfaches Icon fügt ein paar Knoten hinzu. Eine detaillierte Illustration, die aus einem Design-Tool exportiert wurde, bedeutet Hunderte von Pfaden, also Hunderte von Knoten, für ein einziges Bild. Ein Messwerkzeug wie Lighthouse warnt ab ungefähr 800 Elementen auf der Seite und behandelt es als übermäßig ab etwa 1.400. Eine einzige schlecht platzierte Illustration kann allein 300 Knoten hinzufügen, ein großes Stück des Budgets, für nichts.

Je größer das DOM, desto langsamer jede Stil- und Layout-Neuberechnung, desto stärker ruckeln Scrollen und Klicks. Das trifft die Interaktivität direkt, die INP-Metrik (Interaction to Next Paint, wie schnell die Seite auf einen Klick oder Tipp reagiert).

2. Die Parse-Zeit steigt

Bevor er überhaupt etwas anzeigen kann, muss der Browser bei einem Inline-SVG jeden Strich lesen und interpretieren. Multipliziert mit Hunderten von Pfaden, verzögert das den ersten Paint.

Und diese Kosten fallen auf dem Haupt-Thread an, demselben, der auf Klicks reagiert. Man spürt sie also überall, nicht nur beim Laden.

3. Kein Cache, auf jeder Seite neu geladen

Ein Inline-SVG lebt im Seitencode. Es wird nicht für sich allein zwischengespeichert. Wenn es auf fünf Seiten erscheint, wird es fünfmal neu heruntergeladen und neu geparst. Eine externe .svg-Datei hingegen wird einmal heruntergeladen und dann auf jeder anderen Seite aus dem Cache ausgeliefert. Sie blockiert das Rendering nicht und kann verzögert (lazy) geladen werden, wenn sie weiter unten sitzt.

Die Analogie: dasselbe vollständige Rezept in jedes Kapitel eines Buches zu kopieren, statt eines einzigen Lesezeichens, das auf einen einzigen Anhang verweist.

Die Falle in der Falle, ein Raster als SVG getarnt

Der schlimmste Fall, und ein überraschend häufiger: ein PNG oder JPG, in base64 kodiert, das in ein SVG-Tag eingefügt wird. Von außen liest es sich als "ein SVG". In Wirklichkeit ist es ein komprimiertes Foto, das in Text verwandelt wurde.

Das verräterische Zeichen: Wenn das "SVG" Hunderte von Kilobytes wiegt und eine lange Zeichenkette wie data:image/png;base64,iVBOR... enthält, ist es kein SVG. Es ist ein Rasterbild in der falschen Schublade.

<svg width="1200" height="800" ...>
  <image href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg...
     ...tens of thousands of characters of encoded photo...
     ...kSuQmCC" width="1200" height="800"/>
</svg>

Die Lösung: Exportieren Sie eine echte Bilddatei neu, idealerweise WebP (ein modernes Bildformat, leichter als JPEG oder PNG), in einem einfachen Bild-Tag, mit gesetzter Breite und Höhe, Lazy Loading, wenn es außerhalb des Bildschirms liegt, und responsiven Versionen. Diese Versionen lohnen sich nur mit einem korrekten sizes-Attribut: siehe unseren Leitfaden zu srcset und sizes.

Ein echter Fall, anonymisiert

Wir haben eine Seite einer Website auditiert (ein Divi-Build). Im Editor sah nichts falsch aus, sie "hatte einfach ein paar Bilder" nahe dem unteren Rand.

Die Lösung: das Piktogramm als externe .svg-Datei (oder ein WebP in seiner echten Größe), das Podcast-Visual als WebP in einem Bild-Tag. Erwartete Seite: rund 400 KB, die Hälfte des Codes zum Herunterladen und Parsen. Der Punkt ist, dass genau diese Art von Abweichung ein automatisiertes Audit aufdeckt, während es für das Auge, im Editor, "einfach wie ein Bild aussieht".

Die Entscheidungsregel, der Teil zum Merken

Eine Frage, drei Antworten.

1. Ist es ein Foto, ein Screenshot, ein realistisches Rendering? Kein Fall für SVG. Bild-Tag in WebP, responsiv, lazy, wenn außerhalb des Bildschirms.
2. Ist es ein Vektor, aber groß oder komplex (eine große Illustration, viele Pfade, über ~4 KB nach der Optimierung)? Eine externe .svg-Datei, referenziert durch ein Bild-Tag, vorgeladen (preload), wenn sie wichtig und früh sichtbar ist.
3. Ist es ein kleines Icon, wenige Knoten, das Sie per CSS einfärben oder animieren wollen? Inline ist perfekt.

Das Fazit

Ein SVG ist nicht gut oder schlecht. Was zählt, ist das richtige Format am richtigen Ort. Dieselben drei Buchstaben können eine Feder oder ein Amboss sein, je nachdem, was darin steckt.

Der diagnostische Reflex: Achten Sie auf das Gewicht des Blocks und die Anzahl der Pfade, nicht nur darauf, wie es aussieht. Ein Logo, das auf dem Bildschirm gestochen scharf gerendert wird, kann trotzdem ein getarntes 300-KB-Raster sein.