浏览器从输入网址到页面加载的整个过程
浏览器从输入网址到页面加载的整个过程
“从在地址栏输入 URL 到页面渲染完成，发生了什么？”是前端高频面试题，也是理解 Web 工作原理的关键路径。这个过程涉及浏览器、操作系统、DNS、CDN、Web 服务器、HTTP/HTTPS、渲染引擎等多个组件。
本文按照时间顺序，梳理整个流程：
- 用户输入 URL 与地址栏处理
- 浏览器进程与网络进程协作
- DNS 解析与 IP 获取（含缓存与 CDN）
- TCP 三次握手 + TLS 握手（HTTPS）
- 发送 HTTP 请求与服务器处理
- 浏览器接收响应、缓存与重定向
- 渲染流程：解析 HTML/CSS/JS、构建 DOM/CSSOM、布局与绘制
- 关键性能点：首字节时间、首屏渲染、JS 阻塞、资源加载优化
一、输入 URL 与导航开始
1. 地址栏解析
当你在地址栏输入 sunjc.vip 并回车时，浏览器需要判断你输入的是：
- 搜索词？（走搜索引擎）
- 还是一个 URL？（走导航流程）
通常：
- 检测到有协议前缀（如
http://、https://）时按 URL 处理 - 否则尝试补全协议（默认
https://）并做一定规则判断
2. 浏览器进程与网络进程
现代浏览器是多进程架构，至少包括：
- 浏览器进程：负责 UI、地址栏、书签、网络资源的统一协调
- 网络进程：负责真正发起网络请求
- 渲染进程：负责页面解析、布局、绘制、JS 执行
导航开始时，浏览器进程会将 URL 转交给网络进程，由网络进程开始后续“网络请求”阶段。
二、DNS 解析：域名 → IP 地址
要访问 https://sunjc.vip，首先要把域名解析成 IP 地址，这就是 DNS 的工作。
1. 多级缓存
为减少延迟，DNS 解析会优先命中缓存：
- 浏览器缓存：最近访问过的域名解析结果
- 操作系统缓存：如本地 DNS cache
- 本地 hosts 文件：如
127.0.0.1 sunjc.vip - DNS 服务器缓存：运营商或公共 DNS（8.8.8.8 / 1.1.1.1）
只有都未命中时，才会发起完整的 DNS 递归查询。
2. 递归查询与权威 DNS
简化流程：
- 向本地 DNS 服务器（运营商/公共 DNS）发起查询
- 若其没有缓存，会从根域名服务器开始，逐级查询：
- 根（.
）→ 顶级域（.vip）→ 权威 DNS（负责sunjc.vip`）
- 根（.
- 最终获取域名对应的 IP 地址（如
1.2.3.4）
3. CDN 介入（关键优化点）
如果网站使用了 CDN（如 cdn.xxx.com），DNS 解析时会根据：
- 用户所在地域
- 运营商/网络情况
返回“离用户最近”的边缘节点 IP，从而减少延迟。
三、建立连接：TCP 三次握手 + TLS 握手（HTTPS）
拿到服务器 IP 后，浏览器需要与服务器建立连接。
1. TCP 三次握手
在 HTTP/1.1 或 HTTP/2 over TLS 中，底层使用 TCP：
- SYN：客户端 → 服务器，发起连接请求
- SYN-ACK：服务器 → 客户端，回应请求
- ACK：客户端 → 服务器，确认收到
三次握手完成后，TCP 连接建立。
2. TLS 握手（HTTPS）
若是 HTTPS（几乎所有现代站点都已是），在 TCP 之上还需要：
- 协商 TLS 版本与加密套件
- 服务器发送证书（含公钥），浏览器验证证书链是否合法、未过期、域名匹配
- 交换对称加密密钥（通常使用非对称加密来安全协商）
- 使用对称加密进行后续 HTTP 报文的加解密
TLS1.3 以后握手流程有所简化，可以与 TCP 建连更紧密地复用，减少 RTT（往返次数）。
四、发送 HTTP 请求
连接建立后，浏览器会构造并发送 HTTP 请求报文，包括：
- 请求行：
GET /path HTTP/1.1 - 请求头：Host、User-Agent、Accept、Cookie、Referer 等
- 可选请求体：如 POST/PUT 等携带的 JSON、表单、文件等
常见优化点：
- 使用 HTTP/2 多路复用，复用同一 TCP 连接发起多请求，避免“队头阻塞”
- 利用 Keep-Alive 复用连接，减少三次握手开销
五、服务器处理请求并返回响应
服务器侧大致流程：
- 负载均衡（如 Nginx/SLB）接收请求
- 转发给后端应用（Node.js、Java、Go 等）
- 应用处理业务逻辑：
- 路由匹配
- 权限验证
- 访问数据库/缓存/第三方服务
- 生成响应：
- 响应行：
HTTP/1.1 200 OK - 响应头：Content-Type、Cache-Control、Set-Cookie、Content-Encoding 等
- 响应体：HTML、JSON、文件流等
- 响应行：
如果是静态资源：
- 通常通过 Nginx/静态服务器/CDN 直接返回，不必走业务应用。
六、浏览器接收响应、缓存与重定向
1. 状态码处理
200：正常返回301/302：重定向，浏览器会根据 Location 再发起新请求304：协商缓存命中，使用本地缓存内容4xx/5xx：错误页面
2. 缓存策略
基于响应头：
Cache-Control、Expires（强缓存）ETag、Last-Modified（协商缓存）
浏览器会决定：
- 是否直接使用缓存（不发请求）
- 是否需要发起条件请求确认资源是否更新
七、渲染流程：从 HTML 文本到可见页面
拿到 HTML 文本后，浏览器会启用/创建渲染进程，并开始执行以下步骤（以 Chrome 为例）：
1. 解析 HTML，构建 DOM 树
- 自上而下解析 HTML
- 遇到标签，生成对应 DOM 节点并挂载到 DOM 树
- 遇到错误标签时做容错修复
2. 解析 CSS，构建 CSSOM
- 解析
<style>标签与外链 CSS（<link rel="stylesheet">） - 解析内联样式、style 属性
- 应用层叠、继承与优先级生成 CSSOM
注意：CSS 是渲染阻塞资源，即：
- 在构建 Render Tree 之前，需要有基础 CSSOM
3. 处理 JavaScript
遇到 <script> 标签时：
若是同步脚本（无
defer/async）：- HTML 解析会暂停
- 下载并执行 JS
- JS 可能修改 DOM（document.write、appendChild 等）
- 执行结束后继续解析 HTML
若是
defer：- 下载过程不阻塞 HTML 解析
- 在 DOM 解析完成后按顺序执行
若是
async：- 下载过程不阻塞 HTML 解析
- 下载完成后立刻执行，可能打乱顺序
4. 构建渲染树（Render Tree）
- 将 DOM 树与 CSSOM 结合
- 过滤掉不可见节点（如
display: none） - 生成 Render Tree：每个可见元素都有对应渲染对象
5. 布局（Layout）与重排
为每个渲染对象计算：
- 几何位置（x、y）
- 尺寸（宽高）
这一步有时也称为“重排（reflow）”。
6. 绘制（Paint）与合成（Composite）
- 根据样式绘制文字、颜色、边框、阴影、图片等
- 将不同图层（如新 stacking context、GPU 加速层）进行合成
- 最终输出到屏幕（可能涉及 GPU 加速）
八、关键性能节点与优化点
在这一整条链路上，有一些对前端性能尤为关键的节点：
- TTFB（首字节时间）：受 DNS、TCP/TLS、后端处理时间影响
- FCP（首次内容绘制）：用户第一次看到内容的时间
- LCP（最大内容绘制）：关键内容（如大图、主标题）完成绘制的时间
- CLS（布局偏移）：页面加载过程中是否“抖动”
- INP（交互延迟）：点击、输入等交互的响应速度
前端可优化的方向包括：
- 使用 CDN、合理拆分静态资源（减少 TTFB）
- 图片优化、资源压缩、缓存策略（优化 LCP）
- 避免图片/广告位导致布局频繁变化（优化 CLS）
- 控制 JS 大小与执行时机、避免长任务（优化 INP）
关于性能指标与 RUM 监控，可以参考你现有的《真实用户监控(RUM) 与 Web Vitals》文章做进一步串联。
九、总结
从“输入 URL 到页面加载完成”的完整链路，可以粗略拆为三大阶段：
- 网络阶段：DNS 解析 → TCP/TLS 握手 → 发送请求 → 接收响应 → 缓存与重定向
- 浏览器内部协调阶段：进程模型、导航、资源调度
- 渲染阶段：解析 HTML/CSS/JS → 构建 DOM/CSSOM/Render Tree → 布局与绘制
理解这条链路，不仅可以帮助你更好地回答面试题，更重要的是：
- 帮助你定位性能瓶颈（到底慢在 DNS？后端？前端渲染？）
- 帮助你做出有针对性的优化（缓存、CDN、代码拆分、懒加载、骨架屏等）
你可以把这篇文章当作一个“总览地图”，再结合其它专题（性能优化、HTTPS、浏览器渲染、Event Loop 等）深入某个局部。