Devtools slow and occasionally unresponsive on some sites

(Brian Manning) #1

I’m using FirefoxDeveloperEdition 57.0b5 and frequently see slow/unresponsive behavior when developer tools are open. It can take me 10+ seconds to inspect and element and get over to the react devtools tab. I also frequently see beachballs and slowness when I drop a debugger breakpoint into my app, and often times the top half of the debugger window that shows the code above the console doesn’t even appear and I have to refresh/try again.

I tried disabling all my add-ons (including react devtools) and see the same behavior. I’m very happy with Firefox for browsing but I don’t experience these issues in Chrome and they’re significantly slowing my workflow. Has anyone else experienced this?

(Nicolas Chevobbe) #2

hello @ALink2ThePast,
could you send us a link and some steps to reproduce your issue so we can profile it and see where the bottleneck is ?
thanks !

(Brian Manning) #3

hello @Nicolas_Chevobbe. Thanks for your help! Unfortunately most of the issues I’m observing are in my local development environment, so I’m not sure how the best way to share that would be. I’ll do some tests on our production site and maybe some others to see if I can come up with consistent ways to re-create the issue.

Unfortunately in retrospect my timing of this post was a little poor since this afternoon I’ll be leaving for a 12 day vacation so I may not be able to have much of a back and forth discussion until after that. I’ll also talk to my co-workers and try out what I’m doing and determine whether this is an issue unique to my computer - 2015 Macbook Pro, Sierra 10.12.6 -(although I doubt that, might as well check).


(Nicolas Chevobbe) #4

If you could record a profile with and share it here that would really help !
No worries for the timing, we are focusing on performance on Q4 anyway, but it’s nice to have real life cases so we can act on them.

(Brian Manning) #5

Thanks, will do, might be after I get back but I’ll let you know.


Same edition of firefoxDE, same computer and OS, same problems. I really want to choose Firefox over chrome but the FF debugger is almost unusable due to how slow it is. I’m also using FF for local development, but I attempted to record a profile (don’t really understand so hopefully I got it right!) Let me know if there is something more useful I can do re: recording a profile.

(Julian Descottes) #7

Thanks for the profile, it is really useful. From what I see, the debugger seems to be spending a lot of time iterating over scripts.

How many sources/scripts do you have in this test case? And in general any information about the setup of your development environment could be useful. Anything that could help us reproduce on an isolated test case.

(J. Ryan Stinnett) #8

@bjv, thanks for the profile!

If you go to about:config and change the pref devtools.debugger.source-maps-enabled to false, does that improve the performance of the debugger?

Also, what value do you have for


@jdescottes I’m not sure exactly what you mean. The project that I am working on is a few 100k LOC. Development environment is a VirtualBox VM running Ubuntu 12.04. Django backend, Browserify to bundle the JS, Grunt task runner.

@jryans Changing source-maps-enabled massively improved performance! Hovering over variables while paused on a breakpoint is now almost instantaneous. Thanks! The current value of new-debugger-frontend is true.

(J. Ryan Stinnett) #10

Interesting! That’s a bit confusing, as the new debugger frontend isn’t meant to be affected by devtools.debugger.source-maps-enabled at all, so something surprising is going on here.

@bjv, just to make sure we’re investigating the right things, you now have:

  • with the default value of true
  • devtools.debugger.source-maps-enabled set to false by modifying in about:config
  • devtools.source-map.client-service.enabled with the default value of true
  • devtools.debugger.client-source-maps-enabled with the default value of true

Is that an accurate representation of what you have set currently, which you mentioned is much faster than before?


@jryans Yes, those values are an accurate representation of my current configuration. Changing source-maps-enabled to false had a noticeable effect on performance as I mentioned, specifically speeding up the response time when hovering over variables while paused on a break point.

Unfortunately the debugger as a whole is still ~2-3x slower than using the Chrome debugger. The biggest issue is stepping through code and in and out of methods, where each click or button press involves a significant delay.

Let me know if there is any more information I can provide.

(Brian Manning) #12

Hello all, I’d be happy to record a profile as well but I’m experiencing the exact same behavior as @bjv (thanks for engaging while I was gone, good to know it’s not just me).

(Brian Manning) #13

The devtools are still pretty unusable, and browsing also seems to go slower if I have a console open. Unfortunately I’ll be switching back to Chrome for developing until this gets fixed.

I’m happy to provide any info I can to help track this down.

(Nicolas Chevobbe) #14

Hello, really sorry about that.
Would you have some time to record a profile with and share it here so we can investigate what is going on ?

(Brian Manning) #15

For some reason the add on’s in app share feature wasn’t working, but I saved the file.

(Nicolas Chevobbe) #16

Thanks a lot Brian. We are working on performance improvements for 58, and more specifically stepping, which looks like the biggest offender here.
Would you have some time to try the debugger in Firefox Nightly to see if it shows any improvements ?

(Jason Laster) #17

Thanks @ALink2ThePast for the profile. I’m one of the engineers working on the debugger?

Have you tried the same thing in Firefox Nightly:

If you’d like, stop by our slack and I’d be happy to pair w/ you and see if we can hunt down the regression. Perf is our number one goal right now and we’ve done a lot to speed it up recently.

(Brian Manning) #18

thank you @Nicolas_Chevobbe and @Jason_Laster, I’m going to use Nightly for a few days so I encounter all the situations I come across naturally and get back to you with any performance differences.

(Andy Erickson) #19

I have recently tried to switch back to firefox over chrome, but I have also been encountering these issues that everyone is speaking about. My overall experience with firefox has been great, but while debugging, the performance is so slow it’s unusable. I have tried the standard edition, developer edition, the new quantum standard and quantum developer edition, and also the nightly. While the quantum developer addition had the best performance, each step through my javascript code was still at least 4 seconds between steps.

(Mauro Doganieri) #20

Hi guys, i would like to share my experience too.
I’m on Firefox Nightly 59 at work and as other people have pointed out, devtools performance are really bad especially on heavy pages.
I found these issues:

  1. Opening devtools and switching to “Debugger” tab, often cause the latter to stay completely blank until you switch to another tab and then switch back. More generally, the first time you select some devtools tab they are unresponsive for a few seconds.
  2. Reload heavy javascript page with devtools opened, dramatically slows down page loading and cause the whole tab to be sluggish and unresponsive. I face this issue very often working on an Angular project and reloading the page to analize the console output. This is really frustating especially when you have to repeat this operation several times.
  3. Sometimes devtools won’t open after they were closed. You have to close the affected tab and you have to open another one. I encounter this problem several times a day. Unfortunately, i’m not able to reproduce it.

Anyway, i know that some bugs related to devtools performance and some of the issues i reported have been already filed so i hope they will be fixed as soon as possible, and as Firefox 57 was a great release we have to be competitive on devtools(and devtools performance) too.
If you need some additional info, just ask :slight_smile: