1 points par GN⁺ 2023-11-01 | 1 commentaires | Partager sur WhatsApp
  • Après les travaux d’optimisation menés en 2023, Firefox a amélioré non seulement ses benchmarks, mais aussi la vitesse de chargement des pages, la réactivité aux saisies et le temps d’exécution de JavaScript dans la télémétrie d’utilisateurs réels
  • Mozilla travaille avec d’autres navigateurs sur Speedometer 3 afin de créer un test qui reflète mieux les performances perçues par les utilisateurs sur de vraies pages web
  • Le temps entre la réception du premier octet et le First Contentful Paint est passé d’environ 250 ms en début d’année à 215 ms en octobre, soit un retour visuel au chargement presque 15 % plus rapide
  • Le 95e percentile du temps d’exécution de JavaScript pendant le chargement d’une page est passé d’environ 1 560 ms à environ 1 260 ms, soit 300 ms de moins, une amélioration liée aux optimisations de SpiderMonkey
  • Après les versions 116 et 117 de Firefox, la latence des saisies lentes au clavier est elle aussi passée d’environ 65 ms à moins de 59 ms, soit une amélioration de 10 % qui réduit les à-coups pendant la frappe

Pourquoi il est difficile de mesurer les performances réelles des utilisateurs

  • Firefox est un logiciel client complexe qui exécute du code tiers, ce qui rend difficile l’évaluation des changements d’expérience réelle à partir des seuls indicateurs de laboratoire contrôlés
  • Pour évaluer les performances d’un navigateur, il faut des mesures temporelles anonymisées comme le chargement des pages, la réactivité ou le temps de démarrage
  • L’analyse reste contrainte par la nécessité de respecter des standards stricts de protection de la vie privée
    • Comme elle repose sur des indicateurs agrégés, elle ne permet pas d’identifier précisément les données d’un site web particulier
    • Il n’est pas non plus facile de tirer de ces données des conclusions directement exploitables
  • Speedometer 3 vise à créer un test de performance qui simule l’expérience réelle des utilisateurs, afin d’aider les navigateurs à s’améliorer en se basant sur de vrais utilisateurs et de vraies pages web

Amélioration du chargement des pages et du temps d’exécution JavaScript

  • Pour la perception du chargement d’une page, First Contentful Paint est un indicateur plus pertinent que l’événement onload
  • La mesure utilisée est le temps écoulé entre la réception du premier octet depuis le réseau et le FCP
    • Cette valeur montre à quelle vitesse l’utilisateur reçoit un signal indiquant que la page est bien en train de se charger
    • La page web elle-même a une forte influence, mais de meilleures performances globales du navigateur peuvent aussi faire baisser ce chiffre
  • Le temps lié au FCP est passé d’environ 250 ms en début d’année à 215 ms en octobre
    • Les utilisateurs reçoivent donc un retour sur le chargement de la page presque 15 % plus rapidement qu’en début d’année
    • Cette amélioration provient de travaux d’optimisation qui ne ciblaient pas directement le chargement des pages
  • Le temps d’exécution du code JavaScript pendant le chargement d’une page est comparé sur la base du 95e percentile
    • Cet indicateur montre la marge de réduction des frictions utilisateur sur les pages riches en JavaScript
    • Il est passé d’environ 1 560 ms en début d’année à environ 1 260 ms en octobre
    • Cette baisse de 300 ms, soit presque 20 % d’amélioration, pourrait expliquer une part importante de la réduction du temps FCP
  • Le moteur JavaScript SpiderMonkey a bénéficié d’optimisations importantes dans le cadre des travaux sur Speedometer 3, ce qui a contribué à réduire le temps d’exécution de JavaScript

Ce qui a changé dans la réactivité aux saisies

  • La réactivité après le chargement de la page est mesurée par la “keypress present latency”
    • Il s’agit du temps entre le moment où une touche est pressée sur le clavier et celui où le résultat apparaît à l’écran
    • Une page web peut exécuter du JavaScript sur le thread principal pour répondre à un événement keypress, ce qui implique davantage de travail qu’un simple rendu de texte
  • La plupart des frappes sont rapides et limitées surtout par le matériel, comme le taux de rafraîchissement du moniteur, mais les cas de saisie lente perturbent fortement l’expérience utilisateur
  • Comme il est important d’atténuer les pires cas, cet indicateur est lui aussi observé au 95e percentile
  • La keypress present latency au 95e percentile est restée autour de 65 ms pendant la majeure partie de l’année, puis est passée sous les 59 ms après les sorties de Firefox 116 et 117 en août
    • Cela représente une amélioration d’environ 10 % dans les cas de frappes les plus lentes
    • Les utilisateurs bénéficient ainsi d’un retour plus immédiat et de moins d’interruptions pendant la saisie
  • Les améliorations observées dans la télémétrie montrent que les travaux de performance de 2023 ont eu un effet réellement positif pour les utilisateurs de Firefox, tout en laissant encore de la place à de nouvelles optimisations

