简介：本文围绕前端性能优化的常见手段展开，包括请求合并、资源压缩、连接复用等，结合实测数据量化各手段的收益，帮助开发者在真实业务中合理制定优化策略，避免盲目投入。
在移动优先、体验至上的今天，前端性能已经成为产品竞争力的重要组成部分。几乎每一位前端开发者都听过“减少请求数”“开启压缩”“使用 CDN”这类优化建议，但一个更实际的问题往往被忽略：每种优化手段到底能带来多大的收益？在资源有限的情况下，应该优先做哪些？
本文试图从量化角度回答这个问题。基于一组接近真实网页结构的基准测试，我们逐项分析常见优化手段的效果，并讨论其适用边界。
为了让测试数据具有参考价值，首先需要构造一个贴近真实互联网网页的基准场景。参考公开的 HTTP Archive 统计趋势，典型网页的结构大致如下：
测试环境采用单核 2 GB 内存的云主机，按流量计费，峰值带宽 100 Mbps。需要说明的是，单机测试存在局限性，更严谨的结论应当来自大样本的真实用户监测数据。但作为横向对比，该基准足以反映各手段的相对收益。
核心原理：浏览器对同一域名的并发连接数有限（HTTP/1.1 下通常为 6 个），请求数越多，排队和往返延迟的累积越明显。合并请求的本质是减少网络往返次数（RTT），而不是减少字节数。
常见做法：
收益分析：在上述基准中，将 27 个 JS 合并为 3 个、5 个 CSS 合并为 1 个、45 个小图标合并为 1 张 Sprite 后，总请求数从 90 降到约 20。在延迟较高的移动网络下，收益尤其显著——每个请求节省的不仅是传输时间，更是连接建立与排队等待的时间。
注意事项：
Minify：去除代码中的空格、注释、换行，缩短变量名。对 JS/CSS 文本资源通常可减少 20%–40% 的体积，且不改变运行语义。这是构建流程中最基础的一步。
Gzip：在传输层对文本资源进行压缩，通常可将 JS/CSS/HTML 体积压缩至原始的 20%–30%。它与 Minify 是互补关系：先 Minify 再 Gzip，效果最佳。
收益分析：基准中 404 KB 的 JS 经 Minify 后约 280 KB，再经 Gzip 后约 90 KB；CSS 从 71 KB 压缩至约 18 KB。对于文本类资源，这是投入产出比最高的优化之一，几乎零成本。
注意事项：
核心原理：HTTP/1.1 默认开启持久连接，允许在同一个 TCP 连接上发送多个请求，避免反复进行 TCP 三次握手和 TLS 握手。
收益分析：在 HTTPS 场景下，一次完整的 TLS 握手可能消耗 2–3 个 RTT。若 90 个请求分散在多个短连接上，握手开销将占据相当比例的总耗时。开启 Keep-Alive 后，这部分开销被摊薄到一次连接中，对首屏加载时间的改善通常在 10%–20%。
注意事项：
核心原理：在 HTTP/1.1 时代，浏览器对单域名并发连接数有限制，将资源分散到多个域名（如 static1、static2）可以突破这一限制，提升并行下载能力。
收益分析：在 HTTP/1.1 下，适度拆分（2–4 个域名）确实能提升并发度。但每个新域名都意味着额外的 DNS 解析和 TCP/TLS 握手开销。在 HTTP/2 普及后，单连接多路复用已能高效处理大量请求，域名拆分反而增加了连接管理成本，收益为负。
结论：这是典型的“时代性优化手段”。在新项目中应优先采用 HTTP/2 或 HTTP/3，将资源集中在少量域名下。
| 优化手段 | 主要收益维度 | 相对收益 | 实施成本 |
|---|---|---|---|
| Minify + Gzip | 传输体积 | 高 | 低 |
| 合并请求 | 往返次数 | 中高 | 中 |
| Keep-Alive | 连接开销 | 中 | 低 |
| 域名拆分 | 并发度 | 低（HTTP/2 下为负） | 中 |
优先级建议：
性能优化没有“银弹”，也不存在放之四海皆准的收益数字。业务形态、用户网络环境、设备性能都会显著影响实际效果。真正有效的做法是：
优化的本质，是在有限的资源下，把时间花在对用户感知影响最大的环节上。理解每种手段背后的原理与边界，远比记住一份“优化清单”更重要。