Cela fait maintenant quelques années que j’ai changé ma stratégie en terme de référencement. J’ai finir par laisser tomber mes vieilles techniques Blackhat pour me consacrer à d’autres techniques plus pérennes, telle que celle de la longue traine ou encore la construction de liens via les réseaux sociaux. Les résultats de ce changement de direction sont visibles directement au travers de mon site qui marche. Au sujet de ce dernier, les résultats sont toujours croissants mais j’ai pu observer une très légère baisse de trafic sans doute suite à la dernière mise à jour de l’algorithme de Google. Mais globalement, la tendance reste bonne.

L’optimisation des performances du site web

Récemment, je me suis penché sur un autre aspect que j’avais jusqu’à lors assez négligé: l’optimisation des performances du site. Il est établi depuis déjà longtemps qu’un site qui réagit rapidement est plus apprécié par Google qu’un site qui se comporte en limace rhumatisante. D’après mes observations, cette caractéristique est bien souvent laissée de côté par la plupart des gens qui se focalisent beaucoup plus sur la promotion de leur site au travers de la construction de liens. C’est dommage, car un site bien optimisé, performant et qui se charge rapidement peut décoller et même gagner des places dans les SERPS.

Je me suis donc rendu sur la pléiade de sites qui vous propose un rapport sur les performances de votre propre site afin de pouvoir creuser cette idée et aussi bien entendu d’apporter les modifications nécessaire lorsque cela s’avère possible. En fait, ce n’est pas toujours évident car lorsque vous utilisez un CMS assez lourd comme par exemple WordPress, vous êtes tributaire d’un code tiers, de plugins mal codés, de thèmes mal optimisés, etc. Il faut parfois revoir totalement certaines choses carrément dans le code PHP pour arriver à une saine optimisation. A noter toutefois que pour WordPress, il existe des plugins qui peuvent vous aider dans ce genre de démarche.

Dans un premier temps, je me suis donc plutôt focalisé sur mon site qui marche car je suis complétement maitre de tout le code qu’il utilise. Suite à toutes ces optimisations, voici les résultats que me donnent Webpagetest.

Les premiers octets sont très importants

Le « First Byte Time » correspond au temps qu’il faut pour qu’un client obtienne d’un serveur son premier octet. Ce n’est pas forcément évident à optimiser car il existe une grande dépendance à la bande passante et c’est quelque chose que l’on ne maitrise absolument pas à moins d’y mettre le prix. Mais on peut travailler sur l’optimisation de la page principale afin de réduire au maximum son temps d’accès. Dans le cas du site qui marche, cette page est générée par un script PHP que j’ai modifié. D’abord en le réduisant à sa plus simple expression, en supprimant par exemple un maximum de lignes blanches, de commentaires et aussi en utilisant une indentation différente. J’ai aussi supprimé les include qui sont évidemment gourmands en entrée-sortie. Cela m’a obligé à utiliser des constantes directement dans le corps du programme, ce qui n’est bien évidemment pas des plus recommandés et franchement pas pratique. Après plusieurs tests, je me suis rendu compte que ces changements n’apportaient pas beaucoup d’améliorations dans la vitesse d’accès à la page. Les optimisations de type minification semblent beaucoup trop négligeables lorsqu’elles sont effectuées côté serveur.  Je pense qu’il vaut mieux essayer d’optimiser au mieux les accès goulus telles que ceux que l’on pratique en base de données, voir même de créer un système de cache maison. Je ferai cela à l’occasion dans le cadre de la refonte de mon code.

Activez les connexions persistantes

Le « Keep-alive Enabled » correspond à la mise en place d’une connexion socket dite persistante. Lorsque vous communiquez avec un serveur Web, vous établissez en fait une connexion TCP sur le port 80 (ou 443 si vous passez en SSL), vous envoyez la commande GET pour avoir votre page HTML, le serveur vous envoie les données et ferme la connexion. Si vous faites une autre demande, le serveur ouvrira une nouvelle connexion. Sur une connexion persistante, vous choisissez de ne pas fermer la connexion et de poursuivre le dialogue en vue d’obtenir d’autres éléments HTML, avec comme conséquence un gain non négligeable en performance. Ceci se fait très facilement sur Apache en insérant la directive keepalive dans la configuration de votre site web. Et pour votre culture, sachez que Sendmail fait cela également au travers d’un mécanisme appelé « cache de connexion ».

