Un des outils que je regarde c’est pngrewrite. La rumeur voudrait qu’il ne gagne pas grand chose mais qu’il est capable de le faire même après un passage par optipng ou pngcrush. Bref, un petit ajout rapide, juste pour grappiller un peu plus.

Je vais vérifier tout ça là aussi, mais en attendant le code proposé sur le site officiel ne compile pas sur mon linux récent. Pour ceux qui ont le même problème, la distribution gentoo a un patch disponible. Il suffit de le télécharger là où vous aurez décompacté le code source de pngrewrite et de lancer patch -p0 < pngrewrite-1.3.0-gcc44.patch puis de taper l’habituel make.

Voilà, maintenant vous savez.

J’aurai bien fait des paquets Ubuntu pour pngrewrite et pngout mais je ne trouve pas la licence du premier et le second interdit explicitement de reditribuer l’exécutable résultat. Si j’ai le courage je tenterai peut être des paquets « tricheur » qui téléchargent sur Internet lors de leur installation mais ça perd un des intérêts.

J’ai annoncé il y a quelques temps que je comptais développer un outil similaire avec un code source ouvert et au moins une version en ligne de commande pour être intégré dans des mécanismes automatisés de publication (plutôt que d’attendre publication pour ensuite corriger image par image). Ca viendra, mais ça prend du temps parce que je veux faire les choses bien. Je compare donc tous les outils que j’ai pu voir pour comparer leurs résultats, avec différentes options. Il faut tenter de prendre un échantillon d’images représentatif, repérer les avantages et les défauts de chaque outil suivant le format mais aussi le type d’image (taille, transparence, nombre de couleurs, etc.) puis faire un choix en fonction du temps de traitement (prendre le plus efficace sur la taille finale n’est pas forcément la meilleure idée). Bref, ça viendra mais ce n’est pas pour demain.

Par contre vous avez désormais punypng. Je n’ai pas vu de code source, il n’y a pas de version en ligne de commande, ça n’accepte pas une URL de page HTML pour en extraire toutes les images (quoi qu’il doit être assez simple d’adapter l’ancienne extension smushit pour cela) mais ils innovent. Ils ont repris l’idée d’optimiser les images contenant des pixels avec une information RGB mais totalement transparents, ils font plus de travail sur les jpeg, et ils tentent d’avoir une interface plus efficace que smushit. C’est déjà ça et c’est bien.

Par contre j’apprécie beaucoup l’arrivée de ces plugins pour deux raisons. D’abord ils montrent une prise de conscience globale de la problématique des performance, et surtout ils posent les premières briques d’une démarche performance intégrée aux outils de publication. Si pour l’instant rien ne remplace l’expert et le consultant sur ces sujets, rien ne me ferait plus plaisir que de savoir qu’on puisse s’en passer à l’avenir. Il est finalement anormal que quelqu’un qui met juste en place un blog ou un CMS ne puisse pas avoir quelque chose de performant par défaut.

C’est dans cet esprit que je peux vous parler d’une petite idée de configuration, cette fois pour le CMS ezPublish. Là aussi ce n’est pas parfait, il s’agit juste d’un filtre pour envoyer les images à travers imagemagick avec des paramètres pour retirer les métadonnées, ça ne concerne que les miniatures, mais ça existe et on en parle. En soi c’est déjà une réussite.

Si votre outil a lui aussi cette notion de filtre, que ce soit pour les images générées comme les miniatures ou pour les images téléchargées dans l’outil,  je ne peux que vous encourager à mettre en place ce genre de solutions. J’aurai tout de même une préférence pour OptiPNG plutôt que ImageMagick.

Les jpeg ont aussi des métadonnées importantes et des informations inutiles dans un contexte web. Vous y trouverez plusieurs version de l’image à différentes résolutions pour gérer des miniatures, ou même des pistes audio. Stoyan Stefanov a trouvé un gain moyen de 12 % avec des transformations sans pertes sur l’image elle-même, loin d’être négligeable.

C’est Jpegtran dont j’avais parlé la dernière fois, l’outil utilisé par smushit. En plus de retirer les blocs de méta données (moins précisément que JHead), il permet de retoucher un peu la compression sans toucher à la qualité de l’image ni subir de pertes par rapport à l’image originale.

