Priorisation des onglets sur Firefox

Je ne donne pas de nouvelles mais je suis toujours de près toutes les actualités liées à la performance. En ce moment il y a peu d’articles techniques qui font de réelles avancées. L’innovation vient plutôt du navigateur, et Mozilla fait un sacré travail.

Il y a une dizaine de jours j’ai vu l’annonce d’une fonctionnalité qui me semble couler de source. J’avais longtemps pensé que c’était le cas sur tous les navigateurs, et mêmes sur tous les systèmes d’exploitation : donner plus de ressources à l’onglet ou à l’application en cours d’utilisation. Cela semble logique mais ce n’était pas encore le cas.

Jusqu’alors le navigateur gère ses files de téléchargement, premier entré premier sorti, ou presque. Ceux qui ont comme moi l’habitude d’ouvrir des dizaines d’onglets en parallèle connaissent bien le problème. Assez vite le navigateur devient inutilisable car trop de pages sont en chargement. La navigation principale s’en ressent, quand elle n’est pas totalement bloquée.

La solution ? Paul O’Shannessy nous propose une priorisation des onglets et des requêtes réseaux qui en découlent. C’est génial. Ça ne coute rien, ça ne demande pas une amélioration des performances du navigateur réseau, ça n’a quasiment aucun effet négatif, mais c’est une avancée réelle pour l’utilisateur, comme je les aime.

Il est tout à fait possible qu’on voit ça arriver dès Firefox 3.6, rapidement donc. Ça me rappelle leurs précédents travaux sur la performance ressentie. C’est comme ça qu’on fait avancer le web, merci Mozilla.

Paul nous donne quelques détails dans un précédent article. Il s’agit de prioriser l’onglet en cours, puis les onglets en tâche de fond sur la fenêtre en cours ou les onglets en cours sur les fenêtres en tâche de fond, le reste (onglets en tâche de fond sur une fenêtre en tâche de fond) et enfin toutes les fenêtres minimisées.

Pour ceux que ça intéresse une extension est disponible pour tester ça sans attendre l’intégration dans le tronc commun de Firefox.

Publié par edaspet

Plus d'informations sur mon profil en ligne

