Google Chrome Developer Toolkit is Slow

Question

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

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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!