Side navigation
#9604 closed bug (invalid)
Opened June 16, 2011 02:17PM UTC
Closed July 01, 2011 08:02AM UTC
Downgrade IE performance
Reported by: | andy@sherbet-solutions.com | Owned by: | andy@sherbet-solutions.com |
---|---|---|---|
Priority: | low | Milestone: | 1.next |
Component: | misc | Version: | 1.6.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
I've been working on a site which makes heavy use of JQuery and it was all going very nicely until we started testing in IE6+7. The performance of the site was dreadful.
After doing some digging around, I noticed that one method was being called x,000 times and resulted in a 7000ms process time. The method in question was "doScrollCheck".
Making the following code change (commenting out several lines):
// ensure firing before onload, // maybe late but safe also for iframes //document.attachEvent("onreadystatechange", DOMContentLoaded); // A fallback to window.onload, that will always work window.attachEvent("onload", jQuery.ready); // If IE and not a frame // continually check to see if the document is ready // var toplevel = false; // try // { // toplevel = window.frameElement == null; // } catch (e) { } // if (document.documentElement.doScroll && toplevel) // { // doScrollCheck(); // }
I was able to take the time from 7000ms all the way down to 720ms.
Whilst I appreciate that the code I have commented out is relevant, it does have a huge performance hit.
Is there any way that the above code could be re-factored to perhaps, reduce the timeout interval from 1ms to something greater? Only perform the doScrollCheck code if the page actually has iframes in it? Some other creative method that does it all far better.
Cheers,
Attachments (0)
Change History (2)
Changed June 17, 2011 05:43AM UTC by comment:1
component: | unfiled → misc |
---|---|
owner: | → andy@sherbet-solutions.com |
priority: | undecided → low |
status: | new → pending |
Changed July 01, 2011 08:02AM UTC by comment:2
resolution: | → invalid |
---|---|
status: | pending → closed |
Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!
Thanks for submitting a ticket to the jQuery Bug Tracker!
Do you have any test cases on jsFiddle.net or performance reports from jsPerf.com (or otherwise) which you can share to assist us in evaluating the performance issues you're experiencing at the moment (or perf improvements)?. Before any changes or fixes can be suggested or made, it's essential that we be able to establish that more people are able to reproduce the issues described.