Javascript 执行阻止 IE 8 中的渲染/滚动
我在使用 IE 8（可能还有所有以前的版本）时遇到了一些问题。 Firefox 和 Chrome/Webkit 看起来不错。
某些原因导致页面渲染、滚动以及基本上所有页面交互被阻止。据我所知，Javascript 执行导致了这种情况的发生。
具体来说，我认为在我的具体情况下有两个主要责任方 - Google Maps API (v3) 和 Facebook Connect。
在这两种情况下，我都使用 Google 和 Facebook 提供的异步加载方法。
到目前为止，我已经尝试了一些方法，但没有成功：
- 使用 jQuery 的 $(document).ready() 延迟执行。这只是防止锁定，直到页面加载稍晚一些。实际上，由于我使用 gzip 压缩，我不太确定它有什么作用 - 我不清楚它是如何工作的。
- 使用window.onload延迟执行。同样的情况 - 整个页面加载，然后在抓取并执行 Facebook Connect 代码时锁定。
- 使用setTimeout(function(){}, 0)。我并不是 100% 清楚这实际上是如何工作的 - 据我了解，它本质上是应该强制函数代码的执行等待堆栈清空。不幸的是，这似乎对我没有多大作用。
我认为这个问题对我来说尤其严重，因为我的连接速度慢。
我想不出我的网站有任何具体的奇怪之处会成为一个因素，但我不会排除这一点。
那么，我的问题：
针对此问题是否有任何最佳实践或现有解决方案？
我是否明显做错了什么？
有问题的网站位于：http://myscubadives.com/，如果有人愿意看一下具体实施。
预先感谢您的时间和帮助。
山姆
I'm having a bit of trouble with IE 8 (and probably all previous versions). Firefox and Chrome/Webkit are seemingly fine.
Something is causing page rendering, scrolling, and basically all page interaction to become blocked. As best I can tell, Javascript execution is causing this to happen.
Specifically, I think there are two major responsible parties in my specific situation - Google Maps API (v3) and Facebook Connect.
In both cases, I am using the asynchronous load methods provided by both Google and Facebook.
I've tried a couple of things so far, to no avail:
- Delaying execution with jQuery's $(document).ready(). This just prevents the locking until slightly later in the page load. Actually, since I use gzip compression, I'm not really sure it does anything - I'm not clear on how that works.
- Delaying execution with window.onload. Same situation - the whole page loads, then it locks up while it grabs and executes the Facebook Connect code.
- Using setTimeout(function(){}, 0). I'm not 100% clear on how this is supposed to actually work - as I understand it, it essentially is supposed to force the execution of the function's code to wait until the stack is clear. Unfortunately, this doesn't seem to do much of anything for me.
I think the problem is especially exaggerated for me because I am on a slow connection.
I can't think of any specific oddities with my site that would be a factor, but I won't rule that out.
So, my question:
Are there any best practices or existing solutions to this issue?
Is there something that I am obviously doing wrong?
The offending site is at: http://myscubadives.com/, if anyone would be willing to take a look at the specific implementation.
Thank you in advance for your time and help.
Sam
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，浏览器（至少是 IE）在执行 Javascript 时会自行挂起。这使得事情变得更快一些，因为每次进行更改时都不必重新绘制和重新计算布局。然而，如果你的 JavaScript 需要很长时间才能执行，这看起来就像冻结一样。同步 XMLHttpRequest 也很重要。
不幸的是没有很好的解决方法。典型的建议是使用 window.setTimeout() 函数，并将超时设置为 0（或非常小的值），将工作负载分成几个部分。在这期间，浏览器可以设法重绘自身并响应某些用户交互，因此它看起来并不冻结。但代码变得很丑陋。
如果 XMLHttpRequest 很长，您别无选择，只能使用异步版本。
补充：啊，我发现你已经知道这一点了。应该更仔细地阅读。 :P 您是否还知道 IE8 内置了开发人员工具（按 F12 激活）并且 Javascript 选项卡有一个分析器？我查了一下，2秒专门花在了jQyery的
get()方法上。这让我强烈怀疑某些东西仍在使用同步 XMLHttpRequest。Yes, the browser (at least IE) suspends itself while Javascript is being executed. This makes things a bit faster, because it doesn't have to redraw and recalculate layout every time you make a change. However if your Javascript takes a long time to execute, this will seem like freezing. Synchronous XMLHttpRequests also count.
Unfortunately there is no pretty workaround. The typical advice is to use
window.setTimeout()function with timeout set to 0 (or something very small) to split the workload in several parts. Inbetween the browser can manage to redraw itself and respond to some user interaction, so it doesn't seem frozen. The code gets ugly though.In case of lengthy XMLHttpRequests you have no choice but to use the asynchronous version.
Added: Ahh, I see that you already know this. Should read more carefully. :P Did you also know that IE8 has Developer tools built in (Press F12 to activate) and that the Javascript tab has a profiler? I checked it out, and 2 seconds were spent exclusively in jQyery's
get()method. Which gives me a strong suspicion that something is still using synchronous XMLHttpRequests.