Alors voilà, Charles-Christian Croix nous parle un peu de ce qui a été réalisé sur Voici.fr. La première étape se fait via une configuration des entêtes HTTP de cache de ezPublish puis une configuration de mod_gzip sur Apache, et enfin par une configuration de mod_expires, toujours sur Apache. Il fait de même plus tard sur une installation Dotclear.

On peut regretter l’expiration très courte (une journée) accompagniée d’un must-revalidate, mais je me permet d’insister avec intérêt sur le Cache-Control: public très important dans le cas d’une application PHP. EzPublish utilise très probablement les sessions PHP, qui ajoutent par défaut un Cache-Control: private. il faut donc le corriger.

Dans un autre billet on voit le résultat sur le squid de la gestion du cache des images et de la compression HTTP :

Dans une seconde partie il nous parle de compression d’images. Là aussi les solutions sont connues mais c’est appréciable de voir quelqu’un le mettre en œuvre et en parler ensuite. Sur les PNG il identifie un gain moyen d’un tiers pour le poids des images. C’est plus que conséquent, et ça aura un effet visible et sur le client et sur votre infrastructure. Je me permet juste d’apporter un bémol sur l’utilisation du paramètre -brute de pngcrush, qui est loin d’être le meilleur compromis gain/temps.

Modules apache

La présentation débute par des liens vers quelques modules Apache pour automatiser les tâches que je recommande ici régulièrement : concaténation, minimisation, retravail des images.

Pour la concaténation des javascript et css il propose mod_concat dont j’avais brièvement parlé en mars. Il s’agit simplement d’automatiser le processus de concaténation des fichiers javascript et css via un module Apache. Les entêtes de cache utilisées sont celles du fichier le plus récent, vous n’avez rien à gérer, il suffit d’ajouter les noms de fichiers souhaités dans l’URL.

Pour la minimisation nous propose modjsmin, qui est simplement le script de minimisation de Douglas crockford transformé en filtre Apache. Côté images il y a c’est moddims qui redimensionne et découpe les images à la demande avec Image Magick. Si vous vous devez d’utiliser des solutions dynamiques alors ce sont probablement des liens à suivre, mais je continue à penser qu’il vaut mieux traiter ça hors ligne à la publication et pas sur le serveur web.

Les publicités

La seconde partie de la présentation est plus intéressante. Notamment Dave donne sa solution pour le problème persistant de tout intégrateur web : les publicités lentes et bloquantes. Il propose ici de les charger dans une iframe de façons à ce que le contenu de la page générale continue de se charger, puis récupère le DOM et les styles pour les regreffer dans le document principal (ce qui est obligatoire si votre publicité risque d’interagir avec le reste de la page). En pratique il y a quelques écueils quand j’avais essayé, tout dépend donc de ce que vous faites tourner en publicité.

Chargement à la demande

Dave a aussi mis au point un mécanisme que j’aime beaucoup. Il s’agit d’exploiter la différence entre la mesure brute de la performance et le ressenti de performance. L’utilisateur n’a pas besoin d’une page qui se charge vite, il a besoin d’une page qui charge vite ce qu’il a sous les yeux. Seuls 20 % des utilisateurs lisant jusqu’à la fin de la page, il est envisageable de ne charger les composants du bas de page qu’à la demande, quand l’utilisateur passe au dessus. Dave a donc fait un petit outil appelé Sonar pour détecter quand charger quel élément, et faire les ajouts/requêtes nécessaires.

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.