核心是精准控制渲染边界与剥离无效计算：用<template>替代display: none管理非首屏内容，压平DOM深度，切断无关资源加载，并用DocumentFragment批量注入。
直接提升 HTML 组件在复杂应用中的渲染性能，核心不是“加更多逻辑”，而是「精准控制渲染边界 + 剥离无效计算」。多数卡顿来自无意识的 DOM 扩散、样式继承失控和首屏外内容过早参与构建。
用 template 替代 display: none 管理非首屏内容
很多人把长列表、折叠面板、Tab 页签的内容用 display: none 隐藏，以为“不显示=不消耗”。错——浏览器仍会解析、构建 DOM、计算 CSSOM，甚至为 display: none 元素生成渲染树节点（只是跳过绘制）。对含表格或 pre 的区块，这极易触发 OOM 或布局延迟。
- 改用原生
<template>标签包裹非首屏 HTML 片段，它完全不参与 DOM 构建，直到显式调用content.cloneNode(true) - 配合
IntersectionObserver在进入视口前 200px 触发克隆与挂载，避免滚动卡顿 - 注意：SSR 渲染时需服务端同步输出
<template>内容，否则客户端首次 hydration 会丢失结构
压平 DOM 深度，别让 CSS 继承拖垮 layout 阶段
DOM 深度超过 3 层，布局耗时会非线性上升——Chrome DevTools 的 Layout 面板能直接观测到这一拐点。问题不在语义标签，而在人为堆砌的包裹层：<div class="wrapper"><div class="inner"><div class="content">…</div></div></div> 这类结构在组件库或 SSR 模板中高频出现。
- 用
display: grid+grid-template-areas替代多层容器定位，1 层 DOM 实现相同视觉效果 - 清除浮动不用
<div class="clearfix">，改用::after { display: table; clear: both; } - 分隔线、图标+文字组合、状态边框等，优先用伪元素或 border 属性，而非新增 DOM 节点
- 验证方式：Elements 面板右键节点 → “Reveal in Elements Panel”，观察真实渲染树深度，而非源码缩进
HTML 解析阶段就切断无关资源加载
浏览器解析 HTML 时，遇到 <script> 和 <link rel="stylesheet"> 会暂停 DOM 构建。但更隐蔽的瓶颈是：脚本里动态创建的 <img>、<iframe> 或 fetch 请求，会在 DOM 构建完成后才触发，导致“看似空闲”的主线程突然被阻塞。
立即学习“前端免费学习笔记（深入）”；
- 首屏图片必须省略
loading="lazy"（默认eager），且带明确width/height或aspect-ratio，防止 CLS - 所有
<script>按依赖关系加属性：async（无 DOM 依赖）、defer（依赖 DOM 但不依赖其他脚本） - 动态插入的
<img>必须手动补loading="lazy"和尺寸，JS 创建的元素不会继承父级 lazy 行为 - 关键 CSS 只内联「首屏 DOM 节点实际用到的规则」，用 PurgeCSS 或手写 critical CSS，别内联整套框架样式
复杂 HTML 结构用函数式组件 + DocumentFragment 批量注入
直接拼接字符串后赋值给 innerHTML 看似快，但每次赋值都会触发完整 DOM 解析 + 重排；而频繁调用 createElement + appendChild 又带来大量 API 开销。折中解法是模块化 + 批量提交。
- 把组件拆成纯函数，如
renderHeader()、renderTableRows(data)，返回DocumentFragment而非字符串 - 使用
document.createDocumentFragment()作为中间载体，所有子节点先 append 到 fragment，最后单次appendChild到真实 DOM - 对万行表格等场景，按 500 行/批 +
setTimeout(r => r(), 0)让出主线程，避免连续重排阻塞 UI - 注意：
innerHTML +=是反模式，每次都会重建整个子树，必须累积后一次性写入
真正难的不是“怎么写更快”，而是判断哪部分该立刻渲染、哪部分该彻底隔离、哪部分连 DOM 都不该让它存在。这些决策点藏在 HTML 解析、CSSOM 构建、Layout 三个环节的交界处，漏掉任意一个，优化就只在表面打转。
