Der folgende Beitrag wurde von Raymond Schwartz verfasst. Wie seine Raster-Geschwister sollte auch SVG vor der Verwendung auf Produktionsseiten optimiert werden. Es gibt mehrere großartige Werkzeuge dafür, aber wie Raymond Ihnen gleich zeigen wird, erzielen Sie die besten Ergebnisse durch ein tieferes Verständnis und ein wenig manuelle Arbeit. Beispielsweise ist die Dezimalgenauigkeit ein wichtiger Faktor bei der SVG-Optimierung, aber es ist eine eher willkürliche Metrik, die vom Koordinatensystem der SVG abhängt. Ändern Sie dieses System, erhalten Sie andere Ergebnisse. Hier ist Raymond.
Drei Faktoren bestimmen die optimierte Dateigröße einer SVG: physische Abmessungen, viewBox und Dezimalgenauigkeit. Beliebige Einstellungen einer dieser drei Eigenschaften können wertvolle Bytes – sogar Kilobytes – kosten. Jede SVG hat eine spezifische Kombination dieser drei Eigenschaften, die die kleinstmögliche Dateigröße ergibt. Indem Sie verstehen, wie jede einzelne die Artikulation von Vektorpfaden beeinflusst, können Sie herausfinden, wie Sie diese anpassen, um die optimale Optimierung zu erzielen.
1) Physische Abmessungen: Entmystifizierung des "Skalierbaren" in SVG (sozusagen)
Um eine SVG zu erstellen, öffnen Sie Ihren bevorzugten Vektorgrafikeditor, richten Sie das Dokument ein und erstellen Sie etwas Visuell Ansprechendes. Teil der Dokumenteneinrichtung ist die Definition der physischen Abmessungen. Dies scheint nicht kritisch zu sein, da Vektorgrafiken per Definition skalierbar sind und die visuelle Abmessung je nach Kontext variiert. Das mag für die visuelle Darstellung gelten, gilt aber nicht für die Code-Darstellung – diese bleibt konstant. Die Code-Darstellung leitet sich teilweise aus den Abmessungen des Containers (oder "Artboard" in Illustrator) ab, die durch diskrete Maße beschrieben werden. Indem Sie die Abmessungen festlegen, haben Sie bereits teilweise bestimmt, wie groß die Datei sein wird.
2) viewBox und Mikrooptimierung
Abmessungen bestimmen neben der Führung der Pfadartikulation auch die Werte des viewBox-Attributs.
Eine viewBox könnte so aussehen
viewBox="-351.7474061, 2051.85204372, 2520.3925946, 2520.13473217"Dies ist viel zu lang, wenn man bedenkt, dass wir eine Mikrooptimierung verlustfrei durchführen können – ohne das Bild visuell zu verändern. Stellen Sie zunächst die obere linke Ecke auf 0,0 ein.
viewBox="0, 0, 2872.1400007, 468.28268845"Dies spart 23 Bytes, da ein Zeichen einem Byte entspricht. Runden Sie als Nächstes Breite und Höhe auf ganze Zahlen – skalieren Sie die Grafik bei Bedarf.
viewBox="0, 0, 2872, 468"Das spart weitere 17 Bytes. Skalieren Sie schließlich das Zeichenbrett herunter, um die Anzahl der Ziffern zu reduzieren.
viewBox="0, 0, 252, 252"Hinzufügen von zwei weiteren für eine Gesamtersparnis von 42 Bytes. Auch wenn die Einsparungen gering sind, ist diese Optimierung einfach durchzuführen und hat keine negativen Auswirkungen. Und da Sie es jetzt wissen, werden Sie Ihre Dateien von Anfang an so einrichten – das sollte in Ihre Dateieinrichtung integriert werden. Aber wichtiger ist, wie wir sehen werden, dass diese Methode beim Sparen von Bytes in Pfaden eine viel größere Auswirkung hat.
3) Dezimalgenauigkeit: Welche ist die beste?
Wenn Sie eine SVG speichern, müssen Sie eine Dezimalgenauigkeit angeben – normalerweise eine Ganzzahl zwischen eins und acht. Sie definiert die Anzahl der Nachkommastellen für alle numerischen Werte. Denken Sie daran, Zeichen entsprechen Bytes und je weniger wir haben, desto kleiner wird die Datei. Mit abnehmender Dezimalgenauigkeit sinkt auch die Anzahl der Bytes – potenziell sieben Bytes pro Zahl weniger.
Aber wenn die Präzision abnimmt, können SVGs visuell kaputtgehen, da möglicherweise nicht genügend numerische Daten vorhanden sind, um sie genau zu beschreiben. Wenn die Präzision zunimmt, ist mehr Detail vorhanden, aber über einen bestimmten Punkt hinaus erhöht sich die Wiedergabetreue möglicherweise nicht – was Bytes verschwendet. Unser Ziel ist es, Dateigröße und visuelle Wiedergabetreue auszugleichen und genau zu wissen, wo dieses Gleichgewicht perfekt ist.
Was von dieser Einstellung nicht erfasst wird, ist die Anzahl der signifikanten Stellen links vom Dezimalpunkt. Hier kommen die Anpassung von Abmessungen und viewBox ins Spiel. Als Nächstes werden wir uns Pfade ansehen – was die Zeichnung definiert – und wie Abmessungen, viewBox und Dezimalgenauigkeit die Anzahl der Zeichen beeinflussen, die sie enthalten.
Wie sieht ein Pfad aus?
Unser Beispiel basiert auf dem Kiwi-Vogel aus Chris Coyiers „Using SVG“ und hat zwei Pfade: einer ist eine Ellipse, der andere ein Kiwi. Seine Abmessungen sind 100 Pixel Breite mal 82 Pixel Höhe, viewBox ist 0 0 100 82 und die Dezimalgenauigkeit ist sieben – die höchste, die Illustrator zulässt.
Einfache Formen haben eigene Tags: circle, ellipse, line, polygon, polyline und rect. Da diese Formen gut definiert sind, ist die benötigte Code-Menge minimal – alles, was Sie brauchen, sind einige Attribut/Wert-Paare. Hier ist, wie der Code der Ellipse unseres Beispiels aussieht.
<ellipse fill="#C6C6C6" cx="46.3267326" cy="68.9376144" rx="42.3298607" ry="13.0623865"/>Um etwas anderes als einfache Formen zu beschreiben, ist der Pfad-Tag erforderlich. Hier ist der Pfad des Kiwis – der erste Teil und der letzte Wert.
<path id="bird" d="M34.363224,0.0008523C17.0553761,0.1314738-2.0175736,13.9286251,0.1724619,34.4692345c0.7027745,6.5964966,3.0235648,10.4009247,8.5313501,12.8991089c5.9327183,2.6941185,9.315836,8.915081,8.2371655,18.4506187 … 72.8360062,22.4844837z"/>Der gesamte Wert ist etwa zwanzigmal länger. Bei so vielen Zeichen bieten nicht-standardisierte Formen die größte Optimierungsmöglichkeit. Beachten Sie, dass alle Zahlen eine Dezimalgenauigkeit von sieben haben. Ein Optimierungstool kann keine Details hinzufügen. Wenn Sie also mit geringerer Präzision speichern, schränken Sie Ihre Optionen ein. Speichern Sie immer mit der höchsten Dezimalgenauigkeit, die Ihr Editor zulässt.
Wie Abmessungen und Dezimalgenauigkeit Pfade beeinflussen
Der erste Wert im Pfad des Kiwis ist: M34.363224,0.0008523
Dies definiert, wo der Pfad beginnt. M bedeutet „move to“ (zu einem Punkt bewegen). Die durch Kommas getrennten Zahlen sind die x- und y-Koordinaten dieses Punktes. Sie leiten sich von den Koordinaten der oberen linken Ecke (viewBox), der Skalierung Ihrer Abmessungen und der von Ihnen gewählten Dezimalgenauigkeit ab.
Aus unserer Beispieldatei habe ich vier weitere Dateien erstellt, indem ich Breite und Höhe mit zehn multipliziert und dividiert habe. Hier sind die ersten und letzten Werte des Kiwi-Pfades in jeder Datei.
| Abmessungen | Erster Wert | Letzter Wert |
| 1×1 | M0.3436333,0.0000095 | 0.7283611,0.2248458z |
| 10×8,2 | M3.4363234,0.0000861 | 7.2836018,2.2484493z |
| 100×82 | M34.363224,0.0008523 | 72.8360062,22.4844837z |
| 1.000×820 | M343.6322327,0.0085142 | 728.3600464,224.8448334z |
| 10.000×8.200 | M3436.3222656,0.0851329 | 7283.6005859,2248.4482422z |
Die untere Grenze für die Länge einer Koordinate mit einer Dezimalgenauigkeit von sieben beträgt neun Zeichen – ein Dezimalpunkt, eine führende Null und sieben Dezimalstellen – oder höchstens zwei mehr als Ihre Dezimalgenauigkeit. Es kann weniger sein, wenn Sie etwas wie 0,1479000 hätten – das würde auf 0,1479 reduziert – aber die Natur von nicht-standardisierten Formen macht solche Werte sehr unwahrscheinlich.
Die Obergrenze für die Länge einer Koordinate wird nur durch die Größe des Zeichenbretts Ihres Editors begrenzt. Beachten Sie, dass bei jeder Multiplikation der Dimension um zehn eine weitere signifikante Ziffer links vom Dezimalpunkt für jede Koordinate hinzugefügt wurde. Und denken Sie daran: Mehr Zeichen bedeuten größere Dateigröße.
Wie beeinflussen Abmessungen die Dateigröße?
Sehen Sie, wie unsere fünf Dateien mit SVGO-GUI optimiert wurden – ein Port von SVGO, aber mit einer Drag-and-Drop-GUI-Oberfläche. Während Drag-and-Drop praktisch ist, hat diese Bequemlichkeit ihren Preis. SVGO-GUI optimiert nur mit einer Dezimalgenauigkeit von drei. Dies ist jedoch perfekt, um die Auswirkungen der Dimension ausschließlich zu demonstrieren. Hier sind die Ergebnisse.
Die Erkenntnis aus dieser Tabelle ist, dass der Gewinn (Prozentualer Rückgang der Datei) mit abnehmender Dimension zunimmt – je kleiner Ihre Abmessungen sind, desto kleiner kann ein Optimierer Ihre Datei machen. Beachten Sie auch, dass die Dateigröße auch vor der Optimierung abnimmt.
Ich verwende SVGO-GUI, um einen Punkt zu verdeutlichen. Es ist großartig für die Massenoptimierung, super praktisch und gut, wenn Sie nicht viel Zeit haben. Wenn Sie jedoch die kleinste Datei erhalten möchten, benötigen Sie eine Dezimalgenauigkeit unter drei – das bedeutet, dass wir ein anderes Werkzeug verwenden müssen.
Die beste Kombination aus Abmessungen und Dezimalgenauigkeit finden
Betrachtet man das Feedback von SVGO-GUI, so gibt es einen unglaublichen Rückgang der Dateigröße um 50 % von „after“ von kiwi-10 auf kiwi-1. Und während das auf dem Papier gut aussieht, sieht es auf dem Bildschirm nicht gut aus. Auf der linken Seite ist kiwi-10 und sieht aus wie das Original. In der Mitte ist kiwi-1, und Sie sehen einen allgemeinen Verlust an Details. Rechts ist kiwi-10 mit reduzierter Dezimalgenauigkeit von drei auf eins – ebenfalls nicht brauchbar.
Mit abnehmenden Abmessungen nimmt auch die Detailgenauigkeit der Pfade ab. Stellen Sie sich eine Koordinate von 5.5555555 vor. Jedes Mal, wenn die Abmessungen um den Faktor 10 reduziert werden, verlieren Sie die letzte Ziffer – 0.5555555, 0.0555555, 0.0055555 usw. Irgendwann geht so viel Detail verloren, dass eine SVG visuell kaputtgeht. Ebenso kann eine SVG visuell kaputtgehen, wenn die Dezimalgenauigkeit reduziert wird – wenn auch auf andere Weise. Unsere Herausforderung besteht darin, die perfekte Kombination aus Abmessungen und Dezimalgenauigkeit zu finden, die die visuelle Wiedergabetreue beibehält und gleichzeitig die geringste Anzahl von Zeichen ergibt.
Zu diesem Zweck werden wir zunächst eine Gruppe von Dateien erstellen, die auf dem Kiwi basieren und deren Abmessungen auf Zweierpotenzen basieren – 1, 2, 4, 8 usw. Der einfachste Weg, dies in Illustrator zu tun, ist, die gesamte Grafik auszuwählen, sie in die Zwischenablage zu kopieren, ein neues Dokument zu erstellen, die Abmessungen festzulegen und einzufügen. Bei geöffneter Transformationspalette und ausgewählten Pfaden setzen Sie die x- und y-Koordinaten auf 0 und stellen Sie den größeren Wert von Breite oder Höhe auf die entsprechende Abmessung des Zeichenbretts ein. Achten Sie darauf, das Verknüpfungssymbol der Transformationspalette auszuwählen, um das Seitenverhältnis beizubehalten. Machen Sie so weiter, bis Sie 1024 Pixel oder 2048 Pixel erreicht haben.
Nun ist es an der Zeit, Jake Archibalds Online-Optimierer SVGOMG! zu verwenden. Es ist ein fantastischer, umfassender Optimierer, der sowohl online als auch offline verwendet werden kann. Obwohl SVGOMG! eine integrierte Zoomfunktion hat, müssen Sie bei kleineren Größen die Breite auf einen vernünftigen Wert ändern, damit Sie Bilder klar sehen können (500 Pixel sollten ausreichen). Öffnen Sie das erste Bild (1×1). Stellen Sie sicher, dass "Compare gzipped", "Prettify code" und "Multipass" deaktiviert sind. Schalten Sie "Show original" ein, um das unoptimierte Bild mit dem optimierten zu vergleichen. Wir werden die beste Datei ermitteln, indem wir die Dezimalgenauigkeit anpassen. Finden Sie die niedrigste Dezimalgenauigkeit, mit der Sie zufrieden sind, bevor es zu visuellen Brüchen kommt, und notieren Sie sie. Hier sind meine Ergebnisse, nachdem ich dies für jedes Bild getan habe.
| Abmessungen (Quadrat in px) |
Niedrigste Dezimalgenauigkeit ohne Bruch |
Optimierte Dateigröße (K) |
| 1 | 4 | 1.4 |
| 2 | 3 | 1.25 |
| 4 | 3 | 1.28 |
| 8 | 3 | 1.29 |
| 16 | 3 | 1.31 |
| 32 | 3 | 1.39 |
| 64 | 2 | 1.22 |
| 128 | 2 | 1.34 |
| 256 | 1 | 1.11 |
| 512 | 1 | 1.18 |
| 1024 | 1 | 1.28 |
Einige der in dieser Tabelle vorhandenen Muster haben wir bereits besprochen – bei kleineren Größen ist mehr Dezimalgenauigkeit erforderlich, um visuelle Brüche zu vermeiden; bei größeren Größen ist weniger Dezimalgenauigkeit akzeptabel; je größer die Abmessungen, desto größer die Dateigröße.
Ein neues Muster ist aufgetaucht – eine Dezimalgenauigkeit von eins ergibt die kleinste Datei. Die Dateigröße wird bei jedem "Sprung" zur nächstkleineren Dezimalgenauigkeit erheblich kleiner. Die kleinste Datei bei Dezimalgenauigkeit 4 ist 1,4 KB; die kleinste bei 3 ist 1,25 KB; die kleinste bei 2 ist 1,22 KB; und die kleinste bei 1 ist 1,11 KB. Was immer noch unbekannt ist, ist die kleinste Dimension, bei der eine Dezimalgenauigkeit von eins nicht zu Brüchen führt.
Beachten Sie, dass die Bandbreite unserer gezielten Variationen fast 0,3 KB, oder über 20 % des höchsten Wertes, beträgt. Die Bandbreite wäre größer, wenn wir keine spezifischen Werte ausgewählt hätten. Dies gibt Ihnen eine Vorstellung davon, wie sehr willkürliche Entscheidungen die Dateigröße beeinflussen können.
Um die exakte Kombination aus Abmessungen und Dezimalgenauigkeit zu finden, die die kleinste Dateigröße ergibt, konzentrieren wir uns auf die Sprünge in der Dezimalgenauigkeit. Wir können die beiden Sprünge – von 4 auf 3 und von 3 auf 2 – eliminieren, da es eine kleinere Dateigröße gibt (beim Sprung von 2 auf 1) und alle Punkte innerhalb dieser Sprünge größer wären. Dies lässt nur den ersten Sprung von 2 auf 1 zur Untersuchung übrig.
Erstellen Sie eine Datei mit einer Breite des Mittelpunkts des ersten Sprungs – 192. Bei einer Dezimalgenauigkeit von 1 beträgt sie 1,06 KB und sieht akzeptabel aus. Denken Sie daran, dass diese Unterschiede fast unmerklich sind und nur beim Umschalten zwischen Original und optimiert in SVGOMG! sichtbar werden. Der nächste Mittelpunkt – zwischen 128 und 192 – ist 160. Dieser sieht nicht gut aus und stieg auf 1,07 KB – die Dateigröße kann sich verfestigen und widerspricht dem etablierten Muster. Um das zu überprüfen, habe ich mir 200 angesehen, was bei 1,08 KB lag – wie erwartet, wieder aufwärts. Und 190 und 194 waren beide 1,07 KB. Die beste Größe wird also bei 192 Pixel Breite und einer Dezimalgenauigkeit von 1 erreicht. Wie erstaunlich ist es, dass wir das tatsächlich wissen?
Weitere Mikrooptimierungen
Hier ist der optimierte Code von SVGOMG! unseres Gewinners, 192×192.
<svg xmlns="http://www.w3.org/2000/svg" width="192" height="192" viewBox="0 0 192 192"><ellipse cx="88.9" cy="132.4" fill="#C6C6C6" rx="81.3" ry="25.1"/><path d="M66 0C32.7.3-4 26.7.3 66.2 1.7 78.8 6 86.2 16.7 91c11.4 5 18 17 15.8 35.4-3 1.5-5.4 3.4-6 6.2 2.4 0 4.7 0 7 1.4 6.5 4 10 8.6 13.6 16.2.7 1 2.7 1 2.7-1 0-2.6-.6-5.5-1.6-8.4-1-2.6 1-2.5 2.3-2 2 1 5 3 9.5 4.2 1.7.4 2-1.2 1.6-2.2-.6-2.4-3.4-3.4-7.7-6-1.5-1-.2-3 1.7-2.7l6.3 1c1 0 1.5-2 .3-2.6-4.5-2-9-3-17-2.4-3.6-9.2-9.3-19.3-4.8-25.6 4-5.6 9.7-6.5 12.2 13.6-1.5 1-3.5 1.6-3.5 4 2-.8 3.4-.4 4.5 0 5.6 2.3 11.2 7 16.7 11.8 1 1 2.6-.6 2-2-.5-2-2.4-3.3-4.5-6.2-1-1.4 1.6-2.2 3.4-2 4.5 0 7.3 2.5 11.2 3.4 1.4.3 3-.7 2-2.2-1-2-4-2.8-6-4.2-1.3-1-.8-2.2 1-2 1.2 0 2.6.7 4.3.5 3-.2 2.4-2.2-.3-3-6-1.6-12.5-2-19.3-1.5-14-2.7-10-26.7 0-28.4C73 82.6 83.5 80 95 74c10.3-1.7 20.4-4 29.2-10.6 15-4.5 35 5 64 47 1.3 1.7 5 3 3-2-5-13-21.4-29.3-29-41.5C155 54.4 158 47.6 150 38.2c-6.7-7.8-15-8-24.3-5.4-7.3 2-12.3-2.3-16.6-10C100 7 83.5 0 66 0zm73.8 43.2c2 0 3.5 1.5 3.5 3.4 0 2-1.5 3.5-3.5 3.5s-3.4-1.5-3.4-3.4c0-2 1.5-3.4 3.4-3.4z"/></svg>SVGOMG! leistet hervorragende Arbeit bei der Optimierung des Pfades und dem Entfernen von unnötigem Code, den Ihr Editor einfügt. Es zeigt Ihnen auch die Dateigröße des Originals – in diesem Fall 3,92 KB im Vergleich zu 1,06 KB, was einer Ersparnis von 72,96 % entspricht! Was übrig bleibt, bietet weitere Optimierungsmöglichkeiten.
Sie können das Attribut xmlns sicher entfernen, wenn Sie nur HTML5-konforme Browser unterstützen. Im Kontext eines HTML-Dokuments wird xmlns für SVG-Elemente impliziert. Für Abwärtskompatibilität mit XHTML oder um Ihren Markup wie gültiges XML zu behandeln, lassen Sie dies drin. Wenn entfernt, beträgt die Einsparung 35 Bytes.
Wenn Ihr Bild visuell bearbeitet werden kann, entfernt das Runden aller Attributwerte der Ellipse auf die nächste ganze Zahl ein paar Bytes mehr, verschiebt sie aber leicht. Das Ändern der Farbe in etwas Ähnliches, aber Wiederholendes wie #ccc halbiert diesen Wert. Sie könnten auch das Container-Element der SVG mit CSS ansprechen und dieses Attribut ganz entfernen. Die Einsparungen durch diese Mikrooptimierungen betragen 23 Bytes, was zu einer Gesamteinsparung von 58 Bytes und einer endgültigen Dateigröße von 1,025 KB – einer Ersparnis von 73,85 % führt.
Das Entfernen von Breite- und Höhenattributen würde unsere Datei noch weiter optimieren. Vor allem im responsiven Kontext, warum Breite und Höhe explizit in Pixeln festlegen? Responsive SVGs werden mit CSS realisiert, das die Attribute für Breite und Höhe ohnehin überschreibt. Die Vorteile, sie beizubehalten, überwiegen jedoch die Optimierungsvorteile ihrer Entfernung. Sie können jedoch bleiben, wenn Fluidität immer noch erwünscht ist.
Warum Breite- und Höhenattribute beibehalten werden sollten
Wenn Sie dem Prinzip der progressiven Verbesserung folgen, möchten Sie Ihre Seiten mit fehlendem CSS testen. CSS hat SVGs responsiv gemacht und wird nicht mehr angewendet. Was passiert, wenn eine SVG ohne Breiten- und Höhenattribute gerendert wird, ohne CSS? Sie füllt die gesamte Breite des Viewports aus. Dies ist möglicherweise nicht das, was Sie beabsichtigt haben, und kann zu einer schwer lesbaren und fehlerhaften Seite führen.
Die nächste Abbildung zeigt CSS-Tricks ohne besagte Tricks. Das Masthead sieht über die gesamte Breite gut aus, daher wurden Breiten- und Höhenattribute beibehalten, aber das Suchsymbol nicht. Es trennt das Suchlabel vom Suchfeld, ist visuell zu dominant und verursacht übermäßiges vertikales Scrollen.
Hier sehen Sie, was passiert, wenn ein Breitenattribut mit dem Wert 16 zum Suchsymbol hinzugefügt wird.
Dies passt besser zu dem Aussehen des Icons mit angewendetem CSS, macht die Seite besser lesbar und stellt die richtige visuelle Hierarchie wieder her.
Achten Sie darauf, wie es gefüllt wird
In einer anderen Ansicht sieht der obere Teil der Seite mit angewendetem CSS bei einer mittleren Media Query so aus.
Beachten Sie, dass sowohl die SVGs "CSS-TRICKS" als auch "treehouse" weiß auf schwarzem Hintergrund sind, aber im vorherigen Bild wechselt "CSS-TRICKS" zu schwarz, während "treehouse" weiß bleibt – und daher auf dem weißen Hintergrund unsichtbar ist. Das Hinzufügen von Farbe kann entweder über CSS oder das Attribut fill erfolgen. Im Fall des Treehouse-Logos (höchstwahrscheinlich von Treehouse geliefert) wurde das Attribut fill verwendet, um Füllfarbe hinzuzufügen. Wenn CSS fehlt, gilt das fill-Attribut weiterhin, sodass das Treehouse-Logo weiß blieb.
Es ist wahrscheinlich sicherer und intuitiver, die Darstellung in CSS statt durch ein Attribut zu steuern. Wenn Stile zusammen mit einer SVG verpackt werden müssen, verwenden Sie ein Style-Attribut, damit es wie andere CSS-Elemente behandelt wird.
Diese gleichen Anzeige-Probleme erstrecken sich auch auf den Druck. Testen Sie, wie Druckstile-Sheets mit SVGs umgehen, und stellen Sie sicher, dass sie sichtbar und im richtigen Verhältnis sind, falls sie überhaupt angezeigt werden. Wenn gedruckt, wäre das Suchsymbol groß und proportional daneben, genauso wie in unserem Webseiten-Beispiel – was Papier verschwendet und die Lesbarkeit beeinträchtigt.
Fazit
Jetzt können Sie jede SVG auswählen, diesen Prozess durchlaufen und wissen, dass Sie eine Version erstellt haben, die die kleinstmögliche Dateigröße hat – basierend auf Ihrem Ausgangspunkt. Es mag eine bessere Methode geben, ich habe vielleicht etwas übersehen, und die Landschaft wird sich sicherlich ändern, aber ich biete dies als mögliche Lösung an und hoffe zumindest, dass es eine Diskussion anregt und Sie dazu bringt, Ihre eigene Methode zu entwickeln.
Selbst wenn Sie diese Methode nicht buchstabengetreu befolgen, können die Berücksichtigung der Prinzipien Ihren Prozess und Arbeitsablauf leiten. Die visuelle Inspektion ist subjektiv, und die Entscheidung über die richtige Balance zwischen visueller Wiedergabetreue und Dateigrößenersparnis – und wie viel Aufwand Sie dafür betreiben – liegt bei Ihnen. Es gibt viele Vorteile, wenn Websites performant sind, und das Abspecken von SVGs kann erheblich zu diesen Bemühungen beitragen – am kritischsten mit Inline-SVG.
Ein automatisiertes Werkzeug wäre hilfreich, und es wäre wahrscheinlich am besten, wenn etwas wie SVGOMG! – das bereits stark genutzt wird und unter kompetenter Entwicklung steht – diese Art von Funktionalität zu seinen Fähigkeiten hinzufügt. In der Zwischenzeit hoffe ich, dass Sie sich entscheiden, den größten Nutzen aus Ihren SVGs zu ziehen.
Adobe Illustrator hat den Befehl Object > Path > Simplify. Mehr als oft hilft er, ein paar Punkte abzuschneiden.
Ooh, guter Punkt. Genau wie bei jeder Optimierung gilt: Solange es Ihren eigenen, objektiven visuellen Kriterien entspricht, ist es großartig. Ich würde hinzufügen: Object > Compound Path > Make und Object > Ungroup. Der Punkt ist, dass ein Optimierer nur mit dem arbeiten kann, was Sie ihm geben, und je weniger Tag-Elemente und Attribute Sie haben, desto besser – außer denen, die notwendig sind.
Apropos SVG-Optimierung, Jake Archibald hat eine ziemlich coole Web-UI für SVGO gemacht.
https://jakearchibald.github.io/svgomg/
Tolle Zusammenfassung, Raymond. Vielen Dank, dass Sie sich die Zeit genommen haben, die Details so genau zu untersuchen!
Eine Anmerkung jedoch: Ich bin wirklich anderer Meinung bezüglich der Beibehaltung der Breiten- und Höhenattribute der SVG. Ich verstehe Ihren Punkt und ja, klar, die ungestylte Version der Seite ist zunächst mit einem kleineren Icon besser lesbar.
ABER ich habe wirklich Schwierigkeiten zu verstehen, warum jemand die Fluidität der SVG kompromittieren sollte, nur weil es eine Art kleine Möglichkeit gibt, dass die Seite ohne Stile gerendert wird.
Außerdem, da wir über Optimierung sprechen, denke ich, dass – wenn die Seite richtig optimiert ist – der Flash des ungestylten Inhalts gar kein Problem wäre, zumal wir jetzt Möglichkeiten haben, kritische CSS (und mehr) bereitzustellen, die sicherstellen, dass wir diese ungestylten Seiten gar nicht erst bekommen.
Das ist eine großartige Zusammenfassung und ich liebe ihre Gründlichkeit, aber ich rate dringend davon ab, die Breiten- und Höhenattribute beizubehalten.
Prost!
Ich freue mich sehr, dass Sie meinen Beitrag gelesen haben! Ich habe viele Ihrer Beiträge gelesen, einige nur zur Vorbereitung auf diesen. Und ich bin geschmeichelt, dass Sie (ausgerechnet Sie) mich dafür kritisieren, dass ich mich in die Details vertiefe. Ich bin weiter erfreut, dass Sie nur mit einem kleinen Punkt nicht einverstanden sind. Was ich nicht sehe und gerne von Ihnen erklärt bekommen würde, ist, wie die Kompromittierung der Fluidität im Falle von nicht verfügbarem CSS eine schlechte Idee ist. Mit eingeschaltetem CSS gibt es keinerlei Kompromisse – SVGs sind flüssig. In meinem Beispiel hat der Header von CSS-Tricks keine Breite und Höhe, damit er fließend über die Oberseite der Seite gespannt werden kann. Wo ich die Attribute belassen habe, waren es für Icons, die nicht unbedingt flüssig sein müssen, da sie normalerweise nur ein visueller Hinweis sind.
Ich mache mir keine Sorgen um FOUC, ich mache mir Sorgen um CSS, das nicht geladen wird oder absichtlich weggelassen oder überschrieben wird. Und in diesem Fall ist die Fluidität einiger SVGs fragwürdig und das Entfernen scheint einfach durchzuführen und hat keine Nachteile, nur Vorteile. Bitte überzeugen Sie mich vom Gegenteil, wenn ich das falsch sehe. Beim erneuten Lesen sehe ich, dass der Titel der Unterüberschrift „Warum Breiten- und Höhenattribute beibehalten werden sollten“ absolut klingt. Aber im Inhalt des Abschnitts erwähne ich, dass der Masthead gut aussieht und ich keine Breite und Höhe dafür habe. Ich werde diesen Abschnitt bearbeiten, um klarzustellen, dass ich nicht unilateral Breite und Höhe zu jeder SVG hinzufüge – sondern nur dort, wo es sinnvoll ist. Ist das der Punkt, den Sie machen?
Hallo Raymond, danke für die Antwort.
Ja, das war genau der Punkt, den ich machen wollte.
Ich habe auch den Punkt verpasst, an dem Sie die
width- undheight-Attribute in CSS überschreiben. (Ich habe den Artikel nach meiner Heimkehr von meiner Reise gelesen, also war ich etwas müde und habe diesen Punkt daher verpasst; das tut mir leid.)Also ja, das Beibehalten der Attribute ist in Ordnung, solange Sie sicherstellen (und vielleicht im Artikel hervorheben?), dass diese Attribute in CSS überschrieben werden, insbesondere das
height-Attribut.In den meisten Fällen lege ich die Abmessungen der SVG nicht in CSS fest, was ein weiterer Grund ist, warum ich verpasst habe, dass Sie das tun.
Ich bin ganz dafür, Präsentationsattribute für progressive Verbesserung beizubehalten, und habe diesen speziellen Punkt in meinem letzten Vortrag erwähnt (aber in anderen Szenarien). Aber auch hier habe ich das in Ihrem Artikel verpasst.
Auf jeden Fall eine sehr gute Zusammenfassung und danke für die Klärung Ihres Standpunkts. =)
Hallo, Sara! Der Betreuer von svgo ist hier. Ich kann der Entfernung von Breite und Höhe von SVG nicht wirklich zustimmen.
Der Grund dafür ist, dass man SVG als Hintergrund eines Elements platzieren kann. Ohne definierte Bildgrößen dehnt es sich über das Element aus. Das ist in Ordnung, wenn es sich um ein separates Element für ein Icon handelt. Aber solange jemand ein Icon in der Ecke oder einem anderen Teil eines beliebigen Elements platziert, ist das schlecht. Deshalb entfernt svgo diese nicht.
Mit in der SVG gesetzten Breiten- und Höhenwerten können Sie ein Bild sicher überall platzieren. Wenn es nötig ist, die Bildgrößen zu ändern, gibt es die Eigenschaft
background-size. Die Bildgröße muss nicht mit der Elementgröße übereinstimmen.Warum würdest du "Compare gzipped" in SVGOMG deaktivieren? Auf einem richtig konfigurierten Server werden SVGs komprimiert, daher wäre die Aktivierung ein fairer Vergleich, meiner Meinung nach.
Generell bedeutet weniger Bytes auch eine kleinere komprimierte Datei. Das ist nicht immer wahr, aber für optimierte SVGs sind komprimierte Dateien etwa halb so groß wie unkomprimierte Bilder.
@Lev: Stimmt, aber wenn SVGOMG eine Option zum Vergleichen komprimierter Größen hat, warum würdest du sie nicht nutzen, um sicherzugehen, dass du die kleinstmögliche Größe erhältst?
@Lev, danke für deine Einblicke und dafür, dass du ein so nützliches Werkzeug pflegst!
@Sander, ich sage nicht, dass man "Compare gzipped" nie benutzen sollte, aber für den Vergleich mit einer von Illustrator generierten SVG bedeutet das Deaktivieren, dass man Äpfel mit Äpfeln vergleicht – die Illustrator-Datei ist nicht komprimiert. Wenn "Compare gzipped" aktiviert ist, erhält man eine potenziell beste Dateigröße, verschleiert aber auch die Auswirkungen unserer Optimierungen.
Nicht alle Server sind für Gzip eingerichtet und nicht alle Clients sind in der Lage, es zu empfangen. Wenn Sie neugierig auf die endgültige, komprimierte Größe sind, werfen Sie einen Blick darauf, und ich stimme zu, ich fühle mich sehr gut, wenn diese Zahl kleiner ist. Aber ich würde sagen, dass die Metrik, die universeller ist und Ihnen über die von Ihnen durchgeführten Optimierungen informiert, die Größe mit deaktiviertem "Compare gzipped" ist. Das ist mein Hauptanliegen – was ist die Auswirkung der Optimierungen, die ich durchgeführt habe. Und mit SVGOMG! ist "Compare gzipped" nur einen Schalter um.
Und Lev hat Recht, je nach Datei funktioniert Gzip besser oder schlechter, wird aber generell kleiner sein. Bei einer CSS-Datei beispielsweise, wenn Sie Muster wie die Alphabetisierung Ihrer Selektoren hinzugefügt haben, erstellt Gzip eine kleinere Datei. Ich bin mir nicht sicher, ob diese Art von Tweak einer SVG möglich ist. Wenn Sie die Datei also nicht explizit auf eine bessere Gzipping-Verarbeitung vorbereiten können, gehen Sie davon aus, dass eine kleinere Datei auch kleiner komprimiert wird, gemäß Levs Faustregel von etwa der Hälfte (Ihre Erfahrungen können variieren).
Ah, danke für die Klarstellung, ich habe es missverstanden. Ich dachte, es würde die Dateigrößen für die verschiedenen Bildbreiten vergleichen, aber es vergleicht die Größe des optimierten Bildes mit dem Original. Ich stimme zu, es ist sinnvoller, „Vergleiche gzippt“ in diesem Fall zu deaktivieren.
Sehr informativer Artikel!
Aber im Hinblick auf die Nutzbarkeit für Produktionszwecke, sollte das nicht ganz unten auf unserer Prioritätenliste stehen? Was ist der wirkliche Wert darin, 1 KB von einem SVG zu sparen? Sie können weitaus mehr Bandbreite sparen, indem Sie Ihr gesamtes HTML minimieren.
Obwohl Ihr Beispiel 1 KB beträgt, könnten Sie viel mehr sparen, je nachdem, wie aufgebläht Ihre SVGs bereits sind (wobei, woher wissen Sie das?), wie viele Sie haben und wie groß sie sind (nicht alle SVGs sind kleine Icons).
Wichtig ist hier, zu verstehen, wie SVGs aufgebaut und optimiert werden, damit Sie besser vorbereitet sind, Ihre Websites performanter zu gestalten. Der von mir verfolgte Prozess ist absichtlich detailliert, da er zu Erklärungszwecken dient. Wenn Sie ihn ein paar Mal durchlaufen haben (wie ich), werden Sie ein Gefühl dafür entwickeln, was am besten ist, und müssen nicht unbedingt alle Schritte durchgehen – und einige davon sollten zu Ihrem Standardprozess werden.
Ich stimme jedoch zu, dass Sie, wenn Sie 500 SVGs auf einer bestehenden Website haben, die Sie mit diesem Prozess konvertieren möchten, das nicht tun werden. Aber es ist ein Produktions-bereiter Prozess. Was wäre, wenn ich das CSS-Tricks-Logo damit bearbeiten würde? (Ich habe es für Chris getan und Sie können es gerne haben). Ich habe etwas mehr als 300 Bytes bei einer 3-KB-Datei (oder 10 %+) gespart. Sie mögen sagen, das ist keine große Sache, aber wenn Sie das kritische PfpadStart von 14 KB anstreben, zählt jedes Byte. Wenn Ihre Website nur wenige SVGs hat, die auf jeder Seite angezeigt werden, wie ein Logo oder ein paar Icons, warum nicht ein wenig Anstrengung investieren, um überall zu sparen?
Ich bin daran interessiert, diesen Prozess zu automatisieren und mit einem Tool wie SVGO zu verbinden (hast du das gehört, Lev?), in diesem Fall würden Sie es wahrscheinlich tun, wenn es automatisch wäre. Beachten Sie, dass es schwierig sein kann, es vollständig zu automatisieren, da Sie visuell überprüfen möchten, ob die SVGs nicht beschädigt wurden.
Ja, das ist definitiv aus Wissensperspektive nützlich. Je mehr wir über die Werkzeuge und Techniken wissen, die wir verwenden, desto besser sind wir gerüstet, sie anzuwenden.
Nehmen wir diese Seite als Beispiel, Sie sparen nur 300 Bytes beim Logo. Vielleicht ein paar zusätzliche Bytes hier und da, wenn es andere SVGs gibt.
Wenn Sie alle Kommentare im HTML entfernen, sparen Sie 1294 Bytes. Entfernen Sie Leerzeichen und Sie sparen zusätzliche 5757 Bytes.
Ich glaube einfach nicht, dass die Dateigröße von SVGs ganz oben auf unserer Liste der Dinge stehen sollte, um das Gewicht unserer Webseiten zu reduzieren.
Nochmal, guter Artikel, sehr informativ. Nur nicht unbedingt eine Technik, die viel bewirken wird.
Sie verwechseln „etwas bewirken“ mit einer willkürlichen Untergrenze für die Anzahl der Bytes, die eine bestimmte Optimierungstechnik entfernen kann. Je nach Situation erzielen Sie einmal mehr Einsparungen mit der einen Technik und ein anderes Mal mit einer anderen Technik. Daher bin ich mir nicht sicher, warum Sie nicht alle verfügbaren Optimierungsmethoden nutzen möchten, da jede einzelne die größten Einsparungen erzielen könnte.
Sie nennen ein Beispiel, bei dem die durch manuelle Verbesserung der SVG-Optimierung erzielte Einsparung 300 Bytes beträgt. Das Beispiel aus diesem Beitrag sparte fast 3 KB von einem SVG. Und es gibt sicherlich Beispiele, bei denen die Einsparungen durch SVGs mehr als durch das Entfernen von Kommentaren oder Leerzeichen wären.
Ich gab das Beispiel der 300 Byte-Einsparung durch das Logo, um zu betonen, dass es, obwohl die Einsparungen gering waren, nicht nur einen Unterschied machen, sondern einen bedeutenden Unterschied machen könnte. Das Logo befindet sich oben auf der Seite und ist höchstwahrscheinlich etwas, das Sie im anfänglichen 14-KB-Chunk sehen möchten, der für Ihren kritischen Pfad geladen werden soll. Die Tatsache, dass Sie ihn tatsächlich optimieren können, könnte den Unterschied bedeuten, ob Sie unter dem 14-KB-Limit bleiben oder andere Kompromisse eingehen müssen, um dies zu erreichen.
Es tut mir leid, aber 300 Bytes sind selten signifikant. Insbesondere wenn man bedenkt, dass das Entfernen von Kommentaren und Leerzeichen im HTML, etwas, das selten getan oder überhaupt besprochen wird, über 20-mal mehr Speicherplatz sparen könnte.
In der realen Welt haben Sie nicht unbegrenzt Zeit, um jede mögliche Optimierung vorzunehmen. Das ist einfach nicht realistisch. Also müssen Sie priorisieren. Und ich würde sagen, dass die von Ihnen vorgeschlagene Technik sehr weit unten auf dieser Liste stehen sollte.
Sie sparen so wenig bei etwas, bei dem Sie bereits viel sparen. Einfach ein SVG statt eines PNGs zu verwenden, reicht schon aus. Und Sie verlieren Qualität. Diese Zahlen sind nicht zufällig, sie haben einen Zweck, Sie reduzieren die Qualität. Also müssen Sie jedes SVG überprüfen, um sicherzustellen, dass es immer noch gut aussieht. Das ist wertvolle Zeit.
Macht Spaß zu diskutieren, gute Informationen zu wissen, aber letztendlich nichts, was in Bezug auf die tatsächliche Implementierung in Ihrem normalen Workflow sehr wichtig ist.
Sie könnten 300 Bytes, 3 KB, 30 KB, 300 KB usw. sparen. Das variiert je nachdem, womit Sie beginnen – und jedes Byte zählt.
Fühlen Sie sich frei, diese Methode nicht zu verwenden, das ist Ihre Entscheidung.
Fühlen Sie sich auch frei, das letzte Wort zu haben, da dies die letzte Antwort auf Ihre Kommentare ist, die ich geben werde. Und bitte wissen Sie, dass ich bis zu diesem Zeitpunkt für Sie, aber für andere, die diese Kommentare lesen werden, geantwortet habe.
Das muss man nicht persönlich nehmen.
Aber jedes Byte zählt nicht. Das ist überhaupt nicht realistisch.
Und wenn Sie wirklich jedes Byte sparen wollen, gibt es Dutzende anderer Dinge, die Sie tun können, die weniger Zeit in Anspruch nehmen, weniger Risiko bergen, etwas kaputt zu machen, und mehr Dateigröße sparen. Wenn Sie diese bereits getan haben und verrückt werden wollen, dann machen Sie das auch. Daran ist nichts falsch.
Aber in 99 % der Fälle in der realen Welt ist diese Technik nicht nützlich. Das war alles, was ich sagen wollte.
Aber dieser Artikel handelt von der Optimierung von SVGs, nicht von HTML-Leerzeichen. Wenn dieser Artikel von allgemeiner Optimierung handeln würde, hätte Ihr Kommentar mehr Gewicht. Er tut es jedoch nicht.
Er geht auch ein wenig auf die inneren Abläufe ein, wie Optimierungen funktionieren. 300 Bytes sind übrigens etwa 2 % von 14 KB. Das könnte den Unterschied machen, wer weiß. Darüber hinaus sind die Optimierungen, die Sie an einem SVG vornehmen, das auf jeder Seite vorkommt, wahrscheinlich erheblich größer. Es besteht immer die Versuchung zur Überoptimierung, wenn Sie ein SVG für zum Beispiel einen Blogbeitrag erstellen… aber für Dinge, die auf jeder Seite Ihrer Website verwendet werden, wenn Sie versuchen, unter 14 KB zu kommen, könnten 10 % der gesamten Einsparungen auf allen am häufigsten geladenen SVGs tatsächlich dazu beitragen, die anfängliche Ladezeit Ihrer Website zu beschleunigen.
Zu lernen, WIE und WARUM SVGs optimiert werden können, ist eine nützliche Fähigkeit. Dieses Wissen hilft, wenn Sie die ursprüngliche Grafik erstellen und wenn Sie sie speichern. Und dieses Wissen wird auch dazu beitragen, vielleicht jemanden zu ermutigen, einen Optimierer zu entwickeln.
Ja, es geht um die Optimierung von SVGs. Aber ich frage, ob das etwas sein sollte, das uns wichtig ist. Ich denke, die Antwort ist nein. Wenn Sie sich Sorgen um die Optimierung Ihrer Website machen, gibt es viele andere Dinge, die Sie tun sollten, bevor Sie dies tun.
Ich habe bereits mehrmals gesagt, dass dies nützliches Wissen ist. Es ist nur nichts, was für die überwiegende Mehrheit der Menschen in der überwiegenden Mehrheit der realen Situationen eine Priorität sein sollte. Ich versuche nicht, irgendetwas von dem, was er geschrieben hat, abzutun. Ich versuche nur, etwas Kontext zu geben.
Tolle Informationen. Wichtig zu wissen. Aber müssen Sie das tatsächlich tun? Nein.
Tolle Lektüre! Danke für den Share. Ich habe mir bisher nicht wirklich die Zeit genommen, meine SVG-Optimierung zu verbessern, aber jetzt, wo ich Zeit habe. Sehr hilfreich.
Freut mich, dass es Ihnen gefallen hat. Hoffentlich werden einige dieser Schritte zu Ihrem Standardprozess, ohne tatsächlich Zeit zu kosten. Und für den Rest gilt: Je mehr Sie üben, desto weniger Zeit wird es in Anspruch nehmen.
Ändern Sie „effect“ in „affect“ in diesen beiden Titeln
— „How dimension and decimal precision effect paths“
— „How does dimension effect file size?“
Ich schätze die Korrektur und werde diese Änderungen vornehmen. Ich würde mich auch über Kommentare grammatikalischer Natur freuen.
Es hat mich die halbe Lektüre des Artikels gekostet, um zu erkennen, dass Sie, wenn Sie von „Reduzierung der Abmessungen eines SVG“ sprechen, eigentlich meinten: „Reduzierung der Länge der Dimensionswerte“.
Für mich sind die Abmessungen eines Bildes die Größe der Leinwand…
Gibt es eine Möglichkeit zu verhindern, dass Leute die SVG-Datei herunterladen und bearbeiten? Ich glaube nämlich, dass diese Datei editierbar ist wie eine .AI- oder .PSD-Datei. Stimmt das?
Yep. Datei > Exportieren > PNG.
SVG ist eigentlich NOCH editierbarer als ein AI oder PSD. Diese Formate erfordern eine spezielle Software. Mit einem SVG können Sie es in einem Texteditor bearbeiten.
SVG ist lediglich ein Teil von XML. Als solches ist es im Wesentlichen Code. Textbefehle, die über eine Leitung gesendet werden, die vom Client übersetzt und gerendert wird.
Eine bessere Frage ist… haben Sie einen wirklich gültigen Grund, das Herunterladen und Bearbeiten der Quelldatei zu verhindern?