le lab

Un des critères de notation utilisés par l'excellent YSlow pour apprécier la qualité de votre site est l'utilisation des ETags. D'ailleurs, si on consulte les commentaires laissés à ce sujet, on voit l'équipe de Yahoo obligée de se justifier.

Je vais essayer de traduire le consensus sur la question et de vous expliquer en termes simples ce que sont ces ETags.

1. Qu'est ce qu'un ETag, à quoi ça sert?

Un ETag est un code renseigné par le serveur web sur une ressource, et qui est fourni avec l'en tête de la ressource. Cela ressemble à ça: "1ed39b-9a6-45ce4f9c", ou à "-346776727645". Ce code identifie 'de manière unique' la ressource dans le temps et dans son chemin.

C'est donc là pour valider l'unicité d'une ressource ou d'une représentation.

2. Comment sont fabriqués les ETags

Les ETags sont créés par le serveur qui renvoie la ressource. Celui ci utilise différents critères pour créer l'ETag.

Apache utilise par défaut la combinaison de trois éléments pour créer l'ETag : l'inode du répertoire où est stocké la ressource, le timestamp unix (une mesure des millisecondes) et la taille du fichier.

IIS utilise une autre façon de générer les ETags. Le format par défaut est Filetimestamp:Changenumber où Changenumber est un compteur dans le serveur.

Mon serveur lighttpd une autre encore. C'est toutefois encore une combinaison de node-value (emplacement sur le disque), un timestamp et la taille

3. Où sont les ETags?

Les ETags sont dans les entêtes des ressources qui sont envoyées par les serveurs http. Lancez votre firebug et regardez une ressource statique sur le site du meilleur opérateur de la planète (qui n'a pas l'iphone toutefois). Et regardez l'entête d'une image. Vous y verrez quelque chose comme "df0fd-1ca1-44fc2b84".

4. Quand sont ils utilisés?

Quand le cache veut utiliser un objet qu'il détient déjà, et qu'il veut l'utiliser comme réponse à la requête d'un client, il doit d'abord vérifier avec la source (ou avec un cache intermédiaire qui a une donnée plus fraîche) pour voir si sa ressource mise en cache est utilisable (HTTP 1.1 spec 13.3).

Ce cas de figure peut se produire de plusieurs façons:

- vous n'avez pas mis d'informations de cache, comme max-age:36000, si bien que votre cache n'a pas beaucoup d'informations pour juger de la fraicheur de ses ressources. Votre ressource n'est pas fraîche, le cache doit s'assurer de la fraîcheur avant de vous la donner. - la date de validité calculée de votre ressource est dépassée. Votre agent doit alors savoir s'il dispose de la représentation la plus fraîche de la ressource.

Bien sûr, quand je parle de cache, je parle à la fois de votre navigateur et d'un cache intermédiaire (rproxy, proxy, cdn).

5. Est ce que ça marche?

Pour la plupart des sites, cela fonctionne PARFAITEMENT dans la distribution et les réglages de base. En effet pour la plupart des sites, quand un cache a besoin de valider la fraîcheur d'une ressource en envoyant une ressource de type If-None-Natch, le serveur renvoie une réponse de type 304 : Not Modified.

Le but des ETags est alors rempli : au lieu de faire un aller-retour avec une réponse complète contenant toute la ressource, on a une réponse ne contenant que quelques octets : la transaction est normalement beaucoup plus rapide.

Pour les sites plus gros qui ont besoin de plusieurs serveurs web pour servir leurs fichiers statiques, cela peut devenir plus délicat à utiliser. En effet dans ce cas, il est probable que l'ETag généré pour une ressource (pourtant la même) soit différent suivant le serveur qui la génère, ne serait ce que parce que le inode est différent d'un serveur à l'autre.

Oui, c'est un problème de riche.

6. Comment éviter d'avoir des problèmes à cause de ses ETags

Première solution : n'utiliser aucun cache. Oui, cela va à l'encontre de tous les principes, mais si on ne met pas de directive de cache et qu'on envoie pas d'ETag, on ne risque pas d'avoir le problème évoqué plus tôt.

Deuxième solution : faites en sorte que vos ETags ne soient jamais nécessaires, avec des ressources qui ont des durées de mise en cache très importante. Pas très malin non plus, et difficile à appliquer à tous les fichiers.

