浏览器渲染流程：从输入域名到页面显示

浏览器渲染流程可以分成两条互相配合的链路：网络链路负责把服务器返回的 HTML、CSS、JavaScript 和图片下载回来；渲染链路负责把这些字节解析成 DOM、CSSOM、渲染树，经过布局、绘制、

## 目录 * [一、先看一张完整地图](#%E4%B8%80%E5%85%88%E7%9C%8B%E4%B8%80%E5%BC%A0%E5%AE%8C%E6%95%B4%E5%9C%B0%E5%9B%BE) * [二、输入域名后，浏览器先做什么](#%E4%BA%8C%E8%BE%93%E5%85%A5%E5%9F%9F%E5%90%8D%E5%90%8E%E6%B5%8F%E8%A7%88%E5%99%A8%E5%85%88%E5%81%9A%E4%BB%80%E4%B9%88) * [三、DNS 解析到底做了哪些工作](#%E4%B8%89dns-%E8%A7%A3%E6%9E%90%E5%88%B0%E5%BA%95%E5%81%9A%E4%BA%86%E5%93%AA%E4%BA%9B%E5%B7%A5%E4%BD%9C) * [四、TCP 三次握手：先把通道建立起来](#%E5%9B%9Btcp-%E4%B8%89%E6%AC%A1%E6%8F%A1%E6%89%8B%E5%85%88%E6%8A%8A%E9%80%9A%E9%81%93%E5%BB%BA%E7%AB%8B%E8%B5%B7%E6%9D%A5) * [五、TLS 握手、HTTP 请求与响应](#%E4%BA%94tls-%E6%8F%A1%E6%89%8Bhttp-%E8%AF%B7%E6%B1%82%E4%B8%8E%E5%93%8D%E5%BA%94) * [六、HTML 和 CSS 如何变成渲染树](#%E5%85%ADhtml-%E5%92%8C-css-%E5%A6%82%E4%BD%95%E5%8F%98%E6%88%90%E6%B8%B2%E6%9F%93%E6%A0%91) * [七、布局、绘制、光栅化与合成](#%E4%B8%83%E5%B8%83%E5%B1%80%E7%BB%98%E5%88%B6%E5%85%89%E6%A0%85%E5%8C%96%E4%B8%8E%E5%90%88%E6%88%90) * [八、四次挥手：连接如何关闭](#%E5%85%AB%E5%9B%9B%E6%AC%A1%E6%8C%A5%E6%89%8B%E8%BF%9E%E6%8E%A5%E5%A6%82%E4%BD%95%E5%85%B3%E9%97%AD) * [九、回流、重绘和合成到底是什么](#%E4%B9%9D%E5%9B%9E%E6%B5%81%E9%87%8D%E7%BB%98%E5%92%8C%E5%90%88%E6%88%90%E5%88%B0%E5%BA%95%E6%98%AF%E4%BB%80%E4%B9%88) * [十、边界问题：为什么页面会卡](#%E5%8D%81%E8%BE%B9%E7%95%8C%E9%97%AE%E9%A2%98%E4%B8%BA%E4%BB%80%E4%B9%88%E9%A1%B5%E9%9D%A2%E4%BC%9A%E5%8D%A1) * [十一、如何观察真实页面的渲染时间](#%E5%8D%81%E4%B8%80%E5%A6%82%E4%BD%95%E8%A7%82%E5%AF%9F%E7%9C%9F%E5%AE%9E%E9%A1%B5%E9%9D%A2%E7%9A%84%E6%B8%B2%E6%9F%93%E6%97%B6%E9%97%B4) * [十二、总结](#%E5%8D%81%E4%BA%8C%E6%80%BB%E7%BB%93) ## 一、先看一张完整地图 先用一条主线把“从域名到像素”串起来： ```text 输入 URL ↓ 解析协议、域名、端口和路径 ↓ 缓存 / Service Worker / HSTS 检查 ↓ DNS：域名 → IP 地址 ↓ 建立连接：TCP 三次握手（HTTP/1.1、HTTP/2） ↓ TLS 握手（HTTPS） ↓ 发送 HTTP 请求 ↓ 接收响应：状态码、响应头、HTML 字节流 ↓ 字符解码 → HTML 解析 → DOM ↘ CSS 下载与解析 → CSSOM → 样式计算 ↓ 渲染树 ↓ 布局（Layout）/ 回流（Reflow） ↓ 绘制（Paint）/ 光栅化（Raster） ↓ 图层合成（Compositing） ↓ 屏幕像素 ``` 这是一张帮助理解的地图，不是每个页面都严格走完每一格。例如，命中强缓存时可能没有网络请求；复用 HTTP 连接时不会重新握手；页面只有一小块元素改变时，也不一定重新布局整棵树。 浏览器通常还会把工作分到多个进程或线程中。以 Chromium 的概念模型为例： * 浏览器进程负责窗口、标签页和整体协调。 * 网络服务负责 DNS、连接和资源请求。 * 渲染器进程负责当前页面的 HTML、CSS 和 JavaScript。 * 合成器线程和 GPU 负责部分图层合成与光栅化。 不同浏览器的进程名和线程实现可能不同，但“网络获取 → 解析 → 布局绘制 → 合成”的分工思路相近。 ## 二、输入域名后，浏览器先做什么 假设你输入： ```text https://www.example.com:443/products?id=1#detail ``` 浏览器先把 URL 拆成几块： | 部分 | 示例 | 作用 | | --- | --- | --- | | 协议 | `https` | 决定使用 HTTP 还是 HTTPS，以及对应的连接方式 | | 主机名 | `www.example.com` | 需要通过 DNS 找到 IP | | 端口 | `443` | HTTPS 的常见默认端口 | | 路径 | `/products` | 告诉服务器请求哪份资源 | | 查询参数 | `id=1` | 给服务器传递筛选或业务参数 | | 片段 | `#detail` | 通常只在浏览器本地定位，不会发送给服务器 | ### 1\. 先查缓存和本地拦截 浏览器不会每次都从网络重新开始。常见检查顺序包括： 1. 是否有可用的 HTTP 缓存。 2. 是否有 Service Worker 拦截请求。 3. 是否启用了 HSTS，需要把 HTTP 升级成 HTTPS。 4. 连接池中是否已经有可复用的连接。 5. 浏览器、操作系统或 DNS 递归解析器中是否已有 DNS 缓存。 如果强缓存直接命中，浏览器可以跳过 DNS、TCP 和服务器请求。此时页面“打开很快”，不是 DNS 突然学会了瞬移，而是根本没有再问网络。 ### 2\. 预加载扫描器可能提前工作 HTML 主解析器还在逐字节读取文档时，浏览器可能使用预加载扫描器（preload scanner）提前发现 `<link>`、`<script>`、`<img>` 等资源，先发起下载。它不会替代 HTML 主解析器，只是帮资源请求“抢跑”。 ```html <link rel="stylesheet" href="app.css"> <script src="app.js" defer></script> <img src="banner.webp" alt="首页横幅"> ``` 预加载扫描器能减少等待，但遇到动态拼接 URL、`document.write` 或复杂脚本时，浏览器未必能提前猜到资源地址。 ## 三、DNS 解析到底做了哪些工作 DNS（Domain Name System）负责把人类容易记忆的域名转换为网络通信需要的 IP 地址。它不是“把字符串查成数字”这么简单，还要处理缓存、别名、IPv4/IPv6 和多级服务器协作。 ### 1\. 一次查询的主线 ```text 浏览器 DNS 缓存 ↓ 未命中 操作系统缓存 / hosts 文件 ↓ 未命中 递归 DNS 解析器（通常由运营商、公司或公共 DNS 提供） ↓ 未命中时逐级查询 根域名服务器（.） ↓ 顶级域名服务器（.com） ↓ 权威 DNS 服务器（example.com） ↓ 返回 A / AAAA / CNAME 等记录 ``` 现实中最常见的情况是递归解析器已经缓存了结果，因此它不需要每次都重新询问根服务器。根服务器也不是“全世界所有域名的电话簿”，它主要告诉解析器下一步应该去哪里问。 ### 2\. 常见 DNS 记录 | 记录 | 含义 | 示例用途 | | --- | --- | ---- | | `A` | 域名对应 IPv4 地址 | `example.com → 93.184.216.34` | | `AAAA` | 域名对应 IPv6 地址 | `example.com → 2001:db8::1` | | `CNAME` | 域名别名，指向另一个域名 | `www → example.com` | | `NS` | 指定某个域名的权威 DNS 服务器 | 告诉解析器去哪里问最终答案 | | `TXT` | 保存文本信息 | 域名验证、SPF 等 | | `MX` | 指定邮件服务器 | 邮件投递 | 浏览器拿到的可能不是一个 IP，而是一组地址。解析器和网络栈可以根据 IPv4/IPv6 可用性、连接速度、失败重试等策略选择连接目标。 ### 3\. DNS 缓存和 TTL DNS 记录带有 TTL（Time To Live）。TTL 决定缓存可以保留多久： * TTL 较长：查询次数少，解析速度稳定，但 IP 变更传播较慢。 * TTL 较短：变更更快生效，但递归解析器需要更频繁查询。 DNS 缓存不是绝对正确的永久记忆。域名迁移、CDN 调度和网络切换都会让同一个域名在不同时间返回不同 IP。 ### 4\. DNS 安全和协议变体 传统 DNS 查询通常使用 UDP；响应过大、需要可靠传输或特定场景下也可能使用 TCP。DoT（DNS over TLS）和 DoH（DNS over HTTPS）会把 DNS 查询放进加密通道，减少被中途窥探或篡改的机会。 因此，面试时不要绝对地说“DNS 一定使用 UDP，也一定不加密”。更准确的说法是：传统小查询常用 UDP，具体协议由解析器和网络环境决定。 ## 四、TCP 三次握手：先把通道建立起来 对基于 TCP 的 HTTP 连接，客户端不能一上来就把 HTTP 请求扔过去。双方要先确认：你能听见我，我能听见你，而且双方知道接下来从哪个序号开始通信。 ### 1\. 三次握手的过程 假设客户端初始序列号是 `x`，服务器初始序列号是 `y`： ```text 客户端 服务器 | | | ------ SYN，seq = x ----------------------------> | | | | <----- SYN + ACK，seq = y，ack = x + 1 ---------- | | | | ------ ACK，ack = y + 1 ------------------------> | | | TCP 连接建立，可以发送数据 ``` 逐步解释： 1. 客户端发送 `SYN`，表示“我想建立连接，这是我的初始序列号 `x`”。 2. 服务器返回 `SYN + ACK`，表示“我收到了 `x`，这是我的序列号 `y`，我也同意建立连接”。 3. 客户端发送 `ACK`，表示“我收到了 `y`”。双方都确认了对方的收发能力。 ### 2\. 为什么不是两次或四次 * 只有两次时，服务器无法确认客户端确实收到了自己的序列号 `y`。 * 第三次 ACK 让服务器知道客户端已经收到并接受了自己的响应。 * TCP 需要双方分别同步初始序列号，三次消息刚好完成双方的请求和确认。 三次握手不是为了给页面增加仪式感，而是为了避免旧连接请求造成混乱，并同步后续数据使用的序列号。 ### 3\. 握手后不一定立刻看到 HTML 如果请求是 HTTPS，TCP 建好后还要进行 TLS 握手：协商 TLS 版本和密码套件，验证证书，协商会话密钥。TLS 1.3 通常比旧版本减少往返次数，但仍然是 TCP 连接之后的另一层协议过程。 如果是 HTTP/2，同一条 TCP 连接还可以复用多个请求流；如果是 HTTP/3，则基于 QUIC（通常运行在 UDP 之上），不走 TCP 三次握手这条路径。说“浏览器访问网页一定经历 TCP 三次握手”是不完整的。 ## 五、TLS 握手、HTTP 请求与响应 ### 1\. HTTPS 的 TLS 握手 简化理解，TLS 握手会完成三件事： 1. 协商双方支持的协议版本和加密算法。 2. 服务器发送证书，客户端验证域名、有效期和信任链。 3. 双方通过密钥交换得到会话密钥，之后使用对称加密传输 HTTP 数据。 证书验证失败、系统时间错误、域名不匹配或证书链不受信任，都可能导致浏览器阻止继续发送请求。 ### 2\. HTTP 请求里有什么 ```http GET /products?id=1 HTTP/1.1 Host: www.example.com Accept: text/html Accept-Encoding: gzip, br Cookie: session=... Connection: keep-alive ``` 浏览器会根据缓存、Cookie、内容协商和安全策略补充请求头。请求体可能为空，也可能携带表单、JSON 或上传文件。 ### 3\. HTTP 响应告诉浏览器什么 ```http HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Content-Encoding: br Cache-Control: max-age=60 <!doctype html> <html>...</html> ``` 浏览器会根据状态码决定成功、重定向、缓存校验或错误处理；根据 `Content-Type` 和字符集解码响应；根据 `Content-Encoding` 解压内容；根据缓存头决定下次是否可以复用。 ### 4\. 连接为什么不马上关闭 HTTP/1.1 默认支持持久连接，HTTP/2 更强调一条连接上的多路复用。页面里的 HTML、CSS、JavaScript、字体和图片可能共享连接，减少重复握手成本。只有连接不再需要、超时、网络异常或服务器主动关闭时，才会进入 TCP 关闭流程。 ## 六、HTML 和 CSS 如何变成渲染树 ### 1\. 字节先变成字符 浏览器收到的是字节，不是现成的中文字符串。它会结合响应头、BOM、HTML 中的 `<meta charset>` 等信息选择字符编码，再把字节解码为字符流。 ```html <meta charset="UTF-8"> ``` 编码声明越早出现越好。编码识别错误时，中文可能变成乱码，后续解析出来的文本也会跟着出问题。 ### 2\. HTML 解析成 DOM HTML 解析器会把字符流转换成 token，再根据标签嵌套关系构建 DOM（Document Object Model）树： ```html <main class="card"> <h1>浏览器</h1> <p>正在渲染</p> </main> ``` 可以粗略理解为： ```text Document └── main.card ├── h1 │ └── "浏览器" └── p └── "正在渲染" ``` DOM 是文档结构，不等于最后画面。`display: none` 的节点可能存在于 DOM 中，却不会进入可见渲染树。 ### 3\. CSS 解析成 CSSOM CSS 解析器会把样式规则构造成 CSSOM（CSS Object Model），并计算选择器优先级、继承关系和最终样式： ```css .card { color: #222; padding: 16px; } .card strong { color: tomato; } ``` CSS 不是“看到哪一行就改哪一个元素”。浏览器要计算选择器是否匹配、层叠顺序、继承和默认样式，最后得到每个节点的计算样式（computed style）。 ### 4\. 脚本可能阻塞解析 普通脚本默认会暂停 HTML 解析，先下载并执行 JavaScript： ```html <script src="app.js"></script> ``` 因为脚本可能调用 `document.write`、读取或修改当前 DOM。常见缓解方式是使用 `defer` 或 `type="module"`： ```html <script src="app.js" defer></script> <script type="module" src="main.js"></script> ``` `defer` 脚本通常在 HTML 解析完成后、`DOMContentLoaded` 之前按文档顺序执行；模块脚本默认也采用延后执行语义，但具体依赖仍要结合模块图和浏览器实现理解。`async` 脚本下载完成后就可能执行，顺序不稳定，不适合有依赖关系的脚本。 ### 5\. DOM 和 CSSOM 合成渲染树 渲染树（Render Tree）可以理解为“真正需要画出来的节点及其样式”。它不是简单把 DOM 和 CSSOM 两棵树拼接： * `display: none` 的节点通常不进入渲染树。 * `visibility: hidden` 的节点仍占据布局空间，只是不可见。 * 伪元素 `::before`、`::after` 没有独立 DOM 节点，但可能产生渲染内容。 * 文本节点也可能参与布局和绘制。 ## 七、布局、绘制、光栅化与合成 ### 1\. 样式计算（Style Calculation） 浏览器先为渲染树中的节点计算最终样式，例如宽度、字体、颜色、边距、定位方式和继承结果。开发者写的是规则，布局阶段需要的是每个节点已经落地的计算值。 ### 2\. 布局（Layout） 布局会计算每个可见节点的几何信息：位置、宽高、换行结果、边距和盒模型。早期文章常把它叫作回流（Reflow）；现代浏览器内部可能采用增量布局、局部布局等优化。 ```text 父元素宽度改变 ↓ 子元素可用空间改变 ↓ 文字可能重新换行 ↓ 后续兄弟节点的 y 坐标也可能改变 ``` 所以一个看似只改了父元素宽度的操作，可能影响一大片节点。 ### 3\. 绘制（Paint） 绘制阶段把文字、背景、边框、阴影、图片等视觉内容记录成绘制指令。颜色变化、背景变化和阴影变化通常不需要重新计算几何位置，但需要重新绘制受影响区域。 ### 4\. 光栅化（Raster） 光栅化把绘制指令转换成位图纹理或图块（tile）。浏览器可能把这项工作交给 GPU，也可能根据内容和设备选择不同路径。这里的“GPU 加速”不是所有 CSS 属性都自动变快，关键还要看图层数量、纹理大小和合成成本。 ### 5\. 图层合成（Compositing） 合成器把不同图层按照 z-index、透明度、变换等规则组合起来，再交给屏幕显示。某些只改变 `transform` 或 `opacity` 的动画，如果元素已经处于合适的合成层，可以跳过布局和绘制，直接更新图层位置或透明度。 ```css .card { transition: transform 200ms ease, opacity 200ms ease; } .card.is-moving { transform: translateX(20px); opacity: 0.8; } ``` “通常可以只走合成”不等于“加了 `will-change` 就一定快”。过多图层会增加显存和合成压力，应该用 DevTools 的 Layers、Rendering 和 Performance 面板验证。 ## 八、四次挥手：连接如何关闭 TCP 是全双工连接：两个方向可以分别结束。因此关闭通常需要四个控制报文，而不是一个“关门”动作。 ### 1\. 四次挥手过程 假设客户端先主动关闭： ```text 客户端 服务器 | | | ------ FIN，表示客户端不再发送数据 -------------> | | <----- ACK，确认收到了 FIN --------------------- | | | | <----- FIN，服务器也发送完剩余数据 -------------- | | ------ ACK，确认服务器的 FIN ------------------> | | | 连接关闭 ``` 解释如下： 1. 客户端发送 `FIN`，只关闭客户端到服务器的发送方向。 2. 服务器返回 `ACK`，确认收到，但仍可能继续发送数据。 3. 服务器发送自己的 `FIN`，表示服务器也发送完了。 4. 客户端返回最后一个 `ACK`，双方关闭连接。 因为两个方向需要分别确认，所以常见模型是四次。服务器有时可以把 ACK 和自己的 FIN 合并，抓包时可能看到更少的报文，但语义仍是两个方向分别关闭。 ### 2. `TIME_WAIT` 是什么 主动关闭的一方通常会进入 `TIME_WAIT`，等待一段时间，确保网络中延迟的旧报文不会干扰后续同一四元组连接。它不是浏览器“忘记关连接”，而是 TCP 为了可靠关闭留下的安全缓冲。 ### 3\. 页面关闭就一定四次挥手吗 不一定： * HTTP 持久连接可能继续留在连接池中复用。 * 页面关闭只代表文档不再使用资源，不等于立即销毁底层 TCP 连接。 * 连接可能由服务器超时、网络断开或浏览器进程退出而结束。 * HTTP/2 可能关闭单个 stream，而不是关闭整条 TCP 连接。 * HTTP/3 使用 QUIC，关闭流程不是 TCP 四次挥手。 因此“三次握手、四次挥手”是**基于 TCP 的一次连接生命周期模型**，不是每个资源请求都机械执行一遍。 ## 九、回流、重绘和合成到底是什么 ### 1\. 回流（Reflow / Layout） 回流是重新计算节点几何信息的过程，常见触发原因： * 修改 `width`、`height`、`padding`、`margin`、`font-size`。 * 添加或删除 DOM 节点。 * 修改会影响布局的 class。 * 窗口尺寸变化。 * 字体加载完成导致文字重新排版。 回流可能影响后代和后续兄弟节点，通常比单纯重绘更昂贵，但现代浏览器会尽量做局部和增量优化。 ### 2\. 重绘（Repaint） 重绘是几何位置不变，但视觉内容需要重新绘制。例如： * `color`、`background-color` 改变。 * `box-shadow`、`border-color` 改变。 * 文本内容变化但没有导致布局变化的部分。 * `visibility` 等可见性变化。 重绘不一定触发回流，但回流完成后通常需要重新绘制受影响区域。 ### 3\. 合成（Composite） 合成是把已经准备好的图层重新组合。满足条件时，`transform` 和 `opacity` 动画可以只更新合成层，避开布局和绘制： ```javascript // 这个动画通常比反复修改 left 更容易走合成路径。 box.style.transform = `translateX(${distance}px)`; ``` 但“通常”不是承诺。元素是否独立成层、动画是否触发绘制、图层是否过大，都需要浏览器根据实际情况决定。 ### 4\. 三者的关系 | 修改 | 常见结果 | 说明 | | --- | ---- | --- | | `width`、`height`、`margin` | 回流 → 可能重绘 → 合成 | 几何位置变了 | | `color`、`background-color` | 重绘 → 合成 | 几何通常不变 | | `transform`、`opacity` | 可能只合成 | 依赖图层和属性条件 | | 添加 DOM | 样式计算 → 回流 → 重绘 → 合成 | 需要把新节点纳入渲染流程 | ## 十、边界问题：为什么页面会卡 ### 1\. 问题：读写交替导致强制同步布局 ```javascript for (const item of items) { item.style.width = '200px'; // 刚写完布局属性就读取 offsetWidth，浏览器可能被迫马上计算布局。 console.log(item.offsetWidth); } ``` 写入会让布局变“脏”，随后读取 `offsetWidth`、`clientHeight`、`getBoundingClientRect()` 等几何信息，浏览器为了给出准确结果，可能立刻执行布局。这叫强制同步布局（forced synchronous layout）。循环里反复读写，就容易形成布局抖动（layout thrashing）。 修复方式是把“读”和“写”尽量分组： ```javascript const widths = items.map((item) => item.offsetWidth); for (const item of items) { item.style.width = '200px'; } console.log(widths); ``` 先读取旧布局，再统一写入；如果还要做动画，可以把写入放到 `requestAnimationFrame` 中，让浏览器在合适的帧执行。 ### 2\. 问题：批量修改 DOM 造成多次中间状态 ```javascript for (const item of items) { list.appendChild(item); } ``` 一次次插入可能让样式计算和布局工作反复发生。可以先使用 `DocumentFragment` 组装，再一次性挂入文档： ```javascript const fragment = document.createDocumentFragment(); for (const item of items) { fragment.appendChild(item); } list.appendChild(fragment); ``` 这不是保证“绝对只布局一次”，因为浏览器仍可自行优化；它的价值是减少开发者制造的中间 DOM 状态和不必要的更新机会。 ### 3\. 问题：把 `left` 动画当成 `transform` 动画 ```javascript // left 会参与布局，连续修改可能触发回流。 box.style.left = `${distance}px`; ``` 如果只是移动视觉位置，通常更适合： ```javascript box.style.transform = `translateX(${distance}px)`; ``` 但不要机械地把所有动画都改成 `transform`。如果动画会影响周围布局，`transform` 只改变绘制位置，并不会让其他元素跟着重新排版；此时需要先确认视觉效果是否符合需求。 ### 4\. 问题：用 JavaScript 阻塞渲染 ```javascript // 故意示例：长任务会阻塞解析、事件响应和渲染。 const end = performance.now() + 200; while (performance.now() < end) { // 忙等 200ms } ``` 修复思路不是“把 while 写得更优雅”，而是拆分任务： * 大数据分批处理，每批处理完让出主线程。 * 动画更新放进 `requestAnimationFrame`。 * 非关键脚本使用 `defer`、模块或延迟加载。 * 把昂贵计算移到 Web Worker，避免阻塞页面主线程。 ## 十一、如何观察真实页面的渲染时间 ### 1\. 使用 `PerformanceNavigationTiming` 浏览器会提供导航计时信息，可以观察 DNS、连接、请求、响应和 DOM 事件的时间点： ```javascript const navigation = performance.getEntriesByType('navigation')[0]; if (navigation) { console.table({ DNS: navigation.domainLookupEnd - navigation.domainLookupStart, TCP: navigation.connectEnd - navigation.connectStart, TLS: navigation.requestStart - navigation.secureConnectionStart, TTFB: navigation.responseStart - navigation.requestStart, DOM: navigation.domInteractive - navigation.startTime, DOMContentLoaded: navigation.domContentLoadedEventEnd - navigation.startTime, Load: navigation.loadEventEnd - navigation.startTime, }); } ``` 注意： * 从 `file://` 直接打开时，DNS、TCP、TLS 等网络阶段可能没有意义。 * 强缓存、Service Worker、连接复用会让某些阶段接近 `0`。 * `secureConnectionStart` 为 `0` 时，说明没有可用的 TLS 起始时间，不能直接把它当成“TLS 耗时”。 * 这些时间是浏览器提供的观测数据，不等于每个内部线程的精确耗时。 ### 2\. DevTools 中看什么 打开开发者工具，可以重点观察： * **Network**：DNS、Initial connection、SSL、Request sent、Waiting、Content Download。 * **Performance**：长任务、Parse HTML、Recalculate Style、Layout、Paint、Composite Layers。 * **Rendering**：Paint flashing、Layout Shift Regions、FPS 等可视化选项。 * **Layers**：哪些元素被提升为独立合成层，以及图层是否过多。 ## 十二、总结 * 浏览器从域名到界面，经历的是“地址解析 → 连接建立 → HTTP 传输 → 解析 → 样式计算 → 布局 → 绘制 → 合成”。 * DNS 可能经过浏览器缓存、操作系统缓存、递归解析器、根服务器、顶级域名服务器和权威服务器；缓存命中时不会重复走完整链路。 * 基于 TCP 的 HTTP 连接先三次握手；HTTPS 在 TCP 之后还需要 TLS 握手；HTTP/3 基于 QUIC，不走 TCP 三次握手。 * TCP 四次挥手是两个方向分别关闭的过程，但连接复用、HTTP/2 stream 和 HTTP/3 都会改变“每个请求都挥手”的简单想象。 * DOM 描述结构，CSSOM 描述样式；两者合成渲染树后，浏览器才计算几何位置并绘制像素。 * 回流重新计算布局，重绘重新绘制视觉内容，合成重新组合图层；修改 `transform`、`opacity` 在满足条件时可能只走合成。 * 读写布局属性交替、频繁插入 DOM、长时间占用主线程，都可能让页面卡顿。批量读写、`requestAnimationFrame`、`DocumentFragment` 和 Web Worker 是常见优化方向。 这篇文章使用的是方便面试和排查问题的简化模型。不同浏览器、协议版本、缓存状态和硬件条件会改变具体细节；遇到性能问题时，最终应以目标浏览器的 Network 和 Performance 面板为准。