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.

Dans les « on reste très classique »

Préchargement de Firefox au démarage de windows : On va _encore_ ralentir l’ouverture de session pour pouvoir avoir une ouverture quasi instantanée de Firefox lors du clic sur l’icone. Le résultat sur le ressenti de performance est évident mais je suis assez mitigé. J’en ai ma claque des sessions qui prennent 5 minutes à s’ouvrir à cause de tout ce qui est chargé dans le systray. Là on déshabille Paul pour habiller Pierre et on donne l’impression à l’utilisateur que c’est la faute de Paul. Je comprend l’effet mais je n’aime pas le principe.

Garder le logiciel ouvert un bref moment après sa fermeture, au cas où l’utilisateur le réouvre juste après : Ca me fait penser à la fermeture de session de mon poste Linux. Il prend en compte mais n’éteint le poste que 60 secondes après la demande (sauf si je confirme ma demande), me laissant la possibilité de changer d’avis. J’aime bien le principe mais normalement l’OS fait une partie du travail en mettant en cache toutes les bibliothèques logicielles. Normalement un second démarage est déjà plus rapide. Si ce n’est pas le cas je préfèrerai qu’ils trouvent pourquoi plutôt que de chercher des astuces (oui, je sais, c’est facile à dire).

Installer un intersticiel (splash screen) : C’est assez dangereux. D’un côté on donne immédiatement un feedback à l’utilisateur, ce qui est très bien pour donner une impression de réactivité et éviter qu’il lance deux fois le navigateur en pensant que ça n’a pas fonctionner (je compatis, ça m’arrive régulièrement), de l’autre on va renforcer l’idée de l’utilisateur qu’il s’agit d’un logiciel long à charger alors que d’autres sont instantanés sans intersticiel.

Dans les « c’est astucieux »

Accélérer l’indicateur de chargement : Ils disent qu’ils le font à chaque version. Un indicateur qui tourne plus rapidement c’est pour l’utilisateur un logiciel qui fonctionne plus rapidement. C’est idiot mais on a tous le même ressenti inconscient. Par contre on va vite arriver à une limite pour ce genre d’astuces.

Avoir une progression non linéaire pour l’indicateur de progression : Faire qu’il avance plus lentement au début (quand l’utilisateur accepte l’attente) et plus rapidement vers la fin (quand il en a marre et a besoin de voir que « ça avance bien »). Dans le même ordre d’idée la suggestion précédente propose de faire accélérer l’indicateur de chargement (celui qui tourne) avec le temps.

Dans la catégorie « ça c’est génial »

Utiliser les composants en cache en attendant de vérifier qu’ils sont toujours frais : J’adore l’idée. Il s’agit d’utiliser les feuilles de styles, les images en cache en parallèle aux requêtes HTTP de revalidation. S’il s’avère que le contenu a changé, alors on mettra la page à jour. On tient là une réelle avancée. Il faudrait peut être toutefois montrer à l’utilisateur que l’image en question est potentiellement temporaire (par exemple la griser légèrement, ou monter le gamma : l’image reste visible mais on voit qu’elle est « en cours »).

Dans le même ordre d’idée on propose, à défaut de réutiliser les images elles-mêmes, de réserver la place dans le rendu en fonction de la taille de l’image qui est en cache. On évite de trop triturer la page, ce qui est une bonne chose, mais là je suis moins enthousiaste. Sur une page ou une connexion lente, ça peut inciter à réserver des places vides pendant longtemps, et déteriorer le ressenti utilisateur au lieu de l’améliorer. Je préfère nettement l’idée d’utiliser l’image elle-même, car l’utilisateur a au moins un contenu utile.

Mieux, on propose même de lancer immédiatement des requêtes vers les scripts et feuilles de styles référencées dans la page en cache en attendant de recevoir la nouvelle page. C’est quelque chose qui peut réduire le chargement de la page de plusieurs centaines de milli-secondes, plus sur les pages HTML vraiment lentes. Je ne sais cependant pas si le rapport bénéfice sur complexité est assez intéressant pour que ce soit implémenté. Il faudrait en effet que ces requêtes aient une basse priorité par rapport aux autres requêtes (histoire qu’on ne précharge pas en priorité des choses qui sont potentiellement inutiles) et que ces requêtes soient annulées dès qu’on sait que la page HTML a changée.

Plus intéressant encore : charger la page à partir du cache en attendant que la nouvelle page soit chargée. L’idée est intéressante mais la réalisation risque d’être difficile. La page en cache fait probablement référence à des composants qui eux ne sont pas en cache (les pubs) ou peut faire des requêtes Ajax. Est-ce pertinent d’occuper le réseau avec cette ancienne page ? Pire, on va aussi occuper le cpu puisque beaucoup de sites ont des pages qui mettent un temps significatif à effectuer le rendu même quand tout est en cache. On risque de ralentir inutilement la machine.

Pourquoi dis-je que c’est encore plus intéressant alors que je détruis l’idée ? parce que j’avais ça sur Safari (si je choisis une des pages proposées au démarage c’est d’abord une image de la page en cache qui se charge le temps que la page réelle arrive) et j’ai ça depuis peu sur gmail (le temps que gmail se charge j’ai une version HTML non clicable des titres des quelques derniers mails de ma boite). Ca a l’air inutile mais ça améliore vraiment l’expérience. On peut se concentrer immédiatement sur la tâche prévue au lieu d’attendre que la page se charge. La performance ressentie c’est finalement surtout ça.

Alors ?

Je laisse les histoire d’indicateurs plus ou moins rapides à d’autres mais je verrai bien les effets suivants (cumulatifs) :

• S’il s’agit d’une page fréquemment visitée (en bookmark ?) charger une image de la page telle qu’elle était la dernière fois en attendant que la page se charge effectivement. Point bonus si les liens restent clicables (mais je n’ai pas besoin des autres interactions avec la page comme le javascript).
• Quand la page arrive, on utilise par défaut immédiatement les précédentes versions des images et feuilles de style en attendant les nouvelles. Les images sont toutefois grisées/blanchies pour bien symboliser l’état « en chargement ».

Notez que cela demande d’augmenter l’espace dédié au cache, et pour les pages ciblées de mettre en cache même ce qu’habituellement on n’y met pas (quitte à identifier que c’est un cache déjà expiré).