Image vierge. Quoi utiliser: Image JPEG Base64 vs 1x1


11

Je suis en train de créer un site Web et je veux faire le moins de requêtes HTTP possible pour une meilleure vitesse et référencement du site Web. La page que je viens de créer montre des images sur défilement (les images ont un attribut data-scr qui est converti en src lorsque l'utilisateur fait défiler vers le bas sur l'image respective).

Parce que toutes les images ont l' data-srcattribut au lieu de src, W3C me montre des erreurs.

À ce moment, j'ai trouvé deux options, pour résoudre ce problème:

  1. Le src initial de toutes les images doit être l'url d'une image vierge 1x1
  2. Le src initial de toutes les images doit être une image vierge de la base de données 64

Lorsque j'utilise l'URL d'une image vierge 1x1, puis (testé avec tools.pingdom.com), il affiche 1 requête HTTP. Lorsque j'utilise une image vierge de la base de données64, elle affiche autant de demandes que le nombre d'images sur la page.

Lequel est le moyen le plus efficace, pour un site Web plus rapide et qui fait moins de requêtes HTTP? (supposons que l'utilisateur charge la page Web à une vitesse Internet de 14,4 kbps - première vitesse Internet).

Mais pour le référencement?

Y a-t-il une autre option?


8
"Lorsque j'utilise une image vierge de la base de données 64, elle affiche autant de demandes que le nombre d'images sur la page." - il y a quelque chose qui cloche? L'intérêt de l'utilisation d'un URI de données est qu'il n'y a pas de requête HTTP externe. (Seuls les agents utilisateurs qui ne comprennent pas les URI de données peuvent déclencher une requête HTTP.)
MrWhite

Si l'image vierge sera plus grande que 1x1 px (je suppose que c'est le cas), je recommanderais une image d'arrière-plan plus grande (10x10 px, 100x100 px) car le rendu sera plus rapide .
totymedli

3
N'en utiliser aucun? Vous pouvez créer dynamiquement la balise img en même temps que vous convertissez data-src en src. Au lieu d'avoir une image vierge avec un data-src, vous pouvez stocker la liste des images et générer la balise en cas de besoin.
the_lotus

@Pharap qui ne fonctionne pas car le navigateur téléchargera les images même si elles sont cachées.
DisgruntledGoat

Quel que soit le mode de livraison que vous choisissez, le codage au format png8 sera probablement plus rapide que JPEG.
symcbean

Réponses:


12

L'option d'image base64 doit être utilisée lorsque vous ne disposez que d'un très petit nombre d'images et que vous souhaitez éliminer la surcharge réseau liée à la récupération d'une image à partir du serveur. Cependant, d'après ce que vous indiquez dans la question, je suppose que cela pourrait évoluer vers un grand nombre d'images. Dans ce cas, j'utiliserais une seule image transparente 1px x 1px du serveur avec une longue durée de vie du cache car elle sera récupérée une fois sur le serveur puis mise en cache dans le navigateur et tous les serveurs proxy intermédiaires.

