Yslow pour mesurer la performance de votre site selon Yahoo

43 commentaires sur “Yslow pour mesurer la performance de votre site selon Yahoo”

1. 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.

2. merci martin!

3. Merci Martin ;-)

4. 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).

5. eh bé ! sympa ces longues explications. Merci Martin :)

6. 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 ;)

7. Sur octeam, j’ai un C70, pas un B 81. Vous ne parlez pas du même site peut-être.

8. 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:)

9. F36 sur gabyu.com

10. J’ai trouvé cette extension vraiment sympathique même s’il faut relativiser son utilité.

    En très peu de temps, j’ai pu passer le score d’un site de 61 à 97. Pour ceux que ça intéresse, j’ai fait un compte-rendu : http://blog.lecacheur.com/2009.....s-minutes/

11. Bonjour,

    concernant les headers, j’aimerais savoir si le cache est automatiquement regénéré lorsque la source du fichier (image, css, etc.) est modifiée ? Cela me serait plutôt utile en développement, où je modifie souvent mes fichiers. Ou encore, si un jour, je veux pouvoir modifier un fichier sans supprimer manuellement son cache associé.

    Merci.

12. Après quelques optimisations je suis passé à 90. Et sur un projet en cours de dev, je suis à 100, et les moyens mis en œuvre sont assez simples, le résultat en terme de rapidité d’affichage est bluffant !

13. Grade(A) Overall performance score 96

    et je ne pense pas pouvoir améliorer ;)
    ceci grace au htacces, Gzip , compression des images, mise en cache, code php optimiser (retrait des ligne et commentaire superflue ) compression a la volé des js et css en php mais de la a prendre un cdn il y a de la marge , a savoir que facebook utilise un cdn et pourtant il est tres loin derriere sans parler des problèmes d’architectures et de sécurités.

Les commentaires sont fermés.