42

I have been using Google Chrome's dev tool kit (element inspection, stack trace, javascript debugging, etc.) for some time with great success.

However, about two weeks ago, it suddenly became VERY sluggish. For example, when I right-click an element in the UI and then click "Inspect Element", or when I simply press F12, the code window takes 30-45 seconds to come up. It used to happen in less than a second.

Has anyone else run into this problem? If so, were you able to correct it? How?

Thanks in advance!

Matt

Matt Cashatt
  • 23,490
  • 28
  • 78
  • 111
  • Does it happen only when you test your site locally or does it happen on other websites too? I have a similar problem, but mine only happens when testing locally. – silvenon Jan 18 '13 at 19:55

10 Answers10

37

I've had the same problem, tried the same solutions without luck, until I fired procmon and saw that Chrome was actually reading my entire Projects folder (which is several hundred thousand files worth).

There was a reference to that folder in the Workspace/Folders section in the dev tools Settings app. Removing the reference solved the problem.

Pablo Montilla
  • 2,941
  • 1
  • 31
  • 35
  • 2
    +1 for this answer, I also added my Project Root Directory to the workspace some month ago. Didn't recognize it. Perfect, now DevTools is reacting much "faster" again. Thank you very much! – Scriptlabs Sep 24 '14 at 12:47
  • 2
    This was the cause of my problem too. The workspace was my entire user folder. – JNB Jun 30 '16 at 12:41
  • 1
    +1 I had some random folder added probably long time ago. I've removed and pretty good performance is back – SzymonPoltorak Aug 18 '16 at 08:57
10

This was solved by clearing my cache (temp files, cookies, etc) in Chrome. Not sure what the root cause was, but that fixed the problem.

Matt Cashatt
  • 23,490
  • 28
  • 78
  • 111
  • 5
    Didn't fix my problem. I have a javascript library that is around 12k lines of code. When using the debugger, stepping into a function or stepping over a simple same-stack line of code takes about 30 seconds to execute. If the codepath jumps to another section of the source it can take up to 5 minutes to get there and refresh the inspector. IE and FireFox both operate nominally without much of a noticeable delay. I can expect some delay @ 12k locs, but 5 minutes is ridiculous! – Marcus Pope Nov 28 '12 at 21:55
  • Clearing the cache will make it even worse, because every access to whatever script or framework or resource the page you are visiting is using, will get downloaded and cached and inspected again. Don't know why this helped the author of the question... – Scriptlabs Sep 24 '14 at 12:52
  • Well, even though it doesn't make sense according to some people clearing cache also did it for me :) I also needed to restart after clearing cache. Thanks a lot! +1 – Wilt Dec 05 '14 at 09:10
  • It was the same for me. The slowness started once i have started restarting the system everyday. I like to know the reason, so i am upvoting the answer. – Dileep Feb 02 '16 at 03:48
4

I have had the same problem.

My Problem was, that i used browserify to create a large bundle (~92k lines) width SOURCEMAP. browserify app.js -d -o bundle.js.

I solved it by splitting my bundle.js.

I exported all node modules into a seperate file (modules.js) by adding --require [module name]:

browserify -r react -r lodash -r three > build/modules.js

and then create the bundle.js without the outsourced modules by adding --external [module name].

browserify -t babelify -x react -x lodash -x three src/app.js > build/bundle.js

(-t babelify, because i used react/JSX in my project.)

NOTE: You have to include module.js in your html before bundle.js.

My bundle.js shrinked from ~92000 to ~26000 lines ;-)

EDIT: To create a bundle without external modules (node_modules) you can also use --no-bundle-external instead of [-x NODE_MODULE_NAME]*.

EDIT #2: When you are using an module in your project that contains many submodules, -r|-x [MAIN_MODULE_NAME] won't require|exclude the submodules.

Example with react-bootstrap:

react-bootstrap contains many submodules, react-bootstrap/lib/[submodule].

browserify -r react-bootstrap > build/modules.js won't require for example the Button (react-bootstrap/lib/Button) module. So...

...if you are using

browserify --no-bundle-external src/app.js > build/bundle.js

...you wont't be able to use Button in your app, because --no-bundle-external excludes all node modules, including submodules. So don't forget to require all necessary submodules to:

browserify -r react-bootstrap -r react-bootstrap/lib/Button > build/modules.js

NOTE: Additionally, to increase the performance you can use exorcist to put the sourcemap into a separate file. Install it with:

npm install --save-dev exorcist

and change your browserify command:

browserify --no-bundle-external src/app.js | exorcist build/bundle.js.map > build/bundle.js

Thanks to smhg for the hint with excorcist. And show his answer for more details.

Community
  • 1
  • 1
marcel
  • 2,967
  • 1
  • 16
  • 25
  • 2
    For me, with a similar setup, **inline** sourcemaps slowed down Chrome Developer Tools. Splitting up files made little difference. Ever since I pulled out sourcemaps with [exorcist](https://www.npmjs.com/package/exorcist) into _separate_ files, everything is snappy and smooth. – smhg May 24 '15 at 10:43
  • FWIW: I had the worst slowdown after the update to Chrome 43 (on Ubuntu). – smhg May 24 '15 at 11:03
  • yes, for me it worked fine with inline sourcemaps ~5mb until Chrome 43 (on windows 8.1) – Hulvej May 29 '15 at 12:05
  • Yeah I had an inline sourcemap and my app was almost unusable with Chrome tools open. Thanks! – welbornio Jun 02 '15 at 21:27
  • Using exorcist fixed the problem for us. For mi this is the "real" answer :) – Alotor Jun 17 '15 at 07:48
3

Using Chrome 46.x/47.x on Linux (RHEL 7), none of the proposed solutions worked for me. What did work was to disable the setting "Use hardware acceleration when available", in the advanced browser settings.

I noticed in the process monitor/list that the Chrome renderer was taking up a lot of CPU and as described above, even putting a breakpoint or stepping throught statements in the debugger would take 10+ seconds!

AsGoodAsItGets
  • 2,886
  • 34
  • 49
2

I've added it as a comment to marcel's answer, but since it made such a big difference for me I think it is worth to put it as a separate answer:

I had an inline JS source map in a file with a total size of about 2-3MB (uncompressed, during development). Chrome was unbearably slow on page loads (with Developer Tools open). After about 20 seconds, when the file and inline source map were parsed, things would be more or less normal. Additionally, it got worse with the update to Chrome 43 (on Ubuntu).

As soon as I put the source map in a separate file, everything went back to normal. The slowdown on page load is gone. Sources are available instantly.

Since I build with browserify, exorcist was what I used. More specifically: with watchify in the -o parameter as described in this issue.

smhg
  • 2,159
  • 19
  • 26
1

I had a problem like this; opening the debugger window was sluggish (10-20 seconds) and also every time I stepped over code, no matter how simple, I experienced a long delay (10-20 seconds).

The cause for me was that I had some large arrays (1000s of entries, 10s of MB of data) in scope. The debugger pre-renders all in-scope data (including all globals, everything hanging off Window, and all parameters to all functions on the call stack) for display in the "Scope Variables" window. If that tree of data is large, then each step it will take the debugger a long time to recalculate the variable inspection tree.

I was able to work around the problem by (a) moving the large array into a non-global scope, to keep it off of Window, and then (b) moving the rest of my program into a separate scope. Like so:

<script>
(function() {
  // large variable in stack scope, stepping in any
  // code called from here will be slow
  var hugeArray = [...];
  calculateHugeArray(hugeArray);
})();

(function() {
  // large variable now out of scope, so Chrome won't
  // try to display it in the "Scope Variables"
  // window. This makes debugging and stepping faster.
  doMoreThings();
})();
</script>

Unfortunately if you need to step through code that references the large array, then I don't have a workaround.

Zero Trick Pony
  • 496
  • 5
  • 5
1

My solution was to just delete a batch of projects that were running locally on my computer and were connected to IIS. Just removed folders/projects i don't use a lot or anymore. removed 25GB of data and now my dev toolbar works like charm!

Chris Heijnen
  • 129
  • 4
0

Clearing cache and all privacy data solved my problem as well :-)

Shashank Agarwal
  • 712
  • 8
  • 14
0

This is fixed in a future version: https://code.google.com/p/chromium/issues/detail?id=485052

Hulvej
  • 3,895
  • 1
  • 18
  • 21
0

My transpiled file including source map is about 5MB. I have tried all of the solutions in this post and have only seen marginal improvement. I eventually gave up and uninstalled and reinstalled Chrome. Wish I did that right away, my source map load in the debugger went from about 15 seconds to 3.

app_sciences
  • 783
  • 1
  • 7
  • 14