it-swarm.com.de

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

Ich erstelle eine Website und möchte HTTP-Abfragen so gering wie möglich halten, um die Geschwindigkeit und den 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 beim jeweiligen Bild nach unten scrollt).

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

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

  1. Die anfängliche Quelle aller Bilder ist eine URL eines leeren 1x1-Bildes
  2. Die anfängliche Quelle aller Bilder ist ein leeres Bild der Datenbank 64

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

Welche davon ist die effizientere Methode, 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 noch eine andere Möglichkeit?

11
MM PP

Die base64-Image-Option sollte verwendet werden, wenn Sie nur eine sehr geringe 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, gehe ich jedoch davon aus, dass dies auf eine große Anzahl von Bildern skaliert werden könnte. In diesem Fall würde ich ein einzelnes transparentes 1px x 1px-Bild vom Server mit einer langen Cache-Lebensdauer verwenden, da es einmal vom Server abgerufen und dann im Browser und zwischengeschalteten Proxyservern zwischengespeichert wird.

Als Beispiel würde dieses Bild eine Größe von ungefähr 95 Bytes haben ( https://commons.wikimedia.org/wiki/File:1x1.png ), für eine Base64-codierte Bildzeichenfolge würden Sie die Größe finden Dies entspricht der Dateigröße des Bildes, wird jedoch für jedes einzelne Bild wiederholt, zu dem Sie es hinzufügen.

Für 2-5 Bilder wären die 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 zu groß werden, was die Ladezeiten und damit das SEO-Ranking beeinträchtigen würde.

12

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

Das Einbetten vieler winziger Bilder direkt in den HTML-Code scheint mehr Bandbreite in Anspruch zu nehmen als das direkte Verknüpfen. Die Erhöhung wird jedoch durch gzip ; Der einzige Unterschied in der Seitengröße ergibt sich aus dem Längenunterschied zwischen einer Daten-URI eines leeren Bildes und eine URL des Bildes auf Ihrem Server. Ein leeres GIF kann bis zu 43 Byte groß sein. Base 64-codiert, das sind 82 Bytes. Es gibt keine Möglichkeit, die jemals schlechter abschneiden wird als eine > 500-Byte-HTTP-Anforderung , eine Antwort mit ähnlicher Größe, und dann nehme ich nicht einmal die Paketgröße TCP und andere Gemeinkosten in Rechnung.

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

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

Schauen Sie sich für SEO den Quellcode einer Google-Website an, zum Beispiel Google News , und suchen Sie nach data:image/gif,base64

5
user2428118

In diesem Moment habe ich zwei Möglichkeiten gefunden, um dieses Problem zu lösen: Die anfängliche Quelle aller Bilder ist ein leeres Datenbank-64-Bild

Diese Option erfordert nicht nur einen modernen Browser, sondern kann auf Client-Seite auch langsamer sein, da der Browser die Bilddaten mit Base-64-Decodierung dekodieren muss, um das Bild zu erstellen.

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

Es ist ein O.K. move, vorausgesetzt, die leere Bild-URL für alle Bild-Slots ist genau dieselbe URL und die im HTTP-Header "cache-control" festgelegte Cache-Lebensdauer ist lang. Das Problem dabei ist, dass die Bildquadrate beim Laden der neuen Bilddateien auf die neue Größe springen, was die Benutzererfahrung möglicherweise nicht so wunderbar macht.

Die fast perfekte Idee ist, dass ...

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

Wenn Sie das Beste vom Besten wollen und Qualität kein großes Problem ist, empfehle ich (das ich auch auf meiner Site implementiert habe), ein Raster zu erstellen und es so einzustellen, dass das Hintergrundbild dieses Rasters a ist Sprite-Blatt aller Bilder, die als Quadrate von Bildern 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 die Hintergrundpositionswerte setzen, damit sie funktionieren.

2
Mike

Das Image, 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 base64 vergessen.

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

1
Martijn

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 Platzhaltern für Datenbilder). Können Sie eine leere Quelle für das Bild verwenden?

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

Und wenn sie alt Tags haben, können Sie diese vor error/fail image verbergen:

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

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

1
dhaupin