Hello, thanks everybody for coming. I will be talking today about what we know about how Firefox is power, what we can know about it, what we can do about it. First, what we will cover today. So first, why do we care about this topic? Then, how can we understand power use locally?

Which means, like, if Firefox is using too much power on your own computer, what can you do about it? And then, how can we understand it about all users in general in the wild, so the entire release populations? And I will finish by explaining what we have done, what we have improved, and what we are still doing. So, first, why do we care? There are really two different sets of reasons. The first one is user experience.

We very frequently see users complaining that, okay, Firefox is using too much resources, too much CPU. My computer is noisy, like the fans are making noise, they are going at full speed. Or the laptop is hot, if people are using a laptop. Or maybe the battery life is too short.

So all of those are reasons for an individual to want Firefox to use less power. There is another set of reasons, which is sustainability. Mozilla cares about sustainability, about climate commitments, about being carbon neutral, about reducing our greenhouse gas footprint. And because we are Mozilla, we do things in the open. We want to lead on this and do it openly.

We want to share our tools, any material we have on this, methodologies. And also we want to improve our products so that they are more sustainable. And the reason why we care so much about our products is because when estimating our carbon footprint, because we have many users, the use of our products is actually 98% of our footprint.

So playing less, having more efficient offices, this is all very great. But if we want to save a lot of power, that's really looking at the product that we should do. So I said we'll look at it first, because I think there are some people in the room who likely think,

Firefox uses too much power on my computer, I want the battery to last longer. And that's a very valued use case. And if we want to optimize for everybody, we want first to be able to optimize to have it running correctly on one specific machine in front of us, before trying to go at scale. So I will present a few tools that we have for this. But first, I will explain how Firefox uses power.

It's desktop application, so like any other computer application, it's using CPU time, using GPU time, waking up CPUs, and actually CPUs are pretty good at saving power when we ask them to do nothing. They go into deep sleep mode, they use almost no power. The problem is if we keep waking them up, they can't really sleep, and that wastes a lot of power.

And then there's a few more things that we can do that use a little bit of power, but not as much. Like transmitting network packets, for example, or writing to disk. And they are not where we should focus our time if we really want to have a big impact. So this is how we use power, and next how we waste power, and it's almost the same thing. The only difference is when we do it for no user benefit.

If we use CPU time and the user doesn't see a benefit in what we are doing with the CPU, it's a waste. And same for all the other ways we could use resources. And some typical ways to waste power is waking up threats too often, playing animations even though they are completely invisible,

or more generally doing things in the background, things that have no visible effects. Yeah, so typically when someone wants to understand local power use, there's two reasons. Either Firefox is supposed to be guilty of using too much power, there's like one core used at 100%, sometimes even more than one core,

or sometimes the user is looking at the operating system task manager for a completely different reason and notices that, okay, there are some Firefox processes that should be idle, because Firefox is supposed to be doing nothing, it's in the background, but it's using 1% of the CPU or 0 point something, and why?

It used to be difficult to figure out answers to those questions. We now have good tooling for it. So the first tool I wanted to share is the Firefox task manager. You can open it by typing about processes in the address bar. You can also use the Shift-Escape keyboard shortcut that will open it directly.

And it's very similar to a task manager you would see in an operating system. It's showing you a list of processes, how much memory is used by each, how much memory and CPU, but unlike the operating system, it knows exactly which tab we are running in which process. So if you see that there's one process that's using a lot of CPU,

and you see that it's a tab that you actually don't really care about, you can just close that tab, and this is done. Because very often we have people who say, oh, Firefox uses a lot of CPU, but you know I have 50 tabs, so maybe it's because with many tabs Firefox uses a lot. Naturally, very often it's just there's one tab that's misbehaving, and finding quickly the right one and closing it is the most efficient way to fix it.

Something else I want to show on this is that the numbers, the percentage of CPUs were very precise here, a lot more than on the operating system task managers. For example, on the third process here you see 0.011%. On the operating system you just see zero in this case.

And the reason why we want to show it when it's almost nothing is because almost nothing means we are still waking up the CPU to do a little bit of something, and we want to be able to catch this. Because we use this kind of tooling to find real bugs. This is a screenshot captured on nightly. If you are on a release build, you won't see the thread names unless you enable it in about config.

Okay, so let's assume you have found that there's a real problem there, and it's not a tab you can easily close. The next step, which is more in the tooling, is using the Firefox profiler. I won't go into details on the Firefox profiler because the next presentation is also about the profiler. But I will say that we recently added a preset for power profiling,

