2009-10-15 7 views
25

Wie viel schneller ist es, eine Base64/Zeile zu verwenden, um Bilder anzuzeigen, als einfach auf die harte Datei auf dem Server zu verlinken?Wie viel schneller ist es, inline/base64-Bilder für eine Website zu verwenden als nur auf die harte Datei zu verlinken?

url(data:image/png;base64,.......) 

Ich konnte keine Art von Leistungsmetriken zu diesem Thema finden.

Ich habe ein paar Bedenken:

  • Sie nicht gewinnen mehr den Vorteil des Caching
  • Ist kein Base64 VIEL größer als das, was eine PNG/JPEG Dateigröße?

wir definieren „schneller“ als in: Die Zeit, die für einen Benutzer eine volle gerenderte HTML-Webseite

Antwort

3

Sie nicht mehr gewinnen den Nutzen des Caching

zu sehen

Ob das wichtig ist, hängt davon ab, wie stark Sie vom Caching abhängig sind.

Ist ein base64 viel größer in der Größe als eine PNG/JPEG-Dateigröße?

Der Dateiformat/Bildkomprimierungsalgorithmus ist der gleiche, ich nehme es, d.h. es ist PNG.

Unter Verwendung von Base-64 stellt jedes 8-Bit-Zeichen 6 Bits dar: daher werden Binärdaten um ein Verhältnis von 8 zu 6 dekomprimiert, d. H. Nur etwa 35%.

5

Wie viel schneller ist es

definieren 'schneller'. Meinst du HTTP-Leistung (siehe unten) oder Rendering-Leistung?

Sie nicht gewinnt mehr den Vorteil des Caching

Eigentlich, wenn Sie diese in einer CSS-Datei tun wird es noch im Cache gespeichert werden. Natürlich werden alle Änderungen am CSS den Cache ungültig machen.

In einigen Situationen könnte dies als eine riesige Leistungssteigerung über viele HTTP-Verbindungen verwendet werden. Ich sage einige Situationen, weil Sie wahrscheinlich Techniken wie Bildsprites für die meisten Sachen nutzen können, aber es ist immer gut, ein anderes Werkzeug in Ihrem Arsenal zu haben!

+0

Sie werden stark von der reduzierten Anzahl von HTTP-Anforderungen profitieren, auch. –

+1

Definieren wir "schneller" wie: Die Zeit, die ein Benutzer benötigt, um eine vollständig gerenderte HTML-Webseite zu sehen. – Tim

36

‚Faster‘ ist eine harte Sache zu beantworten, weil es viele mögliche Interpretationen und Situationen sind:

Base64-Codierung wird das Bild um ein Drittel zu erweitern, die Bandbreitennutzung erhöhen. Auf der anderen Seite wird durch die Aufnahme in die Datei ein weiterer GET-Umlauf zum Server entfernt. Eine Pipe mit hohem Durchsatz, aber geringer Latenzzeit (z. B. eine Internetverbindung über das Internet) wird eine Seite mit eingebetteten Bildern wahrscheinlich schneller laden, als wenn Sie unterschiedliche Bilddateien verwenden würden. Selbst auf meiner (ländlichen, langsamen) DSL-Leitung brauchen Standorte, die viele Rundreisen erfordern, viel länger zum Laden als solche, die nur relativ groß sind, aber nur wenige GETs benötigen.

Wenn Sie bei jeder Anfrage die base64-Codierung aus den Quelldateien durchführen, verbrauchen Sie mehr CPU, schlagen Ihre Datencaches usw., was die Antwortzeit Ihres Servers beeinträchtigen könnte. (Natürlich können Sie immer Memcached oder ähnliches verwenden, um dieses Problem zu lösen).

Dadurch werden natürlich die meisten Formen des Caching verhindert, was sehr schaden kann, wenn das Bild häufig angezeigt wird - ein Logo, das auf jeder Seite angezeigt wird und normalerweise vom Browser (oder einem Proxy) zwischengespeichert werden kann Cache wie Tintenfisch oder was auch immer) und einmal im Monat angefordert. Es verhindert auch die vielen Optimierungen Webserver für die Bereitstellung von statischen Dateien mit Kernel-APIs wie sendfile (2).

Grundsätzlich wird dies in bestimmten Situationen helfen, und in anderen verletzen. Sie müssen herausfinden, welche Situationen für Sie wichtig sind, bevor Sie wirklich herausfinden können, ob dies ein lohnender Trick für Sie ist.

+0

Definieren wir "schneller" wie: Die Zeit, die ein Benutzer benötigt, um eine voll gerenderte HTML-Webseite zu sehen – Tim

+0

Caching/perf auf dem Server-Ende möglicherweise nicht so problematisch. Sie können Ihre Seiten immer noch teilweise in Dateien zwischenspeichern, sodass Bilder nicht wiederholt in base64 konvertiert werden müssen. Wenn sich Ihre Seite nicht sehr oft ändert, können Sie dem Browser auch mitteilen, dass er die HTML-Datei selbst zwischenspeichern soll. –

15

Ich habe einen Vergleich zwischen zwei HTML-Seiten mit 1800 Ein-Pixel-Bildern gemacht.

Die erste Seite erklärt die Inline-Bilder:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAANSURBVBhXYzh8+PB/AAffA0nNPuCLAAAAAElFTkSuQmCC"> 

Im zweiten Bezug Bilder eine externe Datei:

<img src="img/one-gray-px.png"> 

Ich fand, dass, wenn sie mehrmals das gleiche Bild geladen, wenn es Wird inline deklariert, führt der Browser eine Anfrage für jedes Bild durch (ich nehme an, dass es base64 einmal pro Bild dekodiert), während im anderen Szenario das Bild einmal pro Dokument angefordert wird (siehe das Vergleichsbild unten).

Das Dokument mit eingebetteten Bildern wird in etwa 250 ms geladen und das Dokument mit verknüpften Bildern in 30 ms.

(Getestet mit Chromium 34)

Das Szenario eines HTML-Dokuments mit mehreren Instanzen des gleichen Inline-Bild macht nicht viel Sinn, a priori. Ich habe jedoch festgestellt, dass das Plugin jquery lazyload standardmäßig einen Inline-Platzhalter für alle "faulen" Bilder definiert, deren src-Attribut darauf gesetzt wird. Wenn das Dokument viele faule Bilder enthält, kann eine Situation wie die oben beschriebene auftreten.

Timeline comparison

+2

Haben Sie die Zwischenspeicherung aktiviert? –

+0

Wenn Sie Ihr base64-Bild anstelle des img-Tags in die CSS-Klasse einfügen, ist es blitzschnell und Sie steuern den Cache und den Lebenszyklus. –