Yslow est une petite extension pour firebug qui est lui même une extension pour firefox (vous suivez toujours?). Donc Yslow va donner une note à votre site de A à F en fonction des règles de performances définies par Yahoo. Voici d’ailleurs les 13 règles de performance :
1. Make Fewer HTTP Requests
2. Use a Content Delivery Network
3. Add an Expires Header
4. Gzip Components
5. Put CSS at the Top
6. Move Scripts to the Bottom
7. Avoid CSS Expressions
8. Make JavaScript and CSS External
9. Reduce DNS Lookups
10. Minify JavaScript
11. Avoid Redirects
12. Remove Duplicate Scripts
13. Configure ETags
Lorsque vous lancez le script une belle note va être donnée à votre site, comme à l’école et je n’avoue ne pas être très fier de celle de 2803 : F(44)
Pour information voici la note de performance de quelques sites :
Google : A(99)
Flickr : A (97)
Facebook : D(61)
Digg : A(96)
Et de quelques blogs car je pense qu’il ne faut pas les mettre dans le même sac:
Presse Citron : F(40)
Techcrunch US : F(56)
Mashable : F(47)
Simpleentrepreneur : F(36)
Chauffeurdebuzz : D(62)
Loiclemeur : F(36)
Je crois que vais donc lire les conseils de Yahoo sur la performance on ne sait jamais…
Et vous cela donne quoi en terme de note?
39 Comments
F40 pour moi
F (35)
par contre sur ton image il y a marqué F33 et non F44
En fait j’ai optimisé un peu entre l’image et le post
33 était vraiment trop faible!
henri tu n’as pas trainé ;p
J’ai viré deux trois scripts inutiles…
C’est une note sur 100 ?
Si Google à 99 je crois que oui
Il y a encore du boulot… Bon de là à prendre une offre CDN pour le blog je crois qu’il y a de la marge… Mais n’oublions pas que l’outil est principalement dédié à des sites et pas des blogs de mon point de vue.
F(47) pour moi, je vais retravailler tout ca aussi hein
61 pour moi, loin de google mais j’ai la moyenne, sympa ce script, merci.
D (64) pour ma part
Oh surprise… F (51)
Super intéressant cet outil mais apleins de points d’amélioration techniques où on a besoin d’avoir la main sur son serveur, ce qui je pense, est assez rare pour “nous” blogs ou sites non commerciaux.
Mais c’est à creuser, merci pour l’info
arf au piquet F(44) également…
F(41) pour la version actuelle et F(53) pour la version qui doit sortir dans quelques jours et qui est en phase de finalisation (ptêt que ça va augmenter :))
Chapeau GaKaTaN !
@GaKaTaN belle performance!
Test sur deux de mes sites :
http://blog.lesperlesduchat.com/perles.php : D (64)
http://unearaigneeauplafond.fr : D (67)
Ce qui est intéressant, avec cet outil, c’est qu’en plus de rappeler que l’optimisation d’un site web est importante, il la quantifie, même si c’est d’une manière discutable. Merci pour cet outil, excellent, donc !
Je viens de modifier la configuration de l’un de mes sites pour complaire à notre ami Yslow :
http://blog.lesperlesduchat.com/perles.php : C (79)
Actuellement, pour améliorer mon score, je dois essentiellement réduire la quantité de scripts externes. En effet, sur ce site, j’ai trois systèmes de suivi de trafic (Google Analytics, Xiti et Quantcast). De plus, j’ai plusieurs régies publicitaires (ma propre régie publicitaire à base d’OpenAds, ainsi qu’Oxado), chacune affichant du JavaScript depuis un hôte tiers.
Il existe d’autres optimisations à réaliser identifiées et clairement expliquées par Yslow, mais je doute pouvoir améliorer mon score au-delà du B. En effet, pour monter à la note maximale, A, il faudrait probablement héberger un site web sur plusieurs centres de données locaux (en somme, un par continent, voire un par pays où se trouvent les visiteurs du site), ainsi que de gérer autrement les sous-domaines, voire même changer de régie publicitaire…
Cela étant, la documentation liée aux résultats de l’outil est fort instructive et pertinente !
Merci pour la découverte de cet outil.
On fait des tonnes d’essais depuis ce matin
J’aime bcp le temps réel d’affichage de la page en bas à droite.
Pour info nous avons un A(100) sur notre bon vieux site corporate en FR, comme quoi le web 1.0 a encore du bon !
Non, 36, c’est la loose… Va falloir que je travaille ça
En fait, Franck, avec ton script Google Analytics / Urchin qui figure sur ton site SightUp.com pour le commun des mortels (j’imagine qu’il n’est pas appelé dans le cas d’un utilisateur identifié ou administrateur), ce site-là est à 98/100, même s’il affiche bien un magnifique “A”. Je suis jaloux !
@ Martin > Je parlais du site en FR qui lui n’a pas de GG Anal et donc est à 100. (sightup.fr)
@frank > c’est parce que tu as fait le site sur la page qui définit tes frames… si on regarde la page qui contient effectivement les images et le javascript (http://www.sightup.com/fr/index.html), on a une note qui reste honorable C (70), mais quand même loin du A
@ Lekin > Mince, moi qui croyais être bon, j’ai perdu mes illusions
Merci pour les explications.
lekin & Franck > Tiens, cela montre que la maîtrise de Yslow n’est pas aussi intuitive qu’elle pourrait le sembler, et ce, même pour des professionnels du web. Bref, un excellent outil, simple d’emploi, mais qui mérite que l’on l’étudie de près, afin de pouvoir en interpréter correctement les résultats…
Pour ma part j’ai un F(22) mais ne me demandez pas d’optimiser quoi que soit ce n’est pas ma spécialité et donc je vais devoir me le farcir ce F(22) pour un petit temps sauf si quelqu’un veut fait un tour sur mon blog pour me donner quelques TIPS…;-)
Bonne soirée,
Bon, pour ceux qui cherchent à améliorer le score Yslow, voici quelques astuces simples à mettre en place. Notez que pour exploiter ces astuces, vous devez avoir un serveur web Apache avec la possibilité de placer un fichier “.htaccess” par dossier, ainsi que les modules mod_expires et mod_deflate (Apache 2.0.x) :
1) Dans le dossier de vos skins (avec un blog WordPress, c’est souvent le dossier “/wp-content/themes/”), placez-y un fichier “.htaccess” (sans les guillemets) avec pour contenu suivant :
# DEBUT du fichier .htaccess specifique au dossier skins
ExpiresActive on
ExpiresDefault “access plus 30 days”
FileETag None
# FIN du fichier .htaccess specifique aux skins
2) Dans le dossier où sont stockées les images de votre site, ainsi que d’autres fichiers téléchargeables dont le contenu ne change qu’exceptionnellement (avec un blog WordPress, c’est souvent le dossier “/wp-content/uploads/”), placez le fichier “.htaccess” (sans les guillemets) suivant :
# DEBUT du fichier .htaccess specifique au dossier medias
ExpiresActive on
ExpiresByType image/jpg “access plus 30 days”
ExpiresByType image/gif “access plus 30 days”
ExpiresByType image/jpeg “access plus 30 days”
ExpiresByType image/png “access plus 30 days”
ExpiresByType text/css “access plus 30 days”
ExpiresDefault “access plus 24 hours”
FileETag None
# FIN du fichier .htaccess specifique au dossier medias
3) à la racine de votre site, le fichier “.htaccess” suivant :
# DEBUT du fichier .htaccess global au site
# (ATTENTION ! La configuration de ce fichier est écrasée par
# un éventuel .htaccess apparaissant dans un sous-dossier
# du dossier courant)
ExpiresActive on
ExpiresByType image/jpg “access plus 30 days”
ExpiresByType image/gif “access plus 30 days”
ExpiresByType image/jpeg “access plus 30 days”
ExpiresByType image/png “access plus 30 days”
ExpiresByType text/javascript “access plus 7 days”
ExpiresByType application/x-javascript “access plus 7 days”
ExpiresByType text/css “access plus 30 days”
ExpiresDefault “access plus 1 seconds”
# La configuration (de compression) suivante peut être mal
# supportée par de très vieux et très rares navigateurs web,
# ainsi que certains robots. A voir aussi la compression par
# défaut de vos scripts, voir éventuelle configuration de PHP.INI.
# (Compatibilité avec certains plugins WordPress tels que
# WP-Cache non testée.)
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/plain text/xml
# FIN du fichier .htaccess global au site
Les fichiers de configuration “.htaccess” ci-dessus ne sont certainement pas optimaux et ne correspondent sans doute pas à tous les sites. Néanmoins, ils sont compatibles avec l’immense majorité des sites web et améliorent généralement sensiblement les temps de réponse de ces sites dès la deuxième page chargée.
Si avec ces scripts, il vous venait à l’idée de modifier le contenu d’un fichier, il faut alors changer l’adresse de ce fichier. Pour les éventuelles skins que vous modifiez de temps à autres, pensez à ajouter un numéro de version à la fin du dossier de la skin modifiée. Il y va de même pour d’éventuelles images et autres fichiers mis en cache par le navigateur pour une durée allant jusqu’à 30 jours ici.
merci martin pour ces conseils. Et avec ces htaccess par dossier tu améliores de combien le score?
C’est en appliquant ces quelques “.htaccess” et en supprimant quelques scripts inutiles que je passe de D (64) à C (79) sur l’un de mes blogs. Je n’ai pas touché aux autres sites, ceux-là ayant un trafic suffisamment confidentiel pour que ces optimisations n’aient aucun impact réel…
Oups ! Je viens de me rendre compte que notre ami WordPress, au lieu de convertir les > et autres <, a sucré les balises “IF” des “.htaccess” ci-dessus… Bon, cela n’a aucune incidence si Apache intègre correctement ces divers modules, mais peut résulter sur une erreur interne du serveur (501) dans le cas contraire. Dans un tel cas, il suffit de remettre le contenu précédent des fichiers “.htaccess”, ou de les supprimer, tout simplement.
Effectivement Martin je confirme qu’après le changement, j’ai eu droit à un beau “501″.
Est-ce que tu sais d’où provient l’erreur ?
a+
Je ne suis pas chez moi jusqu’en début de semaine prochaine, je posterai de nouvelles versions avec les bonnens balises “IF” manquantes ici même lundi ou mardi au plus tard.
merci martin!
Merci Martin
Bon, revenons donc à notre ami le “.htaccess” et Yslow. Comme nous l’avons vu plus haut, on peut cibler trois dossiers différents avec un “.htaccess” spécifique :
- la racine du site/blog qui s’appliquera à tous les sous-dossiers sauf changement de configuration spécifique avec un “.htaccess” apparaissant dans les divers sous-dossiers du site ;
- le dossier des skins (et ses sous-dossiers) ;
- le dossier des fichiers média (et ses sous-dossiers).
L’amélioration du score du site (en fait, des pages composant le site) avec Yslow vise à configurer :
- le cache des éléments servis par le serveur web pour indiquer aux navigateurs de ne pas recharger les éléments qui changent peu fréquemment ;
- les modifications des données (ETag) ;
- la compression des données.
On notera que le contenu des images ou de JavaScript d’un site web ne change que très exceptionnellement. Aussi, ajouter les lignes suivantes dans un “.htaccess” permet d’indiquer au navigateur de les garder dans son cache pour un mois :
# .htaccess (début)
# prévu pour fonctionner avec Apache 2.0.x
<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/jpg “access plus 30 days”
ExpiresByType image/gif “access plus 30 days”
ExpiresByType image/jpeg “access plus 30 days”
ExpiresByType image/png “access plus 30 days”
ExpiresByType text/javascript “access plus 30 days”
ExpiresByType application/x-javascript “access plus 30 days”
ExpiresByType text/css “access plus 30 days”
ExpiresDefault “access plus 1 seconds”
</IfModule>
# .htaccess (fin)
Bien entendu, si vous avez l’intention de modifier le contenu des fichiers images ou JavaScript, vos visiteurs risquent de ne pas visualiser ce nouveau contenu avant 30 jours. Aussi, la seule solution pour leur permettre de le visualiser immédiatement est d’abandonner l’ancien fichier pour en proposer un nouveau avec un nom de fichier distinct de l’ancien. Si vous devez développer une skin pour votre site, ou encore un script particulier, pensez à désactiver le cache pour le dossier concerné.
Les serveurs web ont une autre façon d’indiquer au navigateur de ne pas recharger une ressource : l’ETag. C’est un identifiant unique spécifique à chaque fichier permettant d’indiquer au navigateur si la ressource a été modifiée sur le serveur, dans quel cas il faut la recharger, ou si elle est restée inchangée, dans quel cas il faut éviter de la recharger depuis le serveur et utiliser celle présente dans le cache du navigateur.
Or, si l’ETag est excellent pour gérer les modifications éventuelles d’une ressource, ils ne sont plus utiles maintenant que nous venons de mettre en place les instructions de cache ci-dessus. Cela fait double emploi avec le cache. Sachant que l’ETag nécessite une communication avec le serveur pour chaque ressource composant une page, alors que le cache permet d’indiquer une bonne fois pour toutes la date d’expiration d’une ressource au moment de son premier chargement, il est préférable d’opter pour la gestion du cache plutôt que pour l’ETag, sauf cas particulier.
Pour désactiver la gestion de l’ETag, on peut ajouter les lignes suivantes à son fichier “.htaccess” :
# .htaccess (début)
# prévu pour fonctionner avec Apache 2.0.x
# Désactivation de l’ETag
FileETag None
# .htaccess (fin)
Enfin, les pages web, scripts et autres feuilles de styles sont des fichiers texte très fortement compressibles. La quasi-totalité des navigateurs web actuellement utilisés gère sans aucune difficulté cette fonctionnalité qui permet de réduire la taille des données qui transitent au travers du réseau. Il y a cependant des exceptions abordées sur la page de documentation du module mod_deflate (Apache 2.0) gérant cette fonctionnalité sous Apache. A moins d’un cache dédié à cette compression, celle-ci se fait au moment de l’envoi des ressources à l’utilisateur, et consomme par conséquent du CPU au profit d’une bande passante réduite. On peut activer cette compression de la manière suivante :
# .htaccess (début)
# prévu pour fonctionner avec Apache 2.0.x
# Voir http://httpd.apache.org/docs/2.....flate.html
# pour des informations complémentaires.
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/plain text/xml
</IfModule>
# .htaccess (fin)
A noter que le module mod_deflate est apparu avec Apache 2.0.x et que les serveurs Apache 1.3.x devront utiliser mod_gzip (voir http://www.schroepl.net/projekte/mod_gzip/ ).
Bref, j’espère qu’avec ces quelques explications, tout le monde saura configurer son serveur Apache correctement pour améliorer les performances du site sans nuire aux visiteurs et en évitant la fameuse erreur 501 (qui arrive notamment lorsqu’Apache rencontre un fichier .htaccess qu’il n’est pas capable d’interpréter, notamment du fait d’un module non supporté par le serveur).
eh bé ! sympa ces longues explications. Merci Martin
Salut, ben il y a du mieux pour 2803 vu que il ressort un F (52)
Bon , je sais ça fait un peu faillot T_T, je vous donne ma note: B (81)
Sinon, bien de relayer ce genre de chose, il y a pas mal de monde qui devrait s’en préoccuper …
Pour le htaccess, je vous file les miens, un poil différents, mais équivalent (pour les dates d’expirations notamment)
Pour les expirations:
### activate mod_expires
ExpiresActive On
### Expire les fichiers un mois après leur accès
ExpiresByType image/gif A2592000
ExpiresByType image/png A2592000
ExpiresByType image/jpg A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType text/css A2592000
ExpiresByType application/x-javascript A2592000
Ah oui, aussi il n’est pas recommandé de désactiver les ETags si votre site est en “multi-source” sinon ce sera l’embrouille sur la fraîcheur des headers
Sur octeam, j’ai un C70, pas un B 81. Vous ne parlez pas du même site peut-être.
Si si, oui actuellement C79, j’ai remis une GoogleAds depuis et peut être du fait que personnellement j’ai configuré (donc shinté) les CDN dans ma configuration Firefox comme l’explique Yslow ici: http://developer.yahoo.com/yslow/faq.html#faq_cdn
(Using these CDN hostnames from your preferences:)
F36 sur gabyu.com