html文档结构直接决定首屏渲染快慢，嵌套过深（超6层）、script位置不当、内联资源过大是首屏延迟主因；需用语义标签降深度、defer/async控脚本、精简内联资源。
HTML文档结构不是“写完能跑就行”的事——它直接决定首屏渲染快慢、DOM构建耗时、甚至移动端是否卡顿。嵌套过深、<script></script>放错位置、内联资源过大，这三类问题占首屏延迟的70%以上。
DOM树深度超过6层会明显拖慢FCP
浏览器解析HTML是流式自上而下进行的，每多一层嵌套，就多一次节点创建+样式计算。在低端安卓设备上，<div><div><div><div>
<p>这种结构会让首次内容绘制（FCP）延迟300ms以上。</p>
<ul>
<li>用DevTools → Elements → 右键节点 → “Show DOM properties”查<code>nodeDepth，超过6就要重构
<section></section>、<article></article>、<nav></nav>替代<div>堆叠的，优先替换——语义标签本身不增加渲染开销
<li>特别警惕<code><table>里套<code><div>再套<code><span></span>：单元格内样式计算成本高，嵌套后极易触发重排
<script></script>放在
<script></script>默认同步执行，浏览器必须停住HTML解析、下载并执行完脚本，才能继续构建DOM。这是白屏最常见的根源。
- 非关键逻辑（统计、埋点、第三方SDK）一律加
defer属性，保证执行顺序且不阻塞解析 - 纯交互脚本（如按钮绑定）可用
async，但注意它可能在document.body还没生成时就运行，容易报Cannot read property 'appendChild' of null - 真要操作DOM的脚本，必须放在
前——别信“DOMContentLoaded比load快”，实测晚100ms加载，首屏就晚100ms
内联<style></style>或<script></script>超阈值会拉长TTFB和解析时间
服务器返回的HTML如果含大段内联代码，不仅传输时间变长（TTFB升高），还会让HTML解析器卡在文本扫描阶段，推迟DOM构建起点。
-
<style></style>块超过1KB，必须拆成外部<link rel="stylesheet">；CSS-in-JS生成的内联样式同理 -
<script></script>内联代码超50行，基本就是维护风险+性能隐患，应提取为模块文件 - 用
curl -I看响应头Content-Length，HTML体大于15KB时，重点检查内联资源占比——本地大文件场景例外（如2万行记录页，内联样式反而更快）
真正难的不是知道该怎么做，而是判断“什么时候该破例”：比如本地巨型HTML页面，外链CSS反而比内联慢6秒；又比如某些老系统要求<script></script>必须在里初始化全局对象——这时候defer就失效了，得靠document.write兜底，但必须严格校验执行时机。
