J'ai perdu patience !

Différentes études ont montré que le temps de chargement d’une page web est directement lié au taux de rebond.

Performance et taux de rebond

Ainsi un site de designer a réalisé un sondage pour connaître les raisons de sortie d’un site : le temps de chargement apparaît comme une cause importante de « rebond ».
 

Relation entre le temps de chargement et le taux de rebond.

Relation entre le temps de chargement et le taux de rebond.


Les grands sites ont également étudié cette question, avec des conclusions identiques :

  • Amazon indique qu’un temps de chargement de 100ms en moins augmente son chiffre d’affaire de 1%.
  • Google perd 20% de recherche lors d’un chargement allongé de 500ms.
  • Yahoo auto annonce avoir diminué son taux de rebond de 9 à 5% en gagnant 400ms de temps de chargement

Il est facile de comprendre qu’un site rapide est beaucoup plus agréable à utiliser.
Akamai -un grand fournisseur de trafic web- a commandé une étude chez Forrester Consulting, dont les enseignements sont éloquents :

  • Les visiteurs s’impatientent lorsque la page met plus de 2 secondes à s’afficher : 47% des visiteurs estiment qu’une page web ne doit pas mettre plus de 2 secondes pour s’afficher et 40% des visiteurs n’attendent pas plus de 3 secondes, augmentant ainsi le taux de rebond (des temps en nette diminution depuis la dernière étude de 2006).
  • La fidélité des acheteurs en ligne est inversement proportionnelle à la vitesse d’affichage de page : 52% des acheteurs en ligne affirment que la vitesse de chargement  est importante pour leur fidélité (12% seulement dans l’étude de 2006).
  • Les acheteurs en ligne détournent leur attention lorsque l’affichage de la page est long : 14% vont voir un autre site et 23% arrêtent.
  • Il en résulte un manque à gagner pour les sites contre-performants : 79% des acheteurs en ligne ne reviennent pas sur un site après une mauvaise expérience de visite (17% en 2006) et 64%  se rendent sur un autre site.
  • L’impact dépasse le web : 46% des clients en ligne insatisfaits on plus de chance de développer une perception négative de la société et 44% vont en faire part à leurs amis et famille.

Le manque de performance d’affichage sera beaucoup plus sensible pour le visiteur qui vous a trouvé depuis un moteur de recherche en moins de 500ms pour obtenir le résultat de sa recherche.

Je veux améliorer la performance de mon site !

Voici quelques pistes pour vous permettre d’accélérer l’affichage de vos pages web, et en premier lieu, l’outil Firebug. Dans l’onglet « Réseau » on observe le graphe de chargement des éléments.

Graphe de chargement d'une page du site skype.com.

Graphe de chargement d’une page du site skype.com.


Constatation importante : La génération de la page HTML ne prend qu’une toute petite partie du temps de chargement de la page complète. L’optimisation du « backend » n’est donc pas très utile, et il vaux mieux optimiser la suite du chargement.

1ère optimisation : réduire le nombre de requêtes HTTP

Chaque élément transféré pour construire la page web utilise une requête HTTP au serveur Web.

Illustration d'une requête HTTP

Illustration d’une requête HTTP


On peut constater sur ce schéma que chaque requête nécessite du temps de transfert sur internet ainsi que du temps de prise en charge par le serveur Web.
Pour gagner du temps, l’idée est de réduire le nombre d’éléments à transférer.
3 types d’éléments se prêtent plus facilement à ce type d’optimisation.

Les feuilles de style

De manière générale, on différencie le contenu de la page HTML de la mise en forme via les feuilles de style CSS.
Très souvent la mise en forme d’une page web utilise plusieurs fichiers CSS. Dans l’exemple de Skype ci dessus,  la page utilise 6 fichiers CSS. Soit 6 requêtes HTTP. De plus, les feuilles de style nécessitent une interprétation par le navigateur qui retarde les autres téléchargements.
La solution la plus simple est de placer toutes les règles de style dans un seul fichier CSS. Cette solution n’est pas forcément meilleure pour la maintenance, et votre site utilise peut être des styles assez différents suivant les sections. Dans ce cas il vaut mieux séparer vos styles en quelques fichiers.
Une autre solution consiste à utiliser un script serveur qui va « concaténer » à la volée les différents fichiers CSS. Bien entendu il faut faire attention à l’ordre de concaténation, et là encore il peut être judicieux de séparer différentes sections.
Il n’est pas rare de naviguer sur un site utilisant des thèmes nécessitant une dizaine de fichiers CSS. Et pour lesquels il est aisé de concaténer les styles dans 2 fichiers !

Les images de style CSS-image

