Après Google et un Chrome 49 bêta largement centré sur les développeurs web, Mozilla lance à son tour son Firefox 46 Developer Edition. Là encore, l’éditeur continue sur l’amélioration des outils existants, un effort constant depuis quelques mois en particulier.
Chrome a beau mener la vie dure à Firefox, Mozilla n’en démord pas : son navigateur doit devenir une référence pour les développeurs web. Depuis quelques versions, on note ainsi un effort particulier sur l’enrichissement des outils intégrés. Les versions Developer, basées sur le canal Aurora (et donc avant les bêtas), permettent justement de tester les nouveautés en avance, pour peu que l’on s’estime résilient aux éventuels bugs.
Un suivi plus fin de la consommation de mémoire vive
Firefox 46 Developer Edition a du coup été annoncé hier soir et contient plusieurs améliorations pour certains outils, à commencer par celui dévolu à la mémoire vive. Une nouvelle vue, baptisée « Dominator », permet d’examiner de près l’allocation en mémoire pour les différents objets. Le développeur peut ainsi voir n’importe quel objet référence et la taille de chacun en mémoire. L’idée est bien sûr de permettre une plus grande maîtrise de la consommation d’une page, certaines pouvant se montrer particulièrement gourmandes.
Cette surveillance des allocations de mémoire vive se retrouve également dans l’outil dédié aux performances. Les enregistrements sont donc plus détaillés et permettent au développeur de savoir notamment dans quelles proportions le ramasse-miettes (garbage collector) agit sur l’application web en cours d’utilisation. Le signalement des allocations n’est cependant pas actif par défaut, et il faudra se rendre dans les paramètres pour le sélectionner dans le menu, comme indiqué dans la capture ci-dessous.
De la visibilité avant tout
Suite à diverses demandes, Mozilla a ajouté en outre une simplification pour la compilation avec Emscripten. Le nom des fonctions change en effet pendant cette étape, et certains développeurs aimeraient pouvoir faire le lien plus facilement avec le code originel. L’outil de profilage du call tree permet donc désormais d’afficher les noms originaux des fonctions.
Parmi les autres améliorations, signalons en particulier un débogueur dorénavant actif en permanence, la possibilité de vider les instantanés du heap dans l’outil dédié à la mémoire, celle de sélectionner le texte dans le call tree de l’outil des performances, un contraste amélioré sur les pages sombres dans la barre d’informations de l’inspecteur ou encore une suppression du maximum d’éléments dans l’inspecteur de stockage. Rappelons enfin que cette version 46 est la première à activer par défaut le signalement des sites n'utilisant pas de connexion sécurisée, comme nous l'avions indiqué la semaine dernière.
Les développeurs intéressés pourront récupérer cette nouvelle mouture depuis la page dédiée.
Commentaires (48)
#1
Ca serait bien s’ils s’attaquaient à la consommation du CPU également. Surtout utile pour économiser de la batterie sur laptop.
#2
La version développeur sert a créer un site WEB, ou c’est juste pour vérifier le fonctionnement du dit site ?
#3
#4
#5
Désactive/Active Flash pour comparer les performances.
Et si tu es sur windows installe la version 64 bits, il y aura peut être du mieux.
https://ftp.mozilla.org/pub/firefox/releases/44.0/win64-EME-free/fr/
#6
#7
Je ne sais pas quelles vidéos en HD Kaamelott voulait regarder, mais avec la version EME-free ça risque de ne pas passer du tout car beaucoup de vidéos YouTube en 1080 sont protégées par DRM.
Le cas échéant, essayer plutôt https://ftp.mozilla.org/pub/firefox/releases/44.0/win64/fr/
#8
Il faut peut être regarder de ce coté là aussi :
http://lehollandaisvolant.net/?d=2016/01/03/16/30/39-youtube-lent-en-html5-avec-firefox-42
#9
#10
[qutoe]
… de relancer plusieurs fois par jour parce qu’il devient super lent et très poussif,
[/quote]
Un “nextinpactien” ma récemment dit que se problème touche plusieurs personne et est vieux. Mozilla doit en avoir conscience mais en attendant augmente ton cache si tu as plus de 2go de Ram (et je suppose que c’est le cas)
#11
#12
J’ai le problème aussi. J’ai fini par me refaire un profil neuf (juste réimporter mes bookmarks) et bien le problème est toujours présent. Par contre il apparait moins vite depuis que je suis passé sous Firefox 64 bits.
#13
#14
Bizarre ton problème de Ram, j’ai un Firefox chez moi que je n’ai relancé qu’une fois en un mois. Et au boulot il tiens la semaine sans trop de problème et des onglets j’en ouvre et fermer quantité (dév web).
#15
Regarde tes plugins/extensions.
Celles qui servent au dev web bouffent un max de ressources.
#16
150 onglets, environ 500 Mo sous Nightly x86 avec NoScript.
Tu peux mieux faire " />
#17
#18
Le problème n’est pas qu’il permet au script de tout pomper, l’erreur de programmation est clairement de ma faute. La critique porte sur le fait que même après avoir tué le script et fermé la page, la mémoire n’est jamais rendue.
#19
#20
#21
J’ai un profil pour le surf et un pour le dév chez moi. Sinon c’est pas tenable, j’aurais plus de 70 extensions dont des biens lourdent.
#22
#23
C’est un peu le problème des extensions en état, les extensions sont une partie intégrante de Firefox, donc si elle gère mal la mémoire, Firefox n’y peut rien. Les extensions ont tous les droits sur l’interface, donc difficile de les dissocier du reste, mais c’est aussi ce qui fait le puissance de la chose, on peut tout refaire.
Dans le cadre des WebExtensions, qui commence à pointer leur nez, on aura (pour ce que j’ai vu) à peine mieux que ce que propose Chrome, ce qui en terme de personnalisation me fait un peu peur quand je vois les extensions de Chrome.
#24
Personnellement, et dites-moi si je me trompe, je considère que les développeurs de firefox et sûrement des autres navigateurs sont des imbéciles, peut-être même pire que les développeurs de microsoft. La raison en est simple: quand on utilise firefox et qu’il y a pls onglets, celui-ci va mettre en mémoire tous les onglets alors qu’il n’y en a pas l’utilité à moins de vouloir aller sur un onglet. Pour moi, ça s’appelle du codage avec les pieds.
#25
Je trouve ici qu’il n’utilise pas assez de RAM (true story!) et il ne libère pas la RAM correctement.
Il ne dépasse jamais les 1.4 GB de RAM pour une 50 d’onglets. Si je les ferme, ou que j’en ajoute d’autres il restera à 1.4GB
C’est mon navigateur de boulot, grâce aux modules qui me permet de garder des sessions d’onglets verrouillés.
Mais, je le trouve lent à la fin de journée alors que j’ai un SSD, 32 GB de RAM et 6 coeurs.
#26
Et si tu ne stockes pas le contenu des onglets en RAM, tu fais comment ?
Pour moi le stockage en RAM est une bonne chose. Si un onglet est ouvert, c’est qu’on a l’intention de retourner sur ce site web, voire même envie qu’il soit actualisé en temps réel (cf flux FaceBook ou Twitter), chose impossible à faire si l’onglet n’est pas chargé en RAM.
Après on peut faire du code sioux pour garder quelques éléments en RAM et d’autres en ROM, ou les retélécharger, mais dans tous les cas ça aura un impact (pardon, INpact) négatif sur les performances.
#27
#28
#29
#30
#31
#32
C’est un réglage laissé au choix de l’utilisateur.
Général => Ne pas charger les onglets tant qu’ils ne sont pas sélectionnés
#33
C’est un réglage laissé au choix de l’utilisateur.
Général => Ne pas charger les onglets tant qu’ils ne sont pas sélectionnés.
#34
Pas en ROM patron ;) " />
#35
" /> A ROM fait comme les ROMains. " />
#36
Question: cette version peut-elle être utile à un simple naviguant qui veut malgré tout suivre la consommation onglet par onglet, objet par objet?
#37
Va sur about:memory et active le verbose.
#38
#39
Ca veut dire: ce n’est pas nécessaire, c’est présent sur le firefox normal. (et que tu n’as pas essayé " />)
#40
" />
Firefox ! " />