Jpegtran permet aussi de créer des images jpeg progressives, ce qui parfois est légèrement plus petit en taille (mais pas tout le temps, et en particulier pas pour les petites images).

Attention toutefois, cela retirera aussi les mentions de copyright éventuelles. Ne le faites que sur vos images ou prévoyez d’extraire d’abord cette information pour la réinjecter dans l’image finale ensuite.

JHead manipule lui aussi les entêtes et les métadonnées EXIF, IPTC et XMP. Je peux vous proposer les options -du -dc -de -di -dx. Jpegoptim propose aussi une optimisation sans perte et la possibilité de supprimer les entêtes EXIF et commentaires. Je n’ai pas de retour sur la performance de l’outil. Pour ceux que ça intéresse il y a une option pour diminuer la qualité de l’image (non activée par défaut).

Maintenant, comme on me le faisait remarquer il y a peu à propos des PNG, la meilleure compression s’obtient toujours en travaillant l’image avant de la fixer dans un format particulier. En particulier il est généralement appréciable de gérer la qualité par zones, pour avoir les détails là où c’est utile.

PNGcrush me donnait 403 Mo (10% de gain) pour 75 minutes avec les options par défaut, et 399 Mo (11% de gain) en le poussant à fond mais en prenant alors entre 8 et 9 heures.

Optipng, avec les options par défaut, arrive à 392 Mo (13% de gain, donc mieux que le maximum de pngcrush) pour deux heures et demie. C’est long, mais on gagne deux points. À noter tout de même que 10% des fichiers sont légèrement plus gros avec optipng qu’avec pngcrush, mais en moyenne quand optipng est plus gros c’est de moins de 1%, alors que quand il est plus petit c’est plus significatif (et il plus petit dans 90% des cas).

Si il est franchement inacceptable d’imaginer mettre huit heures pour quelques points, le compromis résultat/temps d’optipng peut avoir du sens. Si vous n’êtes pas trop pressés, c’est l’outil qu’il vous faut.

Malgré le mauvais retour des options « brutes » avec pngcrush, j’ai tenté la même chose avec optipng (option -o7). On gagne au plus 2 Mo sur l’échantillon global, et le temps de calcul dépasse la journée. Autant dire que là aussi, sauf si vous avez une bonne raison, restez avec les options par défaut.

Pour y répondre j’utilise un répertoire de 7000 fichiers de 250 ko maximum avec une moyenne à 60 ko. En réalité il y a pour plus de moitié de fichiers inférieurs à 10 ko (pour ceux que ça intéresse, l’écart type est de 50 ko). Je n’ai aucune prétention sur la représentativité de ces images téléchargées de façon automatisée sur le web, mais cela donne au moins un ordre d’idée.

Sur des fichiers sortis sous Photoshop, de mon expérience et au jugé j’aurai tendance à dire qu’un passage par les outils type pngcrush font gagner entre 10 et 30 % sur le poids des images. Sachant que les images représentent généralement plus d’un tiers du poids global des pages, c’est non négligeable.

Donc ces 7000 et quelques fichiers prennent 450 Mo sur disque. Passés par pngcrush on arrive à 403 Mo. Un passage par l’outil nous fait gagner 10 % en moyenne. C’est moins que ce que je pensais (mais mon échantillon n’est pas forcément représentatif) mais notable tout de même.

J’ai tenté plusieurs solutions dans les options, en finissant avec un outrageux « -l 9 -brute -cc -rem alla -reduce -rem time -rem iTXt -rem tEXt -rem zTXt » qui n’est pertinent pour rien d’autre que pour ce test. Je suis tombé à un poids global de 399 Mo. On gagne 1,5 points par rapport aux options par défaut, à peine 1 % à partir du test précédent. Par contre pour gagner ce 1 %, pngcrush a pris 7 fois plus de temps (520 minutes au lieu de 70). Autant dire que votre processeur pourrait trouver de meilleures occupations.

Résultat : pngcrush, oui, mais gardez les options par défaut.

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.

