Maintenant que les fêtes sont finies, et que vos foies sont à nouveau au repos, il est temps de se remettre au boulot.D’autant qu’aujourd’hui c’est les soldes ! Les serveurs vont chauffer, je me doute qu’il va y avoir des crises de nerf .
On commence léger avec la suite du billet ou je vous parlais de firebug et pagespeed. Etant donné que je suis votre seul et unique gourou, et que bien évidemment vous faîtes absolument tout ce que je dit, vous avez déjà optimisé au possible votre site.
Alors aujourd’hui, penchons nous un peu sur les outils pour webmasters de notre ami Google, afin de vérifier les résultats, et plus particulièrement sur 2 options :
- Diagnostic>Statistiques sur l’exploration
- Labos>Performances du site.
Les données de ‘performances du site’ sont obtenues directement auprès des internautes ayant installé la barre d’outils Google et activé la fonctionnalité PageRank . Donc c’est une moyenne qui est présentée sur les graphs. A leur côté vous trouverez maxi, mini et moyenne. Attention, cette méthode ne sert qu’à vous les pauvres. Les riches eux n’ont pas besoin de google, ils utilisent d’autres méthodes plus rapides et plus fiables.
Attention, cet article risque d’être totalement imbitable pour la majorité de notre lectorat. Que la direction générale de cet auguste blog me pardonne.
Ko téléchargés
La première donnée intéressante concerne le nombre de kilos octets téléchargés par jour.
Franchement, j’ignore totalement comment est calculé cette donnée. Et cela n’a aucune importance puisque l’on se basera plutot sur des ratios que sur des valeurs absolues calculées finement.
Tout ce que je peut dire, c’est que limiter les téléchargements a 2 impacts principaux. Le premier est l’impression de fluidité lors du chargement d’une page. Le second est que la bande passante, si vous la payez, coûte cher. Sur un mutualisé cela à également de l’importance, puisque qu’en cas de saturation de cette même bande passante, vous fournirez plus rapidement certains contenus, la BP n’est pas extensible à l’infini.
Devinez quand la compression et le caching ont été activés. Non, pas en Aout.
Activer la compression
Voici le premier moyen simple de limiter le poids des données transférées : la compression. Même si vous confondez la gauche de la droite, vous connaissez surement winzip qui permet de diminuer fortement la taille des fichiers. Ici c’est pareil. Le gain est sensible particulièrement sur les fichiers de type texte (html, js, css, xml).
Sur un serveur Apache, il est assez simple d’activer la compression, sans toucher au code (genre avec un obscur ob_start(‘ob_gzhandler’) à claquer sur toutes les pages. Un petit tour dans le .htaccess en racine et hop, d’un coup les gros on active le mode deflate pour l’ensemble du site et pour les .html, .ico, .js, .css, .xml (ici un exemple avec deflate) :
AddOutputFilterByType DEFLATE text/ico text/html text/plain text/xml text/css application/javascript application/x-javascript application/x-httpd-php application/rss+xml application/atom_xml text/javascript
Vous pouvez également activer le mode gzip. En cas d’erreur 500, votre config Apache demande l’activation des extensions nécessaire (à voir à l’aide d’un phpinfo() ou auprès de l’hébergeur). Tout ça est un poil technique je le convient, mais c’est vite fait et ça ne mange pas de pain.
Sur IIS c’est aussi simple (voir plus encore, c’est une case à cocher). Bref, c’est simple et pas prise de tête pour peu que vous cherchiez un poil.
Activation du cache
Le deuxième point facile à mettre en place est l’activation du cache navigateur et ce n’est pas plus compliqué, puisqu’il suffit encore une fois d’utiliser le .htaccess :
# cache 1 semaine
<FilesMatch « \.(jpg|jpeg|png|gif|swf|js|css|png)$ »>
Header set Cache-Control « max-age=604800, public »
</FilesMatch>
# cache 1 an
<FilesMatch « \.(ico)$ »>
Header set Cache-Control « max-age=29030400, public »
</FilesMatch>
En fonction du type de fichier, votre navigateur mettra en cache au premier accès les images, les flash, les javascripts et compagnie. Au deuxième accès, le navigateur n’ira pas les chercher sur le serveur, mais sur le disque dur. C’est plus rapide (pour l’internaute dès la 2° page) et économe en bande passante (pour vous).
Temps de téléchargement d’une page
Je vais aller vite, parce que nous sommes dans une partie bien plus technique. La donnée représentée ici est le temps de délivrance du HTML. On le voit sur le graph, ici c’est très lent puisqu’il faut environ 1.5 s pour obtenir le HTML. Ensuite il faut au navigateur aller chercher les éléments indiqués dans ce même HTML (images, js, css…). C’est long, d’autant qu’avec l’ADSL nous sommes particulièrement habitués à la vitesse.
Il n’y a pas une solution simple pour optimiser la génération du HTML. C’est un boulot de longue haleine qui demande pas mal de compétences et de temps. Donc, malheureusement on passe. Je ne vais pas non plus écrire un billet de 15000 pages sur le dév, faut pas pousser mémé dans les horties. Il faut voir cela après avoir mis en place les techniques les moins couteuses. Optimiser le code pourrait dans notre cas faire gagner éventuellement 1 seconde, les autres techniques le triple sur le temps total, tout en coutant moins cher. Le calcul est vite fait, pas besoin de réviser la règle de 3 pour comprendre quel est votre intérêt.
Petit bémol quand même puisqu’ici on parle uniquement de temps de génération, pas de volume. Si un site délivre le HTML en 5 secondes ou tombe avec 100 utilisateurs, il faudra y passer quand même (et il faudra aussi penser à envoyer les devs et le chef de projet en formation, ou à l’ANPE).
Performances du site
Voilà une page intéressante au possible, puisqu’elle réuni en son sein un graph sur la durée des temps de chargement de tous les éléments d’une page (alors qu’auparavant nous parlions uniquement du HTML) et un ensemble de conseils pour quelques pages, quasi les mêmes qu’yslow ou pagespeed.
Y a eu de l'optimisation non ?
Sur le graph ci dessus, vous pouvez voir que les temps de chargement de tous les éléments constitutifs d’une page ont considérablement baissés. Dans cet exemple, sur certaines pages, on observe un temps de chargement 10 fois plus rapide, mais surtout une impression de chargement quasi instantané.
En premier lieu, il a été mis en place les actions les plus simples et rapides à mettre en oeuvre : compression, activation de la mise en cache navigateur, optimisation des images, indications des tailles des images, regroupement et compression physique des css et js (minify). Bref du facile, qui rapporte gros rapidement.
Ensuite suppression ou déplacement de fonctionnalités sans aucune valeur ajoutée. C’est également simple à faire. C’est d’ailleurs quelque chose à surveiller à l’aide d’outils de web analytics. La rapidité aide à la conversion. C’est donc également le bon moment pour dépoussiérer le site et virer les fanfreluches (vous savez, les trucs bling bling) qui semblaient trop top géniales kikoo lol au début et qui se révèlent au final de gros boulets. Eventuellement certaines fonctionnalités peuvent être supprimées pendant un gros pic de trafic, puis ré implémentées par la suite.
Les autres actions sont plus affaire de dév qu’autre chose (revue des requêtes SQL, mise en cache serveur, nettoyage de code, mise en place d’un cdn…) et ne sont pas toujours indispensables. Si votre site est assez ancien et qu’il a connu pas mal de modifs, le code est probablement devenu illisible, difficile à maintenir. Bref un gros tas de pus. C’est l’occasion de casser la tirelire et d’y consacrer un peu de temps. C’est vraiment à faire en dernier recours, tant le rapport perf/cout est souvent bas.
Si vous ne l’avez pas encore vue, regardez cette vidéo indispensable à qui voudrait en savoir plus et aller plus loin. Pour vous convaincre de la nécessité de tout cela, lisez cette article qui explique que près de la moitié des visiteurs d’un site n’attendent pas plus de 2 secondes pour qu’une page se charge (les fourbes).
Alors, vous vous y mettez quand ?
Question annexe : des billets techniques ça vous intéresse ? Quel niveau ?
Optimisation site, Techno
Par contre, si je regarde les graphs de google webmaster tools, j’ai peur. Le graph est séparé en 2 zones. Au dessus d’une seconde sur mon exemple, on est considéré comme lent. J’espère que c’est une blague d’un farceur de chez google.
