HTML 本身不消耗 CPU，真正影响性能的是 JavaScript 执行、DOM 操作和渲染流程；内联事件处理器、innerHTML 批量插入、自定义元素初始化及频繁 DOM 访问均易引发主线程阻塞。
HTML 里根本没有“HTML 函数”
浏览器不会执行所谓“HTML 函数”——<div>、<button>、onclick 属性本身不消耗 CPU；真正跑代码的是 JavaScript。很多人搜“HTML 函数吃 CPU”，实际想问的是：写在 HTML 里的 JS（比如内联 onclick="doSomething()"）或 DOM 操作是否拖慢页面。
内联事件处理器（onclick、oninput 等）为什么容易卡
不是语法本身耗资源，而是它常诱发低效行为：
- 每次触发都新建函数作用域，频繁调用时 GC 压力上升（尤其在循环渲染的列表里写
onclick="handleClick('' + id + '')"） - 无法复用或提前编译，V8 等引擎难优化，比外置
addEventListener多一层字符串解析开销 - 绑定后无法轻松解绑，容易引发内存泄漏（比如组件卸载了但监听还挂着）
- 示例对比：
<button onclick="alert('bad')">点我</button><br><button id="good-btn">点我</button><br><script>document.getElementById('good-btn').addEventListener('click', () => alert('good'));</script>
innerHTML 批量插入大量 HTML 字符串会明显卡顿
这不是“HTML 解析慢”，而是浏览器必须同步完成：字符串解析 → 构建 DOM 节点 → 计算样式 → 布局 → 绘制。只要内容超过几百节点，主线程就可能阻塞几十毫秒：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 避免在滚动、输入等高频事件里反复设
innerHTML（比如实时搜索建议列表） - 改用
document.createElement+appendChild或DocumentFragment批量操作，减少重排重绘次数 - 现代框架（React/Vue）底层也绕不开这个原理，只是封装了 diff 和批量更新逻辑
- 注意：
textContent不触发解析，纯文本插入几乎无开销
自定义元素（customElements.define）和 Web Components 的初始化成本
定义阶段（define）基本不耗 CPU，但首次实例化（如 <my-chart></my-chart>）可能很重：
立即学习“前端免费学习笔记（深入）”；
- 构造函数执行、
connectedCallback触发、内部 Shadow DOM 渲染都会同步占用主线程 - 如果组件里直接调用
ctx.drawImage、JSON.parse大数据或递归生成 DOM，就会卡 - Chrome DevTools 的 **Performance** 面板里看
CustomElementConstruction和Layout时间，比看“HTML”标签更准 - 懒加载策略有效：用
IntersectionObserver延迟到进入视口再升级（customElements.upgrade()）
真正影响 CPU 的从来不是标签写法，而是你让 JS 在什么时机、以什么粒度、操作了多少真实 DOM 节点。DOM 是活的，不是模板字符串——每一次访问 offsetHeight、每一次修改 style.color，都可能触发回流。这点最容易被忽略。
