YSlow donnant des résultats incohérents sur ETags

Lorsque je lance YSlow sur mon site, j'obtiens un "F" sur l'item "Configure ETags"; Cependant, si je lance directement le test sur l'une de ces images, j'obtiens un A sur le test d'etag. De plus, sur les en-têtes Response du panneau Firebug Net, je peux voir l'etag sur cet item pour les versions full-page et direct-url.YSlow donnant des résultats incohérents sur ETags

Y at-il quelque chose que je pourrais faire pour causer ce comportement étrange?

(Les URL que je suis Débarquent here et here si quelqu'un veut vérifier eux-mêmes. Je ne me dérangerait pas une vérification de bon sens pour voir si elle est juste mon navigateur qui est confus.)

Source

2010-01-21 Craig Walker

juste essayé ce local avec FF 3.6 et YSlow 2.0.3 (version nouvellement publiée) et l'image autonome Donne un score de "B", citant des ETags mal configurés. L'ETag apparaît dans l'en-tête, dans le panneau de réseau FireBug et dans le panneau de composants YSlow.

Mais, c'est par nature. Si vous regardez http://developer.yahoo.com/performance/rules.html#etags vous verrez que les ETags générés par défaut par IIS et Apache ne sont pas optimaux.

Pour référence, la règle de la charpie réelle YSlow vérifie les deux expressions rationnelles suivantes:

apache_re = new RegExp("^[0-9a-z]+-[0-9a-z]+-[0-9a-z]+$"); 
    iis_re = new RegExp("^[0-9a-z]+:[0-9a-z]+$");

Source

2010-01-22 11:30:34

Encore plus bizarre avec le score "B". Je vais essayer de mettre à jour et voir ce que je reçois. Merci! –

Je pense que le problème de YSlow est que, bien que les ETags soient présents, la façon dont IIS les génère les rend vraiment inefficaces et changent trop souvent. Cela signifie que les utilisateurs obtiendront 200 codes de réponse plus souvent qu'ils ne le devraient. (Le lien YSlow fait un meilleur travail d'explication que moi!) –

Ma réponse, en ce qui concerne IIS 7, est d'ignorer la recommandation de YSlow. IIS 7 utilise un numéro de modification de métabase de zéro lors de la génération de l'ETag. C'est la partie après les deux points ... donc l'etag sera toujours quelque chose comme "5321116d3585ce1: 0", où la première partie est générée à partir du dernier fichier modifié, puis un deux-points et le numéro de métabase change. À partir d'IIS 7, Microsoft a défini ce numéro de modification sur zéro tout le temps, de sorte qu'il en sera de même sur plusieurs serveurs Web. Pour IIS 5 et 6, vous pouvez le mettre à zéro si vous voulez obtenir le même résultat final:

http://technet.microsoft.com/en-us/library/ee619764(WS.10).aspx

Si YSlow utilise encore une règle de regex de iis_re = new RegExp ("^ [0 -9a-z] +: [0-9a-z] + $ "); alors ils ont tort, et il devrait être réécrit pour accepter l'etag comme valide si elle se termine par : 0

Source

2013-10-09 15:42:20

YSlow donnant des résultats incohérents sur ETags

Répondre

Questions connexes