Wenn wir ein PNG-Bild erstellen, verwenden wir ein <img>-Tag oder einen CSS-Hintergrund, und das war's. Es ist kinderleicht und garantiert, dass es funktioniert.
Leider gilt dies trotz seiner vielen Vorteile nicht für SVG. Obwohl Sie bei der Verwendung von SVG in HTML die Qual der Wahl haben, läuft es wirklich auf inline, <object> und <img> hinaus, die alle ernsthafte Probleme und Kompromisse mit sich bringen.
Probleme mit Inline-SVG
Wenn Sie SVG inline einfügen, verlieren Sie die Möglichkeit, den Browser-Cache, Gzip-Komprimierung zwischen Servern und Browsern sowie die Bildindizierung durch Suchmaschinen (Inline-SVG wird nicht als Bild betrachtet) zu nutzen. Auch wenn sich Ihr Bild kein bisschen geändert hat, wird es immer wieder neu geladen, was zu langsameren Ladezeiten für Ihre Website führt – ein Kompromiss, den die meisten nicht eingehen wollen.
Darüber hinaus führt das Inline-Einbetten von SVG zu komplexen Abhängigkeitsproblemen, bei denen Sie Bilder nicht einfach in HTML einfügen können und auf Skripte (PHP oder andere) zurückgreifen müssen. Wenn Sie mehr als nur ein paar Bilder haben, wird dies zu einem großen Problem bei der Wartung Ihrer Website, da Sie das <img>-Tag im Wesentlichen nicht mehr verwenden können.
Zweifellos gibt es Bereiche, in denen das Inline-Einbetten von SVG glänzt – und zwar, wenn Sie möchten, dass Ihre Bilder schnell angezeigt werden, ohne auf andere Ressourcen warten zu müssen. Abgesehen davon kann man offensichtlich nicht alles inline einfügen.
Probleme mit dem object-Tag
SVG ist bekannt für seine hervorragende Qualität bei der Anzeige auf Geräten aller Auflösungen und seine Fähigkeit, auf externe Ressourcen – wie CSS und Schriftarten – zu verweisen, während die Dateigröße sehr klein bleibt. Die Idee ist, viele SVGs zu haben, die sich alle eine einzige CSS- oder eine einzige Schriftartdatei teilen, um die Menge der herunterzuladenden Ressourcen zu reduzieren.
Der Mythos der Ressourcenteilung
Viele wissen nicht, dass die gemeinsame Nutzung externer Ressourcen für SVG nur für Inline-SVG gilt. Da die Verwendung von <object>-Tags den Zugriff auf diese Ressourcen ermöglicht, besteht die Wahrnehmung, dass der Browser eine einzelne Kopie Ihres CSS herunterlädt, obwohl Sie viele <object>-Tags haben, die auf dieselbe CSS-Datei verweisen.
Dies ist jedoch überhaupt nicht wahr
Das Problem verschärft sich dadurch, dass <object>-Tags nicht als Bild erkannt werden und daher keine Bildsuchindizierung möglich ist.
Das Problem wird durch Abhängigkeitsprobleme weiter verschärft. Angenommen, Sie haben 100 Bilder, und 25 davon verwenden eine Roboto-Schriftart, weitere 25 Lato, 25 Open Sans, während der Rest eine Kombination der drei Schriftarten verwendet. Ihr CSS müsste auf alle drei Schriftarten verweisen, da es fast unmöglich ist, nachzuvollziehen, welche Datei welche Schriftarten verwendet, was bedeutet, dass Sie möglicherweise Schriftarten laden, die Sie auf bestimmten Seiten nicht benötigen.
Das Bild-Tag
Damit bleibt uns das <img>-Tag, das viel für sich hat. Da es dasselbe Tag ist, das für andere Bildformate verwendet wird, erhalten Sie Vertrautheit, Browser-Caching, Gzip-Komprimierung und Bildsuche. Jedes Bild ist in sich abgeschlossen, ohne Abhängigkeitsprobleme.
<img>-Tag verwendet wirdDas einzige Problem ist, dass Sie Ihre Schriftarten verlieren werden. Genauer gesagt, wenn Sie Text in Ihrem SVG haben, wird dieser, es sei denn, Sie betten Schriftarten ein, mit Systemschriftarten angezeigt, typischerweise Times New Roman. Sie haben Stunden damit verbracht, eine schöne Schriftart auszuwählen, aber in dem Moment, in dem Sie das <img>-Tag verwenden, um SVG einzubetten, ist all das verloren. Wie kann das akzeptabel sein?
Untersuchung der Schriftarten-Rasterisierung
Unsere erste Reaktion ist, zu prüfen, ob wir eine Schriftarten-Rasterisierung durchführen können. Dies ist eine gängige Technik, um Schriftarten in Pfade umzuwandeln, sodass sie auf allen Geräten gut gerendert werden und keine Abhängigkeiten bestehen. Oberflächlich betrachtet funktioniert dies sehr gut, und im Editor sieht alles perfekt aus.
Obwohl das rasterisierte SVG mit satten **137 KB** im Vergleich zu **15,7 KB** vor der Rasterisierung einbrachte, waren wir optimistisch, denn nach der Optimierung unseres SVG mit Gzip-Komprimierung reduziert sich die rasterisierte Datei auf **11 KB**, etwas kleiner als das äquivalente PNG mit **11,9 KB**.
| Original | Schriftarten-Rasterisierung | Schriftarten-Rasterisierung (.svgz) |
|---|---|---|
| 15,7 KB | 137 KB | 11,0 KB |
| PNG @ 1x | PNG @ 2x | PNG @ 3x |
|---|---|---|
| 11,9 KB | 26,5 KB | 42,6 KB |
Leider stellten wir fest, dass unser Optimismus verfrüht war, als wir das rasterisierte SVG in HTML einbetteten. Obwohl es auf hochauflösenden Displays großartig aussehen mag, ist die Qualität auf niedrigauflösenden Displays inakzeptabel.
Unten im Bild sind die Original-Schriftarten mit klarer Darstellung, während oben die Schriftarten verpixelt sind, wenn sie mit Schriftarten-Rasterisierung dargestellt werden.
Die meisten Betriebssysteme optimieren Schriftarten, um sicherzustellen, dass sie auf allen Bildschirmen klar und scharf angezeigt werden. Unter Windows wird dies als ClearType bezeichnet, und da wir unsere Schriftarten rasterisiert haben, werden keine Optimierungen angewendet, was zu unscharfem Text führt, der besonders auf niedrigauflösenden Bildschirmen sichtbar ist.
Offensichtlich ist eine Qualitätsminderung inakzeptabel, also zurück auf Los.
Schriftarten-Einbettung zur Rettung
Anfänglich waren wir wegen des komplizierten Workflows äußerst skeptisch gegenüber der Schriftarten-Einbettung.
Um Schriftarten in SVG einzubetten, müssen Sie zunächst wissen, welche Schriftfamilien verwendet werden. Dann müssen Sie diese Schriftdateien finden und herunterladen. Nach dem Download müssen Sie reguläre, fette, kursive und fette kursive Schriftarten in Base64-Codierung konvertieren. Wenn Sie dies manuell tun, ist es bei einer großen Anzahl von Dateien nahezu unmöglich, zu wissen, welche Datei fett gedruckt ist und welche nicht. Dann müssen Sie alle vier Base64-codierten Strings in Ihr SVG kopieren.
Sicherlich muss es einen besseren Weg geben. Und deshalb haben wir Nano entwickelt. Nano scannt SVG automatisch und fügt nur die verwendeten Schriftarten ein. Wenn zum Beispiel Fett nicht verwendet wird oder kein Text vorhanden ist, werden keine Schriftarten eingebettet.
Dennoch ist die resultierende Datei riesig und nicht konkurrenzfähig mit dem PNG-Äquivalent, daher haben wir uns weiterentwickelt und unseren eigenen SVG-Optimierer (Nano) entwickelt, der SVG-Dateigrößen auf ein Minimum reduziert. (Sehen Sie, wie Nano SVG komprimiert.) Darüber hinaus haben wir optimiert, wie wir Schriftarten in SVG einbetten, was zu sehr kleinen Dateigrößen führt.
Vergleich von Dateigrößen und Bandbreiteneinsparungen
| Original | Schriftarten-Rasterisierung | Nicht optimierte Schriftarten-Einbettung | Nano-Schriftarten-Einbettung | |
|---|---|---|---|---|
| Größe | 15,7 KB | 137 KB | 65,2 KB | 22,0 KB |
| Gzip | 3,57 KB | 11,0 KB | 44,5 KB | 11,7 KB |
| PNG @ 1x | PNG @ 2x | PNG @ 3x | |
|---|---|---|---|
| Größe | 11,9 KB | 26,5 KB | 42,6 KB |
| Gzip | 12,1 KB | 26,1 KB | 41,7 KB |
Aus dem obigen Vergleich geht hervor, dass Nano ein extrem schlankes SVG erzeugt, selbst mit eingebetteten Schriftarten, das nur **11,7 KB** (Gzip-komprimiert) im Vergleich zu den äquivalenten PNG @1x mit **11,9 KB** benötigt. Auch wenn dies unbedeutend erscheinen mag, sind die gesamten Bandbreiteneinsparungen auf Ihrer Website sicherlich signifikant.
Nehmen wir an, 50 % Ihres Traffics sind niedrigauflösend, 40 % sind 2X-Auflösung und die restlichen 10 % sind 3X-Auflösung. Wenn Ihre Website 10.000 Aufrufe für ein einzelnes Bild hat
(5.000 * 11,9 KB) + (4.000 * 26,5 KB) + (1.000 * 42,6 KB) = 208,1 MB
Wenn Sie Nano verwenden, komprimiertes SVG mit GZip
10.000 * 11,7 KB = 117,0 MB
Dies führt zu: 208,1 MB – 117,0 MB = 91,1 MB Einsparungen oder 43,7 % Bandbreiteneinsparungen, was nach jedem Maßstab erheblich ist.
Zusätzlich zu den Bandbreiteneinsparungen erhalten Sie einen viel einfacheren Workflow, ohne auf mehrere PNG-Bilder mit mehreren srcset-Attributen zurückgreifen zu müssen, mit deutlich besserer Qualität, einschließlich der Betriebssystem-Schriftartenoptimierung, um sicherzustellen, dass Ihre Bilder auf Geräten aller Auflösungen scharf und klar bleiben. Das Beste daran ist eine bessere Benutzererfahrung für Ihre Benutzer, da Ihre Website schneller geladen wird – besonders auf Geräten mit hoher Auflösung.
Umfassendes Testen von Nano
Mit all den Einsparungen nicht zufrieden, begannen wir, nach SVG-Bildern zu suchen, um Nano gründlich zu testen. Insgesamt wurden **2.571** SVG-Dateien unterschiedlicher Größe und Designs verwendet, was insgesamt 16,3 MB ergab. Und nach der Nano-Optimierung, die zu 6,2 MB führte, eine erstaunliche Einsparung von 61,8 % der Größe.
Visuelle Unterschiede anzeigen
Aufgrund der schieren Menge an Dateien, die wir getestet haben und die sich von Zeit zu Zeit erhöht, mussten wir einen automatisierten Test erstellen, der unter anderem automatisch Pixelunterschiede vor und nach der Optimierung hervorhebt. Eine der Beschwerden über andere SVG-Optimierer ist die Tatsache, dass das Minifizieren von SVG Ihr Bild beschädigen kann, sodass es anders gerendert wird als das Original.
Zu diesem Zweck tragen wir die Pixel-Differenzierung in unserem automatisierten Test in Nano selbst ein. Das heißt, Nano warnt Sie, wenn es erkennt, dass das von ihm optimierte SVG mehr als 1 % Pixelunterschied im Vergleich zum Original aufweist, und stellt somit sicher, dass die Optimierung von Nano niemals ein SVG beschädigt.
Da Schriftarten eingebettet und beibehalten werden und SVG ein Vektorgrafikformat ist, ist die Renderqualität bei allen Auflösungen im Vergleich zu anderen Rasterformaten unvergleichlich.
Was kommt als Nächstes?
Wir hoffen, dass unsere Arbeit SVG überall einfacher zu verwenden macht. Wir arbeiten jetzt daran, noch kleinere Dateigrößen zu erzielen und unsere Codes für Node.js zu portieren, damit Sie Ihre Produktions-Builds mit Nano und anderen automatisieren können.
Denken Sie, dass Nano für Ihre Projekte hilfreich sein wird? Lassen Sie es mich in den Kommentaren wissen!
Wenn das W3C nicht von korporativen CSS-Fanatikern beherrscht würde, dann wären SVG-Schriftarten nicht veraltet worden. SVG-Schriftarten lösen alle Ihre Probleme, aber Sie können sie nicht verwenden. Danke an Google, Apple und die NSA.
Vielen Dank für diesen Artikel. Es scheint, dass, wenn Sie nur wenige Stellen hatten, an denen eine Schriftart in der SVG erscheinen würde, die einfache Konvertierung des Textes in Pfade auch eine Option sein könnte. Dies setzt einige Dinge voraus, wie z. B. eine "leichtgewichtige" (nicht viele Punkte) Schriftart und nur wenige Zeichen. Dann würden die Pfade als SVG-Vektoren und NICHT als gerastert bleiben. Die Bildunterschrift lautet: "Schriftarten in Pfade umwandeln", diskutiert dann aber Rasterisierung, ohne mehr über die Verwendung von Pfad-konvertierten Schriftarten zu erwähnen. Ich bin verwirrt.
Hallo Kel, danke für dieses Feedback. Wir nennen die Konvertierung von Schriftarten in Pfade Rasterisierung, im Wesentlichen rasterisieren Sie einfach die Schriftarten in Pfade. Selbst bei "leichtgewichtigem" Text empfehlen wir NICHT die Konvertierung in Pfade, da die Ausgabequalität leidet, da diese Pfade möglicherweise nicht knackig und klar erscheinen. Auf der anderen Seite empfehlen wir Nano, das automatisch sicherstellt, dass die Schriftarten-Einbettungen so leichtgewichtig wie möglich sind, was zu klaren Schriftarten führt, die vom Betriebssystem optimiert werden, und sehr kleinen SVG-Dateigrößen.
Danke Thomas. Ich war nur verwirrt, weil die meisten anderen Anwendungen, auf die ich gestoßen bin, das Wort "rasterisieren" verwenden, um die Konvertierung in ein Rasterbild zu bezeichnen, während die Konvertierung in Pfade immer noch leichter Code war, der Pfade darstellt, nun ja... Pfade :)
Danke. Ich mag SVG im WEB und das sind tolle Neuigkeiten für mich.
Gibt es eine Möglichkeit, dies in ein Sketch-Plugin zu verwandeln?
@smlombardi, derzeit keine Pläne, aber es ist bereits ein Plugin in vecta.io. Suchen Sie danach, denn Zeichnungen mit Vecta haben beim Exportieren von SVG die Option, komprimiert oder minimiert mit eingebetteten Schriftarten zu werden. Ich hoffe, das hilft.
Ich habe vergessen zu erwähnen, dass ein Node.js-Modul in Arbeit ist, das Ihnen hilft, Ihr SVG automatisch zu "nanifizieren", was die Integration in Ihre Build-Prozesse erheblich erleichtert.
Ich stimme den Nachteilen, die Sie für SVGs in diesem Artikel aufgeführt haben, nicht zu. Sie können Gzip für SVGs in Nginx problemlos aktivieren, Browser-Cache ist ebenfalls kein Problem, und selbst wenn es eines wäre, könnte Ihr Service-Worker ihn für Sie cachen.
Hey AJ, Sie können sicherlich Gzip auf Ihrem Server aktivieren, aber wenn Sie SVG inline einfügen, werden sie NICHT als SVG erkannt, daher keine Transportkodierung und kein Cache-Busting. Ich hoffe, das klärt die Dinge.
Der Artikel würde wahrscheinlich von einem passenderen Beispiel profitieren. Die Bilder zeigen Beispiele einfacher Steuerelemente, die aus einem Symbol und Text bestehen. Das ist etwas, das normalerweise mit einem SVG-Symbol und normalem (HTML-)Text gehandhabt wird, das dann leicht über CSS auf eine benutzerdefinierte Schriftart gesetzt werden kann. Warum sollte der Text auch in SVG eingebettet werden müssen? Ich gehe davon aus, dass ein besseres Beispiel eine SVG-Infografik oder ein Diagramm wäre.
@Sime, Sie haben in allen Punkten Recht. In unserem Beispiel wollten wir einen Teil des Dashboards zeigen, und der einfachste Weg ist, sie zusammen mit dem Text zu zeichnen und das Ganze als Bild zu behandeln. Infografiken oder Diagramme wären sicherlich ein besseres Beispiel. Die Trennung des Bildes in ein Symbol und HTML-Text wäre wahrscheinlich weitaus schwieriger zu implementieren. Selbst die besten Teams machen diese Fehler, siehe https://cloud.google.com/storage/, ein einzelnes API-Bild und erneut in ihrem Preisvergleich mit AWS. Wahrscheinlich haben sie Roboto installiert und es sieht auf ihren Systemen gut aus, aber für den Rest von uns würden wir wahrscheinlich lieber nicht auf Times New Roman zurückgreifen.
Warum nicht dynamisch ein externes SVG in das DOM einfügen (Caching), dann alle Ihre aktuellen SVG USE-Referenzen zerstören / neu erstellen? Bam. Zwischengespeicherte Inline-SVGs mit Schriftartunterstützung bis zurück zu IE.
@Chris LaChance, das ist eine ziemlich coole Idee, wenn auch mit einigen Nachteilen.
Durch das Einbetten von Schriftarten behandeln Sie Bilder wie jede andere auch und überlassen dem Browser die Hauptarbeit. Immer noch eine großartige Idee und hat ihre Verwendung. Prost!
Ja, in diesem Fall wäre DOM Ready definitiv erforderlich, zumindest für Browser ohne externe Referenzunterstützung. Ich liebe es, dass Text eingebettet werden kann. Erleichtert die Verwaltung eines Designsystems erheblich.
Das finale Bild, das mit Nano-Optimierung keine visuellen Unterschiede zeigt, sieht großartig aus... in Chrome, Safari und Opera. Aber in Firefox Quantum 60.0.2 hat der umrandete Text seine Hinting-Funktion verloren und ist überhaupt nicht lesbar. Es muss ein Problem mit der Funktionsweise von WebRender geben.
Hallo Sandy, vielen Dank für dieses Feedback.
Für das erwähnte finale Bild handelt es sich um einen Quantum-Bug, bei dem der Browser Schriftarten von USE-Elementen ohne Striche nicht rendern kann, aber lustigerweise wird das Original korrekt gerendert. Wir werden ihnen einen Fehlerbericht einreichen. Wir werden das Bild ersetzen und das USE-Element vorerst entfernen, nochmals vielen Dank, dass Sie uns Bescheid gesagt haben!
Darüber hinaus zeigen unsere Tests, dass Quantum einen Bug hat, der SVG-Attributwerte, die keine Einheiten haben, nicht akzeptiert, insbesondere das Attribut font-size. Gemäß den SVG-Spezifikationen wird, wenn keine Einheiten vorhanden sind, standardmäßig "px" angewendet. Daher bedeutet font-size="45", dass es als font-size="45px" verstanden wird.
Nano als SVG-Minifier entfernt offensichtlich die zusätzlichen "px", was dazu führt, dass Quantum font-size="45" als ungültiges Attribut markiert und somit Rendering-Probleme verursacht. Wir werden dem Quantum-Team einen Fehlerbericht einreichen.
Wenn Sie weitere Probleme haben, lassen Sie es uns bitte wissen, da wir bestrebt sind, Nano plattformübergreifend ohne Probleme zum Laufen zu bringen. Vielen Dank!
Hallo Leute, toller Artikel und Tool – vielen Dank. Vielleicht bin ich aber auch nur dumm – aber ich habe versucht, eine Schriftart mit Nano in mein SVG einzubetten, aber die Ausgabedatei enthält keine eingebetteten Schriftarten (daher viel Times New Roman :-(
Ich habe versucht, ein SVG mit bereits eingebetteter Schriftart als Base64-CSS hochzuladen (wird von Nano gestrippt), mit einer verlinkten Web-Schriftart (keine Auswirkung) und nur dem reinen Output von Sketch oder Illustrator (auch keine Schriftart im nanofizierten Endergebnis eingebettet).
Mir fehlt hier offensichtlich etwas ganz Offensichtliches, aber könnt ihr mir helfen? Wie muss die ursprüngliche SVG-Datei die Schriftart enthalten, damit Nano seine Magie wirken kann?
Jede Hilfe wird geschätzt!