Vous le savez certainement déjà, je suis un fan de tuning de site web, c'est
l'une de mes grandes passions 
Suite aux nombreuses améliorations déjà réalisées il y a plusieurs mois sur
ma Dédibox :
J'ai décidé d'aller plus loin en m'intéressant aux nombreuses
recommandations fournies par l'excellent outil Google Page Speed et par Yahoo!.
Voici plusieurs astuces que j'ai mis en place et qui vous donneront
peut-être des idées pour votre blog / site internet.
Utilisation d'un vhost pour l'hébergement des ressources statiques
J'ai tout d'abord créé un vhost static.geeek.org dédié aux contenus
statiques : images publiés, thème graphique ... Dans Dotclear (plugin
"about:config"), j'ai précisé le chemin de ce vhost sur mon disque et son URL
visible du Web.
Le but de ce vhost est qu'il soit cookie-free, pour permettre au navigateur
de récupérer les images rapidement sans devoir fournir un cookie inutile au
serveur Web.
Cette optimisation permet aussi aux proxy HTTP de cacher les ressources
statiques. Les proxy HTTP ne cachent pas les images qui sont appelées avec un
cookie dans le header http.
Customisation du script Google Analytics
J'ai essayé de faire en sorte que tous les cookies générés par le blog
soient associés au "Hostname" www.geeek.org
et pas au nom de domaine global geeek.org.
Par défaut le script Google Analytics génère un cookie avec le nom de
domaine de votre site. En regardant la documentation de Google Analytics, le
script offre la possibilité de diminuer le "scope" du cookie à un vhost précis.
Pour cela j'ai utilisé la méthode "_setDomainName" qui permet de définir le
scope du cookie.
var pageTracker = _gat._getTracker("UA-605163-4");
pageTracker._setDomainName("www.geeek.org");
pageTracker._trackPageview();
En spécifiant www.geeek.org, le cookie
qui est créé sur le client est spécifique au vhost qui héberge le blog. Toutes
les requêtes vers les fichiers statiques présents sur static.geeek.org seront ainsi sans cookie.
Utilisation du header "Expire"
Sur un blog, tous les contenus statiques varient que très rarement :
les images, les CSS, les fichiers javascripts ... Pour cette catégorie de
fichiers, il est possible de définir un délai d'expiration dans la configuration
de votre serveur web.
L'idéal est de définir une date d'expiration supérieure à un mois, sauf si
vous avez l'habitude de changer régulièrement le thème de votre blog. Les
images, les CSS, les javascripts sont ainsi cachés par les navigateurs et sont
rechargés dès que leur date d'expiration est atteint où dès que l'utilisateur
force le rechargement de la page (CTRL + F5).
Le fait de forcer le cache des images de votre thème peut permettre un
énorme gain de bande passante. Surtout si votre thème est super travaillé.
Utilisation des Etag / If-modified-since
La
norme HTTP 1.1 offre la possibilité aux clients Web de demander si le
contenu d'une page web a été changé. Pour cela le navigateur, dans le cas d'une
page qu'il a déjà parcourue, envoi un Etags unique ou une date de
dernière modification de la page qui lui a été fourni par le serveur lors de sa
dernière visite.
En fonction de ces éléments, le serveur HTTP est capable de décider par lui
même s'il est nécessaire de renvoyer la page Web au client. Si nécessaire, tout
le contenu de la page est envoyé au client, sinon une réponse HTTP
304 est retournée au client pour lui indiquer que la page n'a pas été
modifiée.
Sur Geeek, cette vérification est réalisée dès l'entrée dans le index.php de
la plateforme de blog. Cela permet dès les premières lignes de code de savoir
s'il est nécessaire ou non de retourner une réponse 304 au client.
Les Etags vous
permettent d'économiser du CPU et de la bande passage pour les nombreux spiders
qui visitent votre site Internet à longueur de journée. Ces Etags doivent très certainement
permettre à Google d'économiser des millions de Giga bytes de bande passage. Il
est tout à fait possible que la gestion des Etags influent sur le ranking
Google.
Par défaut Dotclear gère les Etags et les header if-modified-since,
cependant cette gestion est faite à la fin du Workflow de délivrance d'une
page.
Gzip des pages dans le cache
Afin de diminuer la taille du cache mémoire, la taille du trafic réseau et
la quantité de CPU consommée par le serveur, les pages mises en cache mémoire
sont gzippées dès leur insertion (via la fonction php
gzencode)
A chaque requête HTTP d'un client, si la page est présente dans le cache,
elle est retournée au client directement gzippée (si le navigateur supporte le
gzip). Cela permet de réduire par 3 ou 4 la bande passante consommée par les
pages HTML, et indirectement le temps de chargement de la page par le
navigateur.
J'espère que ce petit article est clair, n'hésitez pas à poster un
commentaire si vous trouvez ces optimisations utiles ou inutiles et si vous
avez d'autres idées d'optimisations possibles.
En attendant, ma Dédibox "standard" a une charge CPU moyenne de 8% pour
200 000 hits / jour. Je pense qu'elle peut absorber au max une
charge de 30 000 visiteurs journaliers.