1 commentaires

 
GN⁺ 2023-11-01
Commentaires sur Hacker News
  • On peut subjectivement constater que Firefox semble plus rapide ces derniers temps, et ces améliorations sont vraiment appréciables et bienvenues.
    Cela dit, la méthodologie de mesure, avec sa forte anonymisation, laisse un léger malaise. Il est aussi possible que le web lui-même soit devenu plus rapide, ou que les gens utilisent simplement un meilleur matériel.
    Si les sites à fort trafic sont davantage optimisés et déploient des versions plus légères, la télémétrie peut donner l’impression qu’en moyenne tout est un peu plus rapide. La même chose peut venir d’un renouvellement du matériel, ou de mises à jour de l’OS et des pilotes.

    • J’utilisais un vieux Firefox de 2020 et je n’ai fait la mise à jour qu’après le problème de sécurité WebP ; la nouvelle version m’a paru immédiatement plus rapide.
    • Comme d’anciennes versions de Firefox sont encore utilisées, on devrait pouvoir comparer pour voir si l’amélioration vient bien de la mise à jour de Firefox elle-même ou si c’est simplement le web dans son ensemble qui est devenu plus rapide.
    • Le moyen le plus simple d’augmenter la vitesse semble être de ne toucher à rien côté logiciel et de laisser la puissance de calcul et le réseau continuer à progresser.
      Historiquement, le logiciel se comporte comme un gaz : il remplit l’espace disponible et dévore les ressources, qui n’appartiennent généralement pas à ceux qui écrivent ce logiciel.
      Le logiciel ne dévore pas le monde ; il dévore des ressources informatiques et de la bande passante payées chaque mois.
    • Au cours des six derniers mois, Firefox m’a progressivement donné l’impression d’être un programme lourd, et j’ai envisagé de passer à Chrome à cause de plantages aléatoires et de ralentissements.
      Je ne m’en étais pas rendu compte avant de lire cet article, mais cette impression semble avoir disparu récemment, et j’avais déjà cessé d’envisager de changer.
    • Le web devient réellement plus rapide. On le voit dans les métriques agrégées mondiales, avec une baisse lente mais régulière, et je pense que cela vient en grande partie du fait que Google a fortement poussé en liant les métriques de performance au classement dans la recherche.
      Mais les données de cet article montrent aussi des changements de performance nets, par paliers, qui coïncident avec le déploiement de versions du navigateur. Ne pas reconnaître les efforts de l’équipe Firefox sur les performances ne serait pas honnête.
  • C’est agréable de voir Mozilla améliorer réellement Firefox au lieu de simplement déplacer des éléments d’interface.
    En tant qu’utilisateur de longue date, j’ai envie de soutenir l’outsider pour préserver un minimum d’équilibre des forces sur le web. Que Mozilla se concentre davantage sur la technique que sur la politique est une bonne chose, et de toute façon Firefox reste un bon logiciel, donc je n’ai pas de gros reproches à faire.

    • Que Mozilla continue de changer l’interface ne me dérange pas. Si cela permet d’augmenter le nombre d’utilisateurs, tant mieux, et Mozilla doit avoir la liberté de prendre des risques si elle ne veut pas rester systématiquement un cran derrière.
      Par exemple, FirefoxOS a sans doute été un échec, mais la plupart des grands paris échouent au départ. À trop ménager ce genre de paris à long terme, on finit comme Microsoft, à réaliser trop tard qu’une partie des jeunes n’a même plus de laptop et que, bien sûr, Windows ne tourne pas sur leur téléphone. Je trouverais très bien qu’il y ait davantage de projets comme FirefoxOS.
    • Il n’est pas seulement important de se concentrer sur la technique, mais aussi sur le produit, c’est-à-dire Firefox.
      On peut très bien prétendre se concentrer sur la technique tout en consacrant toutes ses ressources à Firefox OS.
    • Je suis d’accord sur l’idée de soutenir l’outsider pour l’équilibre des forces du web, et après avoir changé il y a quelques années, je suis effectivement satisfait du passage.
  • Depuis la mise à niveau vers la 118, Firefox se fige aléatoirement tous les quelques jours. Ce n’est ni un problème de CPU ni de swap, mais toutes les fenêtres se bloquent et il faut faire killall firefox, même si Firefox se ferme ensuite proprement.
    À cause du spam autour des moteurs de recherche, il est difficile de trouver des informations pertinentes à ce sujet, et avant la 118 tout allait bien depuis des années. C’est trop rare pour faire facilement des essais de reproduction comme désactiver les extensions ou créer un nouveau profil, donc je vais sans doute devoir faire avec.

    • Développeur Firefox ici. Il y a plusieurs façons de diagnostiquer selon l’environnement. Si tout s’est figé sous Linux, il est très probable qu’il y ait un problème avec le processus parent, le processus principal qui gère les onglets.
      Si le rapporteur de crash est activé, vous pouvez envoyer SIGABRT au processus parent ; après redémarrage, une entrée apparaîtra dans about:crashes et pourra être soumise.
      Si vous utilisez le Firefox de votre distribution et que vous avez gdb et debuginfod, vous pouvez attacher gdb au processus parent de Firefox, récupérer les symboles, puis exécuter thread all apply bt pour dumper les piles de tous les threads du processus parent.
      Si vous utilisez un build Mozilla, vous pouvez consulter https://firefox-source-docs.mozilla.org/toolkit/crashreporte... pour utiliser le serveur de symboles maison. Selon la distribution, cela peut fonctionner ou non aussi avec le Firefox empaqueté par la distribution.
      Une fois les informations de crash récupérées, vous pouvez les joindre, avec la pile, la version de Firefox, le rapport de crash, about:support et toute autre information utile, au suivi de bugs de votre distribution ou à https://bugzilla.mozilla.org/enter_bug.cgi?product=Core.
      Sous Linux, ce type de gel vient souvent d’un bug entre Firefox et l’environnement de bureau, ou d’un problème de pilote graphique ; avec une pile, on peut fortement réduire le champ des causes. Parfois, une mise à jour de paquet ou un simple réglage suffit à résoudre le problème.
    • J’ai eu un symptôme similaire sur deux ordinateurs avec Brave, et le problème a disparu après avoir désactivé l’accélération matérielle. Les deux avaient un GPU Intel.
    • Je me demande si vous utilisez une version Linux qui n’est pas la branche stable ou LTS de la distribution.
      Les plaintes sur l’instabilité de Firefox qu’on voit sur HN semblent surtout venir d’utilisateurs Windows, ou d’utilisateurs Linux qui installent la toute dernière version en dehors du packaging de leur distribution. À l’inverse, j’utilise Firefox de Debian stable depuis des années et je n’ai jamais rencontré dans ces discussions les bugs qui y sont décrits.
    • Si cela se produit pendant la saisie, il pourrait s’agir de https://bugzilla.mozilla.org/show_bug.cgi?id=1844505. Moi aussi je suis affecté par ce bug, mais je n’avais pas encore pensé à aller chercher le ticket correspondant.
      Pour le reproduire, il faudra sans doute essayer avec les binaires Mozilla d’origine.
  • C’est une bonne nouvelle, et ça me donne envie de réessayer.
    J’ai utilisé Firefox pendant presque 20 ans, depuis l’époque de Phoenix/Firebird et de l’installation en mode « décompresser quelque part », mais je suis passé à un navigateur basé sur Chromium à cause de la différence de vitesse ressentie.
    Je n’ai pas lancé de benchmarks ni mesuré quelle action était plus lente de quelques millisecondes dans Firefox pour vérifier cette impression, mais quand c’est un outil qu’on utilise toute la journée, tous les jours, y compris pour le travail, il est facile de ressentir ce genre d’écart.
    En voyant récemment plusieurs rapports d’amélioration des performances et des indicateurs d’usage réel, je me dis que je vais le réutiliser pendant quelques jours. Si je ne sens pas de différence, ou si ça me paraît vraiment plus rapide, je reviendrai dessus.
    La raison pour laquelle j’ai envie d’y revenir, c’est qu’il faut absolument un moteur de navigateur alternatif. Je n’ai pas envie que les comités de normalisation deviennent une sorte d’événement du type « cette année, Google a décidé qu’il fallait faire comme ça »

    • Avec de bonnes performances, plus d’excellentes extensions comme Multi Account Containers et Tree Style Tabs, ça fait un excellent navigateur
  • La fonctionnalité phare de Firefox, c’est toujours qu’il permet une grande flexibilité dans la gestion des onglets. Je reste dans l’écosystème Firefox grâce à Sidebery et TreeStyleTab.
    Si on accumule beaucoup d’onglets ou qu’on les utilise comme une liste de choses à faire, l’expérience est incomparablement meilleure, au point qu’il m’est difficile d’imaginer utiliser autre chose.
    J’utilise aussi Firefox sur Android grâce aux extensions uBlock Origin et Dark Reader. La navigation web mobile est bien meilleure comme ça. Je n’ai pas une grande loyauté envers Firefox en lui-même, c’est juste que je n’ai pas trouvé de navigateur basé sur Chromium qui me convienne aussi bien

    • Les onglets verticaux par défaut d’Edge sont aussi très réussis. Ce n’est pas très riche en fonctionnalités, c’est essentiellement des onglets verticaux avec déchargement automatique et groupes d’onglets, mais en contrepartie c’est très stable et il y a très peu de bugs
    • En tant que personne qui accumule beaucoup d’onglets, j’ai besoin de Auto Tab Discard. Ça met en sommeil les onglets d’arrière-plan inutilisés pour qu’ils ne consomment pas de ressources.
      Et j’aime aussi le fait qu’on puisse, avec du CSS, transformer la barre d’onglets par exemple en trois lignes défilables
    • Je me demande, quand on utilise TreeStyleTab, si vous avez supprimé les onglets du haut, ou si vous affichez les deux.
      Sur un petit écran, j’avais l’impression de perdre pas mal d’espace si les deux étaient visibles
    • J’ai essayé les deux, mais au final j’ai préféré les groupes d’onglets de Safari, mieux intégrés de façon fluide à l’expérience du navigateur
  • J’utilise Firefox comme navigateur principal depuis des années, et ça a été très bien. C’est peut-être parce que je l’utilise surtout sur des machines puissantes, mais je n’ai pas eu de plaintes particulières sur Linux, Windows ou Mac

    • Pareil alors même que je n’utilise pas de machine haut de gamme. Tous les appareils que j’utilise chaque jour ont plus de 5 ans, mais je suis totalement satisfait de la combinaison Firefox + uBlock Origin
    • Je l’utilise depuis des années et je suis presque entièrement d’accord, mais le seul endroit où j’ai eu des problèmes, c’est avec les outils de développement.
      Quand on ouvre de gros fichiers JS, le débogueur devient assez lent, et les source maps aggravent encore ce ralentissement. Avec les source maps, il arrive aussi qu’on ne puisse pas toujours inspecter la valeur des variables, même si ça peut venir d’un problème de configuration de l’outil de build
  • Dans Speedometer 2, Firefox est bien plus lent que Chrome, et Chrome est un peu plus lent qu’Edge. Malgré ça, je trouve qu’en pratique la différence est minime.
    Je respecte et je fais confiance à l’approche de Mozilla en matière de protection de la vie privée. Les conteneurs, ainsi que la possibilité d’utiliser Ublock et Tampermonkey sur mobile, sont difficiles à évaluer en termes de valeur

    • Pour les personnes qui utilisent des ordinateurs peu puissants, ça reste important. En voyage, l’écran de mon MacBook s’est cassé et j’ai dû acheter en urgence un portable avec un Celeron 6305 et 4 Go de RAM. J’y ai installé Firefox comme d’habitude, mais c’était tellement lent et saccadé que c’était inutilisable.
      En passant à Edge, c’était bien plus rapide et ça utilisait aussi moins les 4 Go de RAM. Je ne pensais pas que l’écart serait aussi grand, mais c’était indéniable, et sur un PC peu puissant, Edge tourne bien mieux que les autres navigateurs
    • Les principaux navigateurs semblent désormais tous suffisamment rapides. J’aimerais qu’on se concentre davantage maintenant sur la réduction de la consommation d’énergie
    • À ce sujet, il y a aussi https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
    • Avec une connexion à 75 Mbps, Firefox charge instantanément tout ce dont j’ai besoin.
      Du coup, je me demande à quoi servent vraiment les benchmarks
  • Je sais sur quoi travaille l’équipe Firefox en matière de performances, et je pense qu’elle a tiré les bonnes conclusions.
    Mon petit regret, c’est que j’aurais aimé voir aussi l’évolution des performances par rapport à la même période l’an dernier, afin de contrôler les effets saisonniers. L’image 1 montre des variations à l’échelle du 1/100 de seconde, donc à ce niveau de signal, la maîtrise du bruit me semble d’autant plus importante.
    Cela dit, je suis par ailleurs un utilisateur satisfait de Firefox

    • N’est-ce pas justement arewefastyet ?
      https://arewefastyet.com/
      Et en plus il y a https://wiki.mozilla.org/Areweyet
    • Je me demande quels effets saisonniers on suppose ici. Je connais mal le domaine des performances des navigateurs, donc je ne sais pas si la composition des technologies web que les gens consomment change vraiment selon les saisons.
      Naïvement, j’ai l’impression que la tendance ici est cohérente et que le signal est plus fort que la dispersion. On dirait le résultat d’ingénieurs compétents qui ont optimisé cet indicateur pendant la période de mesure.
      En même temps, je suis d’accord pour dire qu’un axe temporel plus long serait utile. La grosse amélioration d’août ne vient peut-être pas de la sortie de Firefox 116 le 1er août, mais du fait que, pendant les vacances d’été dans l’hémisphère Nord, les gens consultent des contenus plus légers à lire
  • Si vous restez sur un navigateur basé sur Chromium pour une question de sensation de rapidité, cela vaut au moins le coup d’essayer Firefox une fois
    En ce moment, je l’utilise tellement bien que je n’envisage même pas d’en repartir, et il est vraiment important de préserver une forte diversité des navigateurs pour l’avenir du web

    • J’utilise Brave en désactivant les récompenses, le VPN et le portefeuille, et en modifiant une vingtaine de flags. Pour moi, il est plus rapide, prend mieux en charge les extensions, a moins de bugs et consomme moins de mémoire quand j’ai peu d’onglets. J’ai choisi Brave parce que la synchronisation est possible
      Firefox m’a aussi impressionné, et j’ai essayé un fork appelé Floorp. Il a quelques fonctions supplémentaires utiles et, avec la synchronisation prise en charge, je l’ai trouvé meilleur que Firefox classique. Avant, j’utilisais ungoogled-chromium
      https://github.com/Floorp-Projects/Floorp/releases
      Malheureusement, d’après mon expérience, certains sites web fonctionnent encore mieux sur les navigateurs Chromium. C’est anecdotique, mais j’ai aussi l’impression que les sites appartenant à Google font une forme d’empreinte négative contre Firefox, et qu’il y a davantage de fuites mémoire. Je finirai probablement par passer à Firefox à cause de Manifest V3, mais pour l’instant je reste sur Brave
  • Je ne sais pas vraiment si ça s’est amélioré, mais il reste deux problèmes qui ne sont jamais résolus
    Premièrement, sur les vidéos VP9, le décodage vidéo accéléré par le matériel fonctionne bizarrement. Même en le désactivant ou en forçant AV1, ça saccade parfois
    Deuxièmement, dans un environnement graphique hybride, si je regarde une vidéo en arrière-plan tout en jouant, kWin se fige, la vidéo en cours de lecture dans le navigateur devient verte, et tout ce qui utilise l’iGPU ou le dGPU se met à ramer très fortement. Au final, je dois me déconnecter puis me reconnecter pour redémarrer manuellement la session
    Le deuxième problème est peut-être lié à Nvidia prime offload sous Wayland. C’est sans doute un peu ma faute d’avoir une carte Nvidia, mais je n’ai pas trouvé dans Bugzilla de sujet connexe déjà non résolu, et honnêtement j’ai un peu peur de le signaler et de me faire reprendre avec des questions pointilleuses. J’aimerais déboguer davantage, mais je n’ai pas la patience
    Ce n’est pas au point de me faire quitter Firefox, mais ce sont deux casse-têtes persistants. Quoi qu’il en soit, félicitations à l’équipe. Aujourd’hui, j’ai réussi à faire passer 5 personnes à Firefox

    • Sous Linux, le décodage matériel est malheureusement assez chaotique. La plupart de ces problèmes viennent probablement du fait que Firefox s’intègre correctement aux différentes API d’encodage vidéo, mais qu’il y a des bugs du côté de certains pilotes ou composants du même genre
      Si vous êtes sur un PC fixe, cela peut valoir le coup d’essayer de désactiver complètement le décodage vidéo matériel
    • Astuce : il existe une extension Firefox qui force YouTube à utiliser H.264
      Mon appareil prend en charge l’accélération matérielle VP9, mais elle n’était pas fiable, et en passant à H.264, les vidéos YouTube se sont mises à être lues de façon fluide. Les autres sites vidéo utilisent H.264 par défaut, donc en pratique, c’est surtout utile pour YouTube
    • Le deuxième problème rend vraiment fou. Pendant des années, j’ai laissé un flux YouTube ou Twitch ouvert sur un second écran, mais maintenant j’ai en permanence des baisses de FPS, des saccades vidéo et des gels
      C’est une régression de performance vraiment étrange