Tuning & Optimisation du site Web
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 :
- Utilisation de Lighttpd comme serveur Web
- Mise en place d'un cache mémoire (APC_Cache)
- Tuning MySQL avec le script Tuning-primer
- Modification des premières lignes index.php de Dotclear pour la gestion d'un cache mémoire.
- L'utilisation de connexions MySQL persistantes
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 www.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 www.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.
