动态插入DOM节点导致卡顿的主因是浏览器需重新计算CSS选择器匹配，尤其“从右到左”遍历的后代选择器（如.card-list div p span）在200个卡片渲染时会反复向上验证父级，引发CLS突增、掉帧和TTI延长。

为什么动态插入的 DOM 节点会让页面卡顿

不是因为 JS 执行慢，而是每次 innerHTML 或 appendChild 后，浏览器要重新计算所有 CSS 选择器匹配结果——尤其是那些“从右到左”遍历全量节点的选择器。比如你用 v-for 渲染 200 个卡片，而样式里写了 .card-list div p span，浏览器就得为每个 span 往上查父级，反复验证是否在 p、div、.card-list 里。

常见现象：CLS（累积布局偏移）突增、滚动掉帧、首次交互延迟（TTI）变长。

• 动态内容越多，后代选择器（空格分隔）性能衰减越明显
• [data-testid] 这类属性选择器在 dev 环境没问题，但上线后没剥离，就会在每次重排时触发全量 DOM 遍历
• 媒体查询里的选择器照样参与匹配，哪怕当前 viewport 不满足条件

怎么写 CSS 选择器才不会拖慢动态渲染

核心原则：让“关键选择器”（最右边那个）能快速定位目标元素，而不是靠层层往上验证。

• 用 .item 替代 .list li —— 类名查找是哈希 O(1)，后代选择器是线性扫描
• 避免 div#main，直接用 #main；ID 本身唯一，加标签名反而多一次 tagName 判断
• 禁用 * 和 [data-xxx] 在生产 CSS 中出现；如果必须保留测试属性，用 PostCSS 插件（如 postcss-data-attr）构建时自动移除
• 深嵌套如 article > section > header > h1 在 SPA 中插入新 article 时，会触发整条链路重匹配，换成 .article-header 更稳

HTML 结构怎么配合 CSS 做性能减负

语义化不只是 SEO 友好，更是减少选择器复杂度的物理基础。

htmlppt.skill

把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。

下载

• 用
  替代
  ，然后直接写 nav a —— 浏览器对原生标签的查找比 class 快一个数量级
• 避免无意义的包裹层：

  ...

  让 .content p 实际要扫三层无关 div
• 动态生成的列表，给容器加明确类名（如 js-card-container），CSS 写成 .js-card-container .card，不依赖 DOM 深度
• 慎用 display: contents：它会让父元素“消失”在可访问树和样式继承链中，某些选择器（如 :has()）行为不可预期

哪些优化手段容易被忽略但影响最大

没有报错、Lighthouse 也不标红，但真实用户感知明显。

• CSSOM 构建是阻塞的：哪怕一条 @media (min-width: 992px) { .hidden-on-mobile { display: none; } } 在小屏下完全不生效，它仍参与首屏 CSS 解析
• 用 link rel="stylesheet" media="print" 或外链独立文件隔离非关键样式，比内联 + 媒体查询更轻量
• 动态组件卸载时，别只删 DOM，检查是否遗留事件监听或未清理的 style 标签 —— 多余的样式规则会持续参与匹配
• 构建工具里开 purgeCSS 是基础，但要注意它可能误删动态 class（如 bg-${color}），得配 safelist