```html

Web浏览技术知识

你在地址栏敲下 example.com，按下回车，术知识页面几乎瞬间呈现。浏览技这中间发生了什么？术知识大多数人只关心结果，但真正理解浏览技术的浏览技人知道，那几百毫秒里藏着一整套精密的术知识协作流程。我第一次用 Wireshark 抓包看 DNS 查询时，浏览技才意识到“打开网页”这个动作有多不简单。术知识

第一步其实是浏览技找 IP。浏览器先查自己的术知识 DNS 缓存，没有就问操作系统，浏览技再没有就向递归 DNS 服务器发请求。术知识我见过一个案例：某公司内网 DNS 服务器配错了转发规则，浏览技员工访问外部网站全部超时，术知识但 ping 公网 IP 却正常——问题就卡在域名解析这一环。浏览技DNS 通常走 UDP 53 端口，响应小、速度快，但一旦响应超过 512 字节或者启用了 DNSSEC，就会切到 TCP。这细节很多人不知道。

拿到 IP 后，浏览器要跟服务器建立 TCP 连接。三次握手——SYN、SYN-ACK、ACK——这是老生常谈。但现代 Web 更常用 HTTPS，所以 TCP 建连之后还有 TLS 握手。TLS 1.3 把握手压缩到一次往返，比 1.2 快了不少。我实测过一个海外站点，启用 TLS 1.3 后首字节时间从 420ms 降到了 280ms 左右。当然，如果服务器支持 HTTP/3，那底层直接走 QUIC（基于 UDP），连 TCP 握手都省了。Chrome 和 Firefox 现在默认对已知支持 HTTP/3 的站点启用 QUIC，你可以在 chrome://flags 里看到相关选项。

连接建立后，浏览器发送 HTTP 请求。请求行、请求头、空行、请求体——格式固定。但真正影响性能的是请求头里的内容。比如 Accept-Encoding: gzip, br 告诉服务器“我能解压缩”，服务器就可能返回 Brotli 压缩的 HTML，体积能减少 20% 左右。我观察过某电商首页，未压缩的 HTML 是 87KB，Brotli 压缩后只有 21KB。还有 Cache-Control，它决定了浏览器要不要再发请求。强缓存（max-age=31536000）直接读本地副本，连请求都不发；协商缓存（ETag 或 Last-Modified）则要发个条件请求，服务器返回 304 才用缓存。很多开发者搞混这两者，结果要么缓存失效太频繁，要么用户永远看不到更新。

服务器返回响应后，浏览器开始解析 HTML。这里的关键是解析器阻塞。遇到 <script> 标签（没有 async 或 defer），HTML 解析会暂停，等 JS 下载并执行完才继续。我见过一个页面在 <head> 里放了一个 300KB 的同步脚本，白屏时间长达 2.3 秒。后来改成 defer，首屏渲染直接提前到 0.8 秒。CSS 也会阻塞渲染——浏览器必须等 CSSOM 构建完才绘制第一帧，但不会阻塞 HTML 解析。所以把关键 CSS 内联、非关键 CSS 异步加载，是常见的优化手段。

DOM 树和 CSSOM 树合并成渲染树，然后进入布局（Layout）和绘制（Paint）。布局计算每个元素的位置和大小，绘制填充像素。如果元素尺寸变化，会触发重排（Reflow）；只改颜色或背景，只触发重绘（Repaint）。重排代价高得多。我调试过一个动画，用 top 属性做位移，帧率只有 30fps；换成 transform: translateY() 后立刻稳定 60fps。因为 transform 不触发重排，只走合成层。

现代浏览器还有预加载扫描器（Preload Scanner）。它在主解析器被脚本阻塞时，会偷偷扫描后续 HTML，提前发现 <img>、<link> 等资源并开始下载。这个机制让很多页面的加载速度提升明显。你可以打开 DevTools 的 Network 面板，看到“Priority”列——高优先级的资源（如字体、首屏图片）会先被请求。

最后说个容易被忽略的：浏览器缓存不止 HTTP 缓存。还有 Memory Cache（内存缓存，存活于当前标签页）、Service Worker Cache（可编程控制）、Push Cache（HTTP/2 推送的缓存，现已基本废弃）。我在调试 PWA 时，发现 Service Worker 缓存了旧版 JS，导致新功能不生效——清除缓存后正常。所以理解缓存层级，比背概念有用得多。

Web 浏览技术没有魔法。每一次点击背后，都是 DNS、TCP、TLS、HTTP、解析、渲染的接力。你不需要记住所有细节，但知道瓶颈可能出在哪一层，排查问题时就不会瞎猜。