Ce sont les images utilisées par les styles. Elles sont statiques et ne servent que pour la mise en forme de la page. Ce sont généralement des fonds de pages, des boutons, des survols et des habillages.
L’idée est de grouper différentes images dans une image plus grande. Évidemment là encore il faut grouper de manière intelligente. Tout n’est pas groupable !

Exemple de fond de boutons en sprites

Exemple de fond de boutons en sprites


Cette méthode se nomme « css sprites » : un peu technique mais vous trouverez aisément toute l’aide nécessaire via Google.

Les scripts Javascript

Pour plus d’interactions et de « tracking » les pages modernes utilisent Javascript. Au risque de multiplier les fichiers de scripts. Notre exemple de Skype utilise 12 fichiers javascript. De plus les fichiers de scripts nécessitent  une interprétation par le navigateur qui retarde les autres téléchargements.
L’idée là encore est de regrouper certains fichiers : ce qui peut être fait manuellement ou à la volée en utilisant un script serveur (dans cette optique Yahoo fournit outils et documentations).
A propos de Javascript, afin d’accélérer le rendu de la page par le navigateur, on dispose le chargement des fichiers scripts qui le peuvent juste avant le </body>.

2ème optimisation : réduire la taille des transferts

Le poids des éléments transférés influe évidemment sur la vitesse d’affichage.

gzip des transferts

Tous les éléments textes de la page peuvent être transférés compressés. C’est une simple opération de configuration du serveur Web qui permet de gagner facilement pas mal de poids.
Voici les lignes de configuration pour Apache 2.2 :

#Sous Apache2 mod_gzip est devenu mod_deflate
<IfModule mod_deflate.c>
<Location />
# Insert filter
SetOutputFilter DEFLATE
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
# BrowserMatch bMSIE no-gzip !gzip-only-text/html
# NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
# the above regex won't work. You can use the following
# workaround to get the desired effect:
BrowserMatch bMSI[E] no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI
.(?:gif|jpe?g|png)$ no-gzip dont-vary
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
</Location>
</IfModule>

poids des images

Les images représentent généralement la plus grande partie du volume de données.
Utiliser des images dont la taille correspond exactement à l’emplacement prévu. Par ailleurs, pour accélérer la mise en forme de la page par le navigateur, il faut spécifier la taille dans la balise <img>.
Le format doit être adapté à l’image, généralement du JPEG ou du PNG. Ces formats contiennent des informations optionnelles qui peuvent être enlevées pour alléger le poids.
De plus le PNG peut coder l’image en différentes profondeurs de couleurs, en 32, 24 ou 8 bits : utilisez le format le plus léger en fonction de l’image.
Pour vous aider dans cette tâche utilisez Optipng et smushit.

3ème optimisation : bien gérer le cache

Une bonne gestion du cache ne va pas changer la vitesse du premier affichage. Mais cela va considérablement accélérer les autres visites de la page et même du site.

Exemple de bonne gestion du cache

Exemple de bonne gestion du cache


Il s’agit là essentiellement de paramétrage du serveur Web.
Deux directives HTTP permettent de gérer le cache.
Il y a Cache-Control: public; qui autorise la mise en cache par le navigateur et par les proxys publics. Si vous avez un système d’authentification sur vos pages définissez plutôt Cache-Control: private;.
La deuxième directive est Expires.
Avec ces directives, vous allez pouvoir informer le navigateur qu’il n’aura pas besoin de redemander la ressource avant une certain date.
Voici un exemple de configuration avec Apache 2.2

<IfModule mod_expires.c>
# turn on the module for this directory
ExpiresActive on
ExpiresByType image/jpg "access plus 6 weeks"
ExpiresByType image/gif "access plus 6 weeks"
ExpiresByType image/jpeg "access plus 6 weeks"
ExpiresByType image/png "access plus 6 weeks"
ExpiresByType image/x-icon "access plus 6 weeks"
ExpiresByType text/css "access plus 2 weeks"
# cache JS
ExpiresByType application/x-javascript "access plus 6 weeks"
# set the default to 4 hours
ExpiresDefault "access plus 4 hours"
</IfModule>

Si ces quelques optimisations ne vous suffisent pas, il existe évidemment d’autres pistes. Nous vous conseillons l’utilisation de Google Page Speed et de Yahoo YSlow.

Bon alors

Vous travaillez le design et le contenu : pourquoi pas la vitesse ?
Vous êtes en concurrence avec d’autres sites : mettez tous les atouts de votre côté !
Google intègre le temps de chargement de la page de destination dans le calcul du Quality Score Adwords. Il se pourrait aussi que Google intègre la vitesse d’affichage du site dans l’évaluation de la pertinence des pages de ce site…

WordPress Video Lightbox Plugin