views:

292

answers:

6

Hi folks,

So I was involved in a site rewrite recently and we've gone live with what’s a big improvement on the previous in every way (no it's not perfect, we live by deadlines and are always improving :D) with one exception: in IE6/7 it will lockup after the page has shown. I know it's the JS as with it disabled it's fast and I'm aware of some things like the simplegallery plugin that we use being very slow but even with that and Google ads removed it's still at a crawl(+8sec). I've looked through the Firebug profiler and made loads of JS/CSS changes such as:

  • Moving all JS except our img error handling to the bottom of the page
  • Improving all jQuery selectors specify for best performance
  • Moving to jQuery 1.4
  • running our core custom JS (main.js) through JS Lint
  • Spriting commonly used images
  • Reducing CSS selector complexity

Doing this was good for all browsers and I know I can do even more but I'm not seeing a major improvement in IE6/7 which I need. We do use DD_roundies_0.0.2a.js for IE7 but not for IE6. I tried DynaTrace but couldn't see anything obvious though I did get a bit lost in its depth.


A sample listing page would be: http://tiny.cc/JrSYr

A sample search page is: http://tiny.cc/tog1D


Can anyone see what I might be missing here and/or point to some good IE profiling tools?

Edit: I should have mentioned that I've been through YSlow, PageSpeed and Chrome's Developer Tool. All of which I used to base most of the improvements mentioned above on. At this point I'm not saying the site is fully optomised but it's Ok and moving in the right direction. However I have an issue in IE6/7 and I believe it to be the JS execution.

Edit 2: We already send down the Chrome Frame meta tag for IE6 from the server. It's not a solution but I see it doing more good than harm for IE6. I'm after JS specifc feedback at this point as I think I've covered all the other bases.

Thanks

Denis

+1  A: 

You're including jquery from http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.js, it'll download faster if you host it on your website.

Also, checkout the YSlow addon for Firebug, it gives you lots of information about what you can do to improve the load time of your site.

Rowno
Thanks for the input. Been through YSlow alot, and Page Speed (will mention above). As for jQuery I prefer it to be on google as it's more likely to be cached for the user. Also I'm not sure the download speed is the issue I think it's more JS execution.
Denis Hoctor
Using http://ajax.googleapis.com/ajax/libs/jquery/1.4.0/jquery.js (1.4.0 instead of 1.4) instead will be slightly faster as it will be cacheable by clients, but you have to update the url for new 1.4.* releases.
Kimble
Thanks Kimble. But what do you think is wrong with that url? WHen I checked the header it was Cache-Control: public, must-revalidate, proxy-revalidate, max-age=3600 and expires in 12 days. Have I missed something?
Denis Hoctor
"it'll download faster if you host it on your website" - It's better to spread things across domains - modern browsers won't download more than a couple things at a time. http://stackoverflow.com/questions/561046/how-many-concurrent-ajax-xmlhttprequest-requests-are-allowed-in-popular-browser
Warren Blanchet
A: 

If you want to be drastic force your users to install the Google Chrome Frame it will make IE use the chrome renderer and javascript engine

http://code.google.com/chrome/chromeframe/

RHicke
The whole Chrome Frame makes no utter sense. Just let the users use Chrome (or any other decent webbrowser).
BalusC
Chrome Frame is definitly not a solution as Corportes and backward IT admins (not to be rude but where the IT guy still wants IE6, he's got to be an idiot or just too lazy, right?) aren't going to allow it. That said for the small number that do we have already sent it down <meta http-equiv="X-UA-Compatible" content="chrome=1" /> conditionally for IE6!
Denis Hoctor
Sorry about that it was 99% a joke. I feel you though as my companies biggest client uses nothing but IE6. The only thing you can do is optimize optimize optimize as IE6's javascript engine is weak. If you need to remove expensive features do it and tell them why.Additionally use chromes profiler to tell you if any of your functions are getting called to often that was what worked best for me.
RHicke
+1  A: 

You can manually profile your "common.js" script in IE6. Just grab a new time-stamp at strategic places and alert them at the end.

e.g.

function ts() { return (new Date).getTime(); }
var t0 = ts();
// some of your code
var t1 = ts();
// rest of your code
var t2 = t();
alert(t1-t0); // milliseconds between t0 and t1
alert(t2-t0); // ms between t0 and t2

Maybe one part of the script is that much slower than the rest.
Or maybe it's just IE6.

Sean Hogan
A: 

Currently only thing that seemed there suspicious was "omniture.js".

Here's a blog post I found regarding omniture.js and IE6.

You can use SpeedTracer on Chrome to debug speed issues. Of course the js speed will be according to V8 engine.

egon
A: 

The javascript itself is often not the issue, it's when you modify the DOM you end up in trouble, for example animating, adding and removing elements. Be extra careful with opacity.

fdsggfdsafs
A: 

Take a look at LABjs & RequireJS: Loading JavaScript Resources the Fun Way which talks about how you can load scripts in parallel.

Until the latest generation of browsers, the tag had some really unfavorable performance characteristics to it. Namely, tags “block”, meaning they call a halt to everything else that’s loading/happening on the page, while they load and while they execute. Not only do they halt all other parts of the page, they even used to halt the loading of any other tags.

Kevin Hakanson