HTML标签结构不是“写出来就行”，嵌套过深、语义混乱、冗余包裹会直接拖慢DOM构建和样式计算，首屏渲染延迟往往就出在这里。
避免超过6层的嵌套浏览器解析HTML是流式自上而下进行的，每多一层嵌套，就多一次节点创建+样式匹配+布局计算。移动端或低端设备上，<div><div><div><div><p>这类结构会让首次内容绘制（FCP）明显变慢。
- 用 Chrome DevTools → Elements 面板右键任意节点 →
Show DOM properties 查看 depth 值，超过6就要警惕
- 能用
<section>、<article>、<header> 替代纯 <div> 堆叠的，优先替换——它们不增加渲染开销，还能简化CSS选择器
- 表格单元格里别再套
<div>：比如 <td><div class="wrapper"><p>...，这种结构极易触发重排
删掉无意义的包裹层和遗留标签
开发调试时随手加的 <div id="debug-wrapper">、空的 <span></span>、或者为兼容老版本硬塞的 <center>，都会让DOM树变胖，延长解析时间。
- 用
grep -r "<div.*class.*wrap\|debug\|temp" src/ 快速扫一遍项目，清理掉非生产必需的包裹
- 移除所有
<!-- 旧版兼容注释 --> 和 <!-- TODO: 后续优化 --> 类注释——它们虽不渲染，但要被解析器扫描，占带宽也占解析时间
- 检查是否在 Flex/Grid 容器外又包了一层
<div>：现代布局已足够健壮，多数情况下那层“保险”<div>纯属冗余
慎用
做布局，更别在里面嵌套语义化标签<table>用于数据表格没问题，但拿它做页面整体布局，或者在 <td> 里再塞 <section> + <aside>，会严重干扰浏览器的样式计算路径。表格单元格的样式继承规则特殊，嵌套后容易触发强制同步布局（Forced Synchronous Layout）。
立即学习“前端免费学习笔记（深入）”；
- 把表格布局全部替换成
display: grid 或 display: flex，尤其是响应式场景下更可控
- 如果必须保留表格（如后台报表），确保
<td> 内只放文本、<img> 或简单内联元素，不要出现块级容器嵌套
- 避免
<table><tr><td><div><div><p> 这类“表格+div堆叠”组合——这是首屏卡顿的高频模式
真正影响速度的，往往不是你写了什么功能，而是你多写了哪几层没用的标签。结构越干净，浏览器解析越快，后续JS操作DOM的成本也越低——这点在长列表、富文本渲染等场景里特别明显。
浏览器解析HTML是流式自上而下进行的，每多一层嵌套，就多一次节点创建+样式匹配+布局计算。移动端或低端设备上，<div><div><div><div><p>这类结构会让首次内容绘制（FCP）明显变慢。
- 用 Chrome DevTools → Elements 面板右键任意节点 →
Show DOM properties查看depth值，超过6就要警惕 - 能用
<section>、<article>、<header>替代纯<div>堆叠的，优先替换——它们不增加渲染开销，还能简化CSS选择器 - 表格单元格里别再套
<div>：比如<td><div class="wrapper"><p>...，这种结构极易触发重排
删掉无意义的包裹层和遗留标签
开发调试时随手加的 <div id="debug-wrapper">、空的 <span></span>、或者为兼容老版本硬塞的 <center>，都会让DOM树变胖，延长解析时间。
- 用
grep -r "<div.*class.*wrap\|debug\|temp" src/快速扫一遍项目，清理掉非生产必需的包裹 - 移除所有
<!-- 旧版兼容注释 -->和<!-- TODO: 后续优化 -->类注释——它们虽不渲染，但要被解析器扫描，占带宽也占解析时间 - 检查是否在 Flex/Grid 容器外又包了一层
<div>：现代布局已足够健壮，多数情况下那层“保险”<div>纯属冗余
