html结构深度超6层会显著拖慢fcp，dom节点应压至800以内；语义化标签可缩短css选择器路径、减少重排；脚本需用defer/async或置底以避免阻塞；关键资源须通过resource hint预加载。
HTML代码质量差，浏览器渲染就慢——这不是经验判断，而是可测量的事实。DOM深度超6层、冗余嵌套、语义缺失、资源加载顺序混乱，每一种都直接拖慢FCP、增加Layout耗时、放大Style Recalc开销。
DOM深度超过6层会显著拖慢首次内容绘制
浏览器解析HTML是流式自上而下进行的，每多一层嵌套，就多一次节点创建 + 样式匹配 + 布局计算。在低端安卓机或旧款iOS设备上，<div>
<div><div><div><p></p></div></div></div>这种结构会让FCP延迟200ms以上。
<ul>
<li>用Chrome DevTools → Elements面板右键任意节点 → <code>Show DOM properties查看nodeDepth值，≥7就要重构
<section></section>、<article></article>、<header></header>等语义标签本身不增解析开销，还能减少DOM节点总数，压到800以内是移动端渲染稳定底线<table> td div p这类路径是重灾区：表格单元格内样式计算成本高，嵌套后极易触发重排，尤其在flex容器里混用时
<h3>CSS选择器匹配性能被深层DOM结构严重放大</h3>
<p>浏览器解析CSS选择器是“从右往左”执行的。越靠右的部分（如<code>.title）匹配基数越大；越靠左的部分（如.card）决定向上回溯几层。DOM深度≥7时，“查父级是否有.body、再查其父级是否有.card”可能要穿越4个无意义div。
-
.wrapper .content p应简化为article p——语义标签让选择器路径更短，不是“好看”，是真省0.5ms/次 - 避免
div > div > div > input这类选择器：它不只慢，还暴露结构脆弱性；可用form input或.field input替代 -
:last-of-type等伪类完全依赖DOM层级关系，结构一乱，行为就不可控
script和内联资源位置不当直接阻塞关键渲染路径
<script></script>默认同步加载执行。放在或顶部时，浏览器必须暂停HTML解析、下载并执行完脚本，才能继续构建DOM树——这是首屏白屏最常见原因。
- 非必要逻辑（统计、埋点、第三方SDK）一律加
defer，确保按顺序执行但不阻塞解析 - 纯交互逻辑（按钮点击绑定）可用
async，但注意它不保证执行顺序，且可能在DOM未就绪时运行 - 真需要操作DOM的脚本，放
末尾——别信“DOMContentLoaded比load快”的模糊说法，实测晚100ms加载，首屏渲染就晚100ms - 单个
<style></style>或<script></script>内联代码超50行，基本可判定为维护风险+性能隐患，应提取为模块文件
resource hint缺失导致关键资源加载滞后
浏览器默认只对HTML中直接出现的链接做预加载。字体、关键CSS、首屏图片这些依赖关系隐含的资源，不加提示就只能等HTML解析到对应标签才发起请求，白白浪费空闲带宽。
- 首屏必用的字体，加
<link rel="preload" href="https://www.php.cn/link/2d084a4acd512e6314d6e8ae111b8205" as="font" type="font/woff2" crossorigin> - 关键CSS文件（如
base.css）在里用<link rel="preload" as="style">，再用<link rel="stylesheet">正常引入 - 首屏关键图必须加
fetchpriority="high"+loading="eager"；大于100KB的图片建议加decoding="async"
真正卡顿的地方，往往不在你写的JavaScript里，而在HTML被浏览器读到第一行时就已经埋下伏笔——结构越深，浏览器越累，用户越等。优化不是删标签，而是让每个标签都有不可替代的语义或布局责任。
