快速提示：
在表格及输入框多时，要小心 <th> 标记引起IE性能问题。
如遇上IE页面中输入框对键盘鼠标反应缓慢，请检查表格上部是否使用了<th>标记，并试着改为<td>看看。
故事是这样开始滴……
客户时有反映，有一个页面反应速度特别慢，几乎无法输入，这个页面主要部分是一个表格，输入预算数，纵向是预算条目，横向按12个月份展开并求合计。
因为不解决这页面的性能问题，这功能就几乎无法使用，于是，决定马上解决它。打开这个页面，测试，在预算项目不多时，很正常。在预算表比较大（大约150个子项）时，点一个输入框，要5秒左右才出现输入光标。
首先判断是否是JS脚本引起的，这是最常见情况。将JS事件都删了，测试，故障依旧。
看来是页面元素太多引起的问题了，试着删了一些不必须的input 元素，因为删不了太多，测试发现故障依旧。
也许是table 格子数太多？试着合并了一半的td，还是没什么效果。
初步判断是IE在处理2000个左右的input时性能不佳。如果是这原因，那这个页面基本没有改进的余地了，开始绝望，放弃。
第二天，心有不甘，写了一个含3000个input的页面，发现页面速度很正常。那么是table的问题了，那就写了一个100*20的table，每格里放一个input，测试，页面速度正常。这个现象让我兴奋，看来问题不是没有解决的可能，但困惑来了，到底是什么引起性能低下？
将性能低的页面中，table里含输入框部分的行拷贝到一个干净的页面，看看是否是table和页面引起问题，还是tr td里各种属性引起问题，结果发现，即使有这么多tr，仍然正常。 看来问题在table 的头上了。
Table由 thead 和tbody两部分组成，删去thead部分，故障现象消失。
继续研究，做了N次测试后，惊奇的发现，将th 改为td 就可以了。
总结：
这真是个典型的脚痛医头的处理办法，解决的办法出乎意料。
网上简单查了下，没发现相关文章。也许是ie对th的处理有些问题吧。
在ie6 ie7下测试现象基本一致。
性能问题处理起来真是耗时，足足费了5个小时，其中有90%的时间在测试，起码一半时间在等待,。
不要轻易放弃，成功有时就在于再坚持一下。
但也别一条路走到黑，峰回路转往往是因为你在合适的地方先转弯了。
补充一下，有可能是因为采用了固定表头效果的式样引起的性能问题，因为时间关系，没来得及再研究了。