Google propose donc un codage supplémentaire pour HTTP qui s’appelle SDCH, et qui peut s’ajouter avant gzip ou deflate. Le serveur découpe sa page en paquets, qui peuvent chacun avoir des métadonnées et une expiration explicite. Le tout est stocké dans un dictionnaire du côté du navigateur, un peu comme les cookies actuellement. Quand le navigateur demande une page il envoie les identifiants de paquet qu’il connaît déjà, le serveur peut donc se contenter de compléter ce qui manque. On a donc le même fonctionnement que les Etag du point de vue de la négociation.

Les entêtes HTTP en jeu sont Avail-Dictionnary (l’équivalent de Etag pour SDCH) et X-SDHC (pour déclarer la version et l’implémentation de SDCH utilisée) du côté du navigateur, et X-SDCH-Dictionary du côté du serveur.

Reste que cela implique que la réponse du serveur soit codée suivant une forme bien particulière, non compatible avec les anciens clients HTTP. Google a donc prévu une auto-négociation et la réutilisation de l’entête Accept-Encoding. Grâce à cela, les navigateurs qui le peuvent auront un contenu SDCH puis compressé par gzip, les autres se contenteront du gzip.

Si vous voyez passer un Accept-Encoding: sdch, gzip c’est que votre navigateur supporte ce codage. Si en plus vous voyez une réponse Content-Encoding: sdch, gzip c’est que le serveur a bien compris que vous supportiez SDCH et va utiliser ce codage.

Je n’ai vu aucun mouvement ni aucune volonté de mouvement de la part de Mozilla, en fait depuis la communication de Google l’idée n’a pas l’air d’avoir fait recette où que ce soit. Seul un groupe de discussion, quasi vide, a fait suite à la communication de juin 2008.

Chrome a un premier support de SDCH (non activé par défaut pour la version publique actuelle) mais ça ne changera pas la face du monde. Le point intéressant est toutefois que SDCH est automatiquement intégré à Microsoft Internet Explorer si la Google toolbar est installée. La page d’aide de Google indique comment désactiver tout ça.

Si l’idée peut être intéressante, je suis un peu étonné que Google tente de l’imposer de lui-même sans avoir le support d’au moins un intervenant (Mozilla, Opera, Apple, Microsoft) ou une publication normative officielle de type RFC. La seule chose qui sauve cet unilatéralisme est la présence d’une version dans l’auto-négociation (donc on pourra gérer d’éventuelles évolutions dans les spécifications si jamais tout le monde se met autour de la table pour en rediscuter).

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.

Qu’est ce qu’un ETag ?

Un ETag sert au serveur web à identifier une ressource et sa version. La valeur d’un ETag est libre, la seule contrainte est que l’ETag soit unique pour une URL donnée. Deux versions d’un même document auront donc deux ETags différents ; dans le temps la valeur d’un ETag ne devrait pas changer si le document lui même n’évolue pas. Cet ETag est renvoyé par défaut à chaque fois que le serveur web renvoie un contenu. On obtient donc quelque chose comme suit dans les entêtes d’une réponse HTTP 1.1 :

HTTP/1.1 200 OK
Date: Sun, 08 Jun 2008 13:53:40 GMT
Last-Modified: Mon, 04 May 2008 19:43:54 GMT
Etag: "3a4ea77d-baa-f3a45280"

Le navigateur s’en sert pour identifier les versions des documents qu’il met en cache. Quand on lui demandera de nouveau la même ressource, il fournira cet identifiant dans une entête de la requête HTTP. On parle alors d’une requête conditionnelle.

GET /test.html HTTP/1.1
Host: www.example.org
If-Modified-Since: Mon, 05 May 2008 19:43:54 GMT
If-None-Match: "3a4ea77d-baa-f3a45280"

Le serveur compare l’ETag reçu par le navigateur avec celui de la version actuelle du document demandé. Si les deux ne correspondent pas c’est que le document a été modifié depuis le dernier accès et on le renvoie normalement. Si les deux sont identique alors le serveur web peut utiliser le code de retour 304 et demander au navigateur d’utiliser sa copie en cache. On évite alors de télécharger de nouveau le document, inutilement. C’est intéressant autant pour le serveur que pour le client :

HTTP/1.1 304 Not Modified
Etag: "3a4ea77d-baa-f3a45280"

D’autres détails (presque) inutiles

En réalité c’est même un peu plus complet que cela puisque le navigateur peut retenir plusieurs versions du même document dans son cache et les renvoie toutes, séparées par des virgules. De son côté le serveur peut aussi avoir plusieurs formats pour un même document. Il va donc comparer toutes les dernières versions avec les identifiants proposés par le navigateur, et retourner un 304 pour la première qui correspond, en spécifiant bien pour que ETag il renvoie ce statut.

