Leeres Bild. Was zu verwenden: Base64 vs 1x1 JPEG-Bild


11

Ich erstelle eine Website und möchte so wenig HTTP-Abfragen wie möglich durchführen, um die Geschwindigkeit und das SEO der Website zu verbessern. Die Seite, die ich gerade erstellt habe, zeigt Bilder beim Scrollen (Bilder haben ein Attribut data-scr, das in src konvertiert wird, wenn der Benutzer zum jeweiligen Bild nach unten scrollt).

Da alle Bilder das data-srcAttribut anstelle von haben src, zeigt W3C mir Fehler an.

In diesem Moment habe ich zwei Möglichkeiten gefunden, um dieses Problem zu lösen:

  1. Die anfängliche src aller Bilder ist eine URL eines leeren 1x1-Bildes
  2. Die anfängliche src aller Bilder soll ein leeres Datenbankbild 64 sein

Wenn ich eine URL eines leeren 1x1-Bildes verwende, wird (getestet mit tools.pingdom.com) 1 HTTP-Anforderung angezeigt. Wenn ich ein leeres Datenbank-64-Bild verwende, werden so viele Anforderungen angezeigt wie die Anzahl der Bilder auf der Seite.

Welcher von ihnen ist der effizientere Weg, um eine Website schneller zu machen und weniger HTTP-Anfragen zu stellen? (Nehmen wir an, der Benutzer lädt die Webseite mit einer Internetgeschwindigkeit von 14,4 kbit / s - erste Internetgeschwindigkeit).

Aber für SEO?

Gibt es eine andere Option?


