Une mise à jour attendue …

J’avais, comme tout le monde, deux principaux reproches à faire sur l’outil. Tout d’abord il ne vérifie qu’une liste très spécifiques de critères. Ce sont une partie des 14 premiers critères retenus par l’équipe performance de Yahoo! mais depuis d’autres recommandations ont pu être dégagée. Il était nécessaire que l’outil s’étoffe.

C’est donc 10 règles supplémentaires qui sont intégrées dans l’outil, pour un total de 23. Mais là où Yslow aurait pu avoir une simple mise à jour, l’équipe Yahoo! a permis l’arrivée d’un modèle communautaire, où chacun peut ajouter facilement ses propres critères. C’est l’histoire de quelques lignes de javascript dans une extension Firefox.

Le second point contestable était le système de notation. Toutes les règles ne sont pas adaptables à tout le monde, avec la même importance. Le premier exemple c’est la question des ETags qui pénalise des notations pour rien, soit parce que l’ETag n’est pas généré avec le système par défaut d’Apache, soit parce qu’il n’y a qu’un seul serveur web derrière le site. Chacun a ses spécificités et je retiens encore l’exemple qu’on m’a donné des sites chinois qui ont tendance à avoir des pages web longues de plusieurs dizaines d’écran parce les usages locaux font qu’on télécharge la page pour une lecture hors ligne, et qu’on espère donc en avoir le plus possible dedans quitte à attendre longtemps.

Bref, là aussi Yslow est personnalisable et il sera possible de définir vos propres algorithmes de notation, voire de choisir le type de notation souhaité parmi une liste. À vous de définir vos limites, vos paliers, vos pénalités et les règles qui sont pertinentes à votre site … ou plutôt à choisir un algorithme créé par quelqu’un d’autre et adapté à votre cas. L’idée est de non seulement pouvoir modifier ces préférences via une interface mais aussi de pouvoir les exporter automatiquement pour les diffuser à d’autres.

… et efficace …

Bref, c’est une très bonne nouvelle, qui va permettre de voir fleurir des personnalisations de Yslow propre à certains types de sites, aux recommandations internes de votre société, ou simplement adaptées à votre échelle. Je m’abstiens de recopier les images ou le code, vous trouverez tout ça dans la présentation de Stoyan.

Mais on trouve encore d’autres petits outils. Parmi eux des menus pour réindenter le code javascript et faire un passage par JSLint. Là encore, quelques lignes de javascript sont prévues pour rajouter vos propres outils.

Mieux, et ça c’est excellent, il est prévu de sauvegarder votre session de résultat pour une étude plus tard et d’importer de sessions crées par Fiddler ou HttpWatch.

… mais imparfaite

Mais tout n’est pas parfait. Dans les recommandations on trouve la #14 (Make Ajax cacheable). Difficile à dire pour un outil automatisé s’il est normal que tel ou tel appel Ajax soit en cache ou dynamique. Je suis dubitatif sur l’idée d’avoir automatisé cette règle là. Même chose pour la #33 (Components under 25k). La limite de 25k est celle de l’Iphone, mais on a vu que les nouveaux firmware Iphone et Ipod Touch permettent de dépasser allègrement cette limite. Bref, on l’ajoute dans Yslow quand il serait presque venu le temps de la retirer de la liste globale des recommandations.

Il y en a d’autres que j’aurai aimé voir, mais qui doivent être bien plus complexes à automatiser. Par exemple :

• trop de présentation en HTML au lieu de CSS
• code javascript lent
• présence de eval() en javascript
• sélecteurs CSS vraiment mal fait
• événements DOM mutualisables avec de la délégation
• processeur excessivement utilisé lors du rendu
• tableaux html dynamique trop gros ou imbriqués

Ah et … pas de date de sortie ni de version béta publique, pour l’instant. Reste que ces nouvelles sont bonnes.

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.

Il y a des fois où ce n’est pas idéal et c’est Steve Souders qui étudie les solutions dans sa présentation aux conférences Velocity 2008. Quelques cas en vrac :

• Le Javascript est prioritaire, il doit être téléchargé et exécuté le plus tôt possible, mais pas au prix d’un blocage de tout le reste ;
• Il n’est pas possible déplacer l’insertion de la balise à la fin du document, le système ne le permettant pas ;
• Vous ne voulez pas montrer à l’utilisateur que la page est toujours en train de se charger (logo et barre de statut) ;
• Vous ne voulez pas que l’événement onload de la page attende le téléchargement et l’exécution du javascript.

Ne pas bloquer le rendu

Pour résumer les solutions intéressantes abordées par Steve Souders :

Passer par l’API DOM

La première solution est d’insérer le javascript via la création d’un noeud DOM. Le script ne bloque alors plus les nouveaux téléchargements. Le problème principal est que certains navigateur délaient l’événement onload tandis que d’autres l’exécuteront avant la fin du script. Cette différence peut rendre la gestion de la page un peu difficile

var se = document.createElement('script');
se.src = 'http://example.org/test.js';
se.type = 'text/javascript' ;
document.getElementsByTagName('head')[0].appendChild(se);

Passer par une iframe