which configures the profiler in a way that causes very little overhead. And we also have a power profiling mode that was added recently that will be able to say how many watts we used, not just how much CPU. So you can enable it quickly with this preset.

I just wanted to show an example of how precise the measurement can be. This is a profile showing Firefox doing nothing. There was just one thing that was left. It was the cursor in the address bar. It was blinking. And all the spikes that you can see in here, they are whenever the cursor appears or disappears. And here we could select this area

and see in the tooltip exactly how much power it used to do this tiny thing. So anything we do, we can see it in the profiler, see how much power it uses and correlate. Honestly, I never thought we could see things like this. I thought we could see bigger things like loading a page, but blinking the cursor.

It was a surprise and a good one. Another thing in the profiler that I wanted to share, and it's the last one because the next talk will be all about the profiler, is the profiler records many markers, and especially I wanted to show the awake and runnable markers that make it easy to see why we were waking up a thread. Whenever the thread wakes up, there's an awake marker. It often says which priority the thread was in

from the operating system's point of view and which curve the thing ran. And runnable markers only exist on nightly, but they say exactly what we ran at that time, which is very convenient to then fail a bug if it's something we should not be running. One last thing there, task manager, if you hover with a mouse next to the PID,

there's a profiler icon that appears. If you click it, it will profile for five seconds the entire process. A few seconds later, you will see a tab opening that shows everything happening in that process. That's all I will say about troubleshooting local excessive power use. I hope you will make good use of the tools I was just showing.

And now we'll talk about what's happening in the wild. So that's for all our users. And whenever we care about what's happening for all users, we think telemetry, because that's a great way to know about what's happening and computers are not in front of us. And I added data collection for a few things that are related to power use over the last couple of months.

Most notably, CPU time used, GPU time used, the number of wakeups that we caused. And also we can break down this data by process type. And here by process type, I mean, is it the parent process that's showing the Firefox user interface? Is it a content process that's showing the tab in the foreground? Is it a content process that's for a background tab?

On the native channel, we can even break it down by thread name, which is a lot more detailed. And now we'll show the use we are making of this data. So I said we care about sustainability and we have climate commitments. And one obvious use case for having this kind of data is estimating our carbon footprint.

So thanks to telemetry, we know that on average, every day, we use between 60 and 80 million hours of CPU time and about 15 million hours of GPU time. Those are big numbers. It's hard to think about what they mean, but we can try to use those numbers to convert to CO2 equivalents by using the CPU specifications

from CPU manufacturers, information about which CPU model is being used, and electricity carbon intensity by country. So we will be publishing our carbon footprint in a couple of months for last year and it's based on this kind of data. And I just wanted to give a sense of scale because millions of hours, that means nothing to me.

The amount of power that would be needed to power Firefox for all of our users, which is hundreds of millions of users, would be the equivalent of a small thermal power station. Or if you're thinking more renewable energy, we would need to cover about the roofs of 50,000 houses with photovoltaic panels.

So even if we save just 1% of the power, that still means a lot compared to other things we could do in our personal lives as engineers. Another example of using telemetry data is verifying that the fix we landed actually had the impact we expected. And this is a case where we fixed something related to how timers were implemented, timers for web pages.

And this chart shows how many times we wake up various threads, so it's from nightly users. You see that there's a change happening here, something trending down. Before, it was about 7% of the wakeups for the timer thread and after it was about 5%. So we really had an impact with this fix

and before we collected this kind of telemetry, it would have been impossible to know. And last but not least, we use this telemetry to verify our ideas about how we can reduce power use. And when I started working on this project, I had the assumption, and other people too, that we use a lot of power in background tabs.

And that's probably because as someone who uses Firefox and the internet a lot, I have many background tabs. And we just collected data. So this is a breakdown per process type. We see that the biggest slice here is the foreground tab, not background. The second biggest is the GPU, so showing things on screen. Then we've got the problem process, which is the UI,

when the user is interacting or not interacting. And only then, we have background tabs. So it's between 7% and 8%. Still worth optimizing, but if we spent all of our efforts optimizing this, we would be missing the biggest part of the thing, which is foreground tabs. Another idea that we tested is,

maybe it's all those ads that are on web pages, they use a lot of power. We should do something about them. We also collected data. It turns out to be less than 2% of it at all. Maybe still worth doing something about it, but again, it's not where we have the biggest wins. And maybe it also means that tracking protection works really well in Firefox, and we are already blocking many things.

And the last section of this presentation will be about improvements, what we have done to reduce power use, and what we can still do. We fixed many bugs. When I wrote this slide, it was 26 bugs that we fixed, only within terms of reducing power use. But if I wrote this slide today, it would be 27, because one was fixed overnight.

The bugs go in various categories. It's almost always the same kind of things that we find. Sometimes we have timers that really should have been stopped, that keep repeating, but they are not really useful. It's one of those bugs that we fixed this night, something that was waking up every 10 seconds, even when you do nothing with Firefox. I'm happy this bug is finally fixed.

Sometimes it's animations that are animating, but they are animating stuff that's not even on screen, maybe because it's a background window, a background tab, or something hidden for some other reason. When we can stop those animations, it's much better. And when I said bogus animation, it's sometimes we have animations that kept running even though the window was closed.

I think we fixed all of those cases, but we might still find more. On avoiding pointless thread wakeups, that's what I was showing before with a chart about timer threads and edge cases where there was massive CPU. So thanks to all the contributors who helped with this. It's the work of many people, mostly on the platform team.

And I will just showcase a few examples of bug fixes we did that had a big impact. So this one is specifically about Windows 11. Windows 11 has an efficiency mode for processes. It's not completely clear what it does, but when reading the documentation, it's mostly letting the operating system know that this process is doing nothing that's user visible. So we could execute the CPU

at the lowest possible frequency. And for CPUs with efficiency or performance scores, always select efficiency calls. And thanks to power profiling that I mentioned before, we could actually verify the impact that we had when deciding that we set processes for background tabs in efficiency mode.

If you look at the slides later on, click the link, you can see it in the profile. But on my computer, I have a tab using the CPU in the background continuously. Another thing I said, we have many bugs that are the same category of bug. And when we can, it's nice to eliminate the entire category of bugs at once.

And for animations that are broken in edge cases, it's almost impossible to write tests for all the possible edge cases. But we have a very extensive test suite. So one idea I had was, what if at the end of every automated test we run, we verify that nothing is animating anymore? And when we did it, the part that was not easy was fixing all the edge cases we uncovered.

But that's why I'm confident it won't regress as much as it used to. Next things we can do, because we still have many ideas of how we could do better. I mentioned background tabs. We still have lots of ideas about how background tabs could be more efficient, how we could be more aggressive about reducing the frequency of timers firing there,

how we could limit CPU use there. I keep talking about timers, the engineer working full-time and improving on timer APIs. The main idea there is to group timers, because the most expensive part about timers is they wake up the CPU.

So if when we do wake up the CPU, we decide to run many timers at once, it would be much cheaper in terms of power. And we are working on those kind of improvements. We still have cases where we have videos that are being decoded, but not played in a place where they are visible for users, like background tabs and things like that. We try to stop those, but there are edge cases that we are still working on.

Hidden animations. So animations that keep running when something has been completely closed. I'm confident we fixed most of those. Animations that keep running even though they are covered by something else. We still have many cases. And the biggest one is fully occluded window, which is you have a window that's entirely above the browser window where we have animation.

We try to detect that. We have got to detect it, and we are doing as well as it should be, and I think we can do much better. So there will probably be work going in that direction. Another thing that I like to profile, also because it's testing the capabilities

of our profiler, is what happens if Firefox is started and does nothing. You open Firefox, you load about blank, literally nothing, and then you go to a meeting, or go for a walk, or do something else, and then you come back a few hours later. You capture the profile and you see what happened. I would like what happened to be almost nothing.

We can still improve things there, and I think it would typically help for sustainability there for people who are not using laptops that tend to go into sleep mode, but more desktop computers that might turn on things on their computer, and then they go home for the night or for the weekend, and the computer keeps running the entire weekend. I think it might have an impact for those cases.

And some more ideas that are not ready to do something about for everybody but could be experimented with. We can do that individually, like if you want to test it for yourself, or experiments, we could run on a few thousand users to see what's the impact. So the preferences there that I'm giving is when showing the chart,

I said that displaying the foreground tab is what's using almost half of the entire program that we use for Firefox. By default, we display stuff, especially animation, 60 times per second, or more if you have a screen with a faster refresh rate. Do you really need that? I think most people don't. You just have to limit the refresh rate.

So if you want to have only half the frames, just set it to 30, and you will see what happens. I think for most use cases, except maybe fast video games, it should be fine. Another thing we'd like to explore is the cost of video to play. We already block videos that could make sound because it's noisy and that's annoying, but videos that are just there in a corner,

typically news article with someone waving hands and talking but you can't hear them because you're reading the article and there's a price that you can set that will block both when there's audio and there's video. Even if there's just video, it will block it. That's all I wanted to share for today

and I'm happy to take questions if you have, but first, thanks for your attention. So, who has any questions?

In the case that you have a lot of background tabs, does Firefox suspend those processes and if so, does the memory get freed and would the process manager show that or not?

Sorry, a lot of questions. So, the question is, if you have lots of background tabs, is Firefox suspending those processes, is the memory getting freed? There are multiple answers to that question because there are different cases. By default, the answer is mostly no. We don't suspend them. One thing we do is we throttle any activity there.

So, if a tab is trying to do things every 10 milliseconds, we will not allow that and we will limit to once per second, which saves a lot of power already. I think we can do better. I would like if it was only once per minute and then maybe after a few minutes or a few hours suspend completely. There are cases where the tabs are completely unloaded. One of the cases when we are using way too much memory

and we are about to crash out of memory, then we will, as a priority, unload the tab that's abusing the memory. There's another case which is when you session restore. We don't reload the tab until you click them, except for the foreground tabs. So, then you will have many tabs, but they don't actually use memory or power. One more case is Firefox on Android.

By the way, everything I said in this slideshow was about Firefox desktop, but we are also looking at the power use of Firefox on Android. On Android, when you put the tab in the background, it's completely suspended. Nothing runs anymore. Any other questions?

Can you just say it? So, the question is, I just learnt about about processes

and quickly wanted to see what Firefox was doing. And the process that's using the most CPU there is the parent process, which is using about 20% of the core.

Do we have an idea of what it is doing? So, the first idea is that the main process itself The way I would figure this out is to click the profiler icon and look at the profile. And if you want to send me that profile, I can tell you exactly. But otherwise, I will just say a quick guess, which is what happens most of the time, is unless you are running on Windows, but I guess you are probably on Linux or something else,

we run. So, I said GPU process is a large part. We actually only have a GPU process on Windows to prevent graphics driver from crashing from crashing into your browser. So, the graphics part happens on the parent process and outside of Windows. And it's very likely that you have animations that are running and causing things to be displayed. And with the profile, I could tell you

which animations are running and why. We have a question here in the matrix room. Have somebody ever compared worldwide usage of Firefox versus other proprietary browser webs? I missed a few ones.

So, worldwide power of Firefox compared to other browsers, have we ever compared I would say no because I think the other browsers don't publish worldwide power use. And I'm hoping we'll be publishing this as part of our greenhouse gas footprint report. I don't think competing browsers publish any of that.

And we're actually thinking that if we start publishing that, maybe we will push the competition to also publish this kind of information. So, this is kind of an extension to the configuration options that you showed.

But are there other tweakables that we could apply to Firefox on mobile devices, like bind from librem and so on, where we definitely don't need 60 frames a second? I'm not sure I understand entirely, but I think you were asking

are there other things that we could do on mobile to reduce power use there? Yes, but it is a mobile platform, so it wants the desktop version of Firefox. So, you have a mobile device running the desktop version of Firefox and there are things you could do to reduce power use there.

Okay. If you are showing only one tab, try to eliminate entirely background tabs and try to suspend them. Otherwise, the answer is almost always the same. Capture a profile, see what's in there. Because whenever we try to optimize by just guessing, almost all the time we are wrong. Like I said, background tabs, it's not that bad.

Ads, it's not that bad. And profiling is always the way to know exactly where you should be spending your time and if you want help with profiling, the next talk will be about the profiler and we are very happy to help about understanding profiles. Yep. Hi, my question is regarding hardware encoding.

For example, in HTML and depending on the browser, you can give a list of different content types or formats. Has there been any exploration into changing maybe the preferred format loaded to optimize for less power consumption? As opposed to faster or higher resolution?

So what I understood of the question is, has there been any exploration to changing the kind of content types we accept, for example for images or media, to reduce power use? I think the answer is no, but I know there's currently exploration

in terms of what we can do to reduce bandwidth use and bandwidth also uses power in some ways and we were thinking about this mostly in the case of estimating the cost of VPNs for users and for users who really care about privacy and really want privacy on a VPN. Could we do things to reduce the cost for them to pay for that VPN but charges for bandwidth?

So I'm afraid that's all the time we have. However, if you can see, Florian put his email there for questions and also shared ideas in the matrix room and we also have that matrix room. Please also add the questions there and there will be member staff there and also other volunteer Mozilla to answer.

Thank you very much. We need to change up for the next talk. Thank you very much Florian.