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.

Souvent ce n’est plus possible pour ceux qui s’occupent des performances mais si vous avez la chance d’avoir la main sur celui qui joue avec Photoshop et qu’il semble assez receptif à vos demandes, lisez vite l’article de Smashing magazine sur l’optimisation PNG, puis celui sur l’optimisation JPEG.

Vous y trouverez comment améliorer certaines zones, comment diminuer le nombre de couleurs tout en gardant une qualité très intéressante, comment supprimer les informations sur les pixels transparents peut améliorer la compression, ou pourquoi un jpeg à qualité 51% est infiniment mieux qu’un jpeg à qualité 49%.

Votre graphiste connait déjà tout ça, mais un rappel tel que celui ci permet de faire en sorte qu’il utilise. Vous vous aurez en tout cas dans les mains les armes pour le challenger sur le poids des images. Il vous restera juste à passer le résultat par OptiPNG si c’est encore nécessaire.

J’aime d’ailleurs beaucoup l’idée de supprimer les informations inutiles dans les pixels transparents pour améliorer la compression. Je suis étonné que ce ne soit pas fait par défaut lors de l’export « pour le web » de Photoshop. Je ne crois pas que OptiPNG ou PngCrush s’en occupent non plus, et c’est malheureux. Je vous propose donc de récupérer un filtre Photoshop pour faire ça automatiquement, ou plutôt le faire faire par votre graphiste.

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.

Suite à plusieurs de ces publications à propos des sprites CSS, il est temps de faire ici un petit complément sur le sujet.

Sprite Me

Le premier lien c’est SpriteMe, un bookmarklet qui permet de repérer les images les plus pertinentes à grouper ensemble dans un sprite. L’outil regarde toutes les images de background dans la CSS, les groupe par alignement et taille. Plus tard il est prévu qu’il génère le sprite associé puis mette à jour la CSS.

Je reste assez septique sur ces deux dernières étapes. C’est réalisable, sans aucun doute, mais pas forcément pertinent. On risque d’associer des images qui ne sont qu’occasionnellement dans le même contexte, ou des couleurs trop différentes, des alignements difficiles à faire parce que telle ou telle image a besoin d’une grande marge, etc.

La décision et la réalisation doivent probablement rester des étapes manuelles, mais l’aide à la décision ne peut être qu’une bonne chose.

Trop c’est trop

Le second lien c’est Vladimir Vukićević de Mozilla qui rappelle les problèmes inhérents à une mauvaise réalisation des sprites.

Sur le réseau on fait transiter des images compressées, aussi seul le poids du fichier et le nombre de requêtes HTTP comptent. Les sprites sont une grande avancée. Toutefois, le navigateur utilise lui l’image décompressée en mémoire. Sur des tailles démeusurées, la mémoire se retrouve encombrée par un simple sprite. Sur un exemple réel, Vladimir parle d’un sprite de 75Mo en mémoire (1299×15000 pixels).

Donc voilà, un rappel n’est jamais mauvais et j’avais déjà abordé ici la problématique à propos des terminaux mobiles, le sprite est globalement une bonne chose mais il vaut mieux rester mesuré : gardez la taille réelle de l’image en tête.

Le plus simple pour éviter les excès c’est de grouper ensemble des images de taille similaire et d’alignement identique. Pas d’icône 16×16 liée à des bandeaux 2000×24 pour éviter de perdre 1984px de largeur. De toutes façons, rappelez-vous qu’au delà de 2000 pixels, un bug du navigateur Opera risque de vous mettre des bâtons dans les roues.

Ne pas jeter le bébé avec l’eau du bain

La solution c’est le pipelining HTTP, qui ne semble jamais venir. Le commentaire de Rob Sayre de Mozilla à ce sujet (« en théorie, ahahaha ») veut tout dire. Les autres possibilités ce sont les conteneurs jar de mozilla, ou les réponses mime/multipart, de Mozilla aussi.

Mais voilà, pour l’instant c’est la seule technique viable que nous ayons, et elle fonctionne. En restant correct sur les tailles, le gain côté réseau dépasse largement le petit effet négatif sur la mémoire. N’oubliez pas, même sur les terminaux mobiles, c’est le réseau qui reste le plus gros goulet d’étranglement.

