Firefox 54 généralise le multiprocessus à tous les utilisateurs
En route vers Quantum
Le 14 juin 2017 à 12h00
5 min
Logiciel
Logiciel
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.
Firefox 54 généralise le multiprocessus à tous les utilisateurs
-
Ne l’appelez plus arlésienne
-
Ne pas sombrer dans un appétit gargantuesque en RAM
-
Le long chemin vers Quantum... au détriment du reste ?
-
Le reste des améliorations dans Firefox 54
Commentaires (100)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 14/06/2017 à 13h19
@jb18v
Ok
Le 14/06/2017 à 13h31
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 !
Le 14/06/2017 à 13h33
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.
Le 14/06/2017 à 13h40
merci de l’info
" />
Le 14/06/2017 à 13h42
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à ?
" />
Le 14/06/2017 à 13h43
Le 14/06/2017 à 13h44
Le 14/06/2017 à 13h48
Je ne sais pas :-/
Le 14/06/2017 à 13h55
les cookies et le localstorage sont deux choses différentes. Localstorage n’est pas affecté par les réglages de cookies dans FF
Le 14/06/2017 à 14h10
Ouep, un bloqueur de trackers depuis Firefox 42 (nov. 2015). ^^ cf. https://www.mozilla.org/en-US/firefox/42.0/releasenotes/
Le 14/06/2017 à 14h38
Et c’est même indiqué dans l’article " />
Le 14/06/2017 à 15h06
J’ai ABP et NoScript. Est-ce utile de refaire cette manip? Je viens de passer aussi au 54.0!
Le 14/06/2017 à 15h14
Dans Nightly on peut modifer la valeur de dom.ipc.processCount dans about:config. Peut-être que ça marche aussi avec Firefox stable.
Le 14/06/2017 à 15h25
Le 14/06/2017 à 15h27
Le 14/06/2017 à 15h51
Le 14/06/2017 à 12h10
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.
Le 14/06/2017 à 12h14
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)
Le 14/06/2017 à 12h21
C’est une bonne idée ça, mais il faut que le site web propose l’option, non ?
Le 14/06/2017 à 12h21
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) ?
Le 14/06/2017 à 12h25
C’est l’Hydre de Lerne : à chaque fois que tu tues un processus, deux autres apparaissent. " />
Le 14/06/2017 à 12h26
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…
Le 14/06/2017 à 12h28
La 54 est une version finale ? Je viens d’avoir une mise à jour vers la… 53.0.3 " />
Le 14/06/2017 à 12h29
" />
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) " />
Le 14/06/2017 à 12h29
Je viens d’avoir la mise à jour 54.0.
Le 14/06/2017 à 12h37
“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”
Le 14/06/2017 à 12h48
Comment est ce qu’on peut modifier le nombre de processus ?
Le 14/06/2017 à 12h50
@zhebulonn : jouer avec la valeur dom.ipc.processCount et ses dérivés
cela dit là il est à 1 et j’ai 3 process " />
Le 14/06/2017 à 12h53
Petites précisions:
Le 14/06/2017 à 13h10
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.
Le 14/06/2017 à 13h15
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 14/06/2017 à 13h16
Comme les mouches, dés que tu en tue un, les autres viennent pour l’enterrement." />
Le 15/06/2017 à 11h39
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?
Le 15/06/2017 à 13h49
Je l’utilise toujours sur mon PC fixe
Le 15/06/2017 à 13h56
Et tu as toujours les problèmes que tu mentionnes avec la 54?
Le 15/06/2017 à 14h02
Oui, Firefox utilise pas mal de ressources en arrière plan
Le 15/06/2017 à 21h56
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.
Le 15/06/2017 à 22h19
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.
Le 16/06/2017 à 01h02
Le 16/06/2017 à 07h34
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 " />
Le 16/06/2017 à 13h33
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 !
Le 16/06/2017 à 13h35
Le 16/06/2017 à 15h01
Le 17/06/2017 à 11h42
Le 17/06/2017 à 18h08
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 " />
Le 19/06/2017 à 09h15
Le 19/06/2017 à 09h28
Avec celle-ci ?
Le 19/06/2017 à 11h52
Le 14/06/2017 à 21h28
Ç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.
Le 14/06/2017 à 21h35
µblock et uBlock Origin ne sont pas exactement les mêmes extensions. ^^
Le 14/06/2017 à 21h44
C’est pas faux ! " />
Le 14/06/2017 à 22h29
Le 15/06/2017 à 01h57
et ils ont ajouté “rechercher avec” qui prend une place énorme pour rien dans la beta 55
de pire en pire à chaque version
Le 15/06/2017 à 05h07
C’était µblock origin.
Le 15/06/2017 à 06h41
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.
Le 15/06/2017 à 07h43
Le 15/06/2017 à 07h59
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/
Le 15/06/2017 à 08h07
Voila justement de quoi remplacer l’extension qui bloquait (speed dial). " />
Le 15/06/2017 à 08h23
Le 15/06/2017 à 09h22
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”.
Le 15/06/2017 à 10h20
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.
Le 15/06/2017 à 10h31
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é.
Le 15/06/2017 à 10h49
La version ESR me sied mieux. Les versions intermédiaires sont souvent immatures.
Le 15/06/2017 à 11h37
Le 14/06/2017 à 15h59
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!
Le 14/06/2017 à 16h05
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é…
Le 14/06/2017 à 16h56
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..
Le 14/06/2017 à 17h03
Le 14/06/2017 à 17h08
Le 14/06/2017 à 17h27
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)
Le 14/06/2017 à 17h35
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.
Le 14/06/2017 à 17h42
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 " /> …
Le 14/06/2017 à 17h52
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 😂
Le 14/06/2017 à 17h54
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
Le 14/06/2017 à 17h59
Le 14/06/2017 à 18h11
Le 14/06/2017 à 18h29
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…
Le 14/06/2017 à 18h30
« Moins ressourcivore », pas pour tout le monde. Quand j’ai testé µblock mon processeur s’excitait et firefox ramait comme pas possible…
Le 14/06/2017 à 18h39
Le 14/06/2017 à 18h45
Le 14/06/2017 à 19h07
Le 14/06/2017 à 19h12
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…
Le 14/06/2017 à 19h30
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).
Le 14/06/2017 à 19h50
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.
Le 14/06/2017 à 20h08
Le 14/06/2017 à 20h18
Le 14/06/2017 à 20h34
Le 14/06/2017 à 20h40
Le 14/06/2017 à 20h44
T’as regardé about:performance pour savoir d’où ça vient ?
Le 14/06/2017 à 20h46
Le 14/06/2017 à 20h47
Le 14/06/2017 à 20h52
Bonjour,
Est-ce que quelqu’un pourrait me dire comment je peux savoir quelle extension bloque le multi-processus ?
Le 14/06/2017 à 21h03
Je me suis posé la même question et j’ai trouvé cet addon qui indique quelles extensions sont compatibles.
Le 14/06/2017 à 21h07
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 " />
Le 14/06/2017 à 21h11
Le 14/06/2017 à 21h27
Mise à jour faites à l’instant et je trouve la différence flagrante avec mon vieux i5 750
Le 14/06/2017 à 12h07
Et comment on fait pour tuer le process dans le gestionnaire des tâches ? " /> 1 chances sur 4 ? " />
Je vais tester
Le 19/06/2017 à 13h41
Désolé du raccourci, mais c’est bien µblock origin que j’ai testé.
Le 20/06/2017 à 14h51
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 ?
Le 20/06/2017 à 18h28
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).