我希望列是固定大小(可由用户控制),而不是垂直或水平增长/缩小.因此,在视觉上,特定表格单元格的内容将在一行上,并且溢出在单元格的末尾被切断.
在大型桌面上的Chrome中进行性能分析,主要的性能杀手是溢出:隐藏.
我已经尝试将每个单元格的内容放在输入中,因为这会复制相同的视觉行为,但这会产生类似的性能影响.
人们建议什么来提高性能?
如果有必要,我不必使用表格标签,但如果可以实现良好的性能,则更愿意坚持使用表格标签.
更新1:我已经包含了一个演示性能问题here的文件.警告文件相当大(25MB)并且会降低计算机速度.默认情况下,表没有溢出设置为隐藏,并且一旦表已加载(可能需要一段时间)浏览器性能相对平稳.
但是,如果您编辑该文件并取消注释第12-15行,然后将其打开.你会看到在加载桌面后的浏览器响应速度明显较慢.
解决方法
一旦一个单元格或一个单元格中的div获得一个强制它单独绘制单元格的属性,它就需要大约300毫秒而不是100毫秒来绘制(这会导致UI对我的情况感觉非常缓慢).
两个属性中的任何一个(位置:相对或溢出:隐藏)都会导致我的问题,如果单元格文本对于固定宽度列太宽,则删除它们会优化速度但会导致文本溢出.
即使在绘制表格之后,也会发生减速,因为我在表格中动态弹出一个绝对的div.在分析javascript(使用(新日期).getTime())时,在javascript中与表无关的位置测量的减速.
>将所有单元格内容放在span元素内(因此可以测量内容的offsetWidth而不是包含块元素的宽度).
>将行附加到文档后,测试每个span.offsetWidth是否大于列宽,如果是,则将“overflow:hidden”添加到包含块的样式(或通过类).
>对于某些列,可以跳过上面的1和2(如果已知单元格内容永远不需要剪裁).
注意事项:
>仅针对iOS5 Safari进行测量(我没有介绍任何其他浏览器).
>为我们工作,因为我们动态创建表行(使用javascript处理您的示例会很慢?).
>我们数据的大多数单元格不会溢出(只需要稀疏地剪切 – 只有有限数量的单元格).
>受损的初始页面加载(页面中表格的生成从80ms到800ms).
>但是加速了动态组合弹出窗口(340ms到130ms),提供了更好的键盘响应能力.
对于您的情况,可能快速首先使用可变宽度列,测量所有列的offsetWidth,将列宽设置为像素宽度并设置溢出:仅在列的offsetWidth大于您将用于的像素宽度的列上隐藏柱.