老旧浏览器HTML操作卡顿主因是渲染与JS引擎陈旧，如IE8不支持CSS3选择器致querySelectorAll遍历DOM；验证需看Performance面板中Recalculate Style/Layout占比超60%；兼容须降级：拆解选择器、用DocumentFragment批量插入、避免强制同步布局。
HTML 函数在老旧浏览器运行慢不是硬件问题
是渲染引擎和 JavaScript 引擎太老，不是你电脑太旧。哪怕换最新 CPU，IE8 里跑 document.querySelectorAll 依然卡顿——它压根没实现 CSS3 选择器的高效解析，全靠遍历 DOM 树模拟。
哪些 HTML 相关操作在老浏览器里特别拖慢
所谓“HTML 函数”，实际多指 DOM 操作 API。老旧浏览器（如 IE8–10、Android 4.3 WebView）对以下行为响应极差：
-
getElementsByClassName在 IE8 中不支持，垫片实现常退化为全量getElementsByTagName("*")+ 字符串匹配 -
querySelectorAll在 IE8 中仅支持 CSS2 选择器，div[data-id="1"]或.item:nth-child(2)会直接抛错或返回空数组 - 频繁调用
innerHTML赋值会触发完整 DOM 重建，老引擎无增量更新机制，100 行 HTML 可能卡顿 300ms+ -
offsetHeight/getBoundingClientRect()触发强制同步布局（reflow），老浏览器 layout 算法低效，连读两次就明显掉帧
怎么验证是不是引擎瓶颈而不是硬件
开开发者工具（F12），切换到 Performance / Timeline 面板，录制一次操作：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 如果
Recalculate Style和Layout占比超 60%，基本确定是引擎能力不足 - 看 JS Call Stack：若大量时间耗在
anonymous function里反复调用getElementById，说明代码没做缓存，但底层仍是引擎慢 - 对比 Chrome 同一页面：若 Chrome 执行
document.createDocumentFragment()耗时 0.2ms，IE11 耗时 8ms，差距来自 V8 vs Chakra 的编译优化层级，非 CPU 主频差异
真要兼容，绕不开的三个降级动作
不改引擎，只能改用法。关键不是“写得更优雅”，而是“让老引擎少干活”：
立即学习“前端免费学习笔记（深入）”；
- 把
document.querySelectorAll(".list li a")拆成document.getElementById("list").getElementsByTagName("a")，避开复杂选择器解析 - 批量 DOM 插入前，先用
document.createDocumentFragment()收集节点，再一次性 append，避免多次 layout - 读取布局信息（如
offsetTop）前，确保 DOM 已静止；避免“读-改-读-改”循环，老浏览器每次读都会重算样式树
最麻烦的点往往不在语法兼容，而在于老引擎对事件委托、CSSOM 访问、甚至 typeof null 的处理都带隐式开销——这些细节不会报错，但会让交互延迟从 16ms 涨到 200ms。