Troisième solution : ne pas utiliser les ETags. Il existe un autre mécanisme de validation (la validation légère) qui repose sur l'entête 'Last-Modified'. Bien que cette validation soit moins précise, elle conviendra dans 99,99% des cas. Bien sûr, il faudra que cette information soit la même sur vos différents serveurs.

Quatrième solution : faites en sorte que vos ETags soient les mêmes sur tous vos serveurs. Pour cela, rabattez vous sur les deux arguments qui peuvent être les mêmes d'un serveur à l'autre : la taille et le timestamp de dernière modification.

7. Les cas limites

Les fichiers gzippés sont différents à chaque fois qu'ils sont regénérés : l'ETag est différent d'une requête à l'autre. Dans ces conditions, lETag n'a servi à rien car on ne peut jamais validé (même si la ressource qui est gzippée n'a pas changé).

Amazon.com: Hail To The Thief: MP3 Downloads: Radiohead

Pour une fois que je trouve Radiohead en qualité potable et en mp3, il faut que ce soit sur un site où seuls les américains peuvent acheter. A 8,99 usd, j'aurais pris....

Lorsque l'on veut comprendre ce qui se passe sur son site, analyser les causes de lenteurs, observer dans le détail le téléchargement de chacune des ressources.

J'ai remis le plat il y a peu de temps sur Yslow. Je n'ai pas fini d'en parler, ni de détailler les usages spécifiques pour lesquels cet outil permet d'aller beaucoup plus vite. Mais il y a d'autres outils.

Un outil dont j'ai parlé auparavant, notamment dans l'ebook 'Accélérer l'affichage de vos pages web' est Tamper Data. C'était mon outil de prédilection avant que Firebug ne soit mis à jour et que Yslow ne vienne se greffer dessus. Il fournit des infos comparables pour ce qui est des requêtes et réponses. Il existait avant Firebug; mais n'a pas reçu de mise à jour depuis octobre 2006. Un avantage très important qu'il avait par rapport aux autres outils : il pouvait exporter la trace d'un parcours et des téléchargement effectués sous la forme d'un fichier texte ou xml.

Aujourd'hui, je l'ai mis à la poubelle pour l'analyse des requêtes. Une série de tests de comparaison ont en effet permis de se rendre compte qu'il avait une influence sur la mesure et qu'il pouvait ralentir ou empêcher le téléchargement de certaines ressources. Cela, plus le fait que le développeur ne répond pas à mes mails et que l'outil n'a pas été mis à jour depuis un an... Je le cantonnerai désormais à son usage d'origine : modifier les requêtes (il permet en effet d'agir sur les requêtes avant qu'elles ne partent du navigateur).

HttpWatch est un outil de prise de traces qui existe en deux version : gratuite et payante. Je n'utilise que la gratuite qui me suffit. La payante permet d'analyser a posteriori les traces d'un parcours car elle relit la trace complète de toutes les requêtes et réponses (header et description) en fonctionnant comme un véritable outil de capture réseau.

La dernière mise à jour de cet outil, la version 5.0 ajoute une fonctionnalité qui était devenue indispensable et manquait cruellement : le chronogramme des téléchargements. Sauf que cette fois, ils sont allés un peu plus loin en ajoutant dans le chronogramme la distinction entre les différentes phases d'un chargement (dns, connect tcp, etc).

Cet outil souffre d'un gros défaut qui est aussi son gros point fort : il fonctionne avec Internet Explorer (6.0 et 7.0). Il se branche sur ce navigateur, ce qui permet de mieux savoir comment se produisent les parcours de 80% de vos visiteurs.

Si vous avez besoin de mieux connaître vos headers et réponses et que vous n'avez que la version gratuite, rabattez vous sur Firebug. Ou utilisez le troisième outil, celui ci en développement encore, l'inspecteur de Safari. Safari existe en effet maintenant à la fois pour mac et pour windows, bien qu'en beta pour le moment. L'inspecteur fait en javascript permet à nouveau de voir l'enchaînement de tous les chargements d'objets sur la page. Le comportement de Safari est différent, il est intéressant à voir. Le résumé du chargement d'une page surtout est intéressant : vous avez la vue à la fois en poids et en temps du chargement de tous vos objets.

Si vous avez d'autres outils à montrer qui permettent de mieux comprendre ce qui se passe, et ce qui ne va pas, vous êtes invités à rajouter vos commentaires sur la question.

Cet article est le deuxième d'une série que je consacre à YSlow pour savoir comment tirer le meilleur parti de cet outil quand on a des problématiques de performance à gérer.

