html结构影响dom构建速度和关键渲染路径，嵌套过深（超6层）拖慢首屏，需用语义标签降深度、控节点数（
HTML文档结构本身不执行逻辑、不占用CPU，但它的写法直接决定浏览器构建DOM树的速度和关键渲染路径（CRP）的长度——对大型前端应用来说，这比JS执行慢更隐蔽、更难定位。
嵌套过深会拖慢首屏，尤其在SSR/静态生成场景下
大型应用常依赖服务端渲染或静态站点生成（SSG），输出的HTML往往包含大量嵌套容器。一旦平均嵌套深度超过6层，低端安卓机上FCP延迟可能突破200ms；Chrome DevTools里右键任意节点 → Show DOM properties 查看depth值，是最快验证方式。
- 用
<section></section>、<article></article>、<main></main>替代三层以上<div class="wrapper"><div class="content"><div class="inner">...</div></div></div>，语义标签本身不增加解析成本，还能压低DOM节点总数（移动端稳定底线是800以内） - 避免在
<table>单元格里嵌套<code><div>再套<code><span></span>——表格样式计算本就重，嵌套后极易触发同步Layout，SSR输出的HTML中这类结构最易被忽略 - Next.js / Nuxt等框架生成的HTML若含
data-reactroot或_next等标记，需确认其父容器是否无意中加深了嵌套层级 - 非关键脚本（统计、错误监控、第三方SDK）必须加
defer：保证执行顺序，又不阻塞HTML流式解析 - 纯交互逻辑（如按钮绑定）可用
async，但注意它不保序，且可能在DOMContentLoaded前运行；若操作DOM，大概率报Cannot read property 'addEventListener' of null - 真要操作首屏DOM的脚本（比如初始化轮播、表单校验），放
前；别信“DOMContentLoaded比load快”的模糊说法——实测晚100ms加载，LCP就晚100ms - 用
curl -I查响应头Content-Length，HTML体超15KB时重点检查内联资源占比 - 关键CSS外链+
<link rel="preload" as="style">，比内联更可控；预加载能抢占带宽，避免等HTML解析到对应<link>才发起请求 - 初始化数据改用
<script id="__NEXT_DATA__" type="application/json"></script>这类约定格式，而非拼接大段innerHTML，减少HTML解析器负担 - 首屏关键图必须加
fetchpriority="high"+loading="eager"（别用lazy） - 大于100KB的图片建议加
decoding="async"，把解码任务从主线程剥离 - SSR/SSG输出的HTML里，这些属性必须在服务端写死，不能靠客户端JS补——因为CRP优化窗口期就在HTML解析阶段
script位置不当会让整个CRP卡死，和打包体积无关
大型应用常把bundle.js拆得很细，但若<script src="vendor.js"></script>仍放在里，默认同步加载，浏览器就得停住HTML解析、下载、执行完才能继续——此时哪怕JS只有1KB，首屏白屏也会发生。
内联资源过大让TTFB和HTML解析双双变慢
大型应用有时为“首屏直出”把CSS或初始化数据塞进<style></style>或<script type="application/json"></script>，结果HTML体积飙到50KB+。这不仅拉高TTFB（服务器响应头发出时间），还会让浏览器解析器卡在文本扫描阶段，DOM构建起点被迫延后。
fetchpriority和decoding不是可选项，是移动端图片加载的开关
大型应用首屏常含轮播图、商品主图等LCP候选元素，但默认所有<img>都被标记为fetchpriority="low"，解码也同步进行——一张200KB的WebP图就能卡住主线程，滚动卡顿、首图延迟全由此起。
真正容易被忽略的，是结构优化无法靠工具自动发现：Lighthouse不会警告“你用了7层div”，Webpack也不会提示“你的index.html里<header></header>嵌在<div id="app">底下导致语义失效”。它得靠人去看DevTools里的DOM depth、去量TTFB、去比对LCP元素在HTML中的物理位置——越大的应用，越要回到HTML本身去调优。</div>
