html结构设计直接影响浏览器解析速度、首屏渲染和内存占用；嵌套过深（超6层）、脚本阻塞、内联资源过大（超15kb或50行）、缺少preload是四大性能瓶颈。
HTML结构设计不是“写得语义化就完事”，而是直接决定浏览器解析速度、首屏渲染时机和内存占用的关键变量。结构不合理，再好的CSS或JS也救不回白屏和卡顿。
嵌套过深导致FCP延迟
浏览器解析HTML是流式自上而下进行的，每多一层嵌套，就多一次DOM节点创建+样式计算。移动端尤其敏感：<div>
<div><div><div><p>按钮</p></div></div></div>这种7层结构，会让首次内容绘制（FCP）比扁平结构慢200ms以上。
<ul>
<li>用<code>DevTools → Elements → 右键节点 → “Show DOM properties”查nodeDepth，超过6层就要重构
<section></section>、<article></article>、<main></main>替代<div>堆叠的，优先替换——它们不增加渲染开销，还让CSS选择器更短
<li>表格布局里嵌套<code><div>是重灾区：<code><table><tr><td><div><span>文字</span></div></td></tr></table>会触发整行重排，改用flex或grid布局
<script></script>位置错误引发渲染阻塞
没加async或defer的<script src="app.js"></script>放在里，浏览器必须暂停HTML解析、下载并执行完脚本，才能继续构建DOM树——这是首屏白屏最常见原因。
- 统计、埋点、第三方SDK脚本一律加
defer：保证顺序执行，又不阻塞解析 - 纯交互逻辑（如
document.addEventListener('click', ...)）可用async，但注意它可能在DOMContentLoaded前执行，DOM还没就绪 - 真要操作DOM的脚本，放
前最稳妥；别信“放里加defer就行”，实测晚100ms加载，首屏就晚100ms - 绝对禁用
document.write()：现代浏览器已废弃，执行即清空文档流，本地双击打开时极易报错
内联资源过大拖慢TTFB和解析
HTML文件本身含大段<style></style>或<script></script>，不仅拉长传输时间（TTFB变高），还会让HTML解析器卡在文本扫描阶段，延迟DOM构建起点。
- 单个
<style></style>或<script></script>内联代码超50行，基本可判定为维护风险+性能隐患，应提取为独立文件 - 用
curl -I看响应头Content-Length，HTML体大于15KB时，重点检查内联资源占比 - 关键CSS可内联，但必须控制在14KB以内；超出后反而阻塞渲染，得不偿失
缺少preload让关键资源加载滞后
浏览器默认只对HTML中直接出现的链接做预加载，像首屏字体、关键CSS、Hero图这些依赖关系隐含的资源，不加提示就只能等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">正常引入 -
preload不是“提前加载所有东西”的开关，只对当前导航中「确定马上要用」的资源有效；乱加反而挤占带宽，拖慢真正关键的资源
真正卡顿的地方，往往不在你写的JavaScript里，而在HTML被浏览器读到第一行时的结构选择——嵌套深度、脚本位置、内联体积、资源提示，这四个点任何一个没控住，首屏就注定慢。
