IE中的标记有可能引起性能问题

快速提示:

在表格及输入框多时,要小心 <th> 标记引起IE性能问题。

如遇上IE页面中输入框对键盘鼠标反应缓慢,请检查表格上部是否使用了<th>标记,并试着改为<td>看看。

故事是这样开始滴……

客户时有反映,有一个页面反应速度特别慢,几乎无法输入,这个页面主要部分是一个表格,输入预算数,纵向是预算条目,横向按12个月份展开并求合计。

因为不解决这页面的性能问题,这功能就几乎无法使用,于是,决定马上解决它。

打开这个页面,测试,在预算项目不多时,很正常。在预算表比较大(大约150个子项)时,点一个输入框,要5秒左右才出现输入光标。

首先判断是否是JS脚本引起的,这是最常见情况。将JS事件都删了,测试,故障依旧。

看来是页面元素太多引起的问题了,试着删了一些不必须的input 元素,因为删不了太多,测试发现故障依旧。

也许是table 格子数太多?试着合并了一半的td,还是没什么效果。

初步判断是IE在处理2000个左右的input时性能不佳。如果是这原因,那这个页面基本没有改进的余地了,开始绝望,放弃。

第二天,心有不甘,写了一个含3000input的页面,发现页面速度很正常。那么是table的问题了,那就写了一个100*20table,每格里放一个input,测试,页面速度正常。这个现象让我兴奋,看来问题不是没有解决的可能,但困惑来了,到底是什么引起性能低下?

将性能低的页面中,table里含输入框部分的行拷贝到一个干净的页面,看看是否是table和页面引起问题,还是tr td里各种属性引起问题,结果发现,即使有这么多tr,仍然正常。 看来问题在table 的头上了。

Table thead tbody两部分组成,删去thead部分,故障现象消失。

继续研究,做了N次测试后,惊奇的发现,将th 改为td 就可以了。

总结:

这真是个典型的脚痛医头的处理办法,解决的办法出乎意料。

网上简单查了下,没发现相关文章。也许是ieth的处理有些问题吧。

ie6 ie7下测试现象基本一致。

性能问题处理起来真是耗时,足足费了5个小时,其中有90%的时间在测试,起码一半时间在等待,

不要轻易放弃,成功有时就在于再坚持一下。

但也别一条路走到黑,峰回路转往往是因为你在合适的地方先转弯了。


补充一下,有可能是因为采用了固定表头效果的式样引起的性能问题,因为时间关系,没来得及再研究了。

原文地址:https://www.cnblogs.com/honghuamin/p/1101872.html