Open Bug 1125322 (dt-open-slow) Opened 5 years ago Updated 6 days ago

[meta] Open developer tools slow down page load

Categories

(DevTools :: General, defect)

defect
Not set

Tracking

(Not tracked)

People

(Reporter: danemacmillan, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

(Keywords: meta)

Attachments

(2 files)

I recently started running performance tests against a big and unwieldy Web site. It's slow, and the long-term goal is to make it faster. Part of that testing involves the use of Firefox's and Chrome's Developer Tools Network panels. I've completed innumerable tests in each. In every case, Chrome reports a significantly faster overall load time. For example, a page that will take 2.74s to fully load in Chrome, will take 8.84s to load in Firefox. These are averages--and to iterate, averages that have been calculated after dozens of tests in each. When I disable Firefox's Developer Tools, however, the load times appear, at least anecdotally, to load in the 2s to 3s range. Ultimately, it feels like it loads in the same time that it loads in Chrome (but Chrome's tools are open).

I've always noticed a fairly significant lag in page load when Firefox's Developer Tools were open, especially on large-ish sites, but this has really hammered that fact into consciousness. This renders load time reporting in Firefox's Developer Tools almost unusable.

Network panel aside, simply having the Developer Tools open causes significant, demonstrable lag. This is beyond "prove it with numbers," because it's just apparent to anyone. Simply trying to scroll during a page refresh with the Developer Tools open is not possible because the browser is in an unresponsive, schizophrenic state; a normal state is resumed once every asset of the page has been downloaded and parsed.

Something I want to make clear is that these such issues don't appear to exist in Chrome with their tools open; there's a certain steadfast, unrockable assurance from the page loads in Chrome, while in Firefox there's just that expectation that between page loads with the tools open, you just have to weather the shaky, histrionic storm until the browser stops choking, settles down, and the elements on the page become clickable and scrolling finally responds (usually with some delayed scroll that compounds the already janky experience). I'm a die-hard Firefox supporter, but I can't shake this feeling.

What can be, or is being, done to improve the performance of this? I'd really like some feedback on this. As it stands, I can't rely on the load times being reporting in Firefox.

---

My current hardware is latest OSX Mavericks, 64bit, 512GB SSD, 16GB RAM. My Internet speed is 100Mbps down and identical up. These stats would definitely not be the bottleneck.
I find this as well. A site which takes 2-3 seconds to open without FF developer tools open is taking 12-15 seconds with it open.
A link to the sites that behave like this is necessary for further investigation. Also, the tool that is open when such slowdown occurs and whether it happens with a specific tool or all of them.
The scrolling slowness if quite easy to see when opening complex websites, like this french newspaper: http://www.lemonde.fr/
May be related to bug 1066581 and bug 1073926
I have finally managed to reproduce this behaviour.

http://rcocks.github.io

This renders fast with no developer tools open. It runs slowly enough in Firefox (37.0.2 normal edition) with developer tools open that it crashes my firefox.

In Developer edition (39.0a2) it runs the same speed with or without developer tools open except if you try to record performance. Then it runs extremely slowly and does not show any time spent in anything but "(root)" when it has finished.
Richard, that page legitimately almost crashed my browser when the devtools were open. When they're closed, the page runs smoothly. Good job on that. That page was very similar to my experience on the production site I was auditing for performance bottlenecks when I initially wrote this ticket.

I accessed your test page with Nightly 41.0a1 (2015-05-20) with e10s disabled and enabled. In OSX I was beachballing hard regardless of the e10s setting.