Compressez les données lors du transfert des pages

Le « Compress transfert » indique qu’une compression est utilisée lors du transfert de l’information depuis votre serveur vers votre navigateur. Bien entendu, celui-ci doit être capable de supporter les mécanismes de compression. Fort heureusement , la plupart des navigateurs le prenne en compte désormais. Néanmoins pour voir si votre navigateur est compatible avec la compression de transfert, il suffit de décoder le trafic Web avec par exemple le plugin Firefox Live HTTP Header et de voir sir votre navigateur envoie la directive suivante: Accept-Encoding: gzip, deflate. Du côté du serveur, pour activer la compression sous Apache, il suffit d’ajouter les directives suivantes dans votre .htaccess:

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent

La problématique des images

L’ensemble de la gestion des images est une problématique à elle toute seule tant il y a dire à ce sujet et les possibilités pour l’optimisation sont légion. La première chose à savoir est le bon choix du format de l’image. Dans mon cas particulier, c’est le format PNG qui donne les meilleurs résultats. En passant par exemple du GIF ou du JPEG vers ce format, j’ai pu réduire de 10% la taille des images avec la même qualité visible. On peut aussi gagner des précieux kilo-octets en réduisant le nombre de couleurs utilisées, ou en supprimant le blanc souvent utilisé comme délimiteur. Les sites d’optimisation recommandent également de bien préciser les dimensions des images afin que le navigateur n’ait pas à lui même refaire un formatage des données ou une nouvelle mise en page. Finalement, il est tout à fait envisageable de réduire drastiquement l’overhead du protocole HTTP utilisé lors de l’envoi des images. L’overhead est la quantité supplémentaire d’informations nécessaire au transport d’une seule information. Par exemple: dois-je nécessairement envoyer des cookies lors de l’affichage unique d’une image ? Dois-je préciser l’URL de provenance (referer) ? Dois-je afficher d’autres informations superflues ? La solution à cette problématique repose dans le déport de toutes mes images vers un site spécialisé. Je crée donc un sous domaine, par exemple images.pagasa.net, qui va se charger de l’affichage optimisé de mes images. Dedans, je piloterai l’envoi de mes images en évitant soigneusement tout overhead inutile.

La minification des données

Il s’agit ici sans doute de la partie la plus facile à réaliser dans l’immédiat. La minification consiste simplement à « compresser manuellement » toutes vos données, et ceci se fait de manière très aisée. Prenez une page Web, et observez son contenu. Vous allez vous rendre compte qu’il y a un très grand nombre d’informations que vous pouvez d’ores et déjà effacer. Par exemple, les lignes blanches, des espaces en veux-tu en voilà et un certain nombre d’autres choses qui n’affecte en rien l’affichage, comme les commentaires par exemple. Vous pouvez faire de même avec vos fichiers CSS ou votre code Java.

De mauvais résultats à cause des scripts extérieurs

Le mauvais résultat obtenu sur le cache statique provient des applets Java utilisés par des éditeurs extérieurs tels que Google pour Adsense et Analytic. Là encore une fois, il n’est pas possible d’y remédier: vous êtes entièrement tributaires de leur performance. On est tout de même en droit de se poser la question de leur légitimité finalement: pour avoir un site entièrement performant, il ne faut donc pas utiliser d’applets externes.

En conclusion, je suis assez bluffé de toutes les possibilités qui me sont offertes pour optimiser le site Web. Rappelez-vous que Google est très sensible à la rapidité de l’accès à votre site Web; donc ne négligez pas cet aspect. Pour terminer, voici une petite liste des sites que j’ai utilisé afin d’effectuer mes tests de performance:

• WebPageTest
• GTMetrix
• Pingdom
• Google Insights