卡顿根源在JavaScript执行、渲染压力或内存泄漏，而非HTML标签；关键因setInterval未暂停、长任务阻塞、visibilitychange误用、GPU纹理占用及第三方脚本后台运行等导致。

HTML 本身没有“函数”会直接导致切换标签页卡顿——卡顿根源在 JavaScript 执行、渲染压力或内存泄漏，而非 HTML 标签或静态结构。

为什么切换标签页时会卡顿？关键看 JS 执行状态

浏览器在标签页失焦（visibilitychange）时，会主动降频甚至暂停部分后台任务，但以下情况仍会拖慢切换体验：

• setInterval 或 requestAnimationFrame 在隐藏页持续运行（尤其未监听 document.hidden 做暂停）
• 长任务（>50ms）正在执行中，切换瞬间被强制打断并排队，造成 UI 响应延迟
• Web Workers 虽独立线程，但若频繁 postMessage + 主线程同步处理，仍可能阻塞页面可见性判断逻辑

visibilitychange 事件没用好，反而加重负担

很多人以为加了 visibilitychange 就万事大吉，但常见错误是：

• 在事件回调里触发重排（如读取 offsetHeight 后立即修改 style），导致强制同步布局
• 重复绑定未解绑，多个监听器叠加执行（尤其 SPA 动态加载模块时）
• 在 visibilitystate === 'hidden' 时仍调用 fetch 或 WebSocket.send，无意义占用网络与内存

正确做法是：失焦时清除动画帧、暂停轮询、释放 canvas 上下文、暂停音视频解码——不是只“打个标记”。

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

立即学习“前端免费学习笔记（深入）”；

硬件压力其实在内存和 GPU 纹理上，不在 CPU 核心数

多标签卡顿常被误判为“CPU 不够”，实际瓶颈更可能是：

• 每个标签页的 canvas 或 WebGLRenderingContext 占用显存，Chrome 对共享 GPU 内存有硬限制（通常 512MB–2GB，因设备而异）
• 大量 img 标签未设置 decoding="async" 或未用 loading="lazy"，失焦页仍在解码位图
• 第三方脚本（如广告、统计 SDK）在后台持续创建 IntersectionObserver 或监听 scroll，即使页面不可见也维持监听开销

可快速验证：打开 chrome://memory-internals，切标签观察 renderer 进程的 mem_footprint 是否陡增；或用 chrome://gpu 查看纹理内存是否接近上限。

真正影响切换流畅度的，是那些“看起来静止却暗中燃烧”的资源——比如一个隐藏的 video 元素仍在播放、一段未清理的 ResizeObserver 持续响应窗口变化、或者 20 个标签页各自维护着未销毁的 Map 缓存。这些比 HTML 结构本身重要得多。