前端资源压缩与合并是网站性能优化中最直接、见效最快的环节之一。它通过减少传输体积和请求数量，直接影响页面加载时间。但许多开发者在使用这些技巧时，往往忽略其适用边界，导致优化效果有限甚至适得其反。本文将明确这些边界，并给出可落地的执行方案。
为什么压缩与合并能提升性能？
根据 MDN 的 Web 性能指南，网站性能不仅取决于客观的加载时间，还取决于用户感知的交互流畅度。资源体积越小，下载越快；请求数越少，浏览器建立连接的次数越少，页面越早进入可交互状态。压缩与合并正是从这两个维度入手：压缩减少字节数，合并减少请求数。
边界条件：并非所有资源都适合压缩与合并
在动手之前，需要明确以下限制：
- 已压缩格式：图片（如 JPEG、PNG、WebP）和视频通常已经过有损或无损压缩，再次压缩收益极小，甚至可能损害画质。这类资源应侧重于格式选择和尺寸优化，而非传统文本压缩。
- HTTP 压缩：对于 CSS、JavaScript 等文本资源，服务器通常启用 Gzip 或 Brotli 压缩。但压缩会消耗 CPU，对于高并发站点，需权衡压缩级别与服务器负载。
- 合并的代价：将多个文件合并为一个，虽然减少了请求数，但会破坏浏览器缓存。例如，修改一个模块可能导致整个合并文件失效，迫使客户端重新下载所有代码。因此，合并策略需结合代码拆分和长期缓存考虑。
可执行方案：从测量开始
优化前必须测量，否则无法判断效果。使用 Lighthouse、WebPageTest 或浏览器开发者工具的性能面板，记录以下指标：
- 页面总重量（KB）
- 请求数量
- 加载时间（FCP、LCP）
这些数据将作为优化前后的对比基准。
文本资源压缩：Gzip 与 Brotli 的选择
对于 CSS、JavaScript 和 HTML，启用 HTTP 压缩是最基础的一步。Gzip 是通用方案，兼容性最好；Brotli 是更新的算法，压缩率通常更高，但需要服务器和浏览器支持。根据 MDN 的指导，现代浏览器均支持 Brotli，因此可以优先考虑。在实际部署中，建议同时配置两种算法，让服务器根据请求头自动选择。压缩级别不宜过高，一般 Gzip 用 6，Brotli 用 5，以平衡 CPU 消耗。
资源合并：从手动到构建工具
传统做法是手动将多个 JS 或 CSS 文件拼接为一个。但这种方式维护困难，且容易破坏缓存。现代工程化构建工具（如 Webpack、Vite）提供了更智能的合并策略：
- 代码拆分：将第三方库与业务代码分离，利用长期缓存减少重复下载。
- 按需加载：将非关键代码异步加载，减少初始请求体积。
- Tree Shaking：移除未使用的代码，进一步压缩体积。
这些方法比简单的合并更精细，也更能适应大型项目。
图片优化：压缩与合并的替代方案
图片通常占页面体积的 60% 以上，但传统的文本压缩技术并不适用。正确的做法是：
- 选择合适的格式：照片用 WebP（或 AVIF），图标用 SVG，复杂图形用 PNG。
- 使用响应式图片：通过 srcset 提供不同尺寸，避免移动端加载超大图。
- 启用懒加载：让视口外的图片延迟加载，减少初始资源。
这些技巧与压缩合并相辅相成，共同降低页面重量。
常见误区与失败条件
在实践中，以下误区可能导致优化失败：
- 过度合并：将所有代码打包成一个巨型文件，导致首屏加载反而变慢。
- 忽略缓存策略：合并后没有设置合理的缓存头，用户每次访问都重新下载。
- 压缩级别过高：服务器 CPU 飙升，响应时间变长，尤其是高并发场景。
- 未验证兼容性：某些旧浏览器不支持 Brotli，需保留 Gzip 作为回退。
因此，优化时需持续监控性能指标，并做好 A/B 测试。
总结
前端资源压缩与合并是网站性能优化的基石，但需要基于测量、考虑边界、采用合适的工具链。对于 WordPress 等 CMS，可参考官方高级管理文档中的性能相关配置；对于通用 Web 开发，MDN 提供了详尽的性能指南。记住：优化不是一次性的，而是持续迭代的过程。
参考资料
延伸阅读