静态资源合并是降低CDN请求数最直接的手段，通过将多个小文件打包为少量大文件，可显著减少请求次数，进而降低按请求数计费的CDN使用成本。
CDN请求数怎么算费用？先搞懂计费逻辑
CDN费用由流量费和请求数费用组成，这是行业公开的常识，流量费容易理解，按实际下行字节数计算；请求数费用则是按“每万次请求”为单位收取，相当一部分中小网站流量不大，月账单中请求数费用占比却很高,原因就在于此。
业内的普遍做法是，从源头减少页面加载的资源数量，这里说的资源数量，不只是用户在地址栏看到的HTML文件，还包括这个页面加载出的CSS、JavaScript、图片、字体文件，一个典型的电商列表页，未优化时可能加载几十个资源文件,经过合并后能压到个位数。
CDN计费本身不区分资源大小，按次计数，一个1KB的CSS片段和一份200KB的完整样式文件，在请求数维度上是等价的，这意味着合并后,同样的访问量产生的请求次数将大幅下降。
静态资源合并的实际效果：以典型站点为参考
假设一个中等规模的内容站，单页加载35个静态资源，日访问量稳定在3万页面浏览量，优化前，每PV产生35次静态请求，总请求数为105万次/日，把这些资源合理合并后，降低到每PV加载8个文件，总请求数为24万次/日。
这笔账算下来，单日请求量从一百万级掉到二十万量级，月度请求数费用降幅相当可观，连接握手开销同步减少,页面加载速度通常会明显提升。
另一个需要关注的维度是回源请求，资源过于零散时，CDN节点缓存命中的压力更大，特别是冷门资源容易回源，合并后的文件数量少，回源概率显著下降，上游源站的出口带宽成本也能省下一部分，据工信部相关技术白皮书指出，国内主流CDN服务商的请求数计费策略在近年来已经趋于标准化，按“每万次请求”计费是行业共识。
静态资源合并对CDN请求数的降低，不只体现在数字上，还对源站带宽成本、边缘节点缓存命中率产生连锁正向影响，多数情况下，资源合并后CSS/JS文件的体积增长不明显，但浏览器需要发起的请求次数降低了70%左右。
静态资源合并的四种主流方式
静态资源合并的具体技术方案，可按照资源类型和构建流程来区分,以下按实践中优先级从高到低排列。
CSS/JavaScript文件级合并
将多个CSS文件合并为一个，将多个JS文件合并为一个，这是基础操作，对于使用构建工具的前端工程,打包器会自动完成这一步。
实操要点：
- Webpack项目的
SplitChunks插件默认会做公共模块抽离 - Vite项目使用Rollup的
manualChunks配置控制合并粒度 - 不使用构建工具的老项目，可以手动在部署前拼接文件，或用Gulp的
concat插件处理
合并后的文件名需要带上内容哈希值，让CDN在内容更新后能识别出新版本，否则浏览器和边缘节点会持续使用旧缓存,这也是CDN刷新和灰度发布场景中经常被讨论的细节。
雪碧图方案
小图标单张图片就是一次独立请求，一个导航栏有5个图标，5个子页面各用不同样式的按钮图,总体来算几十张小图是常事。
雪碧图把多个小图合并到一张图中，通过CSS的背景定位截取对应区域展示，这种方式在CSS/JS文件合并后，成为请求数优化的第二块重要拼图，但实际工作中要考虑图片体积限制，超大雪碧图会拖慢首次渲染，因此业界通常建议只合并“同域名、同场景”的小图标。
字体图标与SVG合并
字体图标将图标封装为字体文件，一个字体文件能承载上百个图标，请求数从N降至1，SVG合并则通过内联<symbol>定义多个图形，页面通过<use>引用,同样是一次请求。
这两种方案的关键区别在于场景：字体图标的渲染依赖字体加载，首次加载后全站可用；SVG Sprite在服务端渲染页面中更灵活,适合需要动态控制图形颜色的场景。
内联资源合并
内联不是把资源放进同一个文件，而是直接把资源内容嵌入页面，小体积的CSS、SVG图标、Base64图片都可以内联进HTML。
这种做法将请求数降为零，但需要注意副作用：HTML体积增加，如果这个页面被频繁修改，会导致整个页面缓存失效，CDN命中率下降，内联更适合首屏关键样式和极小图标,不适合大面积铺开。
四种方式的对比
| 合并方式 | 请求数降幅 | 适用场景 | 常见注意事项 |
|---|---|---|---|
| CSS/JS文件合并 | 显著，通常减少50%-80% | 所有常规站点 | 注意缓存版本控制 |
| 雪碧图合并 | 中等，看小图标数量 | 图标数量多、体积小的UI | 图片过大会拖慢首屏 |
| 字体图标/SVG合并 | 较显著，约减少30-50次 | 图标体系统一、跨页面复用 | 字体文件加载顺序需优化 |
| 内联资源 | 完全消除个别请求 | 首屏关键内容 | 避免大体积图片和频繁变更内容 |
静态资源合并和打包对比：哪种方式更适合你的站点
不少从业者把静态资源合并和静态资源打包当成同一件事,这两者在技术落地和效果层面上存在明显差异。
静态资源合并强调的是“数量归拢”，本质是把原有独立请求变成批量请求，比如把10个JS文件拼接成2个文件，逻辑依旧按原顺序执行,不一定经过编译处理。
静态资源打包则建立在现代构建工具链上，将源码中的多个模块通过依赖分析、Tree Shaking、代码分割等手段，打包成一组优化后的文件，打包器输出的文件不一定“少”，但一定“精”,因为它能移除无用代码和重复声明。
实际操作中,推荐按以下方式选择：
- 传统多页面网站，没有构建流程：优先手动合并或使用简单的Gulp脚本，按页面维度将公共样式和公共JS各合为一个文件
- 使用Vue/React开发的应用：依赖Webpack或Vite的打包能力，重点配置缓存组，把第三方库包和业务代码包按更新频率拆分，固定版本第三方库打包成一个文件，业务代码按页面路由拆分
- 微信小程序等平台类型：受限于单包大小限制，合并且按需加载才是主流做法，例如将分包对应的公共逻辑抽离到主包
从CDN请求数计费角度看，任何方案都要围绕最终产出“资源总数少、体积可控、更新影响面小”三个原则来评估，如果你正在排查站点的CDN费用构成，优先检查单页面的资源数量,这个是后续一切优化的基础。
实操：静态资源合并nginx配置与常见坑
Nginx层面可以做静态资源合并相关的转发策略配合，但Nginx本身并不能把文件压到一起，它承担的是请求转发和缓存策略控制的职责，日常所说的“静态资源合并nginx配置”,通常指下面这三个层面的配置：
合并后的资源路径处理
合并文件后，原有序号或后缀命名可能失效,需要在Nginx中做好alias或rewrite规则。
location /static/ {
alias /data/www/static/;
expires 7d;
add_header Cache-Control "public";
}
expires 7d和Cache-Control: public能确保CDN边缘节点和浏览器缓存这部分静态资源，降低重复请求回源的概率，若内容更新频繁，可配合access_log分析各资源的实际命中率,按需调整缓存周期。
按请求维度控制资源路由
将不常变更的第三方依赖直接由CDN分发，不经过源站Nginx，将动态改动的业务资源指向源站，两种资源的缓存策略不同，这样能在保证更新的基础上,更大程度减少回源次数。
location /static/3rd/ {
proxy_pass http://cdn-edge;
expires 30d;
add_header Cache-Control "public, max-age=2592000";
}
这种拆分做法，本质上是把“第三方库资源”和“业务代码资源”分成两类缓存域,避免业务代码发版后连带着第三方库全部重新拉取。
避免合并过度
这是最容易被忽略的坑，把全站所有资源合成一个超大文件，首屏就得等待这个文件全部加载完成后才能渲染，正常情况下,超过200KB的JS包已经会明显拖慢页面交互。
更理性的做法是：
- 首屏所需的CSS和JS内联或压缩成独立小包
- 路由级的业务代码按页面拆包
- 公共组件和第三方库按更新频率分多个稳定包
这个动作在优化请求数的同时，保障了用户体验，用户感受不到文件数从30降到8有什么差别，但能直观感受到打开速度和交互响应快了,才是真正的效果达标。
静态资源合并对CDN请求数降低效果的长期影响
从长期运营角度看，静态资源合并并不是一次性动作，前端代码增量迭代，新的第三方库接入，新的页面模块上线，都会让资源数量在数月后重新膨胀，CDN请求数费用重新攀升不是个例,这是资源碎片化不断发生的结果。
CDN费用太高怎么办？最基础的财务治理手段是定期巡检页面资源数，最好纳入每个迭代周期的质量检查项，开发环境的构建输出统计信息里，应该有单页面资源数和总体积的指标，在发布时观察这两个数的变化,超过设定阈值就应该触发合并流程的重新执行。
同时要用好CDN服务商提供的数据报表，多数服务商的控制台都提供分域名请求数统计，能按URL排序查看高请求量资源，用这份数据反推，找出后缀细小、体积小但请求次数庞大的资源，优先合并这些“小而高频”的文件。
静态资源合并适合所有场景吗
请求数优化不是唯一指标，如果做偏离了,容易得不偿失。
HTTP/2普及后，多路复用特性允许单个连接同时传输多个文件，此时文件合并对网络层请求开销的压缩作用比HTTP/1.1时代减弱了，当你的站点全站已切换至HTTP/2或HTTP/3，文件合并的优化重心转向CDN计费成本,而非传输层性能改善。
部分流派提倡“不要合并，保持模块化”，这是站在HTTP/2的传输效率和浏览器缓存粒度角度说的，这种观点的合理性建立在流量不计费或请求数不计费的模型下，只要CDN依然按请求数收费,静态资源合并就依然有效。
从实践看，主流SaaS平台和电子商务网站在使用HTTP/2的同时仍然保持资源合并策略，这是因为他们计费模型中对请求数的敏感度远高于字节数，业内的建议是：合并到每页面10个以内静态请求是稳健目标,按业务规模和团队维护成本微调。
Q&A：关于静态资源合并与CDN请求数常见问题
静态资源合并和打包对比之后，哪种方式对CDN请求数减负更好？
打包比合并的适用面更广，打包天然包含了合并的产出结果，同时能做代码精简和依赖去重，纯手写合并适合没有构建工具的老项目，能立竿见影地减少请求数,但后续维护成本会随时间上升。
CDN请求数怎么算费用，合并后能省多少钱？
CDN服务商按流量费和请求数分开计费，流量费按GB计算，请求数按万次计算，静态资源合并后每月节省多少费用，取决于原页面的资源数量和访问量，举个例子，页面资源数从35个降到8个，在同等访问量下，请求数费用理论上降低约75%,这是按计费规则推导得出的结论。
合并后的缓存更新怎么处理？
哈希值让浏览器和CDN节点天然感知到文件更新，没有哈希策略的旧项目，每次发版后需要主动调用CDN刷新接口，或短暂修改缓存后缀刷新版本，配置刷新时建议按目录刷新，结合“按URL刷新”功能，在发版后的2-5分钟内完成全部边缘节点替旧。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/772712.html