La seconde solution est d’insérer le javascript via une iframe. Le rendu et les nouveaux téléchargements ne sont pas bloqués, l’événement onload réagit de la même façon sur tous les navigateur. Le défaut est que l’iframe fait elle-même perdre un peu de temps au rendu et que pour réutiliser le contenu on est limité à avoir la page et le script sur le même domaine. Impossible donc d’utiliser un CDN sur un domaine tiers.

Cela demande de plus de réorganiser le script lui même. La page principale devra passer par window.frames[x] pour accéder aux fonctions du script, et le script devra lui passer par parent.document pour accéder au DOM de la page principale.

Passer par XMLHttpRequest

La solution qui peut paraitre magique c’est d’insérer le javascript via une requête XMLHttpRequest. Le script ne bloque ni les nouveaux téléchargements ni l’événement onload. Mieux le navigateur ne montre pas à l’utilisateur que la page continue à se charger. Cela peut amener l’utilisateur à avoir une meilleure impression de vitesse. Par contre on est ici aussi limité à un seul domaine pour la page HTML et le javascript, donc pas de CDN sur domaine tiers.

Je ne vous met pas de code, chacun a sa bibliothèque pour ça. Vous pouvez utiliser DOM ou eval, comme vous voulez.

Passer par un script DEFER

Enfin, vous avez l’attribut DEFER que vous pouvez ajouter à une balise de script des plus classiqes. Là non plus le script ne bloque pas les nouveaux téléchargements … mais uniquement sous Internet Explorer.

Préserver l’ordre d’exécution

Tout ça donne déjà un bon aperçu mais tout n’est pas résolu. Dès que vous avez plusieurs javascript vous avez certainement des dépendances et l’ordre de chargement est important. Là ça se gâte. Vous oubliez la technique de l’iframe qui ne vous garantit rien.  

Si vous pouvez vous permettre d’avoir le javascript sur le même domaine que la page HTML, alors il va vous falloir gérer vous même un code dans XMLHttpRequest pour assurer l’ordre d’exécution.

L’écran 26 de la présentation donne une excellente grille de lecture de tout ça. Et les autres navigateurs ? motus et bouche cousue. Dans l’ensemble les comportements ont des chances d’être similaires à ceux de Firefox, mais c’est à tester. Il y a quelques liens vers le Cuzillon donc si certains veulent tester et donner les résultats Safari et Opera…

Utiliser YUI

L’équipe Yahoo! est toujours sur la brèche côté performance. Vous avez doc un outil YUI pour charger dynamiquement scripts et des feuilles de style en tenant compte des dépendances, sans bloquer le navigateur. Visiblement tout n’est pas clair sur la situation de Safari, il faudrait que je fouille un peu pour tirer ça au clair. D’ordinaire la politique est d’avoir un comportement stable sur tous les navigateurs grade A, dont Safari fait partie, donc j’ai bon espoir que si ce n’est pas déjà le cas, une solution finisse par être trouvée.

Pour le même prix l’outil YUI permet aussi de charger aussi les feuilles de style et éviter leur aspect bloquant sur Firefox.

Stoyan Stefanov en parle lui aussi, en détail.

Et l’avenir ?

Le bon côté c’est que les équipes Webkit et IE8 ont dans leurs cartons la possibilité de charger les scripts sans bloquer le navigateur et en les exécutant dans l’ordre d’apparition dans la page.

Tout ceci est pour demain, et les navigateurs d’aujourd’hui ne sont pas amenés à disparaitre rapidement, mais au moins, à moyen terme, on pourra n’avoir de ralentissement que sur les anciens navigateurs. Reste juste à espérer que Firefox et Opera bougent aussi sur ce point, mais malheureusement je n’ai pas vu d’information dans ce sens.

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.

Le principe est le même : un petit outil en ligne de commande qui optimise l’image sans aucune perte de qualité. Celui ci ne touche donc pas à la compression de l’image elle-même, mais retire toutes les méta-données embarquées dans le fichier.

jpegtran -copy none -optimize -perfect src.jpg dest.jpg

Par défaut il y a des informations sur l’appareil photo, une miniature de l’image, des informations spécifiques au logiciel d’édition type Photoshop, et même pourquoi pas des coordonnées GPS. Tout ça peut être jeté pour une image à destination du web.

D’après Stoyan c’est près de 12% de gain en moyenne quand il a testé dix sites américains à très fort traffic. Ça représente jusqu’à 38% pour les images de blogger par exemple. Quand on sait que sur ces mêmes sites les images représentent près de la moitié du poids total d’une page, c’est plus qu’intéressant.

Et l’analyse ?

Ce billet est le premier d’un changement d’orientation de ce blog. Vous n’aurez pas le droit à un grand billet encyclopédique. Je parlais à chaque fois de trop de choses, en noyant le principal au milieu de détails tout en oubliant des points que j’aurai aimé abordé. Désormais je ferai un billet par argument ou par information. Cela fera plein de petits billets, regroupés grâce à la navigation par tags. 

Vous aurez donc à attendre quelques jours pour me voir retransmettre ce qui me parait intéressant dans la présentation de Stoyan.