On peut aller plus loin en utilisant des identifiants dits forts et des identifiants dits faibles. Ces derniers sont préfixés par W/ et ne peuvent être utilisés que pour des requêtes GET et HEAD. Un identifiant faible est un identifiant qui peut correspondre à plusieurs représentations différentes d’un même document, ou à plusieurs versions d’une même représentation.

On trouve même la possibilité pour le navigateur d’utiliser un If-None-Match:*, qui ne va effectuer la requête que si la ressource ciblée n’existe pas encore. Soit que la représentation adaptée à cette requête particulière n’existe pas (version du navigateur par exemple), soit quelle n’a pas encore été générée et est générée à la demande.

Sur des requêtes de type POST ou PUT (en fait sur tout sauf GET et HEAD), la réponse n’est pas 304 (not modified) mais 412 (precondition failed). Sur un PUT le If-None-Match:* peut d’ailleurs gérer les problématiques de concurrence d’accès : la requête ne sera effectuée que la première fois, par la suite la ressource sera déjà crée et un statut 412 sera renvoyé.

Les problèmes d’ETag

En soit ce fonctionnement ne pose aucun problème. Il est supporté par l’essentiel des navigateurs et des serveurs. Quand un des intervenants ne connait pas les ETags ils sont ignorés et c’est le comportement Last-Modified / If-Modified-Since qui prend la main.

Il n’y a que deux problèmes potentiels : deux versions d’une même ressource avec le même ETag, ou deux ETags différents pour une même version d’une ressource. Dans le premier cas le navigateur risque de réutiliser son cache alors qu’il existe une mise à jour. Dans le second cas, celui qui nous préoccupe, le navigateur risque de re-télécharger un document qu’il a déjà en cache.

C’est ce dernier cas qui arrive parfois sur certains sites, et qui impacte les performances à cause de la bande passante utilisée inutilement. Cela arrive dès qu’il y a plusieurs serveurs derrière un même site web. Apache utilise par défaut un identifiant basé sur la date de dernière modification et l’inode du fichier. L’inode est garantit comme unique pour un même système de fichier.

S’il y a plusieurs serveurs, chacun a son propre système de fichier. L’inode sera différent sur chaque serveur, et le client risque de recevoir des ETag différents pour la même ressources. Pour peu que la requête du navigateur ne soit pas toujours gérée par le même serveur, tout le système de cache basé sur l’ETag sera mis en échec.

Sur certaines anciennes versions de lighttpd, des serveurs 32bits et des serveurs 64bits peuvent aussi donner des ETags différents bien que l’inode n’intervienne pas dans le calcul. 

Désactiver les ETags

Conclusion simple et rapide de l’équipe performance de Yahoo! : désactiver les Etags. En l’absence des ETags c’est en effet le mécanisme habituel de date de modification qui est utilisé pour générer les 304 et les caches. Ce système n’est pas parfait mais pour des ressources qui ne sont pas amenées à changer plusieurs fois par seconde il n’amène aucun problème.

En suivant les recommandations habituelles on ne modifie justement presque jamais une ressource statique, on créé la nouvelle version avec une nouvelle URL et on laisse l’ancienne telle quelle. Les ressources dynamiques, elles, à cause des personnalisations et des mises à jours très fréquentes, n’utilisent de toutes façons que rarement les 304 et ces systèmes de validation de cache. Quand elles le font c’est que les mises à jour ne sont pas trop fréquentes ; la limitation imposées par la résolution à la seconde des dates de modification n’est alors pas gênante.

Bref, on ne perd pas grand chose et on évite des problèmes dont on sait qu’ils vont survenir.

Sous Apache c’est fait avec FileETag none. Pour Microsoft IIS il y a toute une procédure.

Réactiver les ETags ?

Déjà, tant que vous avez un seul serveur derrière votre site web, n’hésitez pas : activez les ETags même si Yslow vous dit le contraire. Vous avez tout à y gagner et rien à y perdre.

Ensuite, activer tout de même les ETags n’est pas forcément une mauvaise idée. Le problème n’est pas sur la fonctionnalité elle-même, mais juste sur la façon par défaut pour Apache et IIS de générer ces identifiants. Bref, en général un cumul entre la date de modification et la taille du fichier suffit. Dans ce cas vous pouvez demander à Apache d’utiliser FileETag MTime Size.

Enfin, ne changez pas et ne supprimez pas le calcul des ETags sur les sites qui utilisent DAV via le mod_dav_fs. Ce dernier risque de ne plus fonctionner de manière optimale.