Qu’est ce qu’il se passe ? à chaque visite le navigateur va chercher cette icône. Le traffic lié à cette icône peut dépasser 10% du traffic total, principalement sur des sites « de passage » (9% sur Yahoo! Search nous dit Stoyan Stefanov). Une petite optimisation aura alors une grande influence. Alors cherchons les problèmes un à un :

Premier échec

Vous n’avez pas fait de favicon.ico, ou cette icône n’est pas à l’emplacement cherché par le navigateur. Ce dernier va donc télécharger… votre page d’erreur 404, donc probablement quelques kilo-octets de HTML inutiles. On en revient à ce dont nous avions parlé précédemment : faites des pages d’erreurs courtes et légères. Mais surtout, prévoyez toujours un fichier /favicon.ico pour éviter de tomber sur la page d’erreur 404.

Second échec

Vous n’avez pas mis un bête fichier dans /favicon.ico sans vous embêter plus. Le navigateur télécharge ce fichier à chaque nouvelle visite. L’utilisateur perd du temps, occupe sa file de téléchargements avec une requête inutile, et surcharge votre serveur. Mettez une entête d’expiration explicite sur le favicon. Il change de toutes façons rarement et une expiration à deux mois ne gênera vraiment personne.

Troisième échec

Votre favicon contient une version 16x16px, une 32x32px, une 48x48px, toutes en millions de couleurs. Le format permet en effet d’avoir plusieurs images de différentes tailles, et des couleurs sur 24 bits. Le format 16px est utilisé pour la barre d’adresse, les suivants peuvent être utilisés quand vous faites glisser un raccourci sur votre bureau. Évidemment le marketing est formel, l’icône en 24 bits est bien plus jolie. Le résultat c’est que votre simple icône va finir par faire 5 à 10ko, c’est à dire beaucoup trop. Sérieux, au delà de 900 octets, vous êtes en faute. Gardez une icône de 16x16px en 256 couleurs. Pour ce qui en est fait par les visiteurs, c’est largement suffisant.

Si votre marketing insiste faites une détection de navigateur et proposez une image PNG pour les navigateur récents, une icône Microsoft en 16x16px sur 256 couleurs pour les autres (Internet Explorer 6 par exemple). Grâce à la compression vous atteindrez des tailles et des qualités bien meilleures tout en restant en dessous du kilo-octet.

Quatrième échec

Vous avez gardé le chemin par défaut de /favicon.ico. Le résultat c’est que vous n’utilisez pas votre CDN et tous les avantages qu’il procure. Insérez un lien dans les entêtes de vos pages HTML pour donner un chemin explicite à votre favicon. Le téléchargement du favicon sera plus rapide (parce que sur le CDN), profitera des entêtes de cache du CDN, et sera sur un domaine tiers qui n’handicapera pas les files de téléchargement du domaine principal. Par contre gardez toujours une icône de base sur le chemin par défaut, au cas où et pour les documents qui ne sont pas en HTML (sinon vous retombez dans le premier échec).

<link rel="shortcut icon" 
      type="image/png"
      href="//CDN.example.org/favicon" />

Quand vous faites un filter:AlphaImageLoader dans vos CSS, Internet Explorer l’exécute à chaque apparition de l’image dans votre page. Oubliez l’idée qu’il met en cache le résultat ou même qu’il n’exécute le filtre qu’une seule fois par image. Si vous l’utilisez pour une petite icône de présentation qui apparaît vingt fois dans votre page, c’est vingt exécutions du filtres qui sont faites.

À chaque exécution du filtre le rendu est bloqué, en attente. Sur Yahoo! Search en retirant AlphaImageLoader de la feuille CSS c’est jusqu’à 100ms qu’ils ont gagné (information donnée par Stoyan Stefanov sur sa dernière présentation).

Faites un compromis avec vous-même et laissez une simple transparence binaire sur un PNG8. Mais si vous n’y êtes pas prêts, faites au moins en sorte que Internet Explorer 7 et plus n’utilisent pas le filtre, car eux savent nativement lire les couches alpha des images PNG. Transformer filter: en _filter: devrait suffire.

Sur un site classique comme TF1, Amazon, LeMonde, on dépasse les 100 images sur la page d’accueil, pour un total de près de 300ko. Les sites plus au fait des problèmes de performance ont entre 30 et 50 images mais le poids total est encore souvent supérieur à 100ko.