À titre d'exemple cette image serait d'environ 95 octets ( https://commons.wikimedia.org/wiki/File:1x1.png ), pour une chaîne d'image codée base64 vous trouveriez la taille serait à la hauteur de cette image mais serait répété pour chaque image à laquelle vous l'ajoutez.

Pour 2 à 5 images, la taille et la vitesse seraient négligeables et réduiraient le trafic du serveur en éliminant une extraction complète, mais pour plus que cela, la taille de la page commencerait à devenir trop grande, ce qui affecterait les temps de chargement et à son tour le classement SEO.


6
Une image vierge base64 pourrait avoir 55 octets: data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA=. Si l'URL de l'image est un peu plus longue (ex: example.com/templates/template-name/files/1x1.png ), l'image base64 sera recommandée , car vous ne faites pas les requêtes HTTP et il est plus petit en octets que l'URL de l'image (répétée pour chaque image de la page) + la taille de l'image externe.
Hébergement NETCreator du

@ NETCreatorHosting-WebDesign Merci pour votre commentaire. J'ai comparé la taille du site Web lors de l'utilisation d'une image base64 et d'une image externe, et la taille est plus petite lors de l'utilisation d'une image base64. J'utilise environ 40 images par page.
MM PP

Ou vous pouvez télécharger l'image sur la racine de votre site Web et utiliser une URL relative, de sorte que le site Web sera beaucoup plus petit.
Hébergement NETCreator du

3
gzip s'occupe des répétitions, donc avoir 400 images encodées en base 64 dans votre page ne coûtera pas plus de bande passante que 400 URL d'images.
user2428118

3
@Aron Si votre page fait 25,6 Mo (400 URI de données longues de 82 octets avec 64 Ko entre eux = 25 568 800 octets), vous avez de plus gros problèmes à vous soucier de plus de 32,8 Ko d'images encodées en base64.
user2428118

5

Allez-y avec l'URI de données, sauf si vous avez besoin de prise en charge pour IE <8. ( Prise en charge du navigateur .)

L'incorporation de nombreuses petites images directement dans le code HTML peut sembler occuper plus de bande passante que la liaison directe avec celles-ci, mais l'augmentation sera atténuée par gzip ; la seule différence dans la taille de la page proviendra de la différence de longueur entre un URI de données d'une image vierge et une URL de l'image sur votre serveur. Un GIF vierge peut être aussi petit que 43 octets. Encodé en base 64, soit 82 octets. Il n'y a aucun moyen qui puisse être pire qu'une demande HTTP> 500 octets , une réponse de taille similaire, et je ne prends même pas en compte la taille des paquets TCP et les autres frais généraux.

Voici l'image GIF de 43 octets encodée en Base 64:

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

En ce qui concerne le référencement, consultez le code source d'un site Google, par exemple Google Actualités , et recherchez data:image/gif,base64


Votre image est grande. Vérifiez le commentaire ci-dessus pour la version 55 octets.
Joshua

1
Cette réponse sur StackOverflow avec les tests signalés (mai 2014) semble montrer que l'incorporation d'un grand nombre (~ 1800) d'images 1px est considérablement plus lente que la liaison répétée à la même image externe. L'image externe est demandée une fois et mise en cache, tandis que le navigateur doit décoder chaque URI de données séparément dans le cadre du processus d'analyse HTML - cela semble être le goulot d'étranglement. Cela semble suggérer que les URI de données devraient être limités à un petit nombre d'images (petites).
DocRoot

@Joshua Bien que cette image s'affiche correctement dans mon navigateur (Firefox), elle ne peut pas être ouverte par d'autres programmes (par exemple Paint), donc j'éviterais de l'utiliser.
user2428118

2

À ce moment, j'ai trouvé deux options, pour résoudre ce problème: Le src initial de toutes les images doit être une image vierge de la base de données 64

Cette option nécessite non seulement un navigateur moderne, mais elle peut être plus lente du côté client car le navigateur doit décoder en base 64 les données d'image afin de produire l'image.

Le src initial de toutes les images doit être l'url d'une image vierge 1x1

C'est une décision correcte à condition que l'URL d'image vide pour tous les emplacements d'image soit exactement la même URL et qu'elle ait une longue durée de vie de cache définie dans l'en-tête HTTP "cache-control". Le problème avec cela est que lorsque les nouveaux fichiers d'image se chargent, les carrés d'image sautent à la nouvelle taille, ce qui pourrait rendre l'expérience utilisateur moins merveilleuse.

L'idée presque parfaite est la suivante ...

Au démarrage de la page, présentez une grille avec des cases de taille fixe pouvant accueillir chaque image. C'est correct si la grille entière ne tient pas sur l'écran. Créez ensuite du javascript qui s'exécute après le chargement du HTML, et dans ce javascript, créez un nouvel élément d'image et attachez-le à chaque cellule de la grille, puis définissez la source de l'image dans le fichier image correct. Faites-le jusqu'à ce que le premier écran se remplisse. puis détectez le défilement dans javascript, puis lorsque le défilement se produit, répétez le processus ci-dessus pour les nouvelles cellules.

Maintenant, si vous voulez le meilleur des meilleurs et que la qualité n'est pas une préoccupation majeure, alors ce que je recommande (que j'ai également implémenté sur mon site) est de construire une grille et de la définir de telle sorte que l'image d'arrière-plan de cette grille soit un feuille de sprite de toutes les images formatées en carrés d'images. Cette méthode est flexible et rapide à charger car une seule demande est requise pour toutes les images.

