Performance ressentie avec Mozilla

12 août 2009

Ici je m’attache beaucoup aux chiffres : temps de chargement complet, latence, nombre de composants, etc. J’ai besoin de convaincre et seuls les chiffres ont l’objectivité nécessaire pour pouvoir travailler avec des gens non convaincus.

Toutefois, une fois dépassé ce stade il faudrait se détacher un peu des chiffres pour parler de performance ressentie et pas toujours de performance mesurée. Parfois peu importe la durée de l’attente si on voit que nous progressons régulièrement et que l’attente n’est pas frustrante en elle même. C’est vrai aux caisses d’un supermarché comme sur une page web.

Les éditeurs de navigateurs l’ont bien compris. Ils jouent sur les indicateurs de chargement et sur l’interface pour donner une impression de vitesse à l’utilisateur. L’impression de vitesse est l’unique chose qui compte pour ce dernier, même si au final ça veut dire que les temps mesurés sont objectivement plus lents.

C’est avec cette idée en tête que je vous propose de lire le document de Mozilla à propos de la performance perçue. On y retrouve certaines techniques à mettre en oeuvre sur les versions actuelles ou futures de Firefox. Le document mériterait une traduction tellement il fourmille d’idées, dont certaines sont lumineuses.  Je vous en retransmet certaines, avec mes commentaires. Lire la suite de cette entrée »

Page lente = taux d’abandon important

10 août 2009

On en parlait il y a deux semaines dans le résumé de Steve Souders mais il semble que la statistique mise en avant avait peut être quelques défauts. On en a reparlé entre temps avec un joli graphique en camembert, et on a encore reparlé de la pertinence de la statistique.

Il nous reste deux statistiques qui vont encore dans le même sens : Yahoo! affirment que sur leur site auto, ajouter 400ms au chargement de la page fait monter le taux d’abandon de 5 à 9%. Akamaï affirment eux qu’au delà de 4 secondes, le taux d’abandon devient vraiment important.

Encore des chiffres

C’est Artur Bergman qui nous donne encore du grain à moudre dans le dernier slide de sa présentation à l’OSCON. Il a mené une étude à l’aide de Google Analytics pour croiser le taux de rebond et le temps de chargement de la page. Les résultats sont tels que je les attendais : une courbe assez claire, presque une droite, qui confirme que les pages lentes sont de natures à faire fuir les utilisateurs. Lire la suite de cette entrée »

Velocity, les armes secrètes d’AOL

7 août 2009

Toujours aux conferences Velocity de juin dernier, Dave Artz d’AOL mérite un billet propre. Je regrette de ne pas en avoir trouvé la vidéo au milieu des autres vidéos Velocity. Lire la suite de cette entrée »

Velocity, publicité, reflow, CDN, ajax et gzip

5 août 2009

Je poursuis la lecture des vidéos et des présentations des conférences Velocity de juin dernier. Lire la suite de cette entrée »

Punypng, un smushit-like

3 août 2009

Smushit a disparu, ou presque. On nous parlait d’ouvrir le code source. Il y avait une API pour faire des tests automatisés. Il était possible d’optimiser tout un site web. Le site a été repris sur un hébergement interne à Yahoo! et depuis il y a eu des indisponibilités et plus de régressions que d’améliorations. Le concept est toujours très intéressant mais finalement très limité.

J’ai annoncé il y a quelques temps que je comptais développer un outil similaire avec un code source ouvert et au moins une version en ligne de commande pour être intégré dans des mécanismes automatisés de publication (plutôt que d’attendre publication pour ensuite corriger image par image). Ca viendra, mais ça prend du temps parce que je veux faire les choses bien. Je compare donc tous les outils que j’ai pu voir pour comparer leurs résultats, avec différentes options. Il faut tenter de prendre un échantillon d’images représentatif, repérer les avantages et les défauts de chaque outil suivant le format mais aussi le type d’image (taille, transparence, nombre de couleurs, etc.) puis faire un choix en fonction du temps de traitement (prendre le plus efficace sur la taille finale n’est pas forcément la meilleure idée). Bref, ça viendra mais ce n’est pas pour demain.

Par contre vous avez désormais punypng. Je n’ai pas vu de code source, il n’y a pas de version en ligne de commande, ça n’accepte pas une URL de page HTML pour en extraire toutes les images (quoi qu’il doit être assez simple d’adapter l’ancienne extension smushit pour cela) mais ils innovent. Ils ont repris l’idée d’optimiser les images contenant des pixels avec une information RGB mais totalement transparents, ils font plus de travail sur les jpeg, et ils tentent d’avoir une interface plus efficace que smushit. C’est déjà ça et c’est bien.