I'm really curious to know how this will be addressed, because there is no denying the performance degradation when the tools are open.
(In reply to richard.cocks from comment #4)
> I have finally managed to reproduce this behaviour.
> 
> http://rcocks.github.io
> 
> This renders fast with no developer tools open. It runs slowly enough in
> Firefox (37.0.2 normal edition) with developer tools open that it crashes my
> firefox.
> 
> In Developer edition (39.0a2) it runs the same speed with or without
> developer tools open except if you try to record performance. Then it runs
> extremely slowly and does not show any time spent in anything but "(root)"
> when it has finished.

If you test the latest Nightly build, do you still see a slowdown on this site?  I wasn't able to reproduce it, even when trying the Performance tools.
Flags: needinfo?(richard.cocks)
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #7)

> If you test the latest Nightly build, do you still see a slowdown on this
> site?  I wasn't able to reproduce it, even when trying the Performance tools.

Yes, I do still see slowdown in the latest nightly (41.0a1). I am wondering if it is related to profiles, as there was one time I was unable to reproduce this behaviour when I was running a clean user profile. Having said that, even running in safe mode in nightly didn't help here since I still got the crash. Thankfully now thanks to e10s it only took down that tab!
Flags: needinfo?(richard.cocks)
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #7)
> If you test the latest Nightly build, do you still see a slowdown on this
> site?  I wasn't able to reproduce it, even when trying the Performance tools.

I should have added, I'm on windows 7 [6.1.7601] if that makes a difference.

Also, the actual timings returned on the page show similar timings, but the whole site freezes for a long time. So the javascript thinks it is executing quickly but somehow it is locking up the browser anyway.
Flags: needinfo?(jryans)
(In reply to richard.cocks from comment #9)
> (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #7)
> > If you test the latest Nightly build, do you still see a slowdown on this
> > site?  I wasn't able to reproduce it, even when trying the Performance tools.
> 
> I should have added, I'm on windows 7 [6.1.7601] if that makes a difference.
> 
> Also, the actual timings returned on the page show similar timings, but the
> whole site freezes for a long time. So the javascript thinks it is executing
> quickly but somehow it is locking up the browser anyway.

I retested on Windows 8.1, but still appeared to work fine there.  I don't have a Windows 7 setup at the moment.

Can you capture the data in about:support to a file for your profile where you do see the issue, and attach it to this bug?
Flags: needinfo?(jryans) → needinfo?(richard.cocks)
Attached file firefox.txt
I've attached this file which is the about:support data, I hope this helps.
Flags: needinfo?(richard.cocks)
To help narrow this down, if I open the developer tab but never go to the "Inspector" tab then I don't get this behaviour.
Depends on: 1170848
(In reply to richard.cocks from comment #12)
> To help narrow this down, if I open the developer tab but never go to the
> "Inspector" tab then I don't get this behaviour.

That was the hint I needed, I can reproduce now!  I feel like this bug is describing multiple different issues across various sites, so I'll make this a meta bug.

I've created bug 1170848 for this specific issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: meta
Summary: Open developer tools slow down page load → [meta] Open developer tools slow down page load
I can also confirm that the open Inspector panel cripples performance, but the others do not.

One thing I should mention, now that at least the Inspector panel slow down can be reproduced, is the general makeup of the page I was testing in the Network panel:

 13 CSS files
 47 JS files
  7 font files
162 images
  1 HTML document
--------------
230 requests (it was above 250 before I started documenting the progress)


The size of all downloaded assets:
3735.63 KB (3.7 MB)

From that, the HTML document averaged 142.43 KB, so its constructed DOM was massive.

Knowing this, could it be possible that when that many requests are made, some of which being quite large, that the Network panel could be a crippling point as well? Could it be possible that the massive DOM that needed to be constructed could have impacted the performance of other tools in the DevTools? Just having the tools open, regardless of panel, were causing slowdowns, as mentioned in the opener of this ticket.
(In reply to Dane MacMillan from comment #0)
> I recently started running performance tests against a big and unwieldy Web
> site. It's slow, and the long-term goal is to make it faster. Part of that
> testing involves the use of Firefox's and Chrome's Developer Tools Network
> panels. I've completed innumerable tests in each. In every case, Chrome
> reports a significantly faster overall load time. For example, a page that
> will take 2.74s to fully load in Chrome, will take 8.84s to load in Firefox.
> These are averages--and to iterate, averages that have been calculated after
> dozens of tests in each. When I disable Firefox's Developer Tools, however,
> the load times appear, at least anecdotally, to load in the 2s to 3s range.
> Ultimately, it feels like it loads in the same time that it loads in Chrome
> (but Chrome's tools are open).
> 
> I've always noticed a fairly significant lag in page load when Firefox's
> Developer Tools were open, especially on large-ish sites, but this has
> really hammered that fact into consciousness. This renders load time
> reporting in Firefox's Developer Tools almost unusable.

Bug 1143224 (even the part that have already landed) should help a lot with netmonitor timings, and there is one more patch there that should improve things further.

> Network panel aside, simply having the Developer Tools open causes
> significant, demonstrable lag. This is beyond "prove it with numbers,"
> because it's just apparent to anyone. Simply trying to scroll during a page
> refresh with the Developer Tools open is not possible because the browser is
> in an unresponsive, schizophrenic state; a normal state is resumed once
> every asset of the page has been downloaded and parsed.
> 
> Something I want to make clear is that these such issues don't appear to
> exist in Chrome with their tools open; there's a certain steadfast,
> unrockable assurance from the page loads in Chrome, while in Firefox there's
> just that expectation that between page loads with the tools open, you just
> have to weather the shaky, histrionic storm until the browser stops choking,
> settles down, and the elements on the page become clickable and scrolling
> finally responds (usually with some delayed scroll that compounds the
> already janky experience). I'm a die-hard Firefox supporter, but I can't
> shake this feeling.
> 
> What can be, or is being, done to improve the performance of this? I'd
> really like some feedback on this. As it stands, I can't rely on the load
> times being reporting in Firefox.

The best bet for getting these fixed is to file bugs with a link to a page (or attached test case) that demonstrates the slowness on a particular tool.  We now have a performance test to measure toolbox open / close and page reload time for each of the panels, so hopefully that will give us data to validate that the work we are doing is helping: https://wiki.mozilla.org/Buildbot/Talos/Tests#DAMP.

One more thing - if you enable multiprocess mode, there is a good chance that these problems will go away or at least become a lot less bad.
Depends on: 1143224
Alias: dt-open-slow
Depends on: 1176050
I filed bug 1188526 with some profiling info on comment 4.
Depends on: 1188526
Depends on: 1171482
Hello! I have FF 47.0.1, and I am experiencing this issue. I work on an intranet site that is password protected. Due to the sensitive nature of the data on our site I can't provide a link. However, I created a small (7MB) video demonstrating this issue. I can send this directly to the developers (I would prefer to not post it on a random website). Please let me know how I can get it to you.

I can provide any FF log/browser data needed. Just let me know what you need and how I can get it to you. I want to do anything possible to help get this fixed.
(In reply to raphael777777 from comment #17)
> Hello! I have FF 47.0.1, and I am experiencing this issue. I work on an
> intranet site that is password protected. Due to the sensitive nature of the
> data on our site I can't provide a link. However, I created a small (7MB)
> video demonstrating this issue. I can send this directly to the developers
> (I would prefer to not post it on a random website). Please let me know how
> I can get it to you.
> 
> I can provide any FF log/browser data needed. Just let me know what you need
> and how I can get it to you. I want to do anything possible to help get this
> fixed.

Hi, can you give some more details about what tool / actions are triggering the slowness - is it the network monitor, inspector, etc?  As far as the video, you can send me an email with a link to the video (or include it as an attachment) at bgrinstead@mozilla.com.
Flags: needinfo?(raphael777777)
Brian,

I just emailed the video to you. 

I am using the built-in FF Inspector. The slowdown happens regardless of which tab I have open. It happens on a page with many textboxes on the blur event. When the blur happens, the page has to do some updating, which includes an AJAX call. When the Inspector is open, it takes about 5-8 seconds to update. When the Inspector is closed, the update is instantaneous.
Using 47.0 on (Linux Mint 17.3, 8 Cores, 8 GB RAM) the CPU spikes to 105% when editing a property in the CSS.
And by that I mean just going to one property value, hitting Enter (which moves cursor down to type a new property name) and doing nothing else. CPU spikes.
The CSS file used by this page is about 2.2MB in size.
What I find interesting is, that at to that point, I have not changed anything, so not sure why the browser will be "trying" to do something.
Also, same computer as above, I notice that page slows down when doing AJAX requests (I'm using angular with promises). When tools are hidden, everything flights. When open, it just takes a long time (in Network pane, it doesn't show as the call taking a long time, just nothing right before that)
(In reply to Nelson from comment #21)
> Also, same computer as above, I notice that page slows down when doing AJAX
> requests (I'm using angular with promises). When tools are hidden,
> everything flights. When open, it just takes a long time (in Network pane,
> it doesn't show as the call taking a long time, just nothing right before
> that)

Could you please provide a link to the page you are seeing these network issues on?
Flags: needinfo?(nelson.mozilla)
(In reply to Nelson from comment #20)
> Using 47.0 on (Linux Mint 17.3, 8 Cores, 8 GB RAM) the CPU spikes to 105%
> when editing a property in the CSS.
> And by that I mean just going to one property value, hitting Enter (which
> moves cursor down to type a new property name) and doing nothing else. CPU
> spikes.
> The CSS file used by this page is about 2.2MB in size.
> What I find interesting is, that at to that point, I have not changed
> anything, so not sure why the browser will be "trying" to do something.

The tools are likely trying to tokenize this file even before attempting to make an edit.  If you could provide a link to the page, that would be helpful
(In reply to Brian Grinstead [:bgrins] from comment #23)
> (In reply to Nelson from comment #20)
> > Using 47.0 on (Linux Mint 17.3, 8 Cores, 8 GB RAM) the CPU spikes to 105%
> > when editing a property in the CSS.
> > And by that I mean just going to one property value, hitting Enter (which
> > moves cursor down to type a new property name) and doing nothing else. CPU
> > spikes.
> > The CSS file used by this page is about 2.2MB in size.
> > What I find interesting is, that at to that point, I have not changed
> > anything, so not sure why the browser will be "trying" to do something.
> 
> The tools are likely trying to tokenize this file even before attempting to
> make an edit.  If you could provide a link to the page, that would be helpful

Here is one (to avoid automatic links, just type it in your address bar, replacing - for dots):
truereligion-ngcxpress-com
(In reply to Brian Grinstead [:bgrins] from comment #22)
> (In reply to Nelson from comment #21)
> > Also, same computer as above, I notice that page slows down when doing AJAX
> > requests (I'm using angular with promises). When tools are hidden,
> > everything flights. When open, it just takes a long time (in Network pane,
> > it doesn't show as the call taking a long time, just nothing right before
> > that)
> 
> Could you please provide a link to the page you are seeing these network
> issues on?

Unfortunately the places (using Angular) are internal or password protected. I made a screen shot attachment of another site (not using Angular) that is displaying the same behavior. What I noticed is that the file where it takes a long time (in the image is the last javascript before some images) it's a language file (creates an array with language keys, about 600 of them). The same thing that the internal site is doing using Angular.
It seems like for some reason it is getting slow when processing that javascript file.
Notice that when tools are not open, this page flies (no delay whatsoever)
Flags: needinfo?(nelson.mozilla)
Depends on: 1288493
Filed Bug 1288493 based on a test case provided by raphael777777
Flags: needinfo?(raphael777777)
Depends on: 1289203
Seems like a general problem with pages that load many scripts (JS) in background.

Uncompiled (unmerged) ExtJS app loads VERY slowly (x10 factor) on FF with dev tools open.

FF: https://youtu.be/Z95TcgS94RM
Chrome: https://youtu.be/YKgg9aa913Q

Code not public, sorry but I assume you can reproduce with any ExtJS app with 100+ classes.
Also note that I see no difference between HTTPS/2 and plain HTTP on FF. Both complete loading the page in about 34 s in FF (Chrome is always below 3 s).
It (In reply to Maciej Jaros from comment #28)
> Seems like a general problem with pages that load many scripts (JS) in
> background.


The problem presents when you're trying to use source map and you have many JS files.
The same website with source map off, loads as expected.
No longer blocks: 1156747
Depends on: 1156747
Product: Firefox → DevTools
No longer depends on: 1156747
You need to log in before you can comment on or make changes to this bug.