Dans le domaine des performances web, en français, il n'existe pas beaucoup de lecture sur internet. Cependant deux blogs traitent du sujet.

Le premier est celui d'Eric Daspet : Performances web, et le second, celui de Nicole Sullivan.

Je lis celui d'Eric Daspet depuis plusieurs mois, et quand j'ai le temps, je me penche d'un peu plus près sur les conseils qu'il donne et regarde ce que je peux mettre en place de mon coté.

Pourquoi se préoccuper des performances des sites web ?

C'est vrai après tout, tout le monde a une connexion de ouf...

Tout le monde ? Pas forcément. Et des fois, tout se joue pour quelques centaines de millisecondes.

Perdre 500ms c’est perdre 20% de traffic pour Google (ou pourquoi il n’y a que dix résultats par page dans les recherches).
Perdre 100ms c’est perdre 1% de ventes pour Amazon.
Réduire de 25% le poids de la page c’est gagner 25% d’utilisateurs à moyen terme pour Google.
Eric Daspet - A quoi ça sert ?

Pour un petit blog comme le mien, ce n'est rien, je n'ai pas un besoin vital de me préoccuper de cet aspect.
Non.

Je m'en sers comme "bac à sable". Je peux tester certaines pratiques, certaines techniques, afin de voir comment les intégrer dans mon travail, les partager avec mes collègues et leur faire comprendre que c'est un point tout aussi important que l'accessibilité ou que la couleur du bouton que veut le client.

Que peut-on faire facilement ?

Dans un premier temps, j'ai donc installé YSlow, un plugin pour firefox qui vient en surcouche de firebug.

YSlow m'a donné un petit D, soit 58 sur 100. Et mon site se chargeait en 3 secondes.

J'ai regardé point par point ce que je pouvais faire, et après avoir lu de la doc un peu partout, j'ai commencé par réduire le poids des images.

Pour ça, il existe un site web fabuleux, créé par Nicole Sullivan et Stoyan Stefanov : smushit. Il suffit de donner l'url de la page, et le service s'occupe de tout. Au final il vous rend un fichier zip avec toutes les images optimisées et, point important, les optimisations ne sont pas destructives. Votre image sera identique pixel par pixel à celle d'origine.

J'ai ensuite tenté de réduire le nombre de requêtes HTTP.

Pour réduire le nombre de requêtes HTTP, on peut :

  • merger les CSS
  • merger les JS
  • privilégier les CSS Sprites

Je n'ai pas été très chanceux sur ce coup, je voulais à tout prix faire un maximum de CSS Sprites, mais dans mon cas, ce n'était pas possible, je n'ai réussi qu'à réduire d'une image le nombre d'images CSS.

J'ai tout de même réussi à merger les trois feuilles de styles pour n'en faire plus qu'une seule, et je l'ai ensuite optimisée avec code beautifier.

Pour les fichiers JavaScript, rien à faire de ce côté là, utilisant dotclear, je préfère laisser les fichiers JS tels quels.

En troisième action, j'ai demandé à mon hébergeur de configurer le mod_expires d'apache.

mod_expires permet de spécifier une date d'expiration du contenu. Tant que la date n'aura pas expirée, votre navigateur ne rechargera pas le contenu en question. Les gains en cache plein sont assez impressionnants.

Vous pouvez régler la date d'expiration par type de contenu, et vous pouvez le faire soit dans la configuration générale d'apache, soit dans votre vhost ou votre .htacess.

Voici par exemple ce que j'utilise :

ExpiresActive on
ExpiresDefault access plus 10 years
ExpiresByType text/html now
ExpiresByType text/xml now

On active le mode expires, par défaut tous les types de contenus expirent dans 10 ans, par contre, le HTML et le XML expirent immédiatement, ce qui évite de vider son cache quand un nouvel article est publié sur le site et sur le flux RSS par exemple.

Au final, avec ces quelques petites choses, avec un cache vide, mon site (d'après mes tests) se charge en 1s, et avec le cache plein en 0,5s. Ce qui me fait maintenant une note C, soit 79 sur 100.
On remarquera aussi qu'avec le cache vide, 26 requêtes sont nécessaires, alors qu'une fois le cache plein, il ne suffit plus que d'une seule requête : la page HTML.

Prochainement, avec mon hébergeur, nous devrions mettre en place le mod_gzip qui permet de compresser à la volée le contenu, et ainsi réduire la consommation en bande passante et, normalement, accélérer l'affichage des pages. Car plus c'est gros, plus c'est lent.

Tout ce travail porte ses fruits, j'ai déjà commencé à modifier la configuration apache de nos serveurs de production, et les graphistes regardent de près smushit et le format PNG-8 qui est beaucoup plus performant que le GIF.

Les performances web, c'est comme l'accessibilité, toujours en mouvement. On n'est jamais fixé, il y a toujours à faire, c'est pour ça que j'aime le web !

A suivre donc...