6

I have a JS-heavy app and it runs slowly in IE. I'm about to spend about a week optimizing for IE, and I'd like some direction about things to try.

I found this thread referencing Drip, which seems useful:

IE and Memory accumulation in Javascript

I'm looking for tips like, "use for loops instead of $.each" as well as architectural best practices that I may not be using.

Libraries I'm using:

Things I'm already doing:

  • using for loops instead of $.each
  • caching jQuery contexts for commonly-referenced DOM elements
  • building HTML using Array.join() vs. string concatenation

Any suggestions?

Thanks!

Community
  • 1
  • 1
marclar
  • 3,026
  • 5
  • 35
  • 56
  • 1
    *"building HTML using Array.join() vs. string concatenation"* A good idea in almost every JavaScript implementation I've ever seen. – T.J. Crowder Nov 22 '10 at 22:28
  • 1
    Which version of IE is it slow in? The javascript execution in v8 is considerably faster than v7. Version 8 is still slower than FFox. Have a clear goal of what you want to achieve, because there is probably only so much you can do before you hit the wall with IE, if it is still too slow then you will have to look to optimise some other way. – slugster Nov 22 '10 at 22:30
  • Slow in both IE7 and IE8 (I'm ignoring IE6). Obviously, IE8 is better. In what other way would I optimize? I presume it's the JavaScript that's making things slow, and unfortunately, the app requires a great deal of JS. I'm curious as to how Google gets their JS apps to run as well as they do in IE. – marclar Nov 22 '10 at 22:36
  • @T.J. – I suppose you meant the former is preferred above the latter? ;) – Marcel Korpel Nov 22 '10 at 22:42
  • @Marcel: Yes (that was my read of the OP's intent as well, hopefully I'm not mistaken!). :-) – T.J. Crowder Nov 22 '10 at 22:45
  • `` – Stephen P Nov 22 '10 at 22:57
  • I think Array.join() can be considered an anti-pattern now. See SO question [String concatentation vs. string buffers in JavaScript](http://stackoverflow.com/questions/1370830/string-concatenation-vs-string-buffers-in-javascript). I particularly liked [this test](http://jsbin.com/ivako) to prove concatentation performance in any browser – Brad Cupit Apr 12 '11 at 19:15

3 Answers3

8

Use a JavaScript Profiler in IE

Community
  • 1
  • 1
Byron Whitlock
  • 52,691
  • 28
  • 123
  • 168
5

Don't go blindly through your code making trivial improvements like changing $.each() loops to for loops; that's really pointless and someday you'll regret it. Use a profiler because it's a very good bet that most of your problems stem from a very small number of unexpectedly bad pieces of code.

Something like dynaTrace ajax edition are invaluable in situations like this.

Pointy
  • 405,095
  • 59
  • 585
  • 614
  • Mmmm . . . I doubt I'd regret such "trivial" changes, though your larger point is taken. However, I am curious about IE-specific bottlenecks if you happen to know any. And that said I'll certainly be looking for *developer-caused* bottlenecks along the way. – marclar Nov 22 '10 at 22:38
  • Well doing at least some of those things can get rid of some valuable "good code". A loop written with `$.each()` that runs once upon page load and iterates through 5 things really isn't slowing anything down. Look for code that's needlessly performing really expensive jQuery lookups, possibly over and over again. – Pointy Nov 22 '10 at 22:54
2

If it is IE6/7 and "one page" app then minimize the dom manipulation ie. rather do one big replace than hundreds of small changes in a loop.

Heikki
  • 15,329
  • 2
  • 54
  • 49