html嵌套过深会拖慢首屏渲染，因浏览器流式解析时每层嵌套均增加dom节点创建、样式计算和布局更新开销，超6层需警惕；应优先用语义化标签替代冗余div，script须加defer/async或置于前，首屏内容须前置以优化lcp。
为什么HTML嵌套过深会让首屏变慢
浏览器解析HTML是自上而下的流式过程，每多一层嵌套，就多一次DOM节点创建、样式计算和布局树更新。尤其在低端设备或弱网环境下，<div><div><div><p>...</p></div></div></div>这种结构会显著拖慢首次内容绘制（FCP）。
常见错误现象：DevTools里看到“Layout”阶段耗时突增，DOM树深度超过8层，移动端首屏渲染延迟明显。
- 用
devtools → Elements → 右键节点 → “Show DOM properties”查nodeDepth值，超过6就要警惕 - 能用
<section></section>、<article></article>、<nav></nav>替代的<div>堆叠，优先替换——语义标签本身不增加渲染开销 <li>避免在<code><table>单元格里嵌套<code><div>再套<code><span></span>，表格内部样式计算成本高，易触发重排script放哪儿才不卡住页面渲染
<script></script>默认同步执行，放在或未加属性的顶部，会强制暂停HTML解析，等脚本下载并执行完才能继续构建DOM树——这是白屏最常见的根源。关键不是“放底部”，而是“是否阻塞解析”：
- 内联脚本（如
<script>console.log(1)</script>）一定阻塞，除非加defer或async - 外部脚本加
defer：下载不阻塞，执行在DOM解析完成后、DOMContentLoaded前，顺序保证 - 外部脚本加
async：下载不阻塞，下载完立刻执行，不保序，适合统计、广告等独立逻辑 - 别在
里写没加defer/async的外部<script></script>，尤其别放在CSS<link>之前——这会让CSSOM构建卡住
preload用错反而拖慢加载
<link rel="preload">只提升下载优先级，不改变执行时机。滥用会导致带宽被非关键资源挤占，反而推迟真正需要的资源。判断标准很直接：这个资源是否在
DOMContentLoaded前就必须就位？如果不是，大概率不需要。- 首屏必用字体必须加
crossorigin：<link rel="preload" href="https://www.php.cn/link/2d084a4acd512e6314d6e8ae111b8205" as="font" type="font/woff2" crossorigin>，否则可能被拒绝使用 - 关键图片配合
loading="eager"：<link rel="preload" href="hero.jpg" as="image"> - 别对所有
<script></script>都preload——它不会推迟执行，还可能干扰HTTP/2优先级调度 - 旧浏览器直接忽略
preload，无副作用，但别指望它解决兼容性问题
HTML本身别动态拼接，服务端能定的尽量定死
所谓“优化加载速度”，常败在HTML生成阶段：模板引擎边渲染边请求API、条件化插入大量
if/else块、运行时拼接class名……这些都会延长TTFB，且让浏览器无法提前预解析后续资源。实操中容易被忽略的点：
- 服务端渲染（SSR）或静态生成（SSG）时，把能确定的结构、class、
data-属性全写死，别留一堆JS runtime patch - 避免在HTML里用
@import引入CSS——它串行加载，破坏并行能力；改用多个<link rel="stylesheet"> - 检查老项目是否有
grep -r "@import" src/，尤其是主题切换逻辑里藏着的深层@import - 内联关键CSS要克制：超过15KB就该外链，否则解析器卡在文本扫描阶段，DOM构建起点被延迟
真正卡顿的地方，往往不在你写的JavaScript里，而在HTML被浏览器读到第一行就开始的解析路径上。结构设计不是“写得漂亮就行”，而是每一层嵌套、每一个
script位置、每一处preload选择，都在悄悄决定首屏能否快100ms。 - 内联脚本（如
