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.

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.

Voilà donc Page Speed, en gros un Gslow avec quelques règles en plus et une ergonomie différente. On y trouve les même préconisations, avec un système de vérification automatique similaire.

Les mieux

• Vérification automatique de la compression des images (un petit équivalent smushit bienvenu), avec mise à disposition des fichiers recompressés
• Pourcentage d’utilisation du contenu des CSS, avec la liste des sélecteurs non utilisés dans la page
• Une règle pour inciter à préciser les dimensions des images pour éviter d’avoir à refaire plusieurs reflow dans la page
• Identification des sélecteurs CSS inefficaces (mais ils ont l’air un peu trop radical là dessus pour moi)
• Minification des javascripts (on vous propose la version minifiée pour remplacer la votre)
• Proposition pour retarder le chargement de javascript

Clairement il y a du bon. Mais surtout il y a un nouvel outil pour tracer le graphique en cascade des téléchargements. Celui de Page Speed propose tout ce qu’à Firebug 1.4 (DNS, connexion, queue, attente, téléchargement) mais on y ajoute les ressources prises depuis le cache (cache hit), une couleur spécifique à l’envoi de la requête (différente de l’attente de la réponse) et deux couleurs pour le temps d’analyse et le temps d’exécution des javascript. On a là le graphique en cascade le plus complet parmis tous les outils que j’ai vu jusqu’à présent. Ce sera un plaisir de travailler dessus.

Et le moins bon

Au niveau du mauvais il manque certaines règles et fonctions par rapport à Yslow2 :

• L’utilisation d’un CDN
• Présence de 404
• Présence d’AlphaImageLoader
• Redimensionnement des images dans le navigateur
• Règle spécifique au favicon
• Externalisation des composants
• Des notes plus précises

Des notes plus précises ça peut paraître inutile (Page Speed n’a que les catégories : bon, mauvais, moyen et informatif) mais c’est indispensable quand on ne travaille pas seul, ou quand la direction souhaite avoir un aperçu de l’avancement. Quand bien même une note sur 100 n’est pas extraordinairement pertinente, elle montre un avancement, permet de prioritiser les efforts entre plusieurs sites. Même la note Yslow de A à F est importante pour cela. Page Speed demande de compter les points en rouge et les points en vert pour se faire une idée, sans savoir lesquels sont vraiment importants et lesquels non. Bref, c’est un manque sérieux pour une réelle exploitation en entreprise.

Ouverture et extensibilité

Mais surtout il manque l’extensibilité de Yslow2. Implémenter les quelques règles supplémentaires de Google Page Speed dans Yslow 2 doit être faisable en une semaine de travail au plus, seul le graphique en cascade représente un réel développement non reprenable.

Et du coup c’est un peu décevant. Je suis un éternel idéaliste mais un tel outil est compréhensible au début. Google Page Speed arrive en dernier, après plusieurs autres outils. Il aurait été agréable de soit étendre l’existant (mais je suppose que la rivalité Google/Yahoo! a pris le pas sur les belles paroles d’ouverture et de « on veut aider les gens ») au au moins de prévoir d’être soi-même extensible (vu que Yslow 2 l’est).

Heureusement le code lui-même est sous licence libre (ceci est un appel du pied à Stoyan Stefanov à propos de Smushit), mais c’est tout de même dommage qu’ils aient loupé le coche de l’ouverture.

Compatibilité

Seconde note : La compatibilité avec Firefox 3.5 ou Firebug 1.4 est pour l’instant assez mauvaise, je ne sais pas lequel des deux est le coupable, mais testez sur un Firefox 3.0 avec Firebug 1.3 pour pouvoir tout utiliser. C’est dommage d’ailleurs parce que vu ce que m’apportent Firefox 3.5 et Firebug 1.4 au jour le jour, quand bien même ils sont en version de développement, je n’aime pas avoir à choisir entre eux et un autre bon outil.

Oui mais, mieux ou moins bien ?

Là il va falloir attendre. Je n’ai pas pu résister à publier un premier de billet de présentation. C’est un peu d’excitation mais aussi que sinon on va m’envoyer des liens vers Page Speed jusqu’à ce que je publie quelque chose. Pour la réelle analyse, savoir si les règles mises en place sont pertinentes (est-ce que regarder la complexité des sélecteurs CSS est une bonne chose ?), si les réglages fins sont corrects (si oui, qu’est-ce qu’on considère comme un sélecteur CSS complexe ?), il va falloir un bon mois de retour d’expérience. À dans un mois donc…