8
"Wenn ich ein leeres Datenbankbild 64 verwende, werden so viele Anforderungen angezeigt wie die Anzahl der Bilder auf der Seite." - Da stimmt etwas nicht? Der springende Punkt bei der Verwendung eines Daten-URI ist, dass keine externe HTTP-Anforderung vorhanden ist. (Nur Benutzeragenten, die Daten-URIs nicht verstehen, können eine HTTP-Anfrage
auslösen

Wenn das leere Bild größer als 1x1 px ist (ich denke es ist), würde ich ein größeres Hintergrundbild (10x10 px, 100x100 px) empfehlen, da das Rendern schneller ist .
Totymedli

3
Keine verwenden? Sie können das img-Tag dynamisch erstellen, während Sie data-src in src konvertieren. Anstatt ein leeres Bild mit einem Daten-src zu haben, können Sie die Liste der Bilder speichern und das Tag bei Bedarf generieren.
the_lotus

@Pharap funktioniert nicht, da der Browser die Bilder herunterlädt, auch wenn sie ausgeblendet sind.
DisgruntledGoat

Unabhängig davon, was Sie für die Bereitstellung des Inhalts auswählen, ist die Codierung als PNG8 wahrscheinlich schneller als JPEG.
Symcbean

Antworten:


12

Die base64-Image-Option sollte verwendet werden, wenn Sie nur eine sehr kleine Anzahl von Images haben und den Netzwerk-Overhead beim Abrufen eines Bildes vom Server vermeiden möchten. Nach dem, was Sie in der Frage angeben, kann dies jedoch auf eine große Anzahl von Bildern skaliert werden. In diesem Fall würde ich ein einzelnes transparentes 1px x 1px-Image vom Server mit einer langen Cache-Lebensdauer verwenden, da es einmal vom Server abgerufen und dann im Browser und auf allen Zwischenproxyservern zwischengespeichert wird.

Als Beispiel wäre dieses Bild ungefähr 95 Byte groß ( https://commons.wikimedia.org/wiki/File:1x1.png ). Bei einer Base64-codierten Bildzeichenfolge würde die Größe diesem Bild entsprechen Dateigröße, wird jedoch für jedes einzelne Bild wiederholt, zu dem Sie es hinzufügen.

Bei 2-5 Bildern wären Größe und Geschwindigkeit vernachlässigbar und würden den Serververkehr verringern, indem ein ganzer Abruf eliminiert würde. Bei mehr als dem würde die Seitengröße jedoch zu groß werden, was sich auf die Ladezeiten und damit auf das SEO-Ranking auswirken würde.


6
Ein leeres base64-Image kann 55 Bytes haben : data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA=. Wenn die URL des Bildes etwas länger ist (Beispiel: example.com/templates/template-name/files/1x1.png ), wird das base64-Bild empfohlen, da Sie keine HTTP-Abfragen durchführen und es in Bytes kleiner ist als Bild-URL (wiederholt für jedes Bild auf der Seite) + die externe Bildgröße.
NETCreator Hosting

@ NETCreatorHosting-WebDesign Vielen Dank für Ihren Kommentar. Ich habe die Website-Größe bei Verwendung eines Base64-Images und eines externen Images verglichen, und die Größe ist bei Verwendung eines Base64-Images kleiner. Ich verwende ungefähr 40 Bilder pro Seite.
MM PP

Oder Sie können das Bild in das Stammverzeichnis Ihrer Website hochladen und eine relative URL verwenden, damit die Website viel kleiner wird.
NETCreator Hosting

3
gzip kümmert sich um die Wiederholungen, sodass 400 Base-64-codierte Bilder auf Ihrer Seite nicht mehr Bandbreite kosten als 400 URLs von Bildern.
user2428118

3
@Aron Wenn Ihre Seite 25,6 MB groß ist (400 82-Byte lange Daten-URIs mit 64 KB dazwischen = 25.568.800 Byte), müssen Sie sich größere Sorgen machen als 32,8 kB Base64-codierte Bilder.
user2428118

5

Gehen Sie auf jeden Fall mit dem Daten-URI, es sei denn, Sie benötigen Unterstützung für IE <8. ( Browser-Unterstützung .)

Das Einbetten vieler kleiner Bilder direkt in den HTML-Code sieht möglicherweise so aus, als würde es mehr Bandbreite beanspruchen als das direkte Verknüpfen mit ihnen, aber der Anstieg wird durch gzip verringert . Der einzige Unterschied in der Seitengröße ergibt sich aus dem Längenunterschied zwischen einem Daten-URI eines leeren Bildes und einer URL des Bildes auf Ihrem Server. Ein leeres GIF kann bis zu 43 Byte groß sein. Basis 64-codiert, das sind 82 Bytes. Es gibt keine Möglichkeit, die jemals schlechter abschneidet als eine HTTP-Anforderung von> 500 Byte , eine Antwort ähnlicher Größe, und dann berücksichtige ich nicht einmal die TCP-Paketgröße und anderen Overhead.

Hier ist das Base 64-codierte 43-Byte-GIF-Bild:

data:image/gif;base64,R0lGODlhAQABAIAAAP///////yH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==

Schauen Sie sich bei der Suchmaschinenoptimierung den Quellcode einer Google-Website an, z. B. Google News , und suchen Sie nach data:image/gif,base64


Ihr Bild ist groß. Überprüfen Sie den obigen Kommentar für die 55-Byte-Version.
Joshua

1
Diese Antwort auf StackOverflow mit gemeldeten Tests (Mai 2014) scheint zu zeigen, dass das Einbetten einer großen Anzahl (~ 1800) von 1px-Bildern erheblich langsamer ist als das wiederholte Verknüpfen mit demselben externen Bild. Das externe Bild wird einmal angefordert und zwischengespeichert, während der Browser jeden Daten-URI im Rahmen des HTML-Parsing-Prozesses separat dekodieren muss - dies scheint der Engpass zu sein. Dies scheint darauf hinzudeuten, dass Daten-URIs auf eine kleine Anzahl von (kleinen) Bildern beschränkt sein sollten.
DocRoot

@Joshua Obwohl dieses Bild in meinem Browser (Firefox) korrekt angezeigt wird, kann es von einigen anderen Programmen (z. B. Paint) nicht geöffnet werden, sodass ich es nicht verwenden würde.
user2428118

2

In diesem Moment habe ich zwei Möglichkeiten gefunden, um dieses Problem zu lösen: Der anfängliche Quellcode aller Bilder ist ein leeres Datenbankbild 64

Diese Option erfordert nicht nur einen modernen Browser, sondern kann auch auf der Clientseite langsamer sein, da der Browser die Bilddaten auf Basis von 64 dekodieren muss, um das Bild zu erzeugen.

Die anfängliche src aller Bilder ist eine URL eines leeren 1x1-Bildes

Es ist in Ordnung, vorausgesetzt, die leere Bild-URL für alle Bild-Slots ist genau dieselbe URL und hat eine lange Cache-Lebensdauer, die im HTTP-Header "Cache-Control" definiert ist. Das Problem dabei ist, dass beim Laden der neuen Bilddateien die Bildquadrate auf die neue Größe springen, was die Benutzererfahrung möglicherweise nicht so wunderbar macht.

Die fast perfekte Idee ist diese ...

Zeigen Sie beim Start der Seite ein Raster mit Feldern fester Größe an, in denen jedes Bild untergebracht werden kann. Es ist in Ordnung, wenn nicht das gesamte Raster auf den Bildschirm passt. Erstellen Sie dann Javascript, das nach dem Laden des HTML-Codes ausgeführt wird, und erstellen Sie in diesem Javascript ein neues Bildelement, hängen Sie es an jede Zelle des Rasters an und setzen Sie die Quelle des Bildes auf die richtige Bilddatei. Tun Sie dies, bis der erste Bildschirm voll ist. Erkennen Sie dann das Scrollen in Javascript und wiederholen Sie beim Scrollen den obigen Vorgang für die neuen Zellen.

Wenn Sie nun das Beste vom Besten wollen und die Qualität kein großes Problem darstellt, empfehle ich (das ich auch auf meiner Website implementiert habe), ein Raster zu erstellen und es so einzustellen, dass das Hintergrundbild dieses Rasters a ist Sprite-Blatt aller Bilder, die als Bildquadrate formatiert sind. Diese Methode ist flexibel und schnell zu laden, da für alle Bilder eine Anforderung erforderlich ist.

Hier ist eine HTML-Vorlage, die Sie verwenden können, wenn Sie den schnellen Weg gehen möchten. Es werden nur zwei Anfragen gestellt. Der HTML-Code und das eine Bild. In diesem Code gehe ich davon aus, dass jedes Bild auf dem Blatt 100 Pixel breit und 200 Pixel hoch ist und dass jedes Bild ohne Lücken perfekt nebeneinander ausgerichtet ist.

<html>
<head>
<style type="text/css">
#imagegrid {background-color: black; background-image:url('http://example.com/url/to/imagesheet.jpg');}
A {display:block;width:100px;height:200px;margin:10px;float:left;}
#image1{background-position: 0px 0px}
#image2{background-position: 100px 0px}
#image3{background-position: 200px 0px}
...
#imageN{background-position: XXXpx 0px}
</style>
</head>
<body>
<div id="imagegrid">
<a href="image_one.htm" id="image1"></a>
<a href="image_two.htm" id="image2"></a>
<a href="image_three.htm" id="image3"></a>
...
<a href="image_N.htm" id="imageN"></a>
</div>
</body>
</html>

In meinem Code habe ich 3 Punkte hinzugefügt. Das bedeutet, dass Sie weiterhin Bilder hinzufügen können, indem Sie die Zahlen erhöhen und die Position jedes Mal um 100 erhöhen, vorausgesetzt, Ihr Sprite-Blatt enthält nur eine Bildreihe. Bei einigen Browsern wie Opera müssen Sie möglicherweise ein negatives Vorzeichen vor den Hintergrundpositionswerten einfügen, damit sie funktionieren.


2
Wenn Ihre Bilder nicht ein halbes Gigabyte groß sind, hat die Base64-Dekodierung eines Bildes keine messbaren Auswirkungen auf die Leistung.
user2428118

Es hängt auch vom Computersystem ab. Wenn der Client immer noch über einen altmodischen Computer wie Pentium 1 verfügt, kann dies zu Leistungseinbußen führen.
Mike

1

Das Bild, weil Wartbarkeit.

In meinem Erfahrung funktioniert es besser, das Bild zu verwenden. Dies ist im eigentlichen Code offensichtlicher und leichter zu merken. Ich bezweifle, dass Sie sich an die codierte Zeichenfolge für ein transparentes Bild erinnern werden, und selbst wenn Sie dies tun, an Ihre Nachfolger / Kollegen.
Wenn Sie nach einigen Wochen zu diesem Code zurückkehren, haben Sie die base64 vergessen.

Es wird viel einfacher sein, den Code zu pflegen, wenn Sie das Bild verwenden. Die minimalen Profis belasten dies nicht.


Viele Leute verwenden Skripte, um Basis-64-Werte zu generieren. Daher ist es nicht erforderlich, sich solche Werte zu merken, es sei denn, das OP verwendet nur eine Reihe von HTML-Dateien, um den Code seiner Website darzustellen.
Mike

1

Wie wäre es mit nur ~ 3 zusätzlichen Bytes, 0 zusätzlichen http-Anforderungen und 0 zusätzlichen img src-Längen (oder 0 nicht zwischengespeicherten Datenbild-Platzhaltern). Können Sie eine leere Quelle für das Bild verwenden?

<img src data-src="banannanannas.jpg" />

Und wenn sie altTags haben, können Sie diese vor dem Fehler- / Fehlerbild verbergen:

<img src data-src="banannanannas.jpg" onerror="this.alt=''" alt="some desc" />

Anzeigen: nichts. Das Abhacken des Alt-Tags hat eine leichte FOUC-Verzögerung vom Bildplatzhalterrand. Vielleicht kann das auch weggeräumt werden.


2
Obwohl ein leeres srcAttribut immer noch Fehler im W3C-Validator auslöst (was das Problem zu sein scheint).
MrWhite

@ w3dk Ja das ist scheiße, aber andererseits vergehen nur sehr wenige Modernisierungen.
Dhaupin

Wenn Sie W3C-Regeln übergeben möchten, muss für den src etwas angegeben werden, auch wenn es sich um eine URL handelt, die einen 404-Fehler zurückgibt. Ich würde auch empfehlen, die Werte der Attribute width und height für das Bild anzugeben, damit Benutzer zunächst die tatsächlichen Platzhalter sehen, anstatt winzige Kästchen, die sich nach der Hälfte des Ladevorgangs aufblasen.
Mike
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.