HTML结构影响首屏渲染效率：嵌套过深（>6层）拖慢DOM构建，script位置不当导致阻塞，内联资源超限延迟解析，缺少resource hint浪费带宽；四者任一缺失均降低性能。
HTML文档结构不是“写完能跑就行”的静态骨架，它直接决定浏览器解析、构建DOM、触发资源请求的节奏和效率。结构不合理，首屏渲染就卡在第一步。
嵌套过深导致DOM构建变慢
浏览器是流式解析HTML的，每多一层嵌套，就要多创建一个节点、多做一次样式计算、多走一次父节点引用链。移动端或低端设备上，<div><div><div><div><p>这种结构会让首次内容绘制（FCP）延迟200ms以上。
- 用
devtools → Elements → 右键节点 → “Show DOM properties”查看nodeDepth，超过6层就要警惕 - 能用
<section>、<article>、<header>替代<div>堆叠的，优先替换——语义标签不增加渲染开销，还能缩短CSS选择器匹配路径 - 表格单元格内嵌套
<div>是重灾区：<td><div><span>…</span></div></td>会显著拖慢重排（reflow）
<script> 放错位置直接阻塞渲染
未加修饰的 <script src="app.js"></script> 在 <head> 或 HTML 中间出现，浏览器会立刻暂停解析，等 JS 下载并执行完才继续——这是白屏最常见的根源。
- 非关键脚本（统计、埋点、第三方SDK）一律加
defer：下载不阻塞，DOM 解析完再按顺序执行 - 完全独立、无依赖的脚本（如广告加载）用
async；但别对业务主逻辑用它，执行时机不可控 - 真要操作 DOM 的初始化代码，
<script>必须放</body>前，而不是靠DOMContentLoaded等——晚100ms加载，首屏就晚100ms - 绝对禁用
document.write()：现代浏览器已废弃，本地双击打开时会清空整个文档流
内联资源过大拖慢TTFB和解析起点
服务器返回的 HTML 如果含大段 <style> 或 <script>，不仅拉长传输时间（TTFB升高），还会让 HTML 解析器卡在文本扫描阶段，推迟 DOM 构建起点。
立即学习“前端免费学习笔记（深入）”；
- 单个
<style></style>或<script></script>内联代码超50行，基本可判定为性能隐患，应提取为外部文件 - 用
curl -I看响应头Content-Length，HTML 体大于15KB时，重点检查内联资源占比 - 关键 CSS 必须内联，但原始体积建议 ≤14KB（gzip后约4–8KB），否则跨 TCP 包影响 TTFB
- 禁止在
<style>里写@import：它会触发额外 HTTP 请求，并阻塞 CSS 解析
缺少 resource hint 让关键资源“等通知”才加载
浏览器默认只对 HTML 中直接出现的链接做预加载，像字体、首屏图片、核心 JS 这些隐含依赖的资源，不加提示就只能等 HTML 解析到对应标签才发起请求，白白浪费空闲带宽。
- 首屏必用的字体加：
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>（注意crossorigin，否则字体可能被拒绝使用） - 关键 CSS 文件（如
base.css）在<head>里先<link rel="preload" as="style">，再用<link rel="stylesheet">正常引入 -
preload不是“提前加载所有东西”的开关——只对DOMContentLoaded前必须就位的资源有效，比如 Hero 图、首屏字体、核心 JS 模块 - 别对所有
<script>都preload：它不会推迟执行，反而可能挤占带宽，干扰真正关键的资源
真正卡顿的地方，往往不在你写的 JavaScript 里，而在 HTML 被浏览器读到第一行时，结构和资源声明就已经决定了后续所有环节的上限。嵌套、脚本位置、内联体积、resource hint 这四点，漏掉任意一个，优化都打折扣。
