I am building a JavaScript application, and primarily testing it in Chrome. The application involves a fair share of DOM manipulation and building.

My problem: Under certain circumstances, the application suddenly bees several times slower. It appears to be a boolean thing, and predictable: each time I do a certain action, it will bee slow, and stay so until I do one of specific other actions, upon which the performance returns to the normal.

What puzzles me is that there is nothing I can see in the code that would suggest a reason for this. Sorry, the code is too plex to give a sample, especially given that I can't isolate what causes this.

One of the actions that speeds it back up is clicking in the document; even the empty areas, even if I don't register any relevant mousedown/click handlers, somehow a click magically restores the application to health. In contrast, programmatically clearing focus with $(document).find('*').blur(), nor focusing an unfocused element with $('#some_button').focus() do not help.

I also tested on Firefox and Opera. I have pretty severe performance problems in Firefox (its DOM manipulation is much slower? Firebug says it spends most of its time in jQuery.attr() - not relevant here), but it appears that I do not get slowed down by this particular bug; the performance is the same before and after the action that would trigger the slowdown in Chrome. Opera is also not affected.

I haven't yet tried Safari, and I can't test on IE (heavy reliance on SVG, and other issues).

So: Does anyone have any ideas what could be impacting my performance? Or at least, an idea about what effect could a click have if it is not caught by the handler, and if programmatic focus change does not do the same? I've run out of ideas for debugging this thing.

UPDATE: I guess I can isolate the code anyway. fileBrowser is a form (later made into jQuery UI modal dialog).

  var fileBrowserSubmit = function(evt) {
    // trigger the big render - either ~300ms or ~3s
  }
  var chooseDocument = function(evt) {
    // set up variables pertaining to the selected tr,
    // style the tr as selected
  }
  var chooseDocumentAndSubmit = function(evt) {
    chooseDocument(evt);
    fileBrowserSubmit(evt);
  }
  fileBrowser.
    submit(fileBrowserSubmit);
  fileBrowser.find('tr').
    click(chooseDocument).
    dblclick(chooseDocumentAndSubmit);

If I click on a tr, then click OK (thus submitting the form), no slowdown: the code called from fileBrowserSubmit gets executed in ~300ms

If I doubleclick on a tr, slowdown: the rendering function will run for ~3s (on the sample data I am testing on).

It can be seen that the executed code in both cases is almost identical: chooseDocument followed by fileBrowserSubmit.

I am building a JavaScript application, and primarily testing it in Chrome. The application involves a fair share of DOM manipulation and building.

My problem: Under certain circumstances, the application suddenly bees several times slower. It appears to be a boolean thing, and predictable: each time I do a certain action, it will bee slow, and stay so until I do one of specific other actions, upon which the performance returns to the normal.

What puzzles me is that there is nothing I can see in the code that would suggest a reason for this. Sorry, the code is too plex to give a sample, especially given that I can't isolate what causes this.

One of the actions that speeds it back up is clicking in the document; even the empty areas, even if I don't register any relevant mousedown/click handlers, somehow a click magically restores the application to health. In contrast, programmatically clearing focus with $(document).find('*').blur(), nor focusing an unfocused element with $('#some_button').focus() do not help.

I also tested on Firefox and Opera. I have pretty severe performance problems in Firefox (its DOM manipulation is much slower? Firebug says it spends most of its time in jQuery.attr() - not relevant here), but it appears that I do not get slowed down by this particular bug; the performance is the same before and after the action that would trigger the slowdown in Chrome. Opera is also not affected.

I haven't yet tried Safari, and I can't test on IE (heavy reliance on SVG, and other issues).

So: Does anyone have any ideas what could be impacting my performance? Or at least, an idea about what effect could a click have if it is not caught by the handler, and if programmatic focus change does not do the same? I've run out of ideas for debugging this thing.

UPDATE: I guess I can isolate the code anyway. fileBrowser is a form (later made into jQuery UI modal dialog).

  var fileBrowserSubmit = function(evt) {
    // trigger the big render - either ~300ms or ~3s
  }
  var chooseDocument = function(evt) {
    // set up variables pertaining to the selected tr,
    // style the tr as selected
  }
  var chooseDocumentAndSubmit = function(evt) {
    chooseDocument(evt);
    fileBrowserSubmit(evt);
  }
  fileBrowser.
    submit(fileBrowserSubmit);
  fileBrowser.find('tr').
    click(chooseDocument).
    dblclick(chooseDocumentAndSubmit);

If I click on a tr, then click OK (thus submitting the form), no slowdown: the code called from fileBrowserSubmit gets executed in ~300ms

If I doubleclick on a tr, slowdown: the rendering function will run for ~3s (on the sample data I am testing on).

It can be seen that the executed code in both cases is almost identical: chooseDocument followed by fileBrowserSubmit.

• javascript
• performance
• google-chrome

Share Improve this question Follow edited May 23, 2011 at 14:07 Gabe 86.9k1212 gold badges143143 silver badges238238 bronze badges asked May 10, 2011 at 1:21 AmadanAmadan 199k2323 gold badges252252 silver badges319319 bronze badges 3

• Perform the action which slows down the app, and then examine what has changed in the DOM as a result of that. The added plexity in navigating and rendering MUST be to do with the newly entered state. If you add several levels of nested elements with one mouseclick, for example, my guess is that the volume of nested elements would be what's adding so much to the browser's rendering time. – user244343 Commented May 10, 2011 at 1:31
• This was what I thought as well. However, there are two code paths that do roughly the same thing: one causes the slowdown, the other doesn't - and the DOM should be the same after both. Another thing is that the click that clears the slowdown specifically does not do anything - certainly not change the DOM. – Amadan Commented May 10, 2011 at 1:49
• I am experiencing exactly the same problem you describe - what a mystery. – gregsabo Commented Dec 20, 2012 at 3:09

Add a ment  | 

3 Answers 3

Sorted by: Reset to default 4

Use a profiler. It's the only way to be sure.

Chrome's Developer Tools have one built in.

You must collect a new Javascript CPU Profile from the Profiles tab.

1. Select "Collect JavaScript CPU Profile.
2. Click Start.
3. Do some operation in your document.
4. Click Stop.

A new profile will be created under the "CPU Profiles", in the sidebar. Click on it.

Although this question is pretty old already, I ran into the same problem.

My application is also using a lot of SVG. After clicking onto some (but not all) UI elements, the rendering was just taking much longer. Using the profiler and the timeline from the chrome debugger tools only showed that the offsetWidth calculation (for size calculation of foreign objects in that case) was taking much longer than before. Apart from that all the stats (memory consumption, cpu, etc.) where the same as before.

Since I already had a similar issue which was caused by some CSS rule, I kind-of brute-forced trough my CSS rules. The rule which was causing the problem was (my sass, uses twbs):

.some-ponent-selector {
    * {
       @include user-select(text);
    }
}

For the largest part, the application does not allow user selections but in this specific node it does. Before clicking the node, it seems like chrome just treats the node like all others, but after you've clicked it, the svg renders very slow. Removing this rule fixed the problem for me.

I tested this on version 34.0.1847.116 on mac, windows, and linux as well as some chromium version on linux and the problem existed on all platforms.