Devtools slow and occasionally unresponsive on some sites

Developer Tools
#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:

2 Likes
#21

Same issues here. Here’s a link to the perf-html recording of it: https://perfht.ml/2zCWnXh. 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.

#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 !

#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 !

–
Julien

#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!

#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 : https://perfht.ml/2BHHJiZ .

#26

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

Go to https://www.xome.com/Listing/ListingSearch.aspx 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.

#27

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

1 Like
#28

Thanks for the info! The slowness to pick an element seems linked to the issue discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=1412319

#29

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

#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…

#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 https://github.com/devtools-html/debugger.html. If you can file an issue there with clear steps to reproduce, it will help the team address your issue.

#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

#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.

#34

Thanks for the info. Would you be able to capture a performance profile using the profiler at https://perf-html.io/ ?

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!

#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.

#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.

#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 : https://perfht.ml/2CYFNmU
The perf with the network panel open : https://perfht.ml/2oFPlAh
I don’t know how to analyze it so let me know if you there is something I did wrong.

#38

Thanks for the profiles @tony . They highlight a couple methods to investigate already. I found https://bugzilla.mozilla.org/show_bug.cgi?id=1350969 which tracks performance improvements for the Netmonitor and added links to your profiles there.

#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 :

firefox-1
firefox-1.png721×381 38.6 KB

firefox-2
firefox-1.png873×599 81.8 KB

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.