【发布时间】：2014-11-26 21:36:43
【问题描述】：
我有一个由 GWT 生成的相当复杂的 javascript，它在所有浏览器（包括 IE10）中都运行良好，但在 IE11 中我遇到了性能问题。
激活分析器我发现最消耗的代码是...（从最消耗的顺序）
clientWidth、offsetHeight 和具有令人印象深刻的值的类似方法：
clientWidth 32 秒（32806 毫秒），仅 60 次调用 181 次调用的 offsetHeight 为 29 秒
在我看来，我在 IE11 中本地化的性能问题的原因（考虑到整个代码在 IE10 中的执行大约需要 2 秒），当然我可以开始优化减少调用次数（如果可能的话）我想了解我使用的方法或其他方法是否有问题 有谁知道 IE11 出了什么问题？
更新： 只是为了给出一个比较的术语：文档模式下相同代码中的clientWidth = 10它是15ms......差异2000倍太奇怪了我在这个，相同的代码，相同的方法中找不到IE的错误在文档模式下分析边缘 (11) 与 10
更新： 使用探查器更深入似乎 clientWidth 在我的树中挖掘更多时间：
我看到：clientWidth -> Layout -> html-> body -> table x -> 为 display:table -> td -> table-> 为 display:table -> td -> table 生成的表.. .....
等等很多时间（我无法到达树的尽头！
有谁知道生成表的确切含义是什么？我唯一能猜到的是IE11出于某种原因越来越多地在DOM树上运行以计算宽度......但我无法猜测如何打破这个漫长的循环
使用解决方法更新： 足够有趣（并确认到目前为止所看到的）它存在一种“解决”性能问题的方法：将最外部的 div/容器设置为以像素为单位的固定大小（至少两个维度中的一个）这个接缝使 IE 更容易计算容器大小并解决每个问题。 这是一个有趣的解决方法，在某些情况下可能有用，不幸的是，在我的情况下，我需要保持“100%”大小以适应不同的屏幕......所以不是一个可接受的解决方法
带有可能的字段限制的更新： 似乎涉及到大量使用 cellWidth 和 cellHeight，我的 JS 为几乎每个 div 设置了单元格大小和实际大小为百分比，删除单元格大小似乎可以将每次调用的大小计算时间减少到 1ms！
【问题讨论】：
-
它可能是标准模式与怪癖模式的问题。也许出于某种原因，您的 IE11 进入了怪癖模式，这就是性能缓慢的原因。试试看IE11是在什么模式下运行的。
-
nop，用 javascript:window.alert('You are in ' + (document.compatMode==='CSS1Compat'?'Standards':'Quirks') + 'mode.') 和响应是标准模式......就像预期的那样
-
顺便说一句：强制使用开发工具充当文档模式 =10 解决了性能问题...但似乎不是一个很好的解决方案（我必须从页面定义对用户透明）
-
很奇怪。也许您可以举一个导致问题的代码示例？编辑问题并显示代码，如果不是太繁琐的话。
标签： javascript internet-explorer