从输入 URL 到页面展示：浏览器与网络的完整协作

一句话结论（30s）

从输入 URL 到页面展示要经过 DNS、TCP、TLS、HTTP、解析渲染七个阶段——因为每个阶段都有各自耗时（DNS 20-120ms、TCP 1 RTT、TLS 1-2 RTT、HTML 解析 50-500ms），所以 Web 性能优化本质就是逐阶段压缩这些耗时。

核心原理（2min）

• 网络侧：解析 URL → DNS 解析（域名→IP）→ TCP 三次握手 → TLS 握手（HTTPS）→ 发送 HTTP 请求 → 服务端返回响应。
• 渲染侧：解析 HTML 建 DOM 树 → 解析 CSS 建 CSSOM 树 → 合成 Render Tree → 布局（Layout）→ 绘制（Paint）→ JS 执行（可能触发回流/重绘）。
• 关键概念：回流（Reflow，改布局属性，昂贵）vs 重绘（Repaint，只改颜色，较便宜）；批量改 DOM 用 DocumentFragment 减少回流次数。

思考：为什么面试官爱问这道「从输入 URL 到页面」的题？——因为它是一条「贯穿网络 + 浏览器」的主线，任何一个环节都能深挖。DNS 缓存命中没有、TCP 握手几次、HTTPS 证书怎么验证、DOM 和 CSSOM 谁先出来、JS 阻塞不阻塞解析……你能把这条链讲清楚，等于同时证明了自己懂网络协议、懂浏览器内核、懂性能优化。

底层深入（5-10min）

全流程

1. 浏览器解析 URL（提取协议、域名、端口、路径）
2. DNS 解析（域名 → IP）
3. TCP 三次握手（与目标 IP 建立连接）
4. TLS 握手（如果是 HTTPS，协商加密密钥）
5. 发送 HTTP 请求
6. 服务器处理并返回 HTTP 响应
7. 浏览器解析 HTML → 构建 DOM 树
8. 解析 CSS → 构建 CSSOM 树
9. 合成 Render Tree → 布局（Layout）→ 绘制（Paint）
10. JavaScript 执行（可能修改 DOM/CSSOM，触发重绘/回流）

各阶段优化策略

思考：为什么优化策略都围绕「减少往返次数」和「压缩等待时间」？——因为整条链的耗时大头是「等待」而非「计算」。DNS 查询、TCP/TLS 握手、HTTP 往返，每一步都是「发一个请求、等一个响应」的 RTT，叠加起来就是几百毫秒。所以优化方向高度统一：要么提前做（dns-prefetch、Keep-Alive）、要么并行做（HTTP/2 多路复用）、要么一次做完（TLS 1.3 的 1-RTT）。

关键概念：回流（Reflow）vs 重绘（Repaint）

• 回流：修改影响布局的属性（width/height/position/display）→ 浏览器重新计算布局 → 重新绘制 → 昂贵
• 重绘：只修改颜色/背景等不影响布局的属性 → 只重新绘制 → 较便宜

批量修改 DOM 时，用 document.createDocumentFragment() 在内存中构建好再一次性插入——减少回流次数。

思考：为什么回流比重绘「昂贵」？——因为回流会引发「连锁重排」。改了 width 会牵动兄弟节点、父节点乃至整个页面的布局，浏览器要重新计算几何信息（位置、尺寸）再重绘；而重绘只重新上色，不碰布局。所以优化口诀是「尽量批量改、尽量改不触发布局的属性」，用 DocumentFragment 把多次 DOM 操作合并成一次插入。

总结

从 URL 到页面，涉及 DNS、TCP、TLS、HTTP、HTML/CSS 解析、JS 执行 7 个阶段。理解每个阶段的耗时和优化策略，是 Web 性能优化的基础。

章末提问

追问 1：从输入 URL 到页面展示，经历了哪些关键阶段？

回答思路：结论先行——分网络侧和渲染侧两段，共约七个阶段。因为网络侧是「DNS 解析 → TCP 三次握手 → TLS 握手 → HTTP 请求/响应」，渲染侧是「解析 HTML 建 DOM → 解析 CSS 建 CSSOM → 合成 Render Tree → 布局 → 绘制 → JS 执行」；每个阶段都有各自耗时，是性能优化的着力点。

追问 2：回流（Reflow）和重绘（Repaint）的区别？如何减少回流？

回答思路：结论先行——回流是布局变化引起的重新计算（昂贵），重绘只是重新上色（较便宜）。因为改 width/height/position/display 会触发浏览器重算布局并连锁影响其他节点，而只改 color/background 不碰布局；减少回流的方法是批量修改 DOM（用 DocumentFragment 一次性插入）、避免频繁读写布局属性。

追问 3：为什么 TLS 握手比 TCP 握手更慢？如何优化？

回答思路：结论先行——因为 TLS 在 TCP 之上还要额外做 1-2 次 RTT 的密钥协商。因为 TCP 三次握手 1 个 RTT 就建立连接，而 TLS 还要交换证书、协商加密密钥（TLS 1.2 需 2 RTT），所以更慢；优化靠 TLS 1.3（握手压到 1-RTT）+ Session Ticket/会话复用，复用已协商的密钥直接跳过握手。