Modules apache

La présentation débute par des liens vers quelques modules Apache pour automatiser les tâches que je recommande ici régulièrement : concaténation, minimisation, retravail des images.

Pour la concaténation des javascript et css il propose mod_concat dont j’avais brièvement parlé en mars. Il s’agit simplement d’automatiser le processus de concaténation des fichiers javascript et css via un module Apache. Les entêtes de cache utilisées sont celles du fichier le plus récent, vous n’avez rien à gérer, il suffit d’ajouter les noms de fichiers souhaités dans l’URL.

Pour la minimisation nous propose modjsmin, qui est simplement le script de minimisation de Douglas crockford transformé en filtre Apache. Côté images il y a c’est moddims qui redimensionne et découpe les images à la demande avec Image Magick. Si vous vous devez d’utiliser des solutions dynamiques alors ce sont probablement des liens à suivre, mais je continue à penser qu’il vaut mieux traiter ça hors ligne à la publication et pas sur le serveur web.

Les publicités

La seconde partie de la présentation est plus intéressante. Notamment Dave donne sa solution pour le problème persistant de tout intégrateur web : les publicités lentes et bloquantes. Il propose ici de les charger dans une iframe de façons à ce que le contenu de la page générale continue de se charger, puis récupère le DOM et les styles pour les regreffer dans le document principal (ce qui est obligatoire si votre publicité risque d’interagir avec le reste de la page). En pratique il y a quelques écueils quand j’avais essayé, tout dépend donc de ce que vous faites tourner en publicité.

Chargement à la demande

Dave a aussi mis au point un mécanisme que j’aime beaucoup. Il s’agit d’exploiter la différence entre la mesure brute de la performance et le ressenti de performance. L’utilisateur n’a pas besoin d’une page qui se charge vite, il a besoin d’une page qui charge vite ce qu’il a sous les yeux. Seuls 20 % des utilisateurs lisant jusqu’à la fin de la page, il est envisageable de ne charger les composants du bas de page qu’à la demande, quand l’utilisateur passe au dessus. Dave a donc fait un petit outil appelé Sonar pour détecter quand charger quel élément, et faire les ajouts/requêtes nécessaires.

C’est le résumé de Steve Souders qui a été publié récemment. On y retrouve quatre affirmations tirées des conférences. Toutes parlent d’une corrélation importante entre les performances et le trafic ou le business du site web :

Microsoft

Microsoft a trouvé qu’un ralentissement de deux secondes implique une réduction 1,8 % du nombre de recherches par utilisateur. Cela semble peu, mais c’est accompagné aussi d’une réduction de 4,3 % du revenu par utilisateur, et là ça fait moins rire. Autrement formulé : un utilisateur clique moins sur les publicités d’un site lent que sur les publicités d’un site rapide.

Ça rejoint d’ailleurs Google qui prend en compte la performance dans son « quality score » pour adword (en gros un site lent paiera plus cher ses publicités parce que le pourcentage de clic est plus faible) et c’est finalement logique, on hésitera à partir ailleurs et à se laisser tenter si on remet pas en cause une longue et pénible session de navigation qui nous a permis d’arriver jusqu’à la page en cours. Si la navigation est rapide on hésitera moins à partir dans diverses directions pour revenir ensuite.

Avis aux sites qui se rémunèrent sur la pub, et aux agences de comm qui font des publicités ultra lentes sous prétexte d’avoir une meilleur qualité d’image.

Google

Google lui a affirmé que 400 ms diminuait de 0,59 % le nombre de recherches par utilisateur. Là je suis un peu étonné parce que finalement ce n’est pas très significatif (sauf à ralentir de plusieurs secondes, et encore) et parce que leur dernière communication à ce sujet était d’un tout autre ordre de grandeur. Ils refont d’ailleurs état de chiffres bien plus importants dans une autre conférence dans le même événement. J’attends donc de lire leur communication complètement pour juger de ce que cela implique et de comment comprendre leurs différents chiffres qui ne semblent pas dire la même chose.

Par contre Google fait état d’un fait d’importance : les utilisateurs qui ont subit ce ralentissement minime de 400 ms continuent de faire moins de recherche sur le long terme même après que ce ralentissement soit supprimé. En gros vos performances actuelles vous impactent non seulement maintenant mais aussi dans le futur. Le chiffre avancé parait faible mais il a beaucoup d’implications et le contexte de Google est très particulier, j’y reviendrai donc certainement dans un billet dédié.

AOL

Sur le réseau AOL les 10 % d’utilisateurs qui ont les meilleures performances visitent moitié plus de page par session que les 10 % avec les moins bonnes performances.

Autant dire que cela a un impact sur le trafic des sites, et donc forcément la conversion en clic publicitaires ou en achats. Le chiffre est important mais il peut revêtir plusieurs formes, je vous en dirai plus quand j’aurai là aussi lu leur présentation à tête reposée.

Shopzilla

Enfin, Shopzilla a réduit le temps de chargement de 7 secondes à 2 secondes. C’est une différence importante et ça a donc du nécessiter des efforts conséquents, mais le résultat est là : 25 % d’augmentation de trafic, 7 à 12 % d’augmentation sur les revenus, et 50 % de réduction sur les coûts matériels.

À défaut d’être une formule magique, investir dans l’amélioration de la performance *doit* être considéré après lecture de ces chiffres. Payer une étude quelques milliers d’euros et un développeur interne pendant quelques jours/semaines pour corriger ce qui a été trouvé, cela peut assez facilement se révéler un investissement payant à court terme.