Firefox s’est réellement accéléré pour les utilisateurs en 2023
(hacks.mozilla.org)- 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
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.
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.
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.
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.
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.
On peut très bien prétendre se concentrer sur la technique tout en consacrant toutes ses ressources à Firefox OS.
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.
Si le rapporteur de crash est activé, vous pouvez envoyer
SIGABRTau processus parent ; après redémarrage, une entrée apparaîtra dansabout:crasheset pourra être soumise.Si vous utilisez le Firefox de votre distribution et que vous avez
gdbetdebuginfod, vous pouvez attachergdbau processus parent de Firefox, récupérer les symboles, puis exécuterthread all apply btpour 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:supportet 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.
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.
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 »
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
Et j’aime aussi le fait qu’on puisse, avec du CSS, transformer la barre d’onglets par exemple en trois lignes défilables
Sur un petit écran, j’avais l’impression de perdre pas mal d’espace si les deux étaient visibles
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
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
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
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
https://arewefastyet.com/
Et en plus il y a https://wiki.mozilla.org/Areweyet
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
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
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
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
C’est une régression de performance vraiment étrange