• TF1 : 108 images pour 300ko
• Amazon : 106 images pour 300ko
• LeMonde : 102 images pour 250ko
• Yahoo : 45 images pour 126ko
• Ebay : 30 images pour 160ko

Les images, une priorité pour la performance

Pour rappel, sur ma ligne « classique » de 2mb/s avec 40ms de latence et deux connexions simultanées par domaine, je vais mettre plus d’une seconde à tout télécharger. Bien sûr tout ceci c’est si les 2mb/s sont exploités sans une seule perte et si le serveur répond instantanément. En pratique même sur les superbes lignes ADSL vous mettrez probablement bien deux secondes rien que pour les images. Rappelez vous le billet précédent, deux secondes c’est énorme.

Il y a largement matière à plusieurs billets. Je ne parlerai pas de parallélisation, de chargement différé ou de sprites. Contentons nous ici de l’image elle-même.

Différents formats pour différents usages

On peut individualiser trois formats d’images sur le Web : JPEG, GIF et PNG. Tous sont des formats dits « compressés » qui permettent d’obtenir un fichier de taille réduite.

Le premier est un format prévu pour des photos ou des images avec des tons continus et des millions de couleurs. La compression est étudiée pour ça et en s’autorisant une faible dégradation de l’image nous permet de gagner plus de 90%. L’image ne sera donc pas exactement la même avant et après compression mais la différence de qualité devrait être minime si les réglages sont bien faits.

Les deux autres sont des formats sans perte, l’image sera la même avant et après compression, au pixel près. Ces formats sont adaptés à de gros aplats avec peu de couleurs, à de petites images et aux images où la qualité au pixel près est importante – par exemple quand il y a du texte à lire. Ils ont aussi la possibilité avoir de la transparence (et bien d’autres choses pour le PNG).

Une photo se compressera très mal en PNG, et un logo en 4 couleurs avec une tagline textuelle sera très mal adapté au JPEG. Les images de contenu sont souvent des photos, donc en JPEG. Les élements d’interface sont généralement le terrain de GIF et PNG.  Utilisez le bon type de format, votre taux de compression s’en ressentira.

PNG est meilleur dans tous les cas

Pour la petite histoire GIF est basé sur une compression sans perte LZW. La perte de qualité vient uniquement que le format n’accepte que 256 couleurs. C’est la dégradation préalable en 256 couleurs qui cause la perte que certains constatent, le format n’y est pour rien. Sur des images adaptées ont peut compter sur une image 4 à 10 fois plus petite que l’originale en 256 couleurs.

Le format PNG est venu plus tard. La compression est faite via un algorithme de deflate, comme pour gzip, qui permet d’avoir un taux de compression de 10 à 30% plus performant. Les couleurs ont elles aussi des améliorations puisqu’en plus du format 256 couleurs (nommé PNG8) on peut gérer des images en vraies couleurs (24 bits, PNG24) et même des images en 48 bits (16 bits par couleur, plus que votre écran ne peut en afficher). Enfin, si GIF permettait de définir des zones complètement transparentes et des zones opaques, PNG permet de gérer 65000 niveaux de transparence (on parle de couche alpha).

Le choix entre PNG et GIF est vite fait : vous devriez toujours utiliser PNG par rapport à GIF pour une image fixe. Il n’y a pour ainsi dire aucun contre-exemple significatif. À fonctionnalités égales le fichier PNG sera plus petit. À taille égale le fichier PNG offrira plus de possibilités, par exemple plus de couleurs et donc une meilleure qualité.

Faites confiance à PNG

Ne faites pas confiance aux détracteurs de PNG et partisants de GIF :

On vous dit que le PNG fait des fichiers plus gros ? C’est probablement que votre interlocuteur utilise un PNG en 24 bits (abbrévié PNG24) avec des millions de couleurs : Comparé à un GIF qui utilise seulement 256 couleurs, forcément, ça prend plus de place. Utilisez un PNG8 lui aussi en 256 couleurs et ce dernier reprend l’avantage. Le PNG peut avoir une meilleure qualité mais si on compare à qualité égale il reste bien le plus performant.

