IE11出现long running script无响应问题的原因及非配置修复方案咨询

问题复现特征 #

页面加载时调用预订数据接口，返回数据量小于10条时页面完全正常，数据量大于10条时随机触发IE11长时间运行脚本提示，伴随页面阶段性无响应。

核心成因 #

IE11采用单线程架构执行JS脚本与UI渲染，JS执行期间UI线程完全阻塞，默认触发长时间运行脚本提示的阈值为单线程连续执行JS超过5秒，或单段JS执行语句数超过500万条，该场景下触发问题的根因基本可以锁定为以下几点：

• 同步DOM操作开销过高：拿到大于10条的预订数据后，采用同步循环逐节点插入DOM的逻辑，IE11的DOM操作性能仅为Chrome等现代浏览器的1/50~1/100，每次DOM插入都会触发页面重排重绘，数据量上来后连续执行时间很容易超过阈值
• 遍历逻辑未做IE11兼容优化：IE11下Array.prototype.forEach、Array.prototype.map等遍历方法的性能比普通for循环低30%以上，如果循环内部存在重复DOM查询、重复属性计算等逻辑，会进一步拉长执行时间
• 无数据量管控逻辑：未做分页、懒加载等限制，不管接口返回多少数据都一次性全量渲染到页面

前端侧可落地方案（无需修改客户端浏览器/系统配置） #

1. 优化渲染逻辑降低开销 #

• 批量插入DOM：使用document.createDocumentFragment()文档片段，把所有生成的预订数据DOM节点先插入到片段中，最后一次性把片段插入到真实DOM，仅触发1次重排，可降低90%以上的DOM操作开销
• 替换低性能遍历方法：将forEach/map等遍历逻辑替换为普通for循环，避免每次遍历的函数调用额外开销
• 提前缓存重复读取的内容：循环外提前缓存DOM容器、固定计算属性等，不要在循环内部执行querySelector、重复计算相同属性的逻辑

2. 时间分片分块渲染 #

如果数据量较大无法单次批量渲染，可采用时间分片策略，每渲染少量数据就把执行权还给UI线程，避免JS连续执行时间过长，示例代码如下：

// 分块渲染预订数据示例
const renderOrderList = (orderData, batchSize = 2, startIndex = 0) => {
  const fragment = document.createDocumentFragment()
  const endIndex = Math.min(startIndex + batchSize, orderData.length)
  // 单次渲染batchSize条数据
  for (let i = startIndex; i < endIndex; i++) {
    const orderItem = document.createElement('div')
    orderItem.className = 'order-item'
    orderItem.textContent = `${orderData[i].orderNo} - ${orderData[i].time}`
    fragment.appendChild(orderItem)
  }
  document.getElementById('order-container').appendChild(fragment)
  // 还有剩余数据则延迟20ms渲染下一批，让出UI线程
  if (endIndex < orderData.length) {
    setTimeout(() => renderOrderList(orderData, batchSize, endIndex), 20)
  }
}
// 调用渲染
renderOrderList(apiReturnOrderList)

3. 从源头控制单次渲染数据量 #

• 优先对接接口分页：后端支持的情况下调整接口逻辑，单次最多返回10条预订数据，前端增加分页控件供用户翻页查看
• 增加懒加载/虚拟滚动：如果无法做接口分页，可实现滚动懒加载，仅当数据进入可视区域时再渲染；数据量超过50条时建议接入虚拟滚动组件，仅渲染可视区域内的少量节点，从根本上避免大数据量渲染性能问题

4. IE11专属降级处理 #

针对IE11单独关闭非必要的交互动画、复杂样式计算逻辑，降低单条数据渲染的额外开销。

内容的提问来源于stack exchange，提问作者Swayam Mohanty