19 réponses sur « Priorisation des onglets sur Firefox »

  1. j’ai souvent également des tonnes d’onglets ouverts. Ca semble une bonne idée, mais j’ai peur que la priorité donnée à l’onglet en cours de lecture ne ralentissent l’affichage des autres onglets lors de leur affichage.

  2. Intéressant !

    Maintenant, est-ce que cette prioritisation (après l’isolation introduit par Chrome) tiens compte des sous module externe sans modification ? Je pense à Flash et au publicité qui tourne en boucle inutilement… C’est générateur de ralentissement même sur un Mac d’il y a 1 mois 🙂

  3. J’aimerai bien voir leur méthodologie parce que ça semble plus qu’étrange (et qu’à première vue ils comptent les failles dans les extensions, ce qui forcément n’a aucun sens) mais @Olivier …. tu restes clairement hors sujet.

    Il y a (probablement) des blogs sur mozilla ou sur la sécurité sur lesquels ce genre d’annonce à sa place, mais je ne vois pas ce que ça change par rapport aux performances.

    Bref, merci de ne pas lancer de troll, les prochains seront modérés sans autres avertissements.

  4. Bonjour Éric,

    C’est une excellente nouvelle, sais-tu si c’est aussi le cas des ressources systèmes (éxecution de JS et mémoire) ? Je pense par exemple aux setTimeout ou setInterval qui tournent dans des onglet qui de toute façon n’affichent pas le contenu à l’utilisateur. Après, j’imagine que ça pourrait bugger certains scripts mal conçus… Mais bon, le jeu en vaut peut-être la chandelle.

    ++

  5. Non, on ne parle que d’ordonnancement des requêtes réseau, rien d’autre. Sauf à entrainer des timeout (mais ça aurait de toutes façons fait dérailler quelque chose, autant que ce soit des taches de fond et pas des taches en cours), je ne pense pas que ça risque de faire dérailler quoi que ce soit, au contraire.
    Ca va même bien aider les autocompletions et autres requêtes ajax qui ont besoin de réactivité.

  6. Je vois un petit problème :
    écouter de la musique sur deezer sans regarder l’onglet risque t il d’être pénalisé (imaginons : prémium et haute qualité donc plus de bande passante consommé). Je regarde pas mais j’ai besoin que cet onglet soit prioritaire.
    (j’ai pas lu les liens dans le billet).

  7. Je ne sais pas si Flash prend le même chemin que le reste dans le navigateur. Sinon on parle de priorité dans la file d’attente, pas de priorité dans la réception. Je m’engage peut être trop, il faudrait que je regarde le code concerné (ou que quelqu’un plus au fait de Gecko le fasse), mais à priori il s’agit juste de savoir quelle requête lancer en premier. Une fois lancée (ce qui est le cas pour le streaming Deezer) alors ça ne devrait rien changer.

    Sinon on ne m’enlèvera pas de la tête que Deezer sur une page web est le mauvais outil. Spotify a choisi une application séparée. Rien n’empêche de la baser sur Prism si on veut un vrai navigateur, ou sur Air si on veut du flash, mais mélanger la session de navigation et l’écoute en tâche de fond dans le même contexte applicatif, il y en a bien un en trop.

  8. A priori Flash tourne dans un process qui n’appartient pas a navigateur (je dis ça dans mon langage de profane, hein). Le fait même que Flash ne soit pas intégré dans Firefox est une des principales contraintes de son intégration accessible (difficultés à naviguer au clavier de HTML vers Flash et vice-versa). Donc je dirais que Flash ne peut pas être impacté par ce genre de méthode qui travaille sur le moteur de réseau/rendu. (mais c’est une « educated guess »)

  9. « deezer » était juste un exemple pour tout ce qui est contenu musical (audio et/ou vidéo) passant via flash.

    D’ailleurs si j’ai bien compris la réponse, même pour un contenu audio ou vidéo intégrer via le HTML5, l’utilisateur ne ressentira rien de négatif.

  10. Sur Chrome, lorsqu’on lance une action JS qui effectue des modifications sur le DOM voire sur l’URL mais qu’on change d’onglet sans attendre la fin de ce traitement puis qu’on revient sur l’onglet en question, on peut voir pendant un laps de temps très court l’écran avant l’action puis changer immédiatement pour mettre à jour l’affichage.

    Cas concret : la déconnexion d’un compte sur un site (par exemple GMail).

    Le navigateur semble donc effectuer des modifications sur le DOM mais visiblement ne rafraîchit pas l’affichage tant que l’utilisateur ne revient pas sur l’onglet.

    Ce comportement ne serait-il pas plus adapté pour améliorer les performances de l’onglet courant (d’un point de vue utilisation du proc) ?

  11. @Loic: en le lisant ça me parait effectivement logique de ne pas faire le rendu quand l’onglet est en tache de fond, mais je ne sais pas ce qu’il en est pour firefox. Je t’invite à poser la question à ton développeur préféré.

    @Killy: oui mais une vidéo tu ne la met pas en tache de fond, ou si c’est le cas ce n’est pas trop grave si elle rame

  12. Je viens de tester mozNetworkPrioritizer. Effectivement, avec mes 167 onglets à ouvrir j’ai la main très rapidement sur les 10 derniers onglets consultés. Les autres se chargent de manière séquentielle en partant du premier.
    Un nouvel onglet se charge également plus rapidement alors que l’intégralité des onglets ne sont pas encore chargés.

    Ramené sur un nombre d’onglets « normal », l’expérience utilisateur est améliorée.

    Merci Éric pour m’avoir fait découvrir cette extension.

  13. En fait la nouveauté est là surtout au niveau de la file d’attente réseau. La répartition de la charge sur plusieurs cœurs aidera le navigateur mais je ne suis pas sûr que cela influera sur la priorisation.

Les commentaires sont fermés.