Bref, faites juste attention aux tailles des images décompressées.

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.

C’est Marc Hertzog qui se colle à l’exercice avec JQuery. Il a amélioré un module de Scott Jehl qui lit une feuille de style et tente de précharger toutes les images qui y sont référencées. L’idée est séduisante. On supprime alors les temps d’attente pour les images qui s’affichent au survol de la souris ou sur les pages suivantes.

L’idée est séduisante mais je n’accroche pas tout à fait. Tout d’abord parce que c’est au navigateur de faire ça. J’ai souvent dit que sur les performances on compensait les manques des navigateurs et qu’il fallait être pragmatiques (le faire quand même même si dans l’idéal c’est le boulot du navigateur) mais là il s’agit de quelque chose de simple, très simple. Quand un « quick win » n’est pas réalisé par des gens intelligents – et les développeurs de navigateur le sont – c’est qu’il y a anguille sous roche.

Le plus gros défaut que je vois est celui inhérent à tout préchargement : on fait travailler le navigateur. Sur un poste personnel avec une navigation très linéaire ça n’a d’effet négatif quasi que sur les prestataires réseau. Mais sur une ligne partagée (entreprise, wifi), avec des gens très connectés (vidéo en streaming parallèle, deezer ou spotify en tâche de fond), ou simplement sur une navigation avec beaucoup d’onglets (vous faites une recherche, vous ouvrez beaucoup de pages en parallèle), vous pénalisez l’utilisateur ou ses voisins. Même chose pour un utilisateur en itinérance : utiliser son réseau et son processeur pour ça aura une influence forte sur sa batterie.

Le préchargement reste une bonne idée, mais à petite dose, pour des choses ciblées, prévues. Ici on télécharge tout sans discernement. C’est certain, on va aussi télécharger des éléments qui ont une faible probabilité d’être utile. Dans les commentaires de la version originale du script on propose de faire un tri sur l’url de chaque image, suivant son répertoire on décide si c’est une image qui doit être préchargée ou pas. On résout ainsi l’occupation réseau (mais pas l’occupation processeur), mais ça commence à faire usine à gaz. Sans compter que une même image peut avoir du sens pour un préchargement sur certaines pages mais pas sur d’autres.

À ce compte là autant lister les images à précharger dans un tableau javascript au lieu de lire toute la feuille de style. Ou mieux, des <link rel= »prefetch »> parce que c’est fait pour ça.

Enfin, c’est surtout utile pour les changement d’image au survol de la souris, ou sur une action utilisateur. Dans ce cas on modifie l’image en cours, ou on affiche des icônes. Bref, on se retrouve très généralement dans des cas où les images concernées sont de toutes façons dans des sprites, soit avec une liste d’icône, soit avec l’image qu’on remplace – l’image contient alors et la version sans survol et la version avec survol.

Bref, l’idée est bonne mais je reste septique sur la pertinence de mettre en place une solution générique de ce type.

Reste que compresser les images correctement c’est long. Smushit accélère tout ça mais c’est du one shot. Ce qu’il faut c’est intégrer des outils comme optipng dans votre processus de publication.

Alors voilà, pour un gros site au travail c’est réalisable avec un peu d’investissement. Sur un site de moindre importance c’est tout aussi important mais l’investissement devient lourd. C’est là que des outils automatiques sont intéressants, et le premier que je vous propose est un plugin wordpress, wp-smushit, qui envoie automatiquement vos images à smushit. Plus besoin d’opérations manuelles, wordpress s’occupe de tout.

Le second que j’ai croisé est un script PHP qui prend la main sur tout téléchargement CSS ou Javascript : SmartOptimizer. PHP permet de concaténer, minimiser, compresser, et envoyer avec les entêtes de cache appropriées. Le résultat côté serveur est bon, mais je reste dubitatif sur l’idée de faire passer par PHP toutes les ressources statiques. Les ressources serveur vont souffrir de manière importante, et si vos serveurs deviennent lent votre performance client ne va finalement pas y gagner.