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?

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.

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…

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

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.

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