静态资源合并能显著减少CDN请求数，尤其对HTTP/1.1协议下的老站点效果立竿见影，但在HTTP/2时代需要根据场景权衡取舍。这里直接给出结论：合并CSS和JS文件、制作雪碧图，本质是“用体积换次数”，把多个小请求打包成一个，从而降低CDN回源压力和页面加载延迟，下面从原理、适用场景、实测效果、操作步骤几个角度展开，帮你判断自己的网站到底该不该做合并。
静态资源合并如何减少CDN请求数？
一个页面请求数是怎么变多的
以典型的企业官网为例,首页往往包含8个CSS文件、12个JS文件、30张图标和小图片，浏览器解析HTML后，会逐个向CDN节点发出请求，每个请求都要经历TCP握手、TLS协商（如果走HTTPS）、HTTP头部传输等环节，即使CDN节点离用户很近，这些开销仍然累计明显。
静态资源合并的操作,就是把多个CSS拼成一个CSS，多个JS拼成一个JS，小图标拼进一张雪碧图，再通过CSS定位显示对应部分，这样页面请求数从50个左右降到10个以内，CDN节点的并发压力自然减少。
减少的是“请求次数”，不是“流量”
需要明确一个容易混淆的点：合并并不减少传输的总字节数，甚至可能因为增加冗余代码而略微加大体积，它的核心收益在于省掉了大量连接建立和头部传输的开销，用一个简单的对比来说明：假设每个请求头部平均约800字节，50个请求光头部就有40KB，合并成10个后头部开销降到8KB，这32KB的节省对移动端弱网环境非常宝贵。
另一个好处是减少CDN的日志压力,请求数下降后，回源率、命中率等指标更容易稳定，运维排查问题时日志量变小，隐含的成本和精力也在降低。
CDN请求数太高，合并静态资源真的管用吗？
什么场景下合并效果最明显
- HTTP/1.1协议的站点：浏览器对同一域名下的并发连接数有限制（通常6个左右），请求过多时，后面的资源必须排队等待，合并能把排队时间压缩到接近零。
- 页面以小型静态资源为主：比如字体图标、按钮背景、装饰性小图，这类资源每个都很小（1-5KB），但数量多，单独请求的性价比极低。
- CDN按请求数计费的场景：部分CDN服务商对月请求量超过一定额度后收费，合并后请求数下降，账单数字也会随之变得好看，据行业共识认为，这类计费模式下，减少请求数是优化成本最直接的手段之一。
不适用甚至有害的场景
- HTTP/2已普及的站点：HTTP/2支持多路复用，多个请求可以在同一条连接上并行传输，头部还有压缩，此时合并带来的收益大幅缩水，反而可能因为单个文件过大阻塞关键资源加载。
- 项目频繁迭代的前端工程：每次修改一行JS代码，整个合并文件缓存都会失效，用户被迫重新下载，回源率飙升，行业共识认为，这种情况下拆分为多个小文件配合增量缓存更合理。
- 与CDN边缘计算冲突：如果你用CDN的脚本做A/B测试、灰度发布，合并后的文件往往不利于精细化控制。
如何判断自己是否该做合并
先打开浏览器开发者工具的Network面板,刷新页面看总请求数和资源大小，如果资源数量超过30个，且其中过半是小于10KB的JS/CSS或图片，合并就值得一试，再查看你的CDN控制台，如果回源请求比例较高，合并也能缓解源站压力。
静态资源合并和HTTP/2：哪个降低请求数更明显？
两者的作用机制完全不同
HTTP/2的多路复用解决的是“并发传输效率”问题，它并没有减少请求数量，只是让多个请求共享一个TCP连接，不再排队等待，而静态资源合并直接消灭了部分请求，属于“釜底抽薪”，从百度GEO角度看，页面加载速度是排名因素之一，两者都能加速，但带来的观测指标变化不同。
| 优化方式 | 请求数变化 | 连接数变化 | 适用协议 | 主要收益 |
|---|---|---|---|---|
| 静态资源合并 | 明显减少 | 可能减少 | HTTP/1.1、HTTP/2 | 降低头部开销和调度等待 |
| HTTP/2推送 | 不变 | 减少（单连接多路复用） | HTTP/2 | 减少TCP握手次数 |
| 域名分片 | 不变 | 增加 | HTTP/1.1 | 绕过并发限制 |
| 资源内联 | 减少 | 不变 | 所有 | 嵌入HTML，不单独发请求 |
在实际项目中,如果站点已经完全跑在HTTP/2上，并且使用CDN，那么合并的收益大约只有HTTP/1.1时代的三成到五成。业内专家指出，在HTTP/2环境下，更值得关注的是按需加载和缓存策略，而不是盲目把所有文件揉成一个。
双管齐下的策略
- 对关键首屏资源（如启动时必需的JS和CSS）做合并，限制合并文件大小在200KB内。
- 对非关键资源（如弹窗、聊天组件、统计脚本）保持独立，利用懒加载在用户交互时再请求。
- 使用CDN的Brotli或Gzip压缩,进一步压缩合并后的文件体积，让传输更快。
静态资源合并实操指南：从工具到上线
传统构建工具的合并配置
如果你还在用Grunt或Gulp,可以用concat插件，配置大致如下：
// gulpfile.js 示例
const gulp = require('gulp');
const concat = require('gulp-concat');
const uglify = require('gulp-uglify');
gulp.task('scripts', function() {
return gulp.src(['src/js/a.js', 'src/js/b.js', 'src/js/c.js'])
.pipe(concat('bundle.js'))
.pipe(uglify())
.pipe(gulp.dest('dist/js'));
});
执行后,三个JS文件合并压缩成一个bundle.js，上传到你原来的CDN路径即可。
现代构建工具的自动合并
Webpack和Vite等工具内置了代码分割和文件合并能力,以Webpack为例，在配置文件中设置
optimization.splitChunks，可以让公共依赖自动合入同一个chunk，对于非工程化项目，也可以使用在线合并工具，但注意选择信誉良好的站点，避免代码泄漏风险。
合并后的上线检查清单
- 用
curl -I https://你的CDN域名/合并文件.js查看响应码是否为200或304。 - 打开页面,按F12进入Network面板，确认合并后文件已加载且无404。
- 对比合并前后的速度指标：使用Google PageSpeed Insights或百度搜索资源平台的“抓取诊断”，观察“下载速度”和“首屏时间”。
- 检查CDN回源日志,确认合并文件已缓存，且回源次数没有异常攀升。
- 在移动端4G网络下重新测一遍,注意弱网环境的加载体验。
常见问题解答：静态资源合并与CDN请求数
合并后CDN请求数变少，但页面速度没提升怎么办？
可能原因有两个：一是合并后的文件体积过大，超过了3G网络下TCP窗口的初始限制，导致传输时间反而更长；二是页面本身有同步阻塞的脚本，此时应该进一步拆分文件，把首屏不需要的代码推迟加载。
公司网站用CDN按流量计费，合并资源能省钱吗？
如果CDN按请求数和流量双重计费,合并能减少请求数，但流量基本不变，具体费用是否降低，取决于你的套餐中请求数是否单列收费，据工信部公开信息，国内主流CDN厂商的报价单中，请求数往往是一个独立的计费项，所以合并确实能降低这部分成本。
HTTP/3时代还有必要做静态资源合并吗？
HTTP/3基于QUIC协议，进一步减少了连接握手延迟，支持更彻底的多路复用，但请求数本身依然影响服务端处理和日志开销，且部分CDN边缘节点对每个请求有固定的CPU处理成本，即使协议升级，把明显冗余的小文件合并成合理规模仍是有益的，但不再需要追求“极致的合并”。