Firefox 54 marque une étape majeure dans la vie du navigateur. Le multiprocessus est maintenant généralisé à l’ensemble des versions pour Linux, macOS et Windows. Un pas de plus vers le renouvellement plus complet de Quantum.
Mozilla avait promis que l’année 2017 serait la plus importante pour son navigateur depuis sa création. On sait qu’elle devrait se clôturer avec l’arrivée de son nouveau moteur de rendu, Quantum, qui embarque une série d’améliorations provenant du projet Servo. Plusieurs parties seront ainsi rédigées directement en Rust, un langage de Mozilla pensé pour gommer certains défauts du C.
Mais avant même de songer à Quantum, il fallait que Firefox en finisse avec le projet Electrolysis, visant à séparer l'application en plusieurs processus. Un long chemin qui touche au but, même s’il s’agit surtout pour l’éditeur de rattraper une concurrence très en avance dans ce domaine.
Ne l’appelez plus arlésienne
Electrolysis est un nom utilisé depuis de nombreuses années par Mozilla. Il désignait initialement le projet visant à isoler les onglets du reste du navigateur. Ce découpage existe en fait depuis plusieurs mois, mais pas pour tout le monde. Il fallait notamment contrôler le comportement des extensions.
Avec Firefox 54, deux changements importants sont à noter. Tout d’abord, l’utilisation d’Electrolysis ne dépend plus d’aucune condition : il est actif partout, quels que soient le système d’exploitation et les extensions présentes. Ensuite, et c’est sans doute le plus important, le nombre de processus passe de deux à quatre.
On retrouve donc toujours un processus dévolu entièrement à l’interface, trois étant désormais consacrés aux onglets. Ils sont en charge du rendu et des calculs de scripts notamment. La différence de réactivité est très nettement perceptible, surtout lors du chargement de pages lourdes comme Facebook ou Twitter.
Notez que même s’il s’agit d’un changement majeur pour Firefox, les processus multiples sont loin d’être une nouveauté dans le domaine des navigateurs. Chrome, Edge, Opera et Safari créent soit un processus pour chaque onglet, soit pour chaque domaine actif. Mozilla le sait bien, et le choix de quatre processus est selon l’éditeur le bon compromis entre performances brutes et consommation de mémoire vive.
Ne pas sombrer dans un appétit gargantuesque en RAM
Pour prouver ses dires, l’éditeur a publié les résultats de plusieurs tests, visant surtout à charger 30 pages en mesurant parallèlement la consommation de mémoire vive pour l’ensemble des onglets qui s’ouvrent alors. Les tests ont été réalisés sous Windows 10, macOS et Ubuntu 16.04 et Firefox s’est retrouvé moins gourmand que Chrome, Edge ou Safari.
Cela étant, non seulement les résultats sont « normaux », mais il faut les prendre avec quelques pincettes : la consommation de mémoire ne fait pas tout. Elle grimpe invariablement en fonction du nombre d’onglets, et si Chrome et Edge en créent un pour chaque page chargée indépendamment, la quantité de RAM nécessaire va grimper d’autant.
En fait, l’explication tient surtout au modèle de sécurité adopté par les navigateurs récents : ils créent une sandbox pour chaque processus, c’est-à-dire un espace mémoire isolé. Il y a donc répétition d’un certain nombre de composants, un aspect obligatoire pour couper toute communication potentiellement dangereuse entre les onglets ouverts. Ce qui expliquerait pourquoi la consommation de Firefox est inférieure. Nous cherchons cependant à en savoir davantage sur le sujet et reviendrons dessus le cas échéant.
Le long chemin vers Quantum... au détriment du reste ?
Dans tous les cas, les utilisateurs noteront sans peine l’amélioration générale des performances, qui se ressent surtout en termes de réactivité pendant le chargement des pages. L’avantage des processus multiples est en effet que les différents cœurs des processeurs peuvent être utilisés simultanément en répartissant les calculs, ce que les onglets de Firefox ne faisaient pas jusqu’à présent.
L’aboutissement de ces travaux est également une étape majeure vers Quantum, car le nouveau moteur de rendu sera l’occasion pour Mozilla de revoir entièrement l’architecture de son navigateur. L’éditeur l’indique à nouveau d’ailleurs dans son billet de blog sur la version 54 : il veut faire de Firefox le navigateur le plus rapide et le plus réactif, aussi bien sur ordinateur que sur les plateformes mobiles. Un objectif que nous surveillerons évidemment de près.
Mozilla devra aussi faire attention à ne pas oublier les autres aspects d'un navigateur, notamment les questions de respect de la vie privée. Car bien qu'ayant énormément communiqué sur le sujet il y a quelques temps et revu la navigation privée de Firefox, les choses ont peu évolué depuis.
Ce, alors que Google va bloquer certaines publicités gênantes ou nuisibles dans Chrome et qu'Apple introduit un nouveau dispositif de blocage des média en lecture automatique ou d'isolation plus fine des cookies dans Safari.
Le reste des améliorations dans Firefox 54
Bien que la généralisation du multiprocessus soit l’élément le plus important, Firefox 54 comporte également quelques autres apports, mais assez mineurs. Par exemple, une révision du panneau de téléchargement pour rendre son affichage plus clair. Dans les versions mobiles, les marque-pages spécifiques ont été déplacés dans le menu général qui leur est consacré. Comme toujours, Firefox 54 en profite pour corriger plusieurs vulnérabilités, dont trois critiques.
La récupération de la nouvelle version peut se faire dans le navigateur depuis l’à propos. Ceux qui préfèrent télécharger l’installeur pourront le faire depuis la page officielle.
Commentaires (100)
#1
Et comment on fait pour tuer le process dans le gestionnaire des tâches ? " /> 1 chances sur 4 ? " />
Je vais tester
#2
Je n’ai pas encore eu le temps de beaucoup tester sur windows 7 (bien qu’ayant ressenti un petit lag au premier lancement après mise à jour) mais sur android, ca a l’air d’aller.
J’attends juste l’option Android permettant de différencier la qualité des images selon si l’on est en wifi ou 3G/4G.
#3
Pas de sandbox par domaine ? ca va surement s’amuser dans les pwn2own et autres concours.
Il va falloir attendre 2018? (2017 a déjà eu lieu)
#4
C’est une bonne idée ça, mais il faut que le site web propose l’option, non ?
#5
C’est quoi le risque ? Qu’en allant sur une page web un script puisse récupérer les données présentes sur une autre page web (du genre celle de ta banque) ?
#6
C’est l’Hydre de Lerne : à chaque fois que tu tues un processus, deux autres apparaissent. " />
#7
Oui cela rend les plages de mémoire prévisibles car tu reste dans la même sandbox.
Alors que justement l’isolation de chaque sandbox on a une protection supplémentaire via ASLR
Mais bon il faut d’abord trouver une faille de type débordement de tampon ou autre.
Pour faire simple: en consommant plus de mémoire on rajoute un peut plus de sécurité (c’est pas plus mal)
Edit: un article intéressant sur les mécanismes de protection dans Windows 10 (DEP, SEHOP, ASLR)
https://blogs.technet.microsoft.com/askpfeplat/2017/04/24/windows-10-memory-prot…
#8
La 54 est une version finale ? Je viens d’avoir une mise à jour vers la… 53.0.3 " />
#9
" />
bon déjà en prenant le plus gros, ça marche
mais mon extension 1Password bloque le multiprocess " /> (même en 4.6.6 la dernière) " />
#10
Je viens d’avoir la mise à jour 54.0.
#11
“les choses ont peu évolué depuis.
Ce, alors que Google va bloquer certaines publicités gênantes ou nuisibles dans Chrome ”
Il ne faut pas oublier que Firefox a déjà intégré un bloqueur de pub gênantes depuis bien plus longtemps que les autres. Déjà actif par défaut en navigation privée, on peut aussi l’activer manuellement pour les sessions classiques…
Pour cela, il faut aller dans “about:config” et accepter les risques de tout casser et rechercher (dans le champ adéquat “privacy.trackingprotection.enabled” et passer la valeur de “false” à “true”
#12
Comment est ce qu’on peut modifier le nombre de processus ?
#13
@zhebulonn : jouer avec la valeur dom.ipc.processCount et ses dérivés
cela dit là il est à 1 et j’ai 3 process " />
#14
Petites précisions:
#15
Toujours pas vraiment d’évolution quant au support des plugins. Je suis toujours en multiprocessur désactivé à cause de quelques plugins :
-PassIFox
-Self-Destructing Cookies
-YourOnlineChoices Plugin
Autant je pourrais me passer du dernier, doutant sévèrement de son efficacité, autant pas les 2 premiers. 3 plugins non compatibles sur 9, ça fait quand même 30% de taux de rejet… Donc en attendant des M@J, je ne peux pas tester.
#16
La le probleme c’est les auteurs des plugins. C’est dit depuis longtemps que e10s casse la compatibilité avec certains plugin. Il y a même des outils pour tester la compatibilité (en automatique donc je ne sais pas ce que ça vaut)
#17
Comme les mouches, dés que tu en tue un, les autres viennent pour l’enterrement." />
#18
@jb18v
Ok
#19
Oui je sais bien, mais pourtant dans mes 3 exemples, 2 sont quand même très répandus, et pas abandonnés. donc… devraient avoir eu depuis longtemps une mise à jour !
#20
Self-Destructing Cookies ne sera apparemment jamais compatible :
Q: Will this add-on ever be multi-process (e10s) compatible?
A: Add-ons can’t monitor sites’ LocalStorage usage in e10s mode. This functionality will probably never be restored for legacy add-ons such as SDC. This means that the answer is “very likely never”. You can still force-enable e10s and SDC should clean your cookies just fine, but it can only clean your LocalStorage when the browser starts.
Maintenant, il y a réellement besoin de détruire les cookies en temps réel ? Perso je me contente des options standard : ne jamais accepter les cookies tiers, puis conserver les cookies jusqu’à la fermeture de Firefox. J’ai mis certains sites de confiance sur liste blanche (exceptions), et à chaque fois que je relance le navigateur, c’est de nouveau tout beau tout propre.
#21
merci de l’info
" />
#22
Plusieurs parties seront ainsi rédigées directement en Rust
mézalors, chez Mozilla Firefox, on préfère ce rust-ci ou ce rust-là ?
" />
#23
#24
#25
Je ne sais pas :-/
#26
les cookies et le localstorage sont deux choses différentes. Localstorage n’est pas affecté par les réglages de cookies dans FF
#27
Ouep, un bloqueur de trackers depuis Firefox 42 (nov. 2015). ^^ cf. https://www.mozilla.org/en-US/firefox/42.0/releasenotes/
#28
Et c’est même indiqué dans l’article " />
#29
J’ai ABP et NoScript. Est-ce utile de refaire cette manip? Je viens de passer aussi au 54.0!
#30
Dans Nightly on peut modifer la valeur de dom.ipc.processCount dans about:config. Peut-être que ça marche aussi avec Firefox stable.
#31
#32
#33
#34
ublock, je connais mais je n’ai pas testé, alors que adblock +, je suis depuis toujours. Je vais le tester pour voir la différence. Merci!
#35
Je vais l’essayer sur mon smartphone car effectivement, j’ai souvent des avertissements de mémoires saturées, lorsque j’ouvre Firefox et je suis obligé de faire un vidage mémoire, pénible à faire lorsque l’on est pressé…
#36
Bah déjà Firefox n’était pas présent dans la monture 2016 car pas assez sécurisé (pas de challenge).. Il me semble qu’il était présent en 2017 mais bon… On est en 2017 et Firefox n’a clairement pas de solution de mitigation comparable à Chrome/Edge..
#37
#38
#39
Firefox 54 généralise le multiprocessus à tous les utilisateurs éligibles.
Celles et ceux qui utilisent une ou plusieurs extensions qui ne sont pas marquée(s) compatible, n’auront pas le multiprocessus !
https://arewee10syet.com/
Je suis sur Firefox 54 et dans about:support je vois toujours:
Multiprocess Windows 0/1 (Disabled by add-ons)
#40
Passifox va etre rendu compatible soon
Un utilisateur leur a coder un moyen de le rendre compatible, de ce que j’ai compris il fonctionnera comme chromeifox, en webextentions.
Manque plus qu’ils poussent la maj.
#41
Perso je vois une légère différence dans le temps de rendu des pages, par contre il consomme toujours autant de RAM et est toujours lent à démarrer " /> …
#42
Pour résumer, ABP était très bien, mais ils se sont vendus pour laisser passer des contenus ciblés.
uBlock bloque tout sans exception, en plus simple et moins ressourcivore.
Le couple gagnant c’est quand même Firefox avec uBlock, des dns libres et derrière un fichier hosts blindé, et on remet une couche avec le blocage de la pub à la source par la Freebox 😂
#43
A part vivre sans addon, la fonctionnalité e10S est inexistante dans les faits pour les raisons mentionnées par 3 précédents commentaires. La version 53 était plus tolérante.
Bref, ça n’avance pas et c’est regrettable. En espérant que l’article suivant apportera une réelle nouveauté d’ici novembre :
https://support.mozilla.org/fr/kb/modernisation-technologie-modules-firefox
#44
#45
#46
Pas d’accord, FF peut vite devenir ingérable en lui lançant plusieurs onglets avec du JS… Expérience hélas en cours chez un client…
#47
« Moins ressourcivore », pas pour tout le monde. Quand j’ai testé µblock mon processeur s’excitait et firefox ramait comme pas possible…
#48
#49
#50
#51
Oui mais c’est même pas complètement corrigé dans la 54 en fait. Certains styles CSS ne fonctionnent toujours pas (par exemple les “font-weight”).
Et pour les organisations qui sont sur le canal ESR, pas de correctif avant 2018…
#52
La le probleme c’est les auteurs des plugins. C’est dit depuis longtemps
que e10s casse la compatibilité avec certains plugin. Il y a même des
outils pour tester la compatibilité (en automatique donc je ne sais pas
ce que ça vaut)
Le problème est surtout Mozilla, car les changements sont légions et difficiles à suivre vu la fréquence de sortie des releases (6 semaines). Or la fondation a annoncé que le XUL sera abandonné sur la 57+. Ce qui obligera à tous les auteurs à tout réécrire en “Webextensions”, et encore, si c’est possible, car hélas ce type d’addons offre des possibilités inférieures (pas de modification d’interface, etc.) qui font que certains seront condamnés à mourir.
Du coup je conçois que les auteurs ne soient plus très motivés. Le site d’addons Firefox était déjà devenu un vaste cimetière depuis longtemps, mais dans pas longtemps ce sera pire. D’ailleurs “Self-Destructing Cookies” ne sera pas réécrit, l’auteur a indiqué ne pas avoir le temps.
Alors oui les Webextensions sont… cross-browsers et tout mais j’ai pris Firefox pour ses addons et par nécessité (Opera “Presto” mort, Firefox 4 était pas mal, Chrome c’est hors de question)… Si les rares survivants à l’addoncalypse sont compatibles partout, pourquoi rester sur Firefox du coup, autant que je passe sur Vivaldi qui fonctionne bien mieux.
Pour l’instant, j’ai switché sur “Waterfox” car ce dernier gardera XUL pendant un temps. J’attends qu’un des addons qui m’est VITAL soit porté sur Vivaldi (je veux des tabs verticaux en mode “Tree”, pas comme fourni).
#53
Depuis quelques temps mon Firefox rame comme pas possible, ça bouffe des ressources processeurs incroyables pour une utilisation basique.
C’est la première fois en une décennie que je pense à changer de navigateur.
#54
#55
#56
#57
#58
T’as regardé about:performance pour savoir d’où ça vient ?
#59
#60
#61
Bonjour,
Est-ce que quelqu’un pourrait me dire comment je peux savoir quelle extension bloque le multi-processus ?
#62
Je me suis posé la même question et j’ai trouvé cet addon qui indique quelles extensions sont compatibles.
#63
Cette extension donne l’information.
Je viens de faire le ménage chez moi avec ses infos et suis passé en multi-processus.
Edit grillé de peu " />
#64
#65
Mise à jour faites à l’instant et je trouve la différence flagrante avec mon vieux i5 750
#66
Ça dépend des filtres auxquels tu es abonné sur ABP et de ce que tu autorises avec NoScript (google analytics et cie).
Firefox a utilisé à la base de son filtre la liste de Disconnect comme l’indique l’article en lien dans cette news (Merci Vincent).
Cette liste de Disconnect peut être ajoutée à uBlock Origin donc c’est sûrement le cas aussi pour ABP.
#67
µblock et uBlock Origin ne sont pas exactement les mêmes extensions. ^^
#68
C’est pas faux ! " />
#69
#70
et ils ont ajouté “rechercher avec” qui prend une place énorme pour rien dans la beta 55
de pire en pire à chaque version
#71
C’était µblock origin.
#72
Moi qui adorait Firefox, je suis passé à Chrome. Sur mon PC portable, j’ai plein de RAM (8Go) mais un CPU moyen. Firefox était plus lent, et surtout, consomme bien plus de CPU pour les onglets en arrière plan.
#73
#74
Finally the Group Speed Dial addon will be able to override the “New tab” page! Good job Mozilla!
https://addons.mozilla.org/en-US/firefox/addon/groupspeeddial/
#75
Voila justement de quoi remplacer l’extension qui bloquait (speed dial). " />
#76
#77
Euh, e10s ne se limite absolument pas à éviter le plantage de tout le navigateur.
Electrolysis functionality hosts, renders, or executes web related content in background child processes which communicate with the “parent” Firefox browser via various ipdl protocols. The two major advantages of this model are security and performance. Security improvements are accomplished through security sandboxing, performance improvements are born out of the fact that multiple processes better leverage available client computing power.
Electrolysis child processes are currently in use for the following tasks within Firefox:
In the future Electrolysis child processes may be used to handle other browser tasks including audio, networking (bug 1322426), PDFium and Pepper Flash (bug 558184).
In Mozilla documentation “Electrolysis” is often shorted as “e10s”.
#78
Sous Opéra Mini, c’est possible sur mobile. Mais je pense que dans ce cas, la page passe les serveurs d’Opéra. Les images ne sont donc pas fournies directement moins bonne qualité directement.
#79
Petite question à ce sujet… Une extension installée mais pas activée, ça consomme quand même de la RAM/process ou pas ? Est-ce lancé en mémoire uniquement quand on l’active ? J’ai pas mal d’extensions dont je me sers à l’occasion et je me suis demandé si ça pouvait jouer sur la légèreté.
#80
La version ESR me sied mieux. Les versions intermédiaires sont souvent immatures.
#81
#82
Bon j’ai réussi à activer e10s en supprimant mon addon customNewTab. Quelqu’un connaît un addon compatible qui permet d’afficher une page html en local quand on ouvre un nouvel onglet?
#83
Je l’utilise toujours sur mon PC fixe
#84
Et tu as toujours les problèmes que tu mentionnes avec la 54?
#85
Oui, Firefox utilise pas mal de ressources en arrière plan
#86
Si je comprend bien le paramètre force.enable provoque des conflits ? De mon coté j’utilise toujours l’extension Beyond Australis (cache automatiquement la barre d’adresse) avec le multi process forcé. Parfois quelques blocage je suis passé du dépôt Beta au Stable et moins de soucis depuis à priori.
#87
Plus possible de marquer une page web depuis mais ça se joue à pas grand chose je pense.
Le multi process a bien opti mon pc portable sous core I5 broadwell. C’est bien plus rapide que ce soit sous Windows ou Linux.
#88
#89
Merci, c’est ce que j’aurais dis également mais je trouvais Firefox tellement que j’en suis venu à me poser des tas de question. En attendant, je suis reparti sur un profil neuf avec la 54 et le nombre de processus qui me convient et ça va mieux " />
#90
le titre est archi faux et mensonger !
mozzila a activer les multi processus que pour 50% des utilisateur de firefox et encore ca dépend des extensions que vous avez sur votre browser !
#91
#92
#93
#94
Réponse un peu en retard mais si tu es sur Windows 8 ou plus, le processus à tuer est celui qui est dans “Application” quand on est dans l’onglet “Processus” en triant par nom, sinon sans trier par nom c’est celui qui a la flèche à gauche pour déplier (signe que c’est une fenêtre) ou encore chez moi c’est celui qui consomme toujours le plus de RAM des 6 que j’ai (nightly 56)… voila " />
#95
#96
Avec celle-ci ?
#97
#98
Désolé du raccourci, mais c’est bien µblock origin que j’ai testé.
#99
700 mo au démarrage avec µblock désactivé. Lent et rame. Mes 4 coeurs sont affolés.
Il faut 32 Go de ram chez Mozilla maintenant ou c’est juste une version à patcher ?
#100
J’avais recherché cette information et apparemment non, une extension désactivée n’impacte pas les performances de Firefox. Cependant, ce dernier vérifiera quand même les mises à jours de la dite extension (et donc utilisera quand même un peu de ressources pour cette tâche).