Je continue avec l’excellente présentation de Stoyan Stefanov et je prend la suite de la discussion en commentaire d’il y a quinze jours.
Passez en 256 couleurs
Un PNG24 c’est 16 millions de couleurs. En pratique les PNG on souvent moins de 1000 couleurs. Si vous avez besoin des 16 millions ce que vous avez est probablement une photo, qui devrait être compressée en JPEG. En fait l’oeil humain n’est pas si sensible. Passez de 1000 couleurs à 256 couleurs indexées. Si l’index est bien fait vous ne verrez pas la différence et pour le même prix vous résolvez les problèmes de transparence.
Imposez le compromis
Si j’en crois les dernières discussions je vais avoir plein de commentaires pour me dire que le graphiste ou le marketing n’acceptera jamais. Probablement pas, effectivement, du moins pas la première fois. À vous de ne pas accepter non plus. À vous de forcer un compromis avec le graphiste.
C’est votre expertise, ne la niez pas. Le travail de l’intégrateur web et sa connaissance du média sont tout aussi importants que ceux du graphiste. La performance n’est pas plus importante que le reste, mais ce ne doit pas être la dernière roue du carosse de type « faites ce que vous pouvez avec ce qu’on a fait mais ne nous demandez pas de changer quelque chose ».
La première fois c’est difficile, mais le conflit est nécessaire. Une fois que l’équipe aura compris que vous avez un rôle, une expertise, une valeur ajoutée, les compromis suivants seront plus simple. Parce que finalement, le compromis PNG8 il est assez simple à accepter une fois qu’on a passé le refus de principe du graphiste et qu’on s’y penche sans à priori.
L’exception
Le cas où l’image doit rester en PNG24 existe, mais je ne suis pas sûr de l’avoir rencontré jusqu’à présent. La conversion en JPEG ou PNG8 a toujours été possible. Tout le monde a trop facilement tendance à se croire dans l’exception qui justifie le PNG24 sur le web, mais commencez par vous dire que ce n’est pas le cas. D’ailleurs ça n’est probablement pas le cas.
Le web c’est pour les stagiaires
Je ne peux m’empêcher de rappeler un billet rédigé il y a quelques années : Le web c’est pour les stagiaires. À vous de voir si vous pensez que c’est vrai, ou pas.
Pour moi ça fonctionne comme ça : un PNG-8 pour remplacer les gif (à tester, selon les images, le poids peut varier en faveur d’un format ou de l’autre)
Pour les photos, du jpeg. Le PNG n’y est pas adapté…
Et dans quelques cas plus rares, le PNG-32 (pour la transparence sur8 bit) avec tout ce que ça peut entrainer comme gestions côté compatibilité…
Bah, je suis toujours pas d’accord 🙂
Pour commencer, il ya plein de fois ou je suis parfaitement d’accord avec le graphiste pour dire, oui, ya besoin de PNG 24 avec transparence alpha ici. La plupart du temps, ce n’est pas dans le design en lui même, mais dans les détails: un logo, des icônes, des smileys… Bah oui, si on fait toujours des trucs sur la même couleur de fond, pas de problèmes, mais quand on a affaire à du contenu géré par l’utilisateur, ou pire, des scripts de pubs re-habillant une page de pied en cap dynamiquement, on a pas vraiment le choix: même avec un excellent détourage, ca sera généralement moche en transparence binaire.
Enfin, tu peux toujours argumenter auprès du graphiste que c’est ton job, mais c’est aussi le sien et celui de ceux au-dessus de lui. Tu peux toujours dire que c’est meilleur pour les perfs, mais bien souvent, les perfs seront sacrifiées pour avoir un truc plus joli, surtout si ca ne se compte que en dizaines de millisecondes (d’expérience, en dessous d’une demie-seconde, il n’y a guère que des développeurs pour s’y intéresser…)
PS: Note que, par contre, vu les stats actuelles de IE6 sur les sites dont je m’occupe, je n’ai aucun scrupule à utiliser dans de plus en plus de cas des « vrais » PNG 24 sans hack – juste une couleur de fond mise pour éviter que ca soit gris – et tant pis pour IE6.
Pour le PNG8, conctrairement à la croyance commune, il s’avère qu’il est possible d’avoir une opacité variable. Chaque couleur de la palette a sa propre opacité. Bref, même si tu veux de la semi-transparence, le PNG24 n’est pas nécessaire.
Pour IE6 je suis étonné que vous acceptiez d’avoir un service dégradé pour un petit quart de vos visiteurs (et si c’est acceptable pour un quart est-ce nécessaire pour les trois autres quarts ?) mais tant que tu utilises une dégradation légère et pas un filtre CSS, ça n’impacte pas les performances donc du point de vue de ce blog je n’ai rien à y redire.
Pour l’argumentation auprès du graphiste oui, c’est aussi son métier. C’est pour ça que je parle d’imposer un compromis (qui passera par fois par accepter le PNG24 même si vous le trouvez inutile pour pouvoir mieux faire passer en PNG8 la grosse image bien lourde) et pas d’imposer votre point de vue. Maintenant si le chef au dessus ne s’intéresse qu’à la demi-seconde, un tour sur http://performance.survol.fr/2008/06/a-quoi-ca-sert/ est indispensable.
Certes 100ms ne feront pas dire à quelqu’un consciemment « c’est lent », mais c’est quand même quelque chose qui va intervenir inconsciemment pour la fidélisation et la monétisation des visiteurs. Ce n’est pas moi qui le dit, c’est Google, Yahoo!, Amazon …
Certains sont comme St Thomas, tu pourras toujours lui dire que même les autres trouvent que 100ms c’est important, ils ne te croiront pas 🙂
J’avais entendu parler des PNG 8 avec transparence alpha, mais il ya 2 problèmes: 1. ils nécessitent toujours un hack pour IE6 2. ils sont chiants à produire avec les outils habituels (photoshop, gimp). Toutefefois, les tests que j’ai fait avec pngquant et pngnq (2 outils en ligne de commande) sont concluants, je pense que j’en mettrais. Comme je disais, c’est essentiellement des petits détails, les fichiers ne sont déjà pas énormes à la base, ca sera pas flagrant mais c’est déjà pas mal.
Sur la dégradation, c’est moins d’un quart, et ca dépend des cas. Ya des cas ou on mettra un filter (tant pis pour leurs perfs) d’autres ou on coupera (tant pis pour les fonctionalités ou la beauté du truc) et d’autres ou on trouvera une solution alternative.
Pour en revenir à l’idée de compromis, j’ai abandonné la belle utopie que ça pouvait fonctionner en webagency… Pour plein de raisons propres aux webagencies elles-mêmes d’après moi :
– Le turnover effréné : on accueille tous les mois de nouveaux graphistes peu ou pas formés pour le web, et dès qu’ils sont à peu près au point ils partent vers d’autres boîtes qui paient mieux.
– le temps consacré aux projets : calculé ric-rac, on coupe généralement au plus court dès qu’il y a conflit entre corps de métiers ; c’est-à-dire que c’est le dernier intervenant qui décide, donc souvent l’intégrateur ou le développeur mais très rarement le DA, qui bosse déjà sur de nouveaux appels d’offre.
– la non-implication des techniciens en amont : sur les appels d’offre, graphistes et DA only. Ils vendent du rêve au client parce que les concurrents font pareil, et une fois qu’on se rend compte en prod que c’est mal pensé ou coûteux en perf, impossible de reculer parce que « le client a vu les PSD et qu’il veut exactement ça sur son IE ».
A part en changeant de boite, je ne vois pas trop ce que je pourrais faire contre ça !
Le dernier problème dont tu parles est d’ailleurs pas du tout spécifique aux web agency…
Concernant les GIF, est il possible d’optimiser des Gif comme les PNG avec un tool du genre OptiPng ?
J’ai trouvé juste un tool « Gif optimizer » qui est vraiment pas terrible :/
Si quelqu’un connait un tool performant 😉
Je ne sais pas, et franchement quel intérêt ?
Sauf pour des images de moins de 100 octets, le PNG sera toujours plus petit, toujours. Il offrira aussi toujours plus de possibilités.
Pour optimiser les GIF, passez les en PNG, tout simplement. Vous n’avez rien à perdre et tout à gagner.
Tu es sûr que pour des images de plus de 100 octets, le png est plus petit ?
Parceque j’ai un gif de 336 octets et je n’arrive pas à faire mieux en png avec meta.
Si tu veux tester, voici mon gif : http://img393.imageshack.us/img393/6403/flagsdw2.gif
J’ai dit 100 octets, j’aurai pu dire 200 ou 300. Ca m’apprendra à ne pas être précis dans les commentaires. Disons que la différence de taille ne sera en faveur de GIF que sur des images toutes petites, et que sur ces images la taille gagnée quand avec GIF est franchement négligeable.
J’ai http://performance.survol.fr/wp-content/uploads/2008/08/flagsdw3.png en 211 octets. Il n’est pas exact au pixel près, mais je doute que cela se voit autrement qu’en comparant exprès les deux images côte à côte. Pour être honnête les mêmes compromis adaptés au GIF donnent 191 octets. On a donc 20 octets de différence. C’est moins que le cout d’une entête IP ! Autant dire plus que négligeable, même pour une connexion WAP.
Il ne faut pas oublier qu’entre les entêtes du navigateur et celle du serveur, c’est 1ko de qui sont échangés avant même de faire passer l’image. Ensuite on ajoute le temps nécessaire à la latence, le coût de la connexion elle-même … les 20 octets on va vite les oublier.
> Pour le PNG8, contrairement à la croyance commune, il s’avère qu’il est possible d’avoir une opacité variable. Chaque couleur de la palette a sa propre opacité.
Comment fait-tu pour jouer avec cette opacité variable en PNG8 ? J’ai beau chercher dans Photoshop et Gimp, je n’arrive pas à la manipuler autrement qu’en PNG24. Peut-être avec d’autres softs ?
C’est effectivement un problème d’outils : Fireworks sait gérer les couches alpha sur le PNG8
Je dois avouer que sur Photoshop CS3, je sauvegarde souvent en PNG-24 car celui-ci s’avère plus léger que le PNG-8, surtout en prenant en compte l’outil d’optimisation (optiPNG et compagnie).
Est-ce que j’ai raté quelque chose ou bien d’autres personne font aussi ce constat ?
@Louis: tu dois avoir un problème quelque part je pense. PNG8 c’est simplement moins de couleurs. Tu ne devrais pas pouvoir avoir un poids plus gros simplement en réduisant le nombre de couleurs.
Ou alors c’est moi qui ai raté quelque chose.
D’accord, je crois que j’ai enfin compris. Je pense que l’outil de compression que je passe sur mes PNG réduit le nombre de couleurs des PNG-24. Ca expliquerait pourquoi mes PNG-24 sont parfois plus petit que mes PNG-8 après compression : ils ont autant de couleurs, mais sont en plus allégés des meta données et compagnie.
Un PNG-24 peut être plus petit qu’un PNG-8 et c’est souvent ce que produit OptiPNG sur de petits pictogrammes: dans un PNG-8 il faut en effet embarquer la palette de couleurs et ces jusqu’à 3×256 octets de différence peuvent faire perdre le gain de poids dû à un PNG-8.
Et c’est sans perte d’information, contrairement à pngnq (pas de passage de 24bits à 8bits); pour vérifier si les PNG de départ et d’arrivée sont strictement identiques il y a pngcomp fourni avec pngnq.
Perso je sauvegarde en PNG-24 pour pouvoir retravailler l’image plus tard à moins qu’il n’y ait besoin de 8 bits de transparence (là c’est dans Fireworks que ça se passe, le seul capable de rouvrir le fichier), j’essaie pngnq et garde le résultat s’il n’y a pas trop de dégradation, puis lance « optipng -o7 *.png » sur le répertoire entier