浏览器原理：从网络请求到页面渲染的完整工作流

浏览器是我们最常用的软件之一，但它背后的工作机制往往容易被忽略。理解浏览器如何完成一次页面加载，不仅能帮助我们写出更高效、更稳定的前端代码，也能在排查性能问题、白屏问题和卡顿问题时更快定位根因。本文以 Chrome / Chromium 为例，串起浏览器的多进程架构、网络请求流程和渲染流水线。

一、浏览器的多进程架构

现代浏览器不是一个单进程程序，而是由多个相互协作的进程和线程共同完成工作的。

• 进程（Process）：操作系统分配内存和资源的基本单位。进程之间天然隔离，一个进程崩溃通常不会直接拖垮其他进程。
• 线程（Thread）：进程内的执行单元，多个线程共享同一进程的内存空间。

Chrome 常见的进程包括：

• 浏览器进程：负责地址栏、标签页管理、前进后退、权限控制、下载、书签等顶层 UI 以及进程调度。
• 渲染进程：负责解析 HTML、CSS、执行 JavaScript、布局、绘制和页面交互。一般来说，一个站点对应一个渲染进程，但在站点隔离、跨站 iframe 等场景下不一定严格“一页一个进程”。
• 网络服务：负责 DNS、HTTP、缓存、代理、连接复用等网络能力。现代 Chromium 中它通常以独立的网络服务形态运行。
• GPU 进程：负责图形相关任务，例如合成、部分光栅化、2D/3D 加速渲染。
• 扩展/插件相关进程：现代 Chrome 已基本移除传统 NPAPI 插件，更多是扩展、WebAssembly、内置服务等形态；如果从旧资料里看到“插件进程”，可以把它理解为历史概念。

这种架构带来三点好处：

1. 稳定性：某个标签页崩溃通常不会影响整个浏览器。
2. 安全性：不同站点隔离运行，降低页面互相读取数据的风险。
3. 性能：多个任务可并行执行，避免所有工作都挤在一个进程里。

二、浏览器网络请求工作流

当我们在地址栏输入一个 URL 后，浏览器并不是立刻去“请求网页”，而是会按一条比较完整的链路逐步完成资源获取。

2.1 URL 解析

浏览器会先解析输入内容，判断它是搜索词还是 URL，并拆分出协议、域名、端口、路径、查询参数等部分。

例如：

1https://www.example.com:443/path?a=1https://www.example.com:443/path?a=1

会被拆成协议 https、主机名 www.example.com、端口 443、路径 /path 和查询参数 a=1。

2.2 DNS 解析

域名需要先解析为 IP 地址，浏览器才能找到目标服务器。

DNS 查询通常会依次参考这些来源：

1. 浏览器缓存
2. 操作系统缓存
3. 本机 hosts 文件
4. 路由器或本地网络缓存
5. 运营商 DNS 缓存
6. 递归查询到根域名服务器、顶级域名服务器、权威域名服务器

这里要注意两点：

• DNS 缓存时长不是固定的“2 到 30 分钟”，而是由记录的 TTL 决定，不同域名可能完全不同。
• 现代浏览器和系统通常都支持更复杂的 DNS 机制，例如 DoH / DoT、缓存预取等，实际路径会比教科书模型更灵活。

2.3 建立连接

拿到 IP 后，浏览器会与服务器建立连接。

• 如果是 HTTP/1.1 或HTTP/2，通常基于 TCP。
• 如果是 HTTP/3，则基于 QUIC/UDP，不再走传统 TCP 三次握手。

对于 TCP 来说，经典握手过程是：

1. 客户端发送 SYN
2. 服务端返回 SYN + ACK
3. 客户端返回 ACK

这样双方确认了彼此的收发能力，连接建立完成。

2.4 TLS 握手

如果是 HTTPS，还要先完成 TLS 协商。这里的目标不是“让通信变快”，而是建立一条加密、完整、可验证的安全通道。

简化后的过程可以理解为：

1. 客户端告诉服务器自己支持的加密套件，并发送随机数。
2. 服务器返回证书、选择的加密套件和随机数。
3. 客户端验证证书是否合法、是否过期、是否由受信任 CA 签发、域名是否匹配。
4. 双方协商出会话密钥。
5. 后续通信使用对称加密，保证性能和安全性。

补充说明：

• TLS 1.3 比 TLS 1.2 更精简，握手轮次更少。
• 证书验证失败时，浏览器一般会直接阻止连接或给出安全警告。

2.5 发送 HTTP 请求并接收响应

连接建立后，浏览器会发送 HTTP 请求，服务器返回 HTTP 响应。

请求通常包含：

• 请求行：方法、路径、协议版本
• 请求头：Host、Cookie、Accept、User-Agent、Cache-Control 等
• 请求体：如 POST、PUT 中提交的数据

响应通常包含：

• 状态码：200、301、302、304、404、500 等
• 响应头：Content-Type、Cache-Control、ETag、Set-Cookie 等
• 响应体：HTML、JSON、图片、JS、CSS 或其他资源

这里还有一个很重要的点：缓存判断并不只发生在“请求之前”。浏览器会结合强缓存和协商缓存决定是否直接用本地资源，还是发起条件请求。

• 强缓存：通过 Cache-Control、Expires 判断资源是否仍可直接使用。
• 协商缓存：通过 ETag / If-None-Match、Last-Modified / If-Modified-Since 和服务器确认资源是否变化。

如果服务器返回 304 Not Modified，说明资源没变，浏览器可复用本地缓存。

三、浏览器渲染工作流

拿到 HTML 后，渲染进程会开始把字符串变成可见页面。这个过程不是一次性完成的，而是多个阶段协同推进。

3.1 解析 HTML

浏览器会边下载边解析 HTML，把文本流转成结构化节点，最终生成 DOM 树。

例如：

1<div class="root">Hello</div><div class="root">Hello</div>

会被解析为一个包含元素节点、属性和文本节点的 DOM 结构。

浏览器还会启用 预解析器（preload scanner），在主解析器继续处理 HTML 的同时，提前发现外部 CSS、JS、图片等资源并并发下载，这能显著减少等待时间。

3.2 解析 CSS

CSS 会被解析为 CSSOM。DOM 和 CSSOM 合并后，才能决定页面上每个可见元素应该如何显示。

这里要澄清一个常见误区：

• HTML 解析本身可以继续进行。
• 但 CSS 会阻塞渲染，因为浏览器必须拿到足够的样式信息后，才能正确计算页面样式并开始绘制。
• 外部脚本如果要执行并可能读取样式信息，也会受到 CSS 解析状态的影响。

3.3 执行 JavaScript

遇到 <script> 时，浏览器会交给 JS 引擎执行。

JS 之所以重要，是因为它可以修改 DOM、修改样式、创建节点、触发重排重绘，甚至重新安排页面的最终结构。

几个常见结论：

• 同步脚本 默认会阻塞 HTML 解析。
• defer 会在 HTML 解析完成后、DOMContentLoaded 之前执行，适合依赖 DOM 的脚本。
• async 会尽快下载并尽快执行，执行时机不固定，适合彼此独立的脚本。

3.4 构建渲染树

DOM 和 CSSOM 结合后，浏览器会生成 渲染树（Render Tree）。

渲染树只包含真正参与页面显示的节点：

• display: none 的节点不会进入渲染树。
• visibility: hidden 的节点通常仍保留布局空间，只是不可见。

3.5 布局（Layout）

布局阶段会计算每个元素的几何信息：

• 位置
• 宽高
• 盒模型
• 相对关系
• 文档流中的排布结果

任何会影响几何信息的变化，通常都会触发 重排（reflow / layout）。

3.6 绘制与分层

浏览器会把页面拆成若干图层，并决定哪些内容需要单独合成。

常见会促成分层的因素包括：

• position: fixed
• transform
• opacity
• will-change
• 视频、Canvas、复杂动画等

分层的目的不是“越多越好”，而是把变化频繁的内容单独隔离出来，减少每次更新都重画整页的成本。

3.7 光栅化（Raster）

绘制命令会被转换成实际像素。为了提升效率，页面通常会被切成很多小块（tile），再并行交给光栅化线程或 GPU 处理。

3.8 合成与显示

最后，多个图层会在合成阶段重新拼装，形成最终画面并提交到屏幕。

这一步通常由合成线程、GPU 进程和显示系统共同完成。对开发者来说，动画只改 transform 或 opacity，往往就是因为它更容易走合成路径，开销更小。

四、页面导航与关键渲染路径

真正的“打开一个网页”不只是发请求和渲染页面。浏览器还要先完成一次导航，决定用哪个进程处理页面，再逐步进入渲染流程。

4.1 导航开始

当用户输入 URL 或点击链接时，浏览器进程会先接管这次导航，处理地址栏输入、历史记录、权限检查和站点策略。

它通常会先做几件事：

1. 判断这是一次新导航还是当前页面内部跳转。
2. 检查是否需要重定向。
3. 决定是否复用已有渲染进程，还是启动新的渲染进程。
4. 将导航任务交给网络服务和目标渲染进程。

4.2 渲染进程的创建与切换

浏览器不会永远只用一个渲染进程。

• 同源页面通常更容易复用同一个渲染进程。
• 跨站页面可能会被隔离到新的进程里。
• 发生站点隔离、权限隔离或安全策略变化时，浏览器也可能主动切换进程。

这也是为什么“一个标签页”并不总等于“一个固定进程”。

4.3 关键渲染路径

所谓关键渲染路径，就是页面从“拿到最初资源”到“首屏真正能看到内容”所经历的最短有效链路。

它通常最受这些因素影响：

• HTML 是否能快速到达
• 关键 CSS 是否足够早加载
• 阻塞脚本是否过多
• 字体、图片、接口数据是否拖慢首屏
• 是否存在过重的首屏 JS

如果想提升首屏速度，核心思路不是“把所有东西都提前加载”，而是优先保证首屏真正需要的资源先到位。

4.4 首次内容渲染与可交互时机

常见的页面体验指标里，比较关键的两个阶段是：

• FCP（First Contentful Paint）：页面首次出现文本、图片等内容的时刻。
• LCP（Largest Contentful Paint）：首屏最大内容元素完成渲染的时刻。

它们都和关键渲染路径紧密相关。FCP 更像“页面开始有东西了”，LCP 更像“核心内容真正可见了”。

五、事件循环与浏览器里的 JS 执行

浏览器原理里，事件循环几乎是绕不开的一环。页面为什么会卡顿、为什么某些代码会延后执行、为什么微任务总是先于下一帧渲染，答案都在这里。

5.1 宏任务与微任务

JavaScript 在浏览器中不是孤立运行的，它要和任务队列协作。

• 宏任务：例如脚本执行、定时器回调、UI 事件、网络事件等。
• 微任务：例如 Promise.then、queueMicrotask、MutationObserver 回调等。

一般来说，每执行完一个宏任务，浏览器会先清空当前微任务队列，再考虑是否进入渲染阶段。

5.2 为什么微任务很重要

微任务的优先级通常高于下一轮宏任务，这意味着：

• Promise 回调会尽快执行。
• 如果微任务不断追加，可能拖延渲染机会。
• 过长的微任务链同样会造成卡顿。

5.3 JS、样式和布局的交互

JavaScript 不只是“改数据”，它还能直接影响页面计算。

常见情况包括：

• 读取 offsetWidth、getBoundingClientRect() 这类布局相关属性时，浏览器可能被迫先完成一次布局计算。
• 先写样式、马上读布局、再写样式，容易引发连续布局抖动。
• 如果主线程一直忙，页面即使已经拿到数据，也来不及真正绘制出来。

所以，浏览器里的“执行快”不等于“体感快”，真正重要的是别长期占住主线程。

六、安全与隔离

浏览器之所以采用多进程，不只是为了稳定，也是在做安全隔离。

6.1 同源策略

同源策略是浏览器安全模型的重要基础。协议、域名、端口只要有一个不同，通常就会被视为不同源。

它限制了页面直接读取跨源资源的能力，从而降低站点之间互相窃取数据的风险。

6.2 站点隔离

Chrome 会尽量把不同站点的页面隔离在不同进程里，减少恶意页面越权访问其它站点数据的可能。

6.3 CSP 与 CORS

• CSP 用于限制页面可以加载和执行哪些资源，降低 XSS 风险。
• CORS 用于管理跨源请求是否允许被当前页面读取。

它们分别解决的是“我能加载什么”和“我能读什么”。

七、性能优化

理解浏览器工作流的价值，最终还是要落回到“怎么写得更快、更稳”。

7.1 网络层优化

1. 合理使用缓存

   • 使用 Cache-Control、ETag、Last-Modified 等缓存策略。
   • 区分内存缓存、磁盘缓存、协商缓存和 Service Worker 缓存。
   • 静态资源尽量配合文件指纹，做到长缓存 + 版本更新。
   • Service Worker 可用于离线缓存和资源兜底。

2. 减少请求开销

   • 合并零散资源，减少不必要的请求。
   • 图片、字体、接口请求都要按实际收益衡量，不是所有东西都该“打包成一个”。

3. 优化传输

   • 优先使用 HTTP/2 或 HTTP/3。
   • 开启 Brotli 或 Gzip 压缩。
   • 使用 CDN 缩短资源回源距离。

7.2 渲染层优化

1. 避免阻塞主线程

   • 关键 CSS 放在头部。
   • 非关键 JS 尽量使用 defer。
   • 大脚本拆分、按需加载，避免长时间占用主线程。

2. 减少重排和重绘

   • 批量更新 DOM。
   • 读写分离，避免在循环里反复触发布局计算。
   • 动画优先使用 transform 和 opacity。

3. 谨慎使用图层优化

   • 不要滥用 will-change、translateZ(0)。
   • 独立图层会占用额外内存，图层过多反而可能变慢。

7.3 JavaScript 优化

1. 拆包与懒加载

   • 使用 Tree Shaking 去掉无用代码。
   • 路由级拆分、组件级懒加载、动态导入按需拉取。

2. 减少主线程压力

   • 把耗时任务放进 Web Worker。
   • 对高频事件做防抖、节流或合并处理。

7.4 图片与媒体优化

1. 使用合适的格式

   • 图标优先用 SVG。
   • 图片优先考虑 WebP / AVIF。
   • 只有在极小资源、且收益明确时，才考虑内联 Base64。

2. 响应式加载

   • 使用 srcset 和 <picture> 适配不同屏幕密度和尺寸。
   • 非首屏图片使用懒加载。

7.5 首屏加载优化

1. 预加载

   • preload 适合提前加载当前页面马上要用的关键资源。
   • prefetch 适合提前准备未来可能用到的资源。

2. 服务端渲染与 hydration

   • SSR 可以更快输出首屏 HTML，改善首屏可见速度。
   • CSR 更适合交互复杂、状态高度动态的应用。
   • Hydration 则是让服务端输出的静态 HTML 重新“接上”客户端交互能力。

八、浏览器线程分工

在同一个进程里，浏览器也不是“一个线程干所有事”。不同线程各司其职，才能让页面既能渲染，又能响应用户操作。

8.1 主线程

主线程通常负责最核心、最敏感的工作：

• 解析 HTML、CSS
• 执行 JavaScript
• 计算样式
• 执行布局
• 处理大部分 DOM 操作

这也是为什么主线程一忙，页面就容易卡。

8.2 合成线程

合成线程负责把不同图层组合起来，尽量减少主线程参与。

如果动画只改变 transform 或 opacity，很多时候就可以更多依赖合成阶段来完成。

8.3 栅格线程

栅格线程会把绘制命令转成像素数据，并行处理页面切块。

8.4 JS 执行与任务调度

JS 的执行虽然和渲染紧密相关，但从浏览器角度看，它更像是在主线程上不断插入任务。也正因为如此，长任务、频繁同步计算、过深的微任务链，都可能直接伤到流畅度。

九、缓存分层与协议演进

缓存不是一个东西，而是一组分层机制。把它们分清楚，排查加载问题会轻松很多。

9.1 缓存分层

• Memory Cache：读写速度快，通常用于短期复用。
• Disk Cache：落盘保存，适合跨页面、跨会话复用。
• HTTP 协商缓存：通过条件请求验证资源是否变化。
• Service Worker Cache：由开发者显式控制，适合离线和定制化资源策略。

它们之间不是互斥关系，而是会按浏览器策略共同参与资源命中。

9.2 HTTP 协议演进

• HTTP/1.1：连接利用率有限，容易受到队头阻塞影响。
• HTTP/2：支持多路复用和头部压缩，适合并发加载多个资源。
• HTTP/3：基于 QUIC，减少了 TCP 层的一些限制，更适合弱网和高延迟场景。

协议升级的核心目标，不只是“更快”，而是更稳地利用连接和减少阻塞。

十、常用性能指标

如果要判断浏览器加载和渲染是否真正变好，最好不要只看“感觉快不快”，而是看指标。

• TTFB：首字节时间，反映网络和服务端响应速度。
• FCP：首次内容渲染，反映页面开始可见的时机。
• LCP：最大内容渲染，反映首屏核心内容是否够快出现。
• CLS：布局偏移，反映页面是否抖动。
• INP：交互到下一次绘制的延迟，反映交互响应体验。

这些指标能把“页面慢”拆成更具体的问题：是网络慢、渲染慢、脚本慢，还是交互响应慢。

十一、总结

浏览器的一次页面加载，本质上是 URL 解析、DNS 查询、连接建立、请求响应、HTML/CSS/JS 解析、布局、绘制、合成 的完整链路。

如果把这条链路吃透，很多常见问题都会变得更容易解释：

• 页面为什么慢：可能卡在 DNS、建连、下载、JS 执行或主线程阻塞。
• 页面为什么闪：可能是 CSS 未及时就绪、首屏渲染策略不合理或 hydration 不完整。
• 页面为什么卡：可能是频繁重排、长任务过多或图层管理不当。

理解浏览器，不只是理解“页面怎么显示出来”，更是理解前端性能、稳定性和用户体验是如何一步步被建立起来的。