Kategorien
Frontend: HTML5, CSS3, jQuery Linktipps

☞ Bilder als Data-URL: Ein Blick auf die Performance der Technik

Achtung: vermutlich war ich hier etwas voreilig mit Behauptungen, mehr dazu in den Kommentaren.

Sergej Müller hat das Einbinden von Bildern in CSS als Data-URL einem Performance-Test unterzogen Recommended Site. Sein Fazit:

Durch die Base64-Kodierung der Bilder hat sich der „Gewicht“ der Gesamtdatei nahezu verdoppelt. Das trägt dazu bei, dass der Server eine deutlich größere Menge an Daten zu übertragen hat – eine kostspielige Prozedur. Erst die GZIP-Komprimierung reduziert die Dateigröße erheblich und kann die Differenz der Ladezeiten auf ein Minimum verringern.

Ebenfalls nimmt der Browser mehr Zeit in Anspruch, um den Base64-Code zu dekodieren. Ein lokaler Vergleich der Dateien hat bestätigt, dass die Ausführung (das Laden entfällt, da lokal) des HTML-Codes mit Data-URLs stets um 30 ms hinterher hing. Bilder als Data-URL: Ein Blick auf die Performance der Technik

Das Base64 die Datenmenge nahezu verdoppelt war mir soweit sogar bewusst (Nachtrag: meistens handelt es sich nur um ein Drittel mehr), weswegen ich von Data-URLs bislang auch Abstand genommen habe. Der Vorteil nur eine Datei laden zu müssen ist laut diesem Test also eher eine Nullnummer, hinzu kommt ja auch noch die Zeit, die Bilddaten zu dekodieren.

Ändert sich dann doch mal eine Grafik muss diese im CSS aktualisiert werden und damit auch die komplette CSS-Datei beim Besucher neu geladen werden – inkl. der anderen Grafiken.

4 Antworten auf „☞ Bilder als Data-URL: Ein Blick auf die Performance der Technik“

Cool, dir war klar, dass Base64 die Datenmenge nahezu verdoppelt. Und das, wo die Datenmenge durch Base64 erstmal nur um ein Drittel steigt.
Auch im verlinkten Artikel steigt die Dateigröße von 765 KB auf 1012 KB an. Das ist ungefähr ein Drittel mehr. Wer bei 133% von nahezu 200% spricht (das hieße dann nahezu 1530 KB), bei dem weiß ich nicht, ob der Test wirklich objektiv ist oder nicht eine Meinung untermauert werden sollte. Irgendwie.

Da mischte sich wohl altes Halbwissen mit dem Artikel bei mir. Sorry, nicht so klug.

Aber wir können festhalten, dass base64 mehr Daten erzeugt und man dann schon schauen muss ob sich das lohnt, ja?

Ja, base64 ist eine Kodierung, die eben rund ein Drittel mehr Daten erzeugt. Und ja, man muss schauen, wann sich eine Verwendung lohnt.

Der verlinkte Test ist aber nicht wirklich aussagekräftig, da dieser einen zu geringen Umfang hat. Zum einen würde ich nicht nur einmal einen Screenshot aus den Chrome-Tools machen pro Szenario. Dann würde ich nicht nur immer die 15 Dateien nehmen, sondern auch varriieren. Und auch realisitischer/kleinere Dateien. Wenn er die nicht mit seinen Mitteln testen kann, dann sollte er sich andere Mittel suchen (und die gibt es auch im Netz).

Und wenn wir jetzt mal annehmen, dass sich durch GZIP+Base64 und normal kaum Unterschiede ergeben (in diesem Fall gerade einmal 4ms), sollte man sowas doch auch mal in Relation setzen zu den Zeiten, die ein erneuter Connect, Wait, etc. erzeugt, die zusätzliche Last auf dem Server fürs Re-connecten, und und und

Schreibe einen Kommentar zu Markus Baumer Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert