Devtools slow and occasionally unresponsive on some sites

(Brian Adams) #21

Same issues here. Here’s a link to the perf-html recording of it: Hope I did it right, never used that before haha.

A few more details on my setup:

I love the new Firefox. Thanks for all the great work you guys are doing! If you need anything else just let me know.

(Julien Wajsberg) #22

Hi Brian,

thanks for the profile ! We can see there are clearly big 16-second hangs: one in the content (the page itself), one in the main thread (likely the devtools, but could be something else). Is it what you experience too ?

However the profile is not very actionable because it’s cut up; the reason is that the default settings for the profiler are too low for a long profile. Could you please record it again after changing the “buffer size” setting to something like 180MB ? You can access this setting by clicking on the gecko profiler icon, then expand the “setting” lower panel.

Thanks again !

(Julien Wajsberg) #23

That said, we can already see that the main thread hang is caused by the debugger. I know the debugger folks did a lot of performance improvements lately and they’re probably not in v58, some are in Nightly but maybe not all of them yet. Do you think you could try your workload on a recent nightly version too ?

Last thing: by chance, do you have a public-facing website where the issue happens that we could try ? Or a github repo that we could build and run to reproduce the issue ?

Thanks again for your help !


(Brian Adams) #24

I took a couple more profiles. They are both from the most recent nightly build (59.0a1).

Overall it seems the performance on Nightly is a bit better, though still not great. FWIW, the page load is consistently under 3s when devtools are not open.

Unfortunately I can’t share a direct link to the page, and it’s not open source. I can spend some time this afternoon creating a sample project and see if I can get it replicating that way. I’ll update you with a link if I can reproduce in a small project.

Thanks for looking into this!

(Guirec Corbel) #25

I have a similar issue. It’s a lot better with 59.0a1 than with 58.0b8 but the debugger still slow. When a big JS file loaded, like the one I have for my Ember.js project, it took at least 2go or ram and it increase when I reload the page. Here is some information : .

(Rgelb) #26

Same problem here. And I have a specific example for you.

Go to and Inspect any element on the page. It takes several seconds to get to the correct node.

For issues with stepping through code, search sources for displayPins function - you should be able to find it in BingMapv8Wrapper.js (it lists it twice for whatever reason). Place a breakpoint on the first line of the function. Go back to the page, switch to Map view (by clicking on the Map link in top left part of the page). Move the map around to cause it to breakpoint. It takes 2-3 seconds or so for every line - very painful.

I get that the page contains a metric ton of js - but lots of things these days do.

(Karen) #27

Same here :frowning: I found the developer edition too slow to be usable so have reverted to firefox 55 with firebug.

(Julian Descottes) #28

Thanks for the info! The slowness to pick an element seems linked to the issue discussed in

(Guirec Corbel) #29

Is it possible to have updates from the Firefox team. Is there a place to follow the works on this bug?

(Tony) #30

I’ve not found any issue in Mozilla bug tracker. Is this bug already declared?

For me it’s impossible to use Firefox to debug my app as it takes more than 14 seconds to load the page…

(Julian Descottes) #31

The debugger team is working on several performance-related items. Right now we are trying to land improvements for projects using source maps.

All the work is made on GitHub at If you can file an issue there with clear steps to reproduce, it will help the team address your issue.

(Julian Descottes) #32

We have several bugs in Bugzilla and GitHub to track specific performance issues. Can you give more details about your issue (URL if it is public, which panel is selected in DevTools etc…).

Then I can either point you to an existing issue or open a new one. Thanks

(Tony) #33

The URL is not public as it’s a local development.
I’m building an app using Bootstrap and Dojo. When the page loads, it performs 281 requests (mainly js + css files).

The same page takes 2.5 seconds to load with Chromium.

It doesn’t depend on which panel is open. I’ve tried with Console, Memory, Network and Performance and I always have the same time to load the page. If the devtools are closed, the page load in 2-3 seconds.

(Julian Descottes) #34

Thanks for the info. Would you be able to capture a performance profile using the profiler at ?

Maybe it is a panel which was loaded and then hidden. To make sure if a panel impacts or not the reload time you can do the following steps:

  • select the panel (e.g. console)
  • close devtools (F12)
  • open devtools (F12) (it should still be on the console, don’t change the selected panel)
  • reload your page

Any extra info can help!

(Tony) #35

Sorry, in fact the panel impacts. If I open devtools in console directly, the page lors in 3.9s each time. If I open the network panel it can spend more than 12 seconds.
I’ll try to give you a performance profile.

(Julian Descottes) #36

Thanks for checking. There has been a decent amount of performance work in the Network panel recently. If you are not already using Nightly, it would be worth checking the performance there.

(Tony) #37

I’ve tried using nightly and there is a little improvement (9 sec instead of 12 sec) but the problem is still present.
Here is the perf without opening the network panel :
The perf with the network panel open :
I don’t know how to analyze it so let me know if you there is something I did wrong.

(Julian Descottes) #38

Thanks for the profiles @tony . They highlight a couple methods to investigate already. I found which tracks performance improvements for the Netmonitor and added links to your profiles there.

(Guirec Corbel) #39

I tried to find a stable way to reproduce the bug but I don’t have the same behavior. I always have a lot of memory usage but not always in the same range. Sometimes is 2go and sometimes it’s 6go for the same page with the same navigation.

Here is the result of one single page loading when I go to the debugger :

As you can see the CPU is going crazy. The page took about 5 seconds to load but the memory usage increase and the CPU is used for about 30 seconds. If I reload more times, it still continue to use memory.

I went on all tabs of the dev tool and it works well but it goes crazy when I go on the debugger.

It works nicely with Firefox 57. It do this only with the local version of my app but it’s correct with the compressed version in production.

I will try to find a way to reproduce the bug with an online app.

(Adin) #40

Any news on this front. I have the same issues as mentioned above (debugger tab takes many seconds to open, moving line to line (F10) takes 2-3 seconds each time) mousing over a variable takes a long time to show its value)? Using FF 57.0.3

I have another issue where a bunch of breakpoints keep coming back no matter how many times I remove them.