页面加载与关键渲染路径
一、导读
| 定义： | 说明从用户在地址栏发起导航到首屏主要内容可见期间，浏览器与服务器各自承担的工作；阐明关键渲染路径（Critical Rendering Path，CRP）的含义及常见阻塞点。 |
| 代码块 | 含 HTML 注释式要点与配置示意；与《网络层》《构建与运行》《性能与可观测性》交叉处会在正文点名。 |
| 适用场景 | 首屏时间过长、白屏明显、LCP 不达标、需兼顾 SEO 与 CSR/SSR、静态托管下的深层链接（deep link）。 |
学习目标：能够手绘或通过 Network 导出CRP 依赖关系（文档 → 阻塞 CSS → 阻塞脚本 → 字体 → LCP 资源）；掌握
defer、async、type="module"对 HTML 解析的影响差异；明确dns-prefetch、preconnect、preload、prefetch各自缩短的是路径上的哪一段延迟。
篇幅边界：本文不能替代服务端性能治理，但会标明必须由后端、CDN 或网关解决的瓶颈。
二、导航时间轴（与工具面板可对齐）
下列阶段为教学用划分，名称可能与 Lighthouse、Tracing 中的标记略有差异，但顺序可供心智建模：
| 序号 | 阶段 | 说明 |
|---|---|---|
| 1 | 导航启动 | 用户提交 URL、点击链接或脚本赋值location。 |
| 2 | 重定向与 DNS | HTTP 重定向链、DNS 解析。 |
| 3 | 连接与 TLS | TCP 握手；HTTPS 下尚有 TLS。 |
| 4 | TTFB | 首个 HTML 字节到达客户端（含服务端排队与边缘缓存）。 |
| 5 | 下载 HTML | 字节流进入 HTML 解析器。 |
| 6 | 构建 DOM（递增） | 解析 token，构建 DOM；遇到脚本与样式时需遵守阻塞规则（见第三节）。 |
| 7 | CSSOM | 外部样式表下载并解析；与 DOM 共同构成渲染树所需输入。 |
| 8 | 布局与绘制（首帧） | 首次Layout / Paint（及合成），用户可能见到FP/FCP等更早的子指标（工具依赖）。 |
| 9 | 子资源与脚本后续执行 | 图片、字体、defer/async/module脚本；LCP 元素往往在主体资源就绪后才绘制完成。 |
结论：首屏优化并非「压缩一张大图」即可奏效，而应缩短上述链条中每一段的关键路径耗时。
三、脚本与 HTML 解析：阻塞关系总表
| 写法 | 对解析器的典型影响 | 执行次序（直觉） |
|---|---|---|
<script src>（无defer/async） | 阻塞解析：下载完毕后立即执行，执行结束后方可继续向下解析 | 按文档顺序 |
defer | 并行下载，推迟至文档解析完成之后、DOMContentLoaded事件触发顺序之前执行（规范约束顺序） | 按文档中出现顺序 |
async | 并行下载，下载完成后尽快执行，与文档顺序弱相关 | 完成先后不确定 |
type="module" | 默认defer语义；模块依赖图解析后再执行 | 按模块图与文档顺序约束 |
<!-- 正确示例——非关键脚本使用 defer --><scriptsrc="/analytics.js"defer></script><!-- 错误示例——在 head 内放置体积庞大的同步脚本且无拆分策略， 将推迟 body 解析与后续资源发现 --><scriptsrc="/legacy.bundle.js"></script>补充：若必须在文档早期插入内联 JSON 配置，应严格控制体积，并评估其对 HTML TTFB 与缓存策略的影响。
四、CSS：渲染阻塞资源
定义：默认情况下，外部样式表会阻塞渲染（以避免 FOUC，即无样式内容闪现）。实践中可采用：体量可控的关键 CSS 内联（须权衡缓存与 HTML 体积）、异步加载非关键样式（具体手法依团队规范，常见如media技巧或preloadas style）等策略。
注意：将整个站点样式悉数内联至 HTML，通常会削弱缓存效益、放大文档体积，须用数据验证取舍。
五、字体与@font-face
若采用font-display: block，部分浏览器可能在字体就绪前暂不绘制文本（FOIT），不利于LCP与可读性。生产环境更常见的是在swap、optional等取值之间权衡。
六、如何绘制 CRP 依赖图
操作示意：
- 在 DevToolsNetwork中选中文档（document）请求，确认状态码与体积。
- 根据Initiator、Priority字段，列出CSS、同步 JS、字体、LCP 候选图片的依赖顺序。
- 自检：是否存在过长串行链（例如文档末尾才发现 LCP 图片）？是否误对首屏图片使用
loading="lazy"？是否缺少width/height引发额外布局工作？
// 自检清单（建议在评审模板中逐项勾选） □ HTML 文档体积是否在合理范围？ □ 阻塞渲染的 CSS 数量与体积是否可控？ □ head 内是否存在不必要的同步脚本？ □ LCP 资源是否在文档前部即可被发现？ □ 是否为第三方图片域名配置了适当的 preconnect？七、资源提示（侧重「加载阶段」）
以下策略与《性能与可观测性》一致，此处强调其与CRP的衔接：
| 指令 | 作用 |
|---|---|
dns-prefetch | 仅提前解析 DNS，成本低，收益相对有限。 |
preconnect | 提前完成 DNS + TCP + TLS，适用于即将请求的第三方源（身份认证、支付、字体 CDN 等）。 |
preload | 声明当前导航关键路径上即将使用的资源（关键字体须配合crossorigin，首屏大图等）。 |
prefetch | 提示浏览器在空闲时获取下一导航可能用到的资源，优先级较低。 |
<linkrel="preconnect"href="https://cdn.example.com"crossorigin/><linkrel="preload"as="image"href="/hero.avif"fetchpriority="high"/>反例：对数十张非关键图片一律preload，将与LCP 候选资源争抢带宽，往往适得其反。
八、TTFB 与服务端、边缘设施
慢 TTFB的常见成因包括：应用冷启动、数据库查询缓慢、SSR未命中缓存、源站距用户地理跨度过大等。前端可通过BFF 聚合、边缘缓存片段（视架构而定）协助缓解，但SQL 与后端瓶颈须由服务端治理。
九、CSR、SSR、SSG 对首屏的含义
| 模式 | 首屏 HTML 特征 | 常见取舍 |
|---|---|---|
| CSR | 多为壳层与占位 | SEO、LCP 风险较高；依赖骨架屏与并行数据请求 |
| SSR | 首屏 HTML 含主要内容 | TTFB 可能上升；仍需下载并执行 hydration 代码 |
| SSG | 构建阶段生成静态 HTML | 动态数据常依赖 ISR 或客户端补充 |
十、验收：实验室与外场
- 实验室（Lab）：使用 Lighthouse Performance 中的Opportunities / Diagnostics，逐项对照 CRP。
- 外场（Field）：通过Chrome UX Report、自建RUM（如
web-vitals）观察LCP 子部分（含 TTFB、元素渲染延迟等）在分位数上的表现。
十一、结语
页面加载性能的本质，是识别并缩短关键渲染路径上的串行依赖。建议读者在阅读本篇后，结合《性能与可观测性》中的LCP 拆解一并运用：前者给出路径模型，后者给出量化标尺与验收语言，便于与后端、运维及 CDN 厂商对齐职责边界。