Il y a une petite semaine, quelqu'un m'a demandé comment valider que les contenus de son site de commerce étaient aussi petits qu'il le fallait. Il a lancé Firebug et a regardé un par un chacun des items qu'il pouvait envoyer compressé. Le soir même, j'ai remarqué que YSlow dans sa dernière version fournissait une vision plus rapide et plus efficace de la même problématique :

En effet, cette extension classe les requêtes par types de composants, puis indique le mode de compression (le cas échéant) et fait la comparaison entre la taille compressée et non.

Cela m'entraîne à faire un petit retour sur la compression des fichiers avant le transport, sujet traité dans mon livre Accélérer l'affichage de vos pages web. Cette compression est en effet un des moyens d'améliorer la performance de vos pages web. Il consiste à envoyer aux navigateurs des fichiers compressés (donc moins lourds). Ceux ci sont dans 99,99% des cas capables de les décompresser à la volée. On peut ainsi économiser de précieux octets (dans le cas de TF1 présenté, c'est 150 Ko).

Cette possibilité de compression n'est pas à appliquer à tous les fichiers : seuls les fichiers 'texte' bénéficient vraiment de la compression. Cela comprend les fichiers html, les fichiers javascript et les fichiers css. Si votre page est dynamique, demandez à votre serveur de la compresser à la volée (s'il n'est pas capable de le faire, c'est qu'il vous a coûté très cher ou que votre prestataire veut vous ajouter des lignes à votre bon de commande).

• Les images gif, jpg, ou png ne doivent pas être compressées, cela ne sert à rien : elles le sont déjà.

• Cela ne sert pas à grand chose non plus de compresser des fichiers de très petite taille : ici par exemple, tf1 gagne 0,1k sur un fichier de 0,2k. Le rapport temsp de compression/ gain de poids n'est pas grandiose...

Gardez à l'esprit que votre effet de levier sera plus important sur les fichiers les plus gros et que vous devez vous poser la question de la compression pour tous les fichiers texte qui sont sur votre page (y compris vos tags de stats et de publicité), et que vous devez donc faire bosser vos partenaires pour qu'ils ne détruisent pas vos efforts.

Réussissez vos photos numériques by Cyril Godefroy (Book) in Arts & Photography

Ayé, c'est lulupublié... Aïe la fabrication d'un livre en couleurs, c'est cher.

Il était temps que je parle moi aussi de YSlow, l'extension à Firebug, qui est une extension à Firefox (pfiouh...). Cette extension a quelques mois déjà puisqu'elle est sortie en juin/juillet. Si vous n'en avez pas entendu parler, c'est que vous vivez dans une caverne.

Le principe est simple : macher les résultats donnés par firebug et les faire passer au travers du filtre des règles édictées par Steve Souders du Yahoo Performance Group, et présenter ces résultats. Cela donne cela sur fr.yahoo.com:

Vous ne devez pas vous arrêter au premier onglet de résultats pour comprendre ce qui se passe sur votre site web et en bénéficier. Après tout, les règles en question ne sont pas celles de tout le monde.

Allez tout de suite sur le deuxième onglet pour oberver :

• la taille de vos cookies
• ce que vous pouvez gagner avec un bon cache
• le nombre de requêtes effectuées pour construire la page

Je l'ai déjà dit, la taille des cookies peut devenir un facteur fortement impactant de la qualité et de la rapidité de votre site, sur des connexions adsl où vous devez avoir des requêtes légères.

Le cache est essentiel à une bonne performance de votre site, tant pour un parcours (l'internaute ne recharge plus les fichiers cachés d'une page à l'autre) que pour un premier accès (les proxies cachent pour vous vos contenus statiques).

Le nombre de requêtes est aussi plus important que le poids des éléments chargés (d'où le conseil d'utiliser des css sprites) : on voit parfois des requêtes plus lourdes que les réponses, et cela prend plus de temps d'envoyer une requête que le temps du trafic réseau de la réponse.

L'onglet components permet de vérifier la compression gzip de vos contenus et vous conseille sur les contenus qui devraient être gzippés. Regardez le avec attention pour voir où vous pouvez gagner avec une simple directive Apache (dans la plupart des cas).

Je reviendrai plus tard en détail sur les utilisations et les choses à vérifier avec cet outil très malin.

Vous voulez en savoir plus sur l'amélioration des performances de votre site web? Lisez le livre que j'ai écrit sur les différents facteurs de ralentissement, les solutions existantes et la méthode pour analyser et corriger vous même vos défauts.