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