简介：前端性能优化手段众多，但不同手段的实际收益往往因页面结构和业务场景而异。本文基于一组接近真实统计特征的测试页面，对比合并请求、域名拆分、Gzip压缩、Keep-Alive和Minify五种常见优化方式在请求数、传输体积和加载时间上的表现差异，帮助开发者在性能优化时建立更清晰的优先级判断和选型依据。
前端性能优化是Web开发中的高频话题，但在实际工程中，优化手段的选择常常依赖经验判断而非数据支撑。不同团队对“合并请求能快多少”“Gzip压缩到底有多大作用”“域名拆分是否仍然必要”等问题存在明显认知差异。更关键的是，同一种优化手段在不同页面结构、网络环境和资源组成下，收益可能截然不同。
为了更好地理解各类优化手段的适用边界，有必要构建一个相对可控的测试环境，对几种常见优化方式的作用效果进行横向对比。这样的对比不是为了得出“哪种手段最优”的简单结论，而是希望揭示：在特定页面特征下，各类优化分别解决了什么问题，瓶颈在哪里，以及它们之间是否存在叠加或替代关系。
本次对比围绕五种前端性能优化手段展开：合并请求、域名拆分、开启Gzip、开启Keep-Alive和Minify。它们分别作用于HTTP请求的建立、传输、压缩和资源体积等不同环节，具有天然的对比价值。
合并请求是指将多个独立的CSS文件、JavaScript文件或小图标资源合并为更少的文件，从而降低浏览器需要发起的HTTP请求数量。常见实现方式包括合并CSS和JS文件，以及将多个小图片合并为一张精灵图（CSS Sprite）后通过背景定位进行使用。
域名拆分是将页面资源分布到多个域名下加载，以突破浏览器对单一域名并发连接数的限制。在HTTP/1.1时代，浏览器通常对同一域名同时建立的TCP连接数量有上限，因此将资源分散到多个域名可以提升并行加载能力。
Gzip是一种通用的数据压缩格式，在HTTP传输中被广泛用于压缩文本类资源，如HTML、CSS和JavaScript。服务器在返回资源前先进行压缩，浏览器收到后再解压还原。由于文本类资源通常具有较高的压缩比，Gzip可以有效减少传输字节数。
Keep-Alive即HTTP持久连接，允许浏览器与服务器之间复用同一个TCP连接进行多次请求和响应，避免每次请求都重新建立连接。在HTTP/1.1中，Keep-Alive是默认行为，但实际效果受服务器配置和超时时间影响。
Minify是指对CSS、JavaScript等文本资源进行最小化处理，包括删除注释、空白字符、冗余分号，以及压缩变量名等。Minify不改变代码逻辑，但可以显著缩小文件体积。
由于不同网站的页面构成差异巨大，直接使用某个真实站点作为基准容易引入偏差。为此，测试参考了行业公开的页面统计特征，构造了一个接近平均水平的基准页面。该页面的核心参数如下：
| 指标 | 数值 |
|---|---|
| 总请求数 | 90个 |
| 总传输大小 | 约1.6MB |
| HTML请求 | 1个，约4.1KB |
| CSS请求 | 5个，总计约71.2KB |
| JS请求 | 27个，总计约404KB |
| 图片请求 | 57个，总计约1.1MB |
其中图片资源包含12张大图和45个3KB以下的小图标。测试页面中的CSS和JS内容来自通用开源代码库，且刻意排除了会修改DOM结构的脚本，以避免渲染逻辑对加载过程产生干扰。测试关注的是资源加载性能本身，而非渲染性能。
测试环境部署在一台1核2G内存的云服务器上，通过Nginx进行不同优化项的配置切换。测试工具选用提供真实用户客户端测量的第三方性能监测服务，以获取更接近实际用户侧的数据。
合并请求的核心逻辑是降低请求数量。每个HTTP请求都伴随着连接建立、请求头传输和响应头解析等固定开销。对于小文件而言，这些固定开销在整个加载时间中的占比可能远高于文件本身的传输时间。合并后，虽然单个文件体积增大，但请求总数减少，总体加载时间往往能获得改善。
从测试数据看，合并JS、CSS和精灵图后，请求数量从90个显著下降。但需要注意的是，合并请求并非没有代价。过度合并可能导致单个文件过大，反而影响首屏渲染的启动速度，因为浏览器需要完整下载后才能解析执行。
域名拆分解决的是并发连接限制问题。在HTTP/1.1协议下，浏览器对同一域名的并发连接数通常限制在6个左右。当一个页面有大量资源需要加载时，这一限制可能成为性能瓶颈。将资源分配到不同域名后，每个域名都享有独立的并发连接额度，从而提高整体并行度。
不过，域名拆分也有其代价：每个新域名都意味着额外的DNS解析开销和TCP连接建立成本。对于资源数量不多或已经使用HTTP/2的场景，域名拆分的收益会明显减弱，甚至可能因为额外握手开销而适得其反。
Gzip压缩的收益来源非常直观：文本类资源的压缩比通常可以达到60%到80%。在测试中，71.2KB的CSS和404KB的JS在开启Gzip后，实际传输体积大幅下降。对于带宽受限或移动网络用户，这直接转化为更短的内容下载时间。
Gzip的成本主要在服务器端的压缩处理和浏览器端的解压处理。对于现代硬件而言，这一开销通常可以忽略，但在极高并发场景下，压缩操作会消耗一定的CPU资源。此外，Gzip对已经高度压缩的格式（如JPEG、PNG图片）作用甚微，因此通常只对文本类资源开启。
Keep-Alive的作用在于消除重复的TCP握手过程。在未开启持久连接时，每个HTTP请求都需要独立完成TCP三次握手，部分场景下还要进行TLS握手。对于包含大量资源的页面，这部分开销累计起来相当可观。
测试显示，开启Keep-Alive后，后续请求可以复用已有连接，减少了连接建立时间。实际收益在资源数量多、单个资源较小的场景下更明显，因为这类场景中握手开销占总耗时的比例更高。
Minify与Gzip可以形成互补。Gzip是在传输层面进行压缩，而Minify是在代码层面去除冗余字符。经过Minify处理后的CSS和JS文件在未压缩状态下已经更小，再叠加Gzip后总传输体积进一步降低。测试中，对JS和CSS资源进行Minify后，文件体积有明确减少，典型降幅在20%到40%之间。
以下从多个维度对五种优化手段进行横向比较：
| 对比维度 | 合并请求 | 域名拆分 | Gzip压缩 | Keep-Alive | Minify |
|---|---|---|---|---|---|
| 作用环节 | 请求数量 | 连接并行度 | 传输体积 | 连接复用 | 文件体积 |
| 主要收益来源 | 减少请求开销 | 突破并发限制 | 降低传输字节 | 减少握手次数 | 删除冗余代码 |
| 对图片资源有效 | 间接有效（精灵图） | 有效 | 基本无效 | 有效 | 无效 |
| 对文本资源有效 | 有效 | 有效 | 高度有效 | 有效 | 高度有效 |
| 实现复杂度 | 中等 | 较低 | 较低 | 极低 | 较低 |
| 部署改动量 | 需要构建流程配合 | 需DNS和资源路径调整 | 服务器配置即可 | 服务器配置为主 | 构建流程加入 |
| 潜在副作用 | 过大文件影响首屏 | 额外DNS和握手开销 | 少量CPU开销 | 长时间占用连接数 | 可调试性下降 |
| 与HTTP/2兼容性 | 需重新评估 | 收益减弱 | 依然有效 | 原生支持 | 依然有效 |
当页面包含大量小体积资源（如几十个小图标、多个小型CSS/JS文件）时，合并请求的收益通常最为显著。将45个小图标合并为精灵图，可以将数十个请求压缩为1个，请求建立和关闭的开销被大幅摊薄，这也是本次测试中请求合并带来明显改善的主要原因。
在移动网络环境下，传输体积对加载时间的影响被放大。Gzip和Minify的组合能在不改变页面功能的前提下显著缩小文本资源的传输体积，尤其适合JS和CSS占比较大的应用。对于图片资源，Gzip作用有限，需要另寻压缩或懒加载手段。
当页面资源分布在多个域名下且请求量较大时，若网络协议仍以HTTP/1.1为主，域名拆分的并行加载优势较为明显。但需要注意，每增加一个域名都意味着多一次DNS解析流程。对于使用HTTP/2或资源总量不大的页面，这一手段的实际收益会缩水。
在高延迟网络或需要多次建立连接的场景中，Keep-Alive的收益突出。通过复用连接，减少了握手往返次数，对整体加载时间有稳定贡献。该手段实施成本最低，通常只需在服务器配置中确认开启了持久连接即可。
这五种优化手段并非互斥关系，实际项目中可以组合使用。例如，先通过Minify减小源文件体积，再进行合并以减少请求数，传输时开启Gzip压缩，同时利用Keep-Alive复用连接。域名拆分则需要根据资源数量、协议版本和DNS解析成本综合判断是否启用。
需要特别注意的是，在HTTP/2协议下，部分优化思路需要调整。HTTP/2原生支持多路复用，无需为并发连接数而拆分域名；同时，过度合并文件可能阻碍多路复用对资源的并行调度能力。因此，当服务端和客户端都支持HTTP/2时，合并请求和域名拆分的收益逻辑会发生改变，需要重新评估。
另一个常被忽视的问题是缓存策略与合并请求的关系。合并后的文件一旦有任何改动，整个文件的缓存都会失效，而拆分的文件只需重新下载变更部分。在迭代频繁的业务中，需要在请求数量和缓存粒度之间做权衡。
综合对比来看，前端性能优化没有放之四海而皆准的“最优手段”。选择何种优化方式，取决于页面的资源构成、目标用户的网络环境、现有部署架构以及团队能投入的改造工作量。
性能优化的本质是识别瓶颈并针对瓶颈施加干预。对比不同手段的收益，不应只看某项技术在理论上的提升幅度，更要结合自身页面的实际特征，找出当前加载过程中真正耗时最多的环节，然后选择与之匹配的优化策略。