On vous a dit que Microsoft Internet Explorer 6 ne supportait pas la transparence sur les PNG ? En fait il ne supporte pas les couches alpha : Utilisez les mêmes fonctionnalités que GIF, c’est à dire un PNG8 avec une transparence binaire dans la palette de couleurs, et vous récupérez la compatibilité avec MSIE 6 tout en profitant de la taille réduite.

On vous dit que les couleurs ne sont pas exactes dans PNG ? En fait elles le sont, et c’est ça le problème : Les systèmes d’exploitation utilisent des profils de couleur et des valeur de gamma différentes. PNG permet de stocker ces informations dans l’image pour éviter que votre création soit claire sur Mac OS X et sombre sur Microsoft Windows. Les navigateurs ne savent pas tous appliquer correctement ces informations et le même rouge rendra différemment s’il est dans l’image PNG et s’il est dans la CSS, ce qui est assez moche au final. Là aussi, si vous ne mettez pas de profil de couleur et de gamma dans votre PNG, il s’affichera comme le faisait un GIF : parfaitement. Les logiciels pngcrush et optipng peuvent vous aider à retirer ces informations.

Réduisez la taille de vos images

Non seulement les sites contiennent trop d’images mais en plus elles sont bien trop grosses. Dans une majorité des sites, y compris les sites à fort traffic, les images sont insuffisamment compressées. On trouve des petites images d’interface à plus de 5ko et des illustrations photographiques à plus de 30ko. Est-ce vraiment nécessaire ?

Utilisez moins de couleurs

Un format adapté, une bonne compression devraient déjà vous permettre d’obtenir une majorité d’images de 1 à 5ko. Au delà, pour une image d’interface, vous devez vous y attarder. Pour les éléments d’interface réduire 256 couleurs est quasiment toujours une bonne idée. En diminuant encore plus le nombre de couleurs vous pouvez certainement gagner encore un peu à la compression.

Faites (faire) des compromis sur la qualité de l’image

L’étape suivante c’est de faire des compromis sur la qualité, soit sur la compression JPEG soit sur le nombre de couleurs. C’est toujours un sujet sensible avec les graphistes et le marketing, mais poussez les dans leurs derniers retranchements jusqu’à ce qu’ils vous disent que là non vraiment si on baisse la qualité ce n’est plus acceptable. Vous pouvez aussi tenter de faire simplifier l’image elle-même, les aplats de couleurs obtenant une bien meilleure compression. L’argument majeur c’est qu’une image qui n’est pas parfaite mais qui arrive vite est probablement préférable à une image parfaite mais qui met du temps à venir.

Tentez différentes compression avec Photoshop

Photoshop est d’une grande aide pour les choix de couleur et de qualité. Dans le menu « save for the web… »‘ on vous propose de jouer avec tous les paramètres et de constater le poids final de l’image avant de la sauvegarder. Il est même possible de confronter quatre jeux de paramètres, format et compression côté à côté pour comparer taille et qualité avant de choisir le plus intéressant. Imposer à votre graphiste de toujours passer 3 minutes minimum montre en main à essayer différentes solutions de compression sur l’interface Photoshop.

Améliorez la compression avec OptiPNG

Ensuite, quand l’image initiale est au mieux, on peut encore utiliser des logiciels d’optimisation comme pngcrush et optipng déjà cités plus haut. Ils vont retirer toutes les méta données non nécessaires et tester plusieurs pistes de compression pour retenir la meilleure.

Vous trouverez peut être quelques sources qui vous proposent de préférer des sprites horizontaux aux sprites verticaux quand vous avez le choix. GIF appliquait certains algorithmes uniquement sur les répétitions horizontales. PNG fait aussi des opérations verticales ; mes tests ne mettent pas en valeur une différence de plus d’un ou deux octets entre horizontal et vertical sur ce dernier format.

L’impact

Alors certes, on ne gagnera peut être que 1ko par image en moyenne, parfois moins parfois plus. Mais rappelez vous les chiffres en début de billet. Sur 100 images 1ko par image en moyenne ça fait déjà 100ko. On n’est pas dans le négligeable, on est dans le prioritaire.