Vorteile und Nachteile von url('data:image/png;base64...)
0 
Der Martin
0 0 
Gunnar Bittersmann
0 
molily
0 1 0 0 molily
0 Gunnar Bittersmann
Vorteile und Nachteile von url('data:image/png;base64...)
Mahlzeit,
gibt es irgendwelche Vorteile bei der Verwendung von
url('data:image/png;base64...)
gegenüber
url(http://...)
?
Kann mir Vorstellen, dass es weniger Overhead gibt, da alle Bilder mit einem request geladen werden.
Aber ist das so relevant, dass man diese Möglichkeit nutzen sollte?
Gibt es weitere Vorteile oder Nachteile?
thx4hlp
-
Moin,
gibt es irgendwelche Vorteile bei der Verwendung von
url('data:image/png;base64...)
gegenüber
url(http://...)
?
Kann mir Vorstellen, dass es weniger Overhead gibt, da alle Bilder mit einem request geladen werden.
ja, richtig - die Bilder werden quasi in einem Rutsch als Teil der HTML- oder CSS-Ressource geladen.
Vorteil: Weniger Requests, weniger HTTP-Overhead. Fällt vor allem bei vielen kleinen Bildern ins Gewicht.
Nachteil: Die insgesamt übertragene Datenmenge wird größer, da base64 je 3 Bytes zu 4 ASCII-Zeichen umcodiert. Kann vor allem bei langsamen Verbindungen (mobil?) ein Argument gegen data-URLs sein.
Nachteil: Der Quellcode wird durch die base64-Datenwurst sehr unübesichtlich. Irrelevant, wenn man den Quellcode serverseitig generieren lässt.
Mehr fällt mir dazu spontan nicht ein.
Aber ist das so relevant, dass man diese Möglichkeit nutzen sollte?
Das sollte man IMO von Fall zu Fall abwägen.
Ciao,
Martin--
If you believe in telekinesis, raise my hand.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
Man denke auch an dynamisch erzeugte Bilder, die für jeden Aufruf anders aussehen. Zum Beispiel aktuelle Grafiken mit sich schnell änderndem Inhalt.
Da kann es interessant sein, das Bild mit ins HTML zu packen, anstatt einen Link reinzusetzen in dem umständlich der gewünschte Inhalt des Bilds codiert werden muss.Oder Seiten die man aus irgendeinem Grund abspeichern können soll, ohne dass ein enthaltenes Bild später neu geladen werden muss.
-
@@Der Martin:
nuqneH
Nachteil: Die insgesamt übertragene Datenmenge wird größer, da base64 je 3 Bytes zu 4 ASCII-Zeichen umcodiert. Kann vor allem bei langsamen Verbindungen (mobil?) ein Argument gegen data-URLs sein.
Größere zu übertragende Datenmenge? Du überträgst HTML-/CSS-Code doch nicht etwa unkomprimiert?
Ja, bestimmt holen die Kompressionsalgorithmen bei JPEG/PNG/GIF bei Bilddaten noch etwas mehr raus als ZIP, aber das sollte nicht so ins Gewicht fallen.
Gerade bei mobiler Datenübertragung ist die Einsparung von HTTP-Request ein deutlicher Vorteil.
Nachteil: Der Quellcode wird durch die base64-Datenwurst sehr unübesichtlich. Irrelevant, wenn man den Quellcode serverseitig generieren lässt.
Sass/Compass kann das auch. Übrigens auch für Webfonts.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Hallo,
Nachteil: Die insgesamt übertragene Datenmenge wird größer, da base64 je 3 Bytes zu 4 ASCII-Zeichen umcodiert. Kann vor allem bei langsamen Verbindungen (mobil?) ein Argument gegen data-URLs sein.
Größere zu übertragende Datenmenge? Du überträgst HTML-/CSS-Code doch nicht etwa unkomprimiert?nein, wohl nicht. Daran hatte ich überhaupt nicht gedacht, weil das normalerweise unbemerkt im Hintergrund abläuft, ohne dass man sich aktiv drum kümmern muss.
Ja, bestimmt holen die Kompressionsalgorithmen bei JPEG/PNG/GIF bei Bilddaten noch etwas mehr raus als ZIP, aber das sollte nicht so ins Gewicht fallen.
Ich glaube, jetzt schmeißt du was durcheinander: Wenn wir mal davon ausgehen, dass die verschiedenen Kompressionsalgorithmen "ähnlich gut" sind, sollte gzip ungefähr das wieder herausholen, was base64 vorher aufgebläht hat.
Damit ist natürlich mein Argument des höheren Datenvolumens hinfällig.Ciao,
Martin--
Ich bin im Prüfungsstress, ich darf Scheiße sagen.
(Hopsel)
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
@@Der Martin:
nuqneH
Ich glaube, jetzt schmeißt du was durcheinander
Ich glaube nicht.
Wenn wir mal davon ausgehen, dass die verschiedenen Kompressionsalgorithmen "ähnlich gut" sind, sollte gzip ungefähr das wieder herausholen, was base64 vorher aufgebläht hat.
Ja, genau das meinte ich. Nur mit der Ergänzung, dass »ähnlich gut« nicht gleich gut ist. Sonst könnte man sich die ganzen Grafikformate ja sparen und gezippte Bitmaps verwenden.
Damit ist natürlich mein Argument des höheren Datenvolumens hinfällig.
Darauf wollte ich hinaus.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Hallo Gunnar,
Ich glaube, jetzt schmeißt du was durcheinander
Ich glaube nicht.ich schon, oder du hast es sehr unglücklich formuliert.
Wenn wir mal davon ausgehen, dass die verschiedenen Kompressionsalgorithmen "ähnlich gut" sind, sollte gzip ungefähr das wieder herausholen, was base64 vorher aufgebläht hat.
Ja, genau das meinte ich. Nur mit der Ergänzung, dass »ähnlich gut« nicht gleich gut ist. Sonst könnte man sich die ganzen Grafikformate ja sparen und gezippte Bitmaps verwenden.Ja, wir meinen eigentlich dasselbe. Nur dass du die Kompressionsalgorithmen der Grafikformate mit zip oder gzip verglichen hast:
Ja, bestimmt holen die Kompressionsalgorithmen bei JPEG/PNG/GIF bei Bilddaten noch etwas mehr raus als ZIP, ...
Da die aber in beiden Fällen Teil der Verarbeitungskette sind, fallen sie aus der vergleichenden Betrachtung raus, es bleibt also
a) Bildkompression + base64-Zunahme + gzip-Kompression
vs.
b) Bildkompression + gzip-Kompression
wobei die bereits komprimierten Bilddaten kaum weiter komprimierbar sind und zip/gzip im Fall a) fast nichts gewinnt, und im Fall b) im Wesentlichen die Volumenzunahme durch base64 kompensieren kann.Wie gesagt, ich hatte die Transfercodierung und -komprimierung nicht bedacht, und kam dadurch natürlich zu einem anderen, in den meisten Fällen vermutlich falschen Schluss.
Schönes Wochenende,
Martin--
Vater Staat bringt uns noch alle unter Mutter Erde.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
-
-
-
-
Hallo,
Nachteil: Die insgesamt übertragene Datenmenge wird größer, da base64 je 3 Bytes zu 4 ASCII-Zeichen umcodiert. Kann vor allem bei langsamen Verbindungen (mobil?) ein Argument gegen data-URLs sein.
Die Gesamtdatenmenge ist nicht notwendig größer, denn der HTTP-Overhead ist bis zu einer bestimmten Bildgröße größer als die Kosten der Base64-Kodierung. Gerade bei Mobilverbindungen mit großer Latenz (bloße Geschwindigkeit ist nicht der entscheidende Punkt) wirkt sich die Einsparung des HTTP-Requests (und damit i.d.R. einer TCP-Verbindung) positiv auf die Performance aus. Da im CSS zumeist keine großen Inhaltsgrafiken, sondern kleine Logos und Schmuckelemente referenziert werden, verringert die Einbettung mit data-URLs in den meisten Fällen die Gesamtdatenmenge.
Mathias
-
-
hi,
ich würde ersteinmal klären, ob auch alle Browser der Welt mittlerweile base64 können.
Zeckenhorst
--
Das Schwarze an den Füßen sind nur Zecken.-
ich würde ersteinmal klären, ob auch alle Browser der Welt mittlerweile base64 können.
Den Browsern, die das nicht können, sollte man ihre Totenruhe lassen.
-
hi,
ich würde ersteinmal klären, ob auch alle Browser der Welt mittlerweile base64 können.
Den Browsern, die das nicht können, sollte man ihre Totenruhe lassen.
Irgendwann einmal wird auch base64 sterben. Das ist alles nur eine Frage der richtigen Geschäftsidee, dass zukünftige Browser und insbesondere mobile Endgeräte komplett mit binaries umgehen können.
Schönes Wochenende,
Horst Sonnenschein--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
Hallo,
Irgendwann einmal wird auch base64 sterben. Das ist alles nur eine Frage der richtigen Geschäftsidee, dass zukünftige Browser und insbesondere mobile Endgeräte komplett mit binaries umgehen können.
Mit »Binaries« kann jeder Browser umgehen, das Problem ist doch, Binärdaten sinnvoll in zeichenbasierten Textformaten wie HTML, CSS und JavaScript unterzubringen. Diese unterliegen immer einer bestimmten Zeichenkodierung, die Unicode-Zeichen binär repräsentiert. Wenn man darin wiederum Binärdaten als Zeichen repräsentieren will, wird es notwendig eklig und es kommt so etwas wie Base64 heraus. Man kann höchstens eine neue Zeichenkodierung erfinden, die beides gut kann, aber: Not gonna happen.
Grüße,
Mathias-
hi,
die Binary für den € ist z.B. E2 82 AC
Ja, ein Browser kann mit dieser binary umgehen, er bekommt diese drei bytes und stellt das Eurozeichen dar, wenn er die Mitteilung bekommt, dass das utf8 ist.
Jetzt stell Dir mal vor, der Browser bekäme eine andere Mitteilung, z.B. diese hier:
- lese 4 bytes
- packe diese 4 bytes aus in Network-Order (Big Endian 32 bit)
- der Big Endian ergibt die Zahl 3
- lese nun 3 bytes, du bekommst damit die bytes für das Euro-Zeichen
- lese wieder 4 bytes um die Längenangabe für die als nächstes zu lesenden bytes zu bekommen
usw.
Das z.B. sind binaries, mit denen ein heutiger Browser nichts anfangen kann, weil er den Big Endian genausowenig kennt, wie den Little Endian. Ein heutiger Browser würde versuchen, aus bytes, gleich welcher Wertigkeiten, stets Zeichen darzustellen, ein Browser kennt nur Kodierungen.
Bytesemantik ist Low Level. Zeichenkodierungen spielen da überhaupt keine Rolle, die werden erst interessant, wenn es um die Darstellung auf einem höheren Level (Presentation-Layer) geht. In diesem Level steht der Browser, der macht aus bytes sichtbare Zeichen, wenn er dazu den Content-Type text/html oder text/plain dazu bekommt.
Ein Browser wird ein Bild darstellen, wenn er zu den Bytes den Content-Type image/gif geliefert bekommt. Ein Browser wird ein image/gif auch innerhalb text/html anzeigen, wie das auszusehen hat, sagen ihm die Tags. Für all diese Dinge bekommt ein Browser binaries, er bekommt auch für uns sichtbare Texte (HTML) als binary. Ein Browser wird weitere Requests machen, wenn ihm ein Tag sagt: Hier sind noch Bilder. Alles nüschd Neues.
Neu wäre, wenn der Browser die gesamte multipart Message (text, bilder) als Binary in einem Request bekommt. Eine Binärsequenz, in der auch Big Endians enthalten sind, die z.B. den Offset angeben, von wo bis wo die Bytes für ein Bild zu lesen sind.
Das ist, was heutige Browser nicht können. Es gibt ja auch (noch) keine Standards für den Aufbau einer multipart message als Binärsequenz. Letztere jedoch gab es bereits zu einer Zeit, als es das Internet noch gar nicht gab ;)
Schönen Sonntag
-
PS:
Den enctype="multipart/form-data" haben wohl die Wenigsten unter uns jemals zu Gesicht bekommen. Macht nichts, ist ja auch Schrott:
Text und reine Binärdaten sind hier im Presentation Layer zusammengeführt als Multipart Message. D.h., die Strukturierung erfolgt mit Mitteln des Presentation Layers, obwohl es gar nicht vorgesehen ist, einen solchen Content-Type präsentieren zu wollen.
Die Mauer ist Geschichte...
-
-
-
-
-
@@M.:
nuqneH
Aber ist das so relevant, dass man diese Möglichkeit nutzen sollte?
Ja.
Gibt es weitere Vorteile oder Nachteile?
Ein Nachteil ist, dass man nicht per Media-Query eins aus mehreren Bildern übertragen lassen kann. Alle Bilder einzubetten (also auch zu übertragen) kann ja meist nicht Sinn der Sache sein.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Ein Nachteil ist, dass man nicht per Media-Query eins aus mehreren Bildern übertragen lassen kann. Alle Bilder einzubetten (also auch zu übertragen) kann ja meist nicht Sinn der Sache sein.
In meinen Fall geht es um Screenshot-Thumbnails, die beim Klick in voller Grösse nachgeladen werden. In meinem Fall ist das dann eher kein Problem, da in der Übersicht nur dir Bilder geladen werden, die nötig sind und alles andere per Ajax passiert.
Auf jeden Fall Danke an alle, die geschrieben haben, damit kann ich was anfangen :)
-