Voici un modèle HTML à utiliser si vous souhaitez suivre la voie rapide. Deux demandes seulement sont faites. Le code HTML et l'image unique. Dans ce code, je suppose que chaque image de la feuille a une largeur de 100 pixels et une hauteur de 200 pixels et que chaque image est parfaitement alignée l'une à côté de l'autre sans aucun espace.

<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>

Dans mon code, j'ai ajouté 3 points. Cela signifie que vous pouvez continuer à ajouter des images en incrémentant les nombres et en incrémentant la position de 100 à chaque fois à condition que votre feuille de sprite ne comporte qu'une seule ligne d'images. En outre, avec certains navigateurs tels que Opera, vous devrez peut-être ajouter un signe négatif devant les valeurs de position d'arrière-plan pour les faire fonctionner.


2
À moins que vos images ne mesurent un demi-gigaoctet, il est impossible que le décodage en base64 d'une image ait un impact mesurable sur les performances.
user2428118

Cela dépend aussi du système informatique. Si le client possède toujours un ordinateur à l'ancienne comme un pentium 1, il peut y avoir un problème de performances.
Mike

1

L'image, parce que la maintenabilité.

D'après mon expérience, il est préférable d'utiliser l'image. Ceci est plus évident dans le code réel et plus facile à retenir. Je doute que vous vous souveniez de la chaîne codée pour une image transparente, et même si vous le faites, de vos successeurs / collégas.
Si vous revenez à ce code après quelques semaines, vous avez oublié le base64.

Ce sera beaucoup plus simple de maintenir le code si vous utilisez l'image, les pros minimaux ne pèsent pas autant.


Beaucoup de gens utilisent des scripts pour générer des valeurs en base 64, donc l'exigence de se souvenir de ces valeurs est hors de la fenêtre à moins que l'OP n'utilise un ensemble de fichiers HTML pour représenter le code de son site Web.
Mike

1

Que diriez-vous de seulement ~ 3 octets supplémentaires, 0 demande http supplémentaire et 0 longueur src img supplémentaire (ou 0 espace réservé d'image de données non mis en cache). Pouvez-vous utiliser un src vierge pour l'image?

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

Et s'ils ont des altbalises, vous pouvez les cacher de l'image d'erreur / d'échec:

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

Affiche: rien. Le piratage de la balise alt a un léger retard FOUC à partir de la bordure de l'espace réservé à l'image. Peut-être que cela peut aussi être nettoyé.


2
Bien qu'un srcattribut vide génère toujours des erreurs dans le validateur W3C (ce qui semble être le problème).
MrWhite

@ w3dk Ouais ça craint, mais là encore très peu de modernisations passent.
dhaupin

Si vous voulez passer des règles W3C, quelque chose doit être spécifié pour le src, même si c'est une URL qui renvoie une erreur 404. Je recommanderais également de spécifier les valeurs des attributs de largeur et de hauteur pour l'image afin que les utilisateurs voient d'abord les espaces réservés réels au lieu de minuscules boîtes qui se gonflent à mi-chemin du processus de chargement.
Mike
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.