Ce qui donne 4734 caractère juste pour une image !?
Et il y en aurais entre 30 et 40 sur ma page.
>> Etant en local, je ne peux tester l'intérêt niveau performances entre chargement de la page HTML (poids alourdi avec base64) et les requête http au serveur pour charger les images.
Reste l'idée d'un sprite qui regroupe le tout, mais certaines images ont une sémantique, donc besoins d'une balise <img + le alt)
Ais-je bien comprise, ou alors je me trompe, sachant que depuis un mobile certains sont toujours en 3G vu la couverture médiocre actuelle.
Merci à vous pour vos lumières et expérience
ps: prochain sujet : Utilité et bonne pratique avec srcset pour que le navigateur face le choix + problème de ratio 2 sur Rétina (Iphone 5 par exemple)
- Edité par pipelette13 28 octobre 2018 à 21:05:29
Pour tester l’efficacité tu as le Benchmark apache sous Windows qui permet de faire x requête(s) et même en local et ensuite ça te renvoi des stats, il suffit donc de le faire avec tes images en png et ensuite en base64 et tu verras la différence
Je l'avais fait pour nodeJS, voici un tuto que je trouve plutôt bien fait : http://naholyr.fr/2011/06/benchmark-node-js-methodes-synchrones-ou-asynchrones/
Oui j'ai bien comprise pour les requêtes, sauf q'un icône représente dans mon exemple 4734 caractères de texte dans mon HTML, donc multiplié par 20 ou 30 icônes ? mon fichier HTML va passer de centaines de lignes à + de 1000 lignes, donc le rapport bénéfice avec un requête serveur ?
Pour optimiser je peux placer la base64 dans une class CSS en effet, mais j'alourdi la aussi ma feuille css.
Il y a un package sous Gulp pour la conversion, sinon reste la technique du sprite css (toujours sous Gulp)
Arf dilemme.....
Pickles: tu avais testé le bench entre png et base64, si oui quelle était ta conclusion ?
merci pour ton tuto qui est clair
--->
J'ai consultée pas mal de site en tout genre (amateur et pro comme le monde, etc...) et je trouve très peu de base64, j'ai l'impression que c'est utile pour un stockage en BDD par contre.
- Edité par pipelette13 29 octobre 2018 à 11:33:36
les base 64 je les utilise surtout quand je fais de la doc, c'est plus simple à passer aux gens, aucun problème de compatibilité, de fichier manquant ou autre ^^. et pour la taille ça rallonge pas tant que ça le doucement, car tu remplace une image par son contenu donc ça ce vaux (à un ration+33% quand même).
Autre inconvénient du base64 ici : ça ne se met pas en cache (sauf si tu mets ton HTML en cache).
Cette technique est conseillée si tu as de petites images et en petit nombre.
> J'étais parties sur un sprite, mais en cas d'évolution il faut revoir le code à chaque fois.
Bin si tu génères ton sprite, pas besoin de revoir le code, si ? Perso quand je le peux j'utilise un plugin Grunt ou Gulp qui va chercher les icônes dans un dossier et fabrique le sprite tout seul. Si tu mets un nouveau fichier dans le dossier, il suffit de relancer la tâche associée, et paf.
Pas d'aide concernant le code par MP, le forum est là pour ça :)
Mes images sont en 32*32, et visiblement c'est déjà trop lourd en base 64, tu as raisons. j'ai consultée le code source de pas mal de sites, et à part la page d'accueil de Google, les icônes en base 64 se font rares.
Oui j'utilise Gulp pour générer mon image sprite, mais si rajoutes des images dans mon dossier à piper(), j'ai peur que l'ordre des images change.
Il va les prendre suivant l'extension et ordre alphabétique, ou la solution serait de les renommer (img-1,2 3, etc...) pour conserver l'ordre originel.
Aucun impact pour des images dans le css si j'utilise des class, sauf si je boucle avec un @foreach sous Sass
ps: J'utilise aussi le package "compress-images" pour choisir le taux de compression...
----
Mais pour images sémantiques <img> en HTML + le alt="desc" , la j'hésitais entre le png et l'encodage 64. Je pense donc rester sur du traditionnel, soit en .png avec un scrset suivant le viewport ( l'émulation sur iphone 5 donne une catastrophe )
- Edité par pipelette13 29 octobre 2018 à 15:22:51
Bon j'ai relue 4 fois et pas tout comprise, le côté réseau n'est pas mon fort...
Vu que le protocole n'est pas encore officiel et standardisé comme http/1, côté serveur il faut un dédié pour configurer via Node+ Express.
Sauf que moi je serais en mutualisé, donc cela dépend de mon hébergeur, donc pas de version 2. Mais vivement que ce soit le standard du web.
Je vais donc faire ainsi (faut bien trancher) :
- icônes sémantiques en png (balise <img>)
- les autres via mon scss (.class), image sprite générée et compressée avec Gulp.
je vais quand même regarder du côté du format SVG pour les tout petites icones.
ps: avec ton lien et ceux donnés sur mon sujet "mode dark vs mode blanc" pour le confort de lecture, je viens de ma taper plus d'heure de lecture, sans compter les docs diverses de mon côté (css grid, etc...) qu'on ne dise pas que je ne fait pas de veille
- Edité par pipelette13 29 octobre 2018 à 15:49:36
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
la connaissance est une chose qui ne nous appauvrit pas quand on la partage.
Mon GitHub
la connaissance est une chose qui ne nous appauvrit pas quand on la partage.
Mon GitHub
Pas d'aide concernant le code par MP, le forum est là pour ça :)
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !