Image vide. Quoi utiliser: image JPEG Base64 vs 1x1
Je construis un site Web et je veux faire le moins de requêtes HTTP possible pour une meilleure vitesse et un meilleur référencement. 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 à l'image respective).
Comme toutes les images ont l'attribut data-src au lieu de src, le W3C m'affiche des erreurs.
A ce moment, j'ai trouvé deux options pour résoudre ce problème:
- Le src initial de toutes les images doit être l'URL d'une image vierge 1x1
- 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 1x1 vierge, puis (testé avec tools.pingdom.com), il affiche une requête HTTP. Lorsque j'utilise une image vierge base64 de données, elle affiche autant de demandes que le nombre d'images sur la page.
Lequel d'entre eux est le moyen le plus efficace, pour un site Web plus rapide et faisant moins de requêtes HTTP? (supposons que l'utilisateur charge la page Web à une vitesse de 14,4 kbps - la première vitesse de transmission sur Internet).
mais pour le référencement?
Y a-t-il une autre option?
L'option 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 du réseau liée à l'extraction d'une image du serveur. Cependant, d'après ce que vous indiquez dans la question, je suppose que cela pourrait être étendu à un grand nombre d'images. Dans ce cas, j'utiliserais une seule image transparente de 1 x x 1 x xpx du serveur avec une longue durée de vie du cache, car elle serait extraite du serveur une fois puis mise en cache dans le navigateur et tous les serveurs proxy intermédiaires.
Par exemple, cette image aurait une taille d'environ 95 octets ( https://commons.wikimedia.org/wiki/File:1x1.png ), pour une chaîne d'image codée en base64, vous trouveriez la taille serait à égalité avec cette taille de fichier d'image, mais serait répété pour chaque image unique que vous ajoutez à.
Pour 2 à 5 images, la taille et la vitesse seraient négligeables et réduiraient le trafic du serveur en éliminant une extraction totale, mais dans le cas contraire, la taille de la page commencerait à devenir trop grande, ce qui aurait une incidence sur les temps de chargement et le classement SEO.
Allez définitivement avec l'URI des données, sauf si vous avez besoin de la prise en charge de IE <8. ( prise en charge du navigateur .)
L’incorporation directe de nombreuses images minuscules directement dans le code HTML peut donner l’impression que cela prendra plus de bande passante que de les lier directement, 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 une URI de données d'une image vide et une URL de l'image sur votre serveur. Un GIF vierge peut être aussi petit que 43 octets. Base codée en 64, soit 82 octets. Il n’ya aucun moyen que cela produise des résultats pires qu’une requête HTTP> 500 octets , une réponse de la même taille, mais je ne prends même pas TCP taille du paquet et autres frais généraux en compte.
Voici l'image GIF de 43 octets codé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 News , et recherchez data:image/gif,base64…
A 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 aussi être plus lente côté client car le navigateur doit décoder en base 64 les données de l’image pour produire l’image.
Le src initial de toutes les images doit être l'URL d'une image vierge 1x1
C'est un O.K. déplacez-vous à condition que l'URL d'image vide pour tous les emplacements d'image soit exactement la même URL et que sa durée de vie de cache soit longue, définie dans l'en-tête HTTP "cache-control". Le problème, c’est que lors du chargement des nouveaux fichiers image, les carrés d’image passeront à la nouvelle taille, ce qui rendrait l’expérience utilisateur moins agréable.
L'idée presque parfaite est la suivante ...
Lorsque la page démarre, présentez une grille avec des boîtes de taille fixe pouvant accueillir chaque image. Ce n'est pas grave si la grille entière ne tient pas sur l'écran. Créez ensuite un code javascript qui s'exécute après le chargement du code HTML. Dans ce code javascript, créez un nouvel élément image et associez-le à chaque cellule de la grille, puis définissez la source de l'image sur le fichier image approprié. Faites-le jusqu'à ce que le premier écran se remplisse. puis détectez le défilement dans javascript, puis répétez la procédure ci-dessus pour les nouvelles cellules.
Maintenant, si vous voulez ce qu'il y a de mieux, et que la qualité n'est pas une préoccupation majeure, ce que je recommande (que j'ai également implémenté sur mon site) est de construire une grille et de la définir de sorte que l'image d'arrière-plan de cette grille soit un. Feuille de sprite de toutes les images au format carrés. 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 emprunter la voie rapide. Seules deux demandes 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 les unes à côté des autres, sans 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 augmentant la position de 100 à chaque fois, à condition que votre feuille Sprite ne comporte qu'une rangée d'images. De plus, avec certains navigateurs tels qu'Opera, vous devrez peut-être ajouter un signe négatif devant les valeurs de position de l’arrière-plan pour les faire fonctionner.
L'image, car maintenabilité.
Dans mon expérience cela fonctionne mieux d'utiliser l'image. Ceci est plus évident dans le code actuel et plus facile à retenir. Je doute que vous vous souveniez de la chaîne encodée pour une image transparente, et même si vous le faites, de vos successeurs/collègues.
Si vous revenez à ce code après quelques semaines, vous avez oublié la base64.
Il sera beaucoup plus simple de maintenir le code si vous utilisez l’image, les professionnels les plus modestes n’ayant pas cette pondération.
Que diriez-vous de seulement ~ 3 octets supplémentaires, 0 demande http supplémentaire et 0 longueur supplémentaire d'img src (ou 0 espaces réservés 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 balises alt, vous pouvez les masquer de l’image erreur/échec:
<img src data-src="banannanannas.jpg" onerror="this.alt=''" alt="some desc" />
Affiche: rien. Le piratage de la balise alto a un léger retard de FOUC par rapport à la bordure d'espace réservé pour l'image. Peut-être que cela peut être nettoyé aussi.