序言
首屏加载速度，是前端性能优化中最基础、也最能直接影响用户体验的核心命题。我们熟知的优化手段有很多：懒加载、代码分割、资源压缩、缓存策略、构建优化…… 但往往只停留在 “用了什么方案”，却很少深究：真正阻塞页面渲染的瓶颈到底在哪里？
在近期的学习与项目实践中，我逐步梳理出浏览器从输入 URL 到页面完全呈现的全链路关键节点，并整理出一系列常见性能瓶颈。本文将作为「前端性能优化系列」的开篇，从页面加载全流程出发，逐一拆解各阶段瓶颈与成因，为后续的优化策略、性能监控与落地实践打下基础。
问题1：页面加载大致过程是怎样的？
当我们在浏览器地址栏输入 URL 并回车后，整个页面加载过程大致会经历三个核心阶段。
在这三个阶段中，主要会出现以下几类的性能瓶颈：
1. 发起请求阶段
DNS 解析耗时
DNS 解析本身会产生网络耗时，优化思路主要围绕缓存与预解析展开：
- DNS 查询会优先走本地与浏览器缓存；
- 浏览器支持 DNS 预获取（
dns-prefetch），可以在页面初始化或 WebView 启动时提前配置； - 实际请求时会先检查浏览器缓存，命中则无需再向 DNS 服务器发起查询，显著降低耗时。
本地缓存机制
浏览器缓存是请求阶段最直接的性能优化点，主要分为两类：
- 强缓存：浏览器根据响应头中的
Expires和Cache-Control判断资源是否仍在有效期。若命中强缓存，直接从本地读取资源，完全不发送请求到服务端；未命中则走完整请求流程。 - 协商缓存：浏览器会先向服务器发送校验请求，通过
Last-Modified/ETag验证资源是否未发生变化。若命中协商缓存，服务器仅返回 304 状态，浏览器继续使用本地缓存；未命中则服务器返回最新资源。
HTTP/1.1 对同一域名的连接数限制
-
在 HTTP/1.1 下，浏览器对同一域名默认最多同时建立 6 个连接，超出的请求会进入排队阻塞状态；
-
针对多资源、高并发场景，常见优化方案：
- 做好域名规划，按资源类型合理拆分；
- 适当采用域名发散，使用多个不同域名部署静态资源，提升浏览器并行请求能力。
2. 服务端数据处理阶段
服务端数据处理阶段，是指 WebServer 接收到请求后，从数据存储层获取数据并返回给前端的过程。
整体流程如下：
该过程的核心瓶颈在于：是否做了数据缓存、是否开启 Gzip 压缩、是否存在重定向。
Gzip 压缩
Gzip 能将文本类资源压缩至原大小的 1/3 左右，大幅减少传输体积，提升下载速度。一般Nginx会默认开启，是性价比极高的优化手段。
CDN 缓存
CDN 通过在网络各处放置节点服务器，将用户的请求导向离用户最近的服务节点上。
这些边缘节点会缓存静态资源（如图片、JS、CSS、字体等），用户请求时优先从节点获取资源，不需要每次都回源站请求，从而大幅降低网络时延，减轻源站压力。
重定向
重定向包括服务端 302、META 标签、JS 的 window.location 跳转。
无论哪种，都会引发新的 DNS 查询、TCP 握手、TLS 协商和 HTTP 请求，明显增加耗时，属于典型性能瓶颈。
3. 页面解析和渲染阶段瓶颈点
服务端返回数据后，客户端拿到 HTML、CSS、JS 资源，便进入解析 → 布局 → 绘制 → 合成的渲染流程。这一阶段环节多、阻塞风险高，是前端性能最容易出问题的地方。
最容易成为瓶颈的环节：DOM 树构建与布局（重排） 。
1. 构建 DOM 树的瓶颈点
（1）HTML 不规范、语义化差、标签嵌套混乱
标签书写不标准、嵌套错误、容错修复过多，会让浏览器花费额外时间进行语法纠错。
（2）DOM 节点数量过多
DOM 树越大、节点越多，解析、遍历、计算样式的耗时就越长。
👉 优化：分片渲染（借鉴 Fiber 思想） 一次性渲染大量 DOM 会造成卡顿，可将渲染任务拆分为小批次，按帧分批执行，避免长时间阻塞主线程。
（3）同步 JavaScript 阻塞解析
HTML 解析遇到 <script> 脚本时会完全暂停 DOM 构建，直到：
- 脚本下载完成
- 且 CSSOM 构建完成
- 脚本执行完毕
解析被阻塞期间，页面呈现空白，用户无任何内容可见。一个普通脚本就可能让解析时间从 200ms 涨到 1s 以上。
优化方式
- 脚本尽量放在页面底部
- 使用
defer/async实现异步加载 - 非关键脚本采用延迟执行
👉 优化：长任务拆分（JS执行耗时长），将复杂计算、长耗时逻辑拆分为微任务 / 宏任务，或使用 requestIdleCallback、Web Worker 放到后台执行，避免阻塞 DOM 解析。
2. 构建 CSSOM 树的瓶颈点
CSS 不会阻塞 DOM 解析，但会阻塞 JavaScript 执行和页面渲染。浏览器必须等 CSSOM 构建完成，才能开始布局与绘制。
如果首屏使用外链 CSS，下载过程会直接阻塞渲染，导致白屏时间变长。
👉 优化：关键 CSS 内联将首屏必需的布局样式、骨架屏样式内联在 <head>，避免外链 CSS 下载阻塞渲染，让浏览器尽快生成 CSSOM 并进入渲染流程。
3. 布局（Layout / Reflow）中的瓶颈点
布局就是浏览器计算元素大小、位置、排版的过程，采用流式布局模型，需要自上而下遍历整个 DOM。
布局阶段是渲染链路中开销最大、最容易阻塞的环节，主要瓶颈有：
（1）频繁触发重排（Reflow）
任何会改变元素几何信息（尺寸、位置、显示隐藏）的操作，都会触发重新布局。例如：
- 修改
width / height / margin / padding / top / left - 增删 DOM
- 图片加载后尺寸未预留，导致页面 “跳动”
一次重排往往会引发连锁反应，父元素、子元素、兄弟元素全部重新计算，开销极大。
（2）合成层不合理，频繁整体重绘
没有合理开启 will-change 或提升合成层，导致微小动画也触发整页重排重绘。
结束
以上就是我对页面加载全流程的常见性能瓶颈梳理，内容偏基础，下一篇文章我们将围绕‘如何监控首屏性能’和‘优化实战案例’展开”。
欢迎大家一起交流学习，共同进步～
