JSfiddle for proof
结论:不,大的 HTML 元素似乎不会对渲染大小或内存产生任何影响,但它们可能会导致古怪。
在我的小提琴中,我测试了向 DOM 添加不同数量的元素,测试了操作 DOM 元素所需的时间,并测试了进行基本数学运算(测试内存)所需的时间。
示例输出(在 Chrome 32 中):
前三个测试使用小元素,只改变元素的数量。他们将 10、350 和 1,000,000 个 0 大小的元素添加到容器元素中,然后运行测试。 DOM 和内存测试显示彼此几乎没有差异,这意味着 DOM 中的元素数量不会影响:
1) 通过 id 从 DOM 获取元素并编辑其内容所需的时间。
2) javascript 可用的内存。
Init reg1 显示了在容器中插入所有数据所用的时间,它后面和结束每个测试的数字是容器高度。这些数字表明,向 DOM 添加大量数据会减慢速度,尽管通常数量并不显着。请注意,使用如此多的 HTML 加载页面会比以这种方式加载更显着地减慢速度。
init1 reg10: 1.000ms (index):35
0 (index):37
init reg10: 7.000ms (index):38
DOM reg10: 34.000ms (index):48
mem reg10: 24.000ms (index):56
0 (index):58
init1 reg350: 1.000ms (index):35
0 (index):37
init reg350: 3.000ms (index):38
DOM reg350: 29.000ms (index):48
mem reg350: 25.000ms (index):56
0 (index):58
init1 reg100000: 229.000ms (index):35
0 (index):37
init reg100000: 705.000ms (index):38
DOM reg100000: 29.000ms (index):48
mem reg100000: 24.000ms (index):56
0
前三个测试使用大元素(1,000,000 宽和高),只改变大元素的数量。同样,它显示了与上述测试相同的内容。 DOM 速度和内存不受元素数量或大小的影响。
所有这些数字都与之前的测试基本一致,除了容器高度数字。由于这个数字在 init1 结束后立即发生变化并且与结束时的数字一致,我们知道 DOM 几乎是立即渲染的,没有明显的延迟。然而,在最后的测试中,我们超出了内存限制,它返回 -33554432 作为容器高度。这根本不会减慢它的速度。这就是我前面提到的怪癖。这些数字应该用于测试。我们不知道它在各种边缘情况下的表现如何,因此只能在必须使用它的地方使用它。
init1 huge10: 1.000ms (index):35
1000000 (index):37
init huge10: 2.000ms (index):38
DOM huge10: 29.000ms (index):48
mem huge10: 24.000ms (index):56
1000000 (index):58
init1 huge350: 1.000ms (index):35
33500000 (index):37
init huge350: 3.000ms (index):38
DOM huge350: 29.000ms (index):48
mem huge350: 24.000ms (index):56
33500000 (index):58
init1 huge100000: 227.000ms (index):35
-33554432 (index):37
init huge100000: 757.000ms (index):38
DOM huge100000: 28.000ms (index):48
mem huge100000: 24.000ms (index):56
-33554432
但作为一般规则,HTML 元素的大小不会影响内存或渲染时间。