Firefox's Performance Monitor highlights slow add-ons and resource usage
Performance Monitor is a new internal page in the Firefox browser that displays slow add-on alerts and resource usage of the browser starting with Firefox 40.
One of the things that I like about Google Chrome is the browser's Task Manager as it highlights resource usage of browser components in an easy to access way.
While you have a couple of tools for Firefox that provide you with similar information, they come mostly in form of add-ons that you have to know about before you can install them.
Tab Data for instance displays each tab's memory usage while about:addons-memory the memory usage of add-ons.
The newly integrated Performance Monitor is an internal component of Firefox which means that you can run it without installing add-ons first.
Performance Monitor
Just type about:performance in the browser's address bar to get started. Depending on how you are using Firefox at that moment in time, you may not see any data or lots of it.
The performance monitor divides data into performance related information that update automatically while you are using the browser and slow add-ons alerts which seems to use the new slow add-on notification system that Mozilla integrated in Firefox 38 Nightly.
Resource use is sorted from highest to lowest which may already give you a good understanding of what is causing slow downs or memory usage in the browser.
Most of the information provided on the page are designed for developers and not end users as most users probably don't know what jank level, activations or cross-process means and how it relates to the browser's performance.
That's not a big issue however since the data is sorted already so that you can react based on that alone if necessary.
The tool could use additional features though. One would be an option to collect historic data so that you get information about performance requirements over time and not only in particular moments in time.
Closing Words
All in all though this can be a useful feature to all users of the browser. If you notice slow downs for instance or lags while using Firefox, you may be able to tell why those are happening by opening the about:performance page in the browser.
If you see a web page, browser component or add-on listed there at the top, you get all the information you require to do something about it.
For instance, if it is an add-on, you may want to turn it off for a test to see if your browsing experience improves. If it is a web page, you may want to close it to resolve the issue.
It is unclear when this feature will land in stable builds of the browser. If the version is anything to go by, it may take three releases before it does.
Guys, guys, guys. (and girls).
Firstly, s’got nothing to do with being OCD. I can tell you alllll about that, I’m
an ex- systems analyst / programmer / rescuscitator. Jack-of-all-trades,
master of umm three? I don’t remember.
It’s about the flavor of ‘information’ about:performance supplies.
It’s essentially useless to anyone But developers. But.
Being able to monitor FF’s memory growth over time (see Chris Chiesa’s
comment) on a per FUNCTION basis might help, e.g.
if I’ve only got AOL up in a tab, why-oh-why does FF consume more and
more and more memory as time goes on? Is it caching everything AOL’s page is requesting?
Does a zero-cache philosophy help?
Perhaps something like memory allocation requests (remember GETMAINs?)
on a per-process or per-module basis would help, especially if presented
a-la PROC(ess)EXP(plorer) in a history graph….
I’m just sayin’. I thought the New, Improved FF was sposedta be faster and lighter
on resources. Well, the other side of the equation is the ridiculous number of
chunklets of crud sucked in by pick-your-fave website’s pages. S’why ADBLOCK
helps, to some degree; unfortunately it also makes some pages non-viable re
functionality. It’s a losing proposition all the way around, methinks.
The good news, for me, is that FF still works pretty well on my ancient
Compaq running XP with 2G of memory…’long as I remember to RESTART
it every so often to clear the logjam.
Well, this article got me excited and sent me on a wild-goose chase, but I’ve learned unfortunately this didn’t make it into the Firefox 40 release, due to… would you believe it? Performance concerns!
https://bugzilla.mozilla.org/show_bug.cgi?id=1170178
There was never a real chance that this feature will be in Firefox 40, the feature is developed behind a Nightly flag and does not “ride the trains”. It’s not only about performance, it’s also about accuracy. And the feature is simply not yet finished. Please have a look with Firefox Nightly, it looks totally different now. ;-)
I find this to be a very good idea. A slim-down version of Firefox (without this kind of performance monitoring) would be almost pointless, because in case of performance problems you would have to install another version of Firefox, which would defeat the whole debugging purpose of the new facility.
I personally think it’s a great idea to have an easier time of getting performance data of extensions. That being said, there are a few potential issues. Firstly, some people have already said it, but this isn’t a feature every user needs and it fits rather well into a developer/debug usage scenario. Why not try to slim down the end-user version and do away with everything that’s not needed for diagnose in case of errors? Secondly, Mozilla uses the term “jank” as a way of classifying inefficient code and this “jank level” seems to be a very subjective voting system. I don’t know if that’s such a good idea, because it allows for no interpretation of that score. If the browser can tell which code calls are bad, then why not mention them specifically or deprecate these functions?
Granted, I haven’t really spent a lot of time developing Firefox extensions – those rare few personal usage scenarios aside – so I may be off the mark with some of my comments. If that’s the case, especially my lack of knowledge how the jank level seems to be computed, please let me know.
The more logging, the more slower browser is, I think the best way for Mozilla should provide end-user a non-logging version and developer a logging-enabled version.
Logging is thing like about:memory
It’s a Nightly-only feature and Firefox Nightly is not for endusers. ;)
“This feature is Nightly-only for the time being, with no definite plans to let it ride the trains. For the moment, the intended users are 1/ us; 2/ add-on developers.”
Bugzilla ticket 674779.
Well, THAT certainly sucks, then. If I let FF 44.0.1 run long enough — like, *weeks* during which I leave tabs open that I’m waiting to get around to reading, while only ever *hibernating* the machine — on my WinXP laptop of eight years’ vintage, performance becomes *abysmal* — like, to where *at best* it can take five or six *seconds* to respond to any given mouse click. And if I happen to open the wrong web page — by which I have no idea what the criteria is — it rapidly degrades to where it can take 25 minutes to scroll through a page of text, or do an “Inspect Element” and “delete [a] node.” Eventually I have to give up and kill FF from Task Manager, and who the heck knows whether I’ll ever see those open tabs again?
Throughout all of this, FF is using maybe 60% of the CPU, with the Idle Process using most of the other 40%, and everything else on the system competing for the remaining sliver. Other apps than FF remain usably responsive, though. FF is *by far* the biggest memory user on the system, by at least a factor of 10, sometimes more like 150 or 1000; today it was over a gigabyte with only four or five tabs open, and constantly increasing even when I wasn’t actively interacting with FF. I thought maybe it was network congestion, but — other network-using apps work fine, and during today’s episode network usage was something like 0.19% — and I mean that, exactly: I’m *not* saying it’s “0.19,” which would be “19%” — no, I’m saying 0.19% — just under two tenths of one percent.
I’m damned if I can figure out what the system is doing that makes FF (and eventually a lot of other things) so unusably slow, but it *definitely* has to do with letting FF run a long time and acquire a lot of memory. Maybe my use case is a little extreme, but I’ve heard of worse, and things ought to scale better than this.
So I’m wondering whether something else is going on, and I don’t know where to look. I had high hopes for “about:performance,” and now it turns out I don’t have it. It would have been perfectly safe for you to have included it in the normal release; it’s not like anybody is going to run across it by *accident.* I’ve been using Firefox since about version 4, and only just found out about it *tonight*, by reading Reddit posts.
Disappointing… I would’ve liked that in the stable version as well, for reasons I described below :)
This is further demonstration of just how out of touch Mozilla developers are with the general public. While this may be useful for developers, 99% of all browser users are not OCD enough to find a use for it. So you find a page that uses resources – what are you supposed to do? Stop using that website? The same goes for addons. The biggest Firefox resource hog is the plugin-container, which Mozilla has no plans to do anything about.
I really REALLY doubt you’re a psychologist. No psychologist in the world would use OCD so lightly and in such a mundane way as you have. You basically used OCD the same way the general population does that doesn’t know what OCD means. If you are a psychologist, you’re a very very bad one at it. See ya.
So you say it worked without plugin container and plugin container uses too much resources.
Take a guess where the memory for the plugins was stored before the introduction of the plugin container.
Yeah in the FF process. Nothing has changed except it’s now it’s own process and you can nicely kill flash.
Get some informations about what you talk about, before you talk about it – might help not to sound stupid.
@Martin – does your comment software not allow for more than one answer to a post? I mean I cannot answer to an answer like tree-style.
I forgot one “answer”. I cannot answer to an answer of an answer :>
If plugin-container is the biggest resource hog (for you), you should know that it contains *plugins*, e.g. Flash, Silverlight, etc. Things that run directly on the OS and code which Mozilla has zero to do with.
But that they have no plans to do anything about it is untrue. They’re trying to get rid of plugins. (Additionally they’re looking to replace Flash’s horrible, chronically broken sandbox with a browser-side one that doesn’t suck.)
Sarcasm will get you nowhere. Of course plugin-container contains plugins. But earlier versions of Firefox existed and functioned well without plugin-container. Ergo, it doesn’t seem to be necessary. (Google “How to disable plugin-container”.)
You are wrong, Oxa. *All* users benefit from performance improvements. And about:performance is a helpful tool for the developers to improve the performance.
Oh, and I don’t have any performance problems with the plugin container.
“Of course, all users benefit from performance improvements. What I said was that only about 1% of users are savvy or compulsive enough to be able to use this feature to accomplish performance improvements.”
It’s a Nightly-only feature…
“It’s nice that you don’t have any problems with plugin-container, but thousands of users do. (Just google it.) Logic 101: Don’t generalize from the specific.”
I don’t need to google, I am the administrator of the official german-speaking Firefox support forum, so I know what kind of problems is common…
Of course, all users benefit from performance improvements. What I said was that only about 1% of users are savvy or compulsive enough to be able to use this feature to accomplish performance improvements.
It’s nice that you don’t have any problems with plugin-container, but thousands of users do. (Just google it.) Logic 101: Don’t generalize from the specific.
First, 2% of people on the earth have OCD. Not 1%.
Second, you don’t know what exactly OCD is. Do some research.
Prove it.
First, I didn’t say 1% of the population had OCD. Second, I know what OCD is; I’m a psychologist.