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.
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é).
Slt,
Tes propositions me semblent tout à fait intéressantes, j’ajoute qu’en cas de mise en oeuvre, ces dernières devraient revêtir un caractère optionnel car celles-ci pourraient agacer une certaine portion de la population.
On pourrait imaginer également ne l’activer que si l’utilisateur a permis une taille de cache suffisante pour envisager de le mettre en oeuvre.
S’il y a une chose que je regrette dans la majorité des applications, même si je dérive peut-être un peu, c’est l’absence d’une gestion du comportement du logiciel en fonction de la performance avec un curseur progressif du genre :
Je veux que Firefox :
– utilise mon ordinateur sans limite pour améliorer mon expérience utilisateur
– ménage les ressources de mon ordinateur
– ne fasse que le minimum quand on le lui demande
Un peu comme le niveau de sécurité dans les options internet de windows.
Ces solutions sont certes, très intéressantes mais envisageables uniquement lors de la conception/création/modification d’un navigateur internet. Gérer de cette manière le cache pour un Webmaster, c’est impossible, dû moins il me semble… S’il y a des contre-indications, je suis – très – preneur !
Ce sont donc des idées de Mozilla pour… Mozilla et compagnie. 🙂
@samuel: Ah oui, ce sont des améliorations pour le navigateur, il y n’y a rien que tu puisses faire en tant que webmaster pour réaliser ces effets. D’ailleurs la liste vient bien des équipes de Mozilla.
@Nicolas: Quasiment personne ne modifie la configuration, et pas sur ces choses là. Même dans les geeks, finalement assez peu ont modifié la taille du cache. Le navigateur devrait régler lui même la configuration par défaut « au mieux ». Ce n’est pas à l’utilisateur de faire les réglages.
La possibilité de régler le niveau de sécurité dans IE est pour moi un échec complet. Ca incite les particuliers à baisser dangereusement certains réglages au moindre problème (ou au premier site qui leur dit de le faire) et les professionnels à bloquer inutilement n’importe quoi en configurant « par principe » tout au maximum.
Bonjour,
Merci pour ce document très intéressant et vos commentaires !
J’ai été amusé de voir le pré-chargement de Firefox revenir sur le tapis. Du temps de la suite Mozilla, il y avait un module de pré-chargement, ça améliorait bien les choses… En cherchant un peu j’ai trouvé ça : http://sourceforge.net/projects/ffpreloader/
Aujourd’hui je ne suis pas persuadé que l’on soit dans le même contexte, vu que le parc n’est plus le même. En tout cas en ce qui concerne mon expérience, alors qu’il y a 6 ans j’étais assez irrité des temps de chargements de mon navigateur, aujourd’hui vraiment ça ne me pose pas soucis du tout ?
Tout dépend de la plateforme. On trouve maintenant des netbook avec des performances processeur/disque qui sont similaires à celles qu’on avait il y a plusieurs années.
Les extensions sont aussi un problème puisqu’un firefox équipé de mauvaises extension ou en trop grand nombre peut facilement chiffre un temps de démarrage en secondes.
Reste aussi que si les performances se sont objectivement améliorées, les attentes des utilisateurs aussi. La plupart attendent quasiment de l’instantané pour ce type de logiciels (alors qu’ils acceptent parfois bien plus de logiciels « plus simples »). Firefox garde finalement un temps de chargement assez lent, il fait beaucoup de lectures disque au démarrage. Ceux qui ont pu tester l’accès sur un SSD ont du remarquer une sacré différence.
J’avais proposé pleins de petites améliorations pour Firefox (pas que pour la perf) : http://www.jroller.com/dmdevito/entry/some_simple_firefox_enhancements_i
Cela a été un sacré boulot de réaliser cette liste dont j’ai mis du temps à collecter les éléments suivant mon expérience.
Proposition (31): j’avais proposé que Firefox, lors du premier démarrage, demande à l’utilisateur ce qu’il attendait comme expérience utilisateur. Par ex, voulait-il minimiser le temps de chargement en faisant du préchargement au risque de charger les ressources CPU+réseau ou l’utilisateur préférait-il que Firefox fasse une utilisation modérée des ressources de la machine ?
J’ai soumis qques-unes (pas toutes) de ces idées à Mozilla en faisant l’effort de les proposer/entrer dans leur base Bugzilla. J’ai eu peu de retour (tous horizons confondus) ou trouvé le retour décevant. Dommage.
Quelques idées aussi
– un cache préférentiel : j’aimerais un cache PERMANENT pour certains sites que je vais voir régulièrement, et un cache en LIFO classique pour le tout venant. A moi et/ou bien aux « statistiques » de visite de définir cet aspect. Je n’ai pas envie de faire un cache de 2Go pour arriver à ce quasi résultat.
– Toutes les pages Web (99%) sont dynamiques. Le If-Modified-Since ne marche donc pas. Il faudrait inciter les serveurs Web (Apache) à intégrer un simple CRC de la page HTML. Le navigateur pourrait ainsi simplement voir dès le début de la transaction, ou bien même avec un équivalent (if-modified-since) ne se servir de la page en cache, si le CRC est le même.
– un cache de rendu : si l’HTML n’a pas changé, si les images n’ont pas changé, et si le CSS n’a pas changé, alors pourquoi refaire tout le parsing et les positionnements ?
– Pour finir : par pitié ! Arrêtez les plugins, le javascript et les images tournantes quand ma page n’est pas visible. J’en ai assez d’un Firefox à 60% du CPU parce que j’ai ouvert 10 onglets contenant des animations « sapin de noël »
personnellement, mon Firefox étant ouvert en permanence, et, mon PC s’éteignant via la mise en veille prolongée quasi à chaque fois (sauf MAJ windows update grrr), je ne me préoccupe pas beaucoup du temps de chargement
ce qui me dérange le plus, c’est la perte de performance au bout de quelques jours ou semaines d’utilisation qui finit par devenir énorme si on compare à « juste après » une réouverture (en récupérant la session précédente)
Voilà l’effet Tristan, plus de commentaires 😉
@Dominique : poser la question est souvent peu utile. Beaucoup ne sauront pas quoi répondre, les autres risquent de répondre sans savoir, ou de se demander s’ils ont fait une bêtise. C’est à nous (ou à Mozilla) de trouver la bonne valeur par défaut, quitte à laisser les geeks (ou les extensions) la modifier dans le about:config.
Mozilla semble faire un vrai travail de ce côté là d’ailleurs. J’ai bien aimé la page d’erreur sur les certificats SSL cassés, qui est bien plus sensée qu’une question « voulez vous continuer ? »
@Sebastien : avoir des pages dynamiques n’empêche pas de générer et d’utiliser une date de dernière modification … ou plutôt dans ton cas un ETag. Le CRC ferait un très bon composant d’etag. Apache et le navigateur savent gérer tout ça, créer l’etag dans tes pages dynamiques c’est quelques lignes (d’ailleurs certaines bibliothèques PHP le font).
Pour la différenciation de cache entre les pages fréquentes et les autres, en fait j’espère que ça entre déjà en considération actuellement (j’avoue mon ignorance) mais ça me parait logique de faire d’abord expirer ce qui est peu utilisé (et donc que quelle que soit la taille du cache, ce soient les éléments les plus fréquents qui restent en dernier)
@Kriket: il y a eu beaucoup d’améliorations de ce côté là. Le plus souvent ce sont des extensions mal codées ou des plugins (comme flash) qui sont responsables.
Si je peux ajouter ma pierre de créateur d’extension, j’estime être assez bon en programmation Javascript et ce n’est pas rare que l’on me demande de modifier telle ou telle chose avant de valider une mise à jour. Ce n’était pas le cas avant.
Je pense que cela, bien que pour les développeurs d’extension ce soit assez saoulant de reposter, a dû grandement diminuer les chances d’extensions vaseuses.
@Eric
Je ne suis pas d’accord que poser une telle question soit inutile !
Une question telle que :
« »
voulez-vous minimiser le temps de chargement en faisant du préchargement au risque de charger les ressources CPU+réseau ou préférez-vous que Firefox fasse une utilisation modérée des ressources de la machine ?
« »
Penser que poser une telle question est souvent peu utile, c’est mettre tous les utilisateurs dans le même moule et s’empêcher d’avancer un tant soit peu !
Bien sur, les 20% des utilisateurs les moins éduqués ne sauront pas répondre à une telle question, mais Internet étant de plus en plus vulgarisé, je pense que 80% de la population saura répondre à une telle question (franchement facile). Et s’il n’y en avait que 40% qui saurait y répondre, c’est quasiment 1 utilisateur de Firefox sur 2.
Pour info, au moins 1/3 des utilisateurs de Firefox utilisent une extension ! C’est tout simplement énorme et cela témoigne du degré de confiance et de « débrouille »/manipulation de ces utilisateurs.
Parce que, franchement, laisser uniquement aux geeks la possibilité de modifier les paramètres correspondant au comportement de **base** de Firefox, c’est pas ce que j’appelle une ouverture au plus grand nombre.
C’est une façon de voir l’interface. Pas que ce soit inutile, mais c’est souvent plus un frein qu’une aide. Avec ta question, la plupart des non informaticiens ne comprendront pas la première partie et diront « bien sur je veux qu’il utilise modérément les ressources de la machine ».
Même s’ils comprennent, de combien ça ralenti au démarrage ? de combien ça accélère ensuite ? quelles ressources ça prend entre les deux ? l’utilisateur n’a pas les éléments pour faire un choix éclairé.
C’est un peu comme si on lui demandait de choisir entre une taille pour son cache. Il y a un compromis à faire entre disque et performance, mais même si tout le monde n’a pas des besoins identiques, c’est au logiciel de faire un choix premier sans poser de question. Même pour les geeks, moi je préfère que le logiciel prenne le comportement le plus sensé et que je bidouille si j’ai vraiment besoin.
Mais bon, ce n’est pas à moi de savoir si poser la question est une bonne idée ou pas, c’est au projet Mozilla. Et de ce que j’ai compris le fait de ne pas poser de question technique à l’utilisateur fait justement partie de leurs guidelines.
C’est là bas que je t’encourage à porter le débat éventuel.
Perso, moi, j’aimerais bien que Firefox me pose la question au démarrage, car je l’arrête fréquemment (plusieurs fois) dans la journée, car il vient à me pomper une bonne partie des ressources de ma machine et il faut que je le stoppe pour retrouver le contrôle. Certes, il ne plante pas comme Windows dont il était bon ton de se moquer un temps, mais le fait est le même : je dois le redémarrer plusieurs fois par jour !
Ou on pourrait voir les choses autrement : que Mozilla propose une extension pour régler les paramètres de Firefox, en suivant un certain nombre de questions. Cela conviendrait peut être à plus de monde.
Quant à porter le débat chez Mozilla, cf. plus haut.