Plus que les outils eux-même, qui n’ont rien de révolutionnaires, c’est la prise de conscience des questions de performance par les développeur d’applicatifs et de bibliothèques de code qui me réjouit. Il est vrai qu’on ne peut pas demander à tous de se préoccuper des performances. Beaucoup d’éditeurs n’ont pas vraiment de techniciens compétents et se contentent d’utiliser des solutions toutes faites.

Le fait qu’il existe des plugins ou des composants utilisables peut faire la différence entre « il faudrait » et « j’installe et configure ».

C’est dans cet esprit que je vois arriver trois plugins pour le framework PHP Symfony :

• sfOptimizeStyleAndScriptPlugin : concaténation et compression
• sfMinifyPlugin : concaténation, minimification et cache
• sfCombinePlugin : concaténation

J’ai aussi vu passer Minify, un script PHP qui fait concaténation, minimification et cache, et mod_concat (doc), qui s’occupe de la concaténation au niveau du serveur Web Apache.

Je ne suis pas fana des systèmes PHP qui fonctionne à l’exécution de l’applicatif. Les performances sont rarement au rendez-vous et il s’agit au minimum de faire traiter toutes les requêtes statiques par PHP, ce qui est franchement dommage. Je préfère sérieusement des outils qui s’intègrent à votre processus de publication : un bouton qui concatène et minimise une fois pour toutes les fichiers en les versionnant correctement et qui les pose au bon endroit sur un serveur avec de bonnes entêtes de cache.

Seul le système de concaténation mod_concat, qui ne prend virtuellement pas de ressources inutiles, remporte mon adhésion. On rejoint ce que fait d’ailleurs Yahoo! avec son combo handler.

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.

Heureusement tout ça est fini. C’est toujours quand on rêve de faire un outil que quelqu’un sort ça le lendemain, donc voilà, ce coup ci ce sont Stoyan Stefanov et Nicole Sullivan qui ont commis smushit.

Un outil en ligne

Smushit c’est un site sur lequel vous envoyez votre image. Il vous retourne immédiatement une image optimisée en vous indiquant le gain en poids sur le fichier. Parce qu’un outil automatique ne pourra jamais faire des choix de qualité, la recompression est sans perte, les images seront les mêmes au pixel près.

Mais le côté vraiment nouveau c’est une extension Firefox qui sur votre demande va lister toutes les images utilisées par la page courante et les envoyer à smushit. Là vous avez une grille de résultat avec chaque image, le poids final de l’image, combien vous avez gagné, et un gros zip contenant les images optimisées.

Magique. En trois minutes, installation de l’extension comprise, vous avez un audit complet de vos images, et le travail est déjà fait pour améliorer la situation. En cinq minutes de plus vous remplacez les anciennes images par les nouvelles et vous avez fait un travail exceptionnel.

Des résultats ahurissants

Pour rappel le poids de la page HTML et des feuilles de style ou javascript est souvent négligeable ou équivalent au poids total des images. Améliorer la situation même d’un peu sur les images, c’est améliorer la situation globale pour l’utilisateur.

Alors j’ai mené deux tests pour vous, Pages jaunes et Orange. Sur les deux on peut gagner environ 25% sur le poids total des images. C’est respectivement 30ko et 57ko qu’on gagne. En jouant avec la qualité et le nombre de couleurs on peut certainement aller bien plus loin. Dans le second on reste avec des images de plus de 20ko donc on doit pouvoir monter facilement à 75ko ou même 100ko au total si on joue sur des baisses de qualité non perceptibles à l’oeil nu ou qu’on fait quelques sprites.

Je ne sais pas si vous vous représentez bien ce que ça fait mais dans les deux cas le gain représente plus de 10% du poids total de la page, css html et javascript compris. Dites à votre responsable que vos pages sont 10% moins lourdes sans différence de qualité pour 2 heures de travail (pause café comprise), il va vous sauter dans les bras. C’est justement ce que smushit vous propose de faire.