浏览器工作原理
技术笔记2020-05-051197
浏览器原理：从网络请求到页面渲染的完整工作流
浏览器是我们日常开发和使用中最常见的软件之一，但它的内部工作机制往往被忽略。理解浏览器的运行机制，不仅能帮助我们编写更高效、更安全的代码，也能让我们在性能优化和排查问题时更加得心应手。本文将以 Chrome 浏览器 为例，深入探讨浏览器的多进程架构、网络进程的工作流以及渲染工作流。
一、浏览器的多进程架构
和大多数复杂的应用程序一样，浏览器由多个进程协同组成，每个进程有自己独立的职责。
- 进程（Process）：当启动一个应用时，操作系统会为该应用分配一部分独立的内存空间，这就是一个进程。进程之间相互隔离，一个进程崩溃不会影响其他进程。
- 线程（Thread）：进程中的实际执行单元。一个进程中通常包含多个线程，这些线程共享同一进程的内存资源。
在 Chrome 中，常见的进程有：
- 浏览器主进程：负责地址栏、书签栏、前进后退等浏览器 UI，以及管理子进程。
- 网络进程：处理网络请求，如 DNS 查询、TCP 连接、HTTP 请求和响应。
- 渲染进程：每个标签页通常对应一个独立的渲染进程，负责解析 HTML、CSS、JS，并将页面绘制到屏幕上。
- GPU 进程：负责 2D、3D 图形加速绘制。
- 插件进程：负责运行浏览器插件，避免插件崩溃影响浏览器。
这种多进程架构提升了稳定性和安全性，同时通过并行执行提高了性能。
二、浏览器网络进程工作流
浏览器加载一个网页时，网络进程承担了关键任务：从用户输入 URL 到获取页面资源的全过程。
graph LR
A[DNS查询] --> B[TCP握手连接]
B --> C[TLS协商]
C --> D[建立连接]
D --> F[获取数据]
2.1 DNS 查询
当用户在浏览器地址栏输入域名（如 www.example.com）时，首先需要将域名解析为对应的 IP 地址。
DNS 查询的过程：
- 查找 浏览器缓存（最近访问过的 DNS 记录，2-30 分钟）。
- 查找 系统缓存（操作系统 hosts 文件）。
- 查找 路由器缓存。
- 查找 ISP DNS 缓存（本地运营商 DNS 服务器）。
- 递归查询：若仍未命中缓存，则依次向根域名服务器、顶级域名服务器、权威域名服务器发起查询，直到找到目标 IP 地址。
DNS 查询结果通常会被缓存（TTL 时间内有效），加快后续访问速度。
2.2 TCP 三次握手
得到服务器 IP 地址后，浏览器通过 TCP 三次握手 与服务器建立可靠的连接：
- 客户端 → 服务器：发送一个 SYN 请求，表示“我要建立连接”。
- 服务器 → 客户端：收到请求后，回复 SYN+ACK，表示“我同意并确认”。
- 客户端 → 服务器：再发一个 ACK，确认收到。
至此，TCP 连接建立完成。
2.3 TLS 协商（HTTPS）
如果目标站点使用 HTTPS，还需要进行 TLS 握手 来确保数据传输安全。其过程包括：
- 浏览器发送支持的加密算法、随机数。
- 服务器返回数字证书、加密套件、随机数。
- 浏览器验证证书有效性。
- 浏览器生成“预主密钥”，用服务器公钥加密并发送。
- 服务器用私钥解密，双方生成会话密钥。
- 之后所有通信都使用对称加密。
这样可以保证数据的机密性和完整性，防止中间人攻击。
2.4 建立连接
完成 TCP 和 TLS 的握手后，连接建立成功，浏览器可以正式向服务器发送请求。
2.5 获取数据
1. 发送 HTTP 请求
- 浏览器首先检查缓存，若命中缓存则直接返回资源。
- 否则，构造 HTTP 请求（包含请求方法、URI、请求头等），并发送给服务器。
常见请求方法有：GET、POST、PUT、DELETE 等。
2. 接收 HTTP 响应
服务器处理请求并返回响应，包括：
- 状态码（200 成功、301 重定向、404 未找到、500 服务器错误）。
- 响应头（缓存策略、内容类型等）。
- 响应体（HTML、JSON、图片等）。
成功返回 HTML 文件后，浏览器会将渲染任务交给渲染进程继续处理。
三、浏览器渲染工作流
当渲染进程接收到 HTML 文档时，便会启动页面渲染流程：
graph LR
A[解析HTML] --> B[解析CSS]
B --> C[执行JavaScript]
C --> D[构建渲染树]
D --> E[布局Layout]
E --> F[分层]
F --> G[绘制]
G --> H[分块]
H --> I[光栅化Raster]
I --> J[合成与显示]
3.1 解析 HTML
浏览器会对 HTML 文档进行 词法分析，生成 Token 流，并进一步构建 DOM 树。
例如：
html
<div class="root">Hello</div>会被解析成一个包含节点层级关系的 DOM 结构。
3.2 解析 CSS
CSS 会被解析成 CSSOM（CSS 对象模型），与 DOM 结合后形成 渲染树（Render Tree）。
注意：
- 浏览器会使用 预解析线程 并行下载 CSS 文件，避免阻塞 HTML 解析。
- 但在执行 JavaScript 前，必须保证相关的 CSS 已解析完毕，否则可能导致样式计算不完整。
3.3 执行 JavaScript
浏览器遇到 <script> 标签时，会交由 JS 引擎（如 V8） 执行代码。
- JS 可以操作 DOM 和 CSSOM，因此执行顺序对页面渲染影响很大。
- 阻塞型脚本可能导致页面停顿，因此常用
defer或async来优化加载。
3.4 构建渲染树
DOM 树和 CSSOM 合并，生成 渲染树。渲染树只包含 可见元素，不会包含 display: none 的节点。
3.5 布局（Layout）
计算每个元素的大小和位置，形成几何结构。
3.6 分层 & 绘制
某些复杂的元素（如 position: fixed、3D transform、opacity 等）会被单独分成图层。
绘制（Painting）阶段会将每个图层的内容绘制成位图。
3.7 光栅化（Rasterization）
图层会被进一步切分为小块（Tiles），交给 GPU 进行并行处理，生成最终的像素数据。
3.8 合成与显示
最后，浏览器将多个图层合成（Compositing）并显示到屏幕上，用户就能看到完整的页面。
四、性能优化
理解浏览器工作机制的最终目的，就是指导我们写出更高效的代码。下面结合前文的网络和渲染工作流，总结常见的优化策略：
4.1 网络层优化
-
使用缓存
- 合理设置
Cache-Control、ETag等缓存头，减少重复请求。 - 善用 Service Worker 实现离线缓存。
- 合理设置
-
减少请求次数
- 合并资源（CSS、JS），减少 HTTP 请求数。
- 使用图片精灵（Sprite）、字体图标或 SVG 替代零碎图片。
-
优化传输
- 使用 HTTP/2 / HTTP/3，支持多路复用和头部压缩。
- 静态资源开启 Gzip/Brotli 压缩，减少数据体积。
- 合理使用 CDN，缩短传输距离。
4.2 渲染层优化
-
避免阻塞渲染
- 将 CSS 放在
<head>，但 JS 尽量放在文档底部，或使用defer、async。 - 减少大体积同步脚本，避免长时间阻塞主线程。
- 将 CSS 放在
-
优化重排（Reflow）和重绘（Repaint）
- 尽量减少对 DOM 的频繁修改，可以使用 文档片段（DocumentFragment） 或 批量修改。
- 避免逐帧修改样式，尽量合并多次修改（如
classList.add()一次性完成）。 - 使用
transform和opacity来实现动画，因为它们不会触发重排，只会触发合成层更新。
-
减少图层复杂度
- 不要滥用
will-change或translateZ(0)强制开启 GPU 加速，否则会消耗更多内存。 - 仅在必要时才创建独立图层（如固定定位、复杂动画）。
- 不要滥用
4.3 JavaScript 优化
-
代码拆分与懒加载
- 使用 Tree Shaking 去掉无用代码。
- 路由级别拆分代码（Code Splitting），按需加载模块。
-
减少主线程压力
- 将耗时任务放到 Web Worker，避免阻塞 UI 渲染。
- 对高频事件（
scroll、resize、input）使用 防抖/节流。
4.4 图片与多媒体优化
-
使用合适格式：
- 图标类用 SVG；
- 高清图片用 WebP/AVIF 替代 JPEG/PNG；
- 小图用 Base64 或 Data URI 内联，减少请求。
-
响应式加载：
<picture>和srcset提供多分辨率资源，避免移动端加载过大文件。- 对非首屏图片使用 懒加载（lazyload）。
4.5 首屏加载优化
-
预加载与预渲染
<link rel="preload">提前加载关键资源。<link rel="prefetch">为未来可能使用的资源做准备。
-
SSR / CSR / Hydration
- 首屏渲染采用 SSR（服务端渲染） 提升速度。
- 或结合 CSR（客户端渲染） 与 Hydration，实现更快交互体验。
结语
浏览器从 输入 URL → 网络请求 → 页面渲染 的过程，其实是网络、系统、前端工程综合作用的结果。
- 更快的页面加载（网络优化 + 缓存策略）；
- 更流畅的用户体验（减少重排重绘 + 合理使用 GPU 加速）；
- 更高效的代码组织（代码拆分、懒加载、Web Worker）。
评论
昵称：Alice时间：2025-08-13
这是一个顶级评论
回复：
这是对 Alice 评论的回复