Webpack 中 devServer.compress 如何启用 gzip 压缩？

Webpack 生态中的 webpack-dev-server 在本地开发时提供了一系列优化体验的配置，其中 devServer.compress 直接决定开发服务器是否对响应的文本资源进行 gzip 压缩。开启该选项后，浏览器与开发服务器之间的传输数据量会明显下降，特别是在项目体积较大或网络环境不理想时，资源加载速度的提升会非常直观。这个配置项本身并不复杂，但它的实际行为与 compression 中间件、浏览器协商以及文件类型筛选紧密相关，值得从配置、原理、误区和性能四个维度深入梳理。

一、compress 配置与基本用法

在 webpack.config.js 中开启 devServer.compress 非常简单，只需在 devServer 对象中将 compress 设置为 true。该选项的默认值是 false，因此如果不显式开启，开发服务器不会对响应做 gzip 压缩。以下是一个常见的开发环境配置示例，同时启用了热更新和静态资源目录：

const path = require('path');

module.exports = {
  mode: 'development',
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
  },
  devServer: {
    compress: true,
    port: 9000,
    hot: true,
    static: {
      directory: path.join(__dirname, 'public'),
    },
  },
};

除了配置文件方式，webpack-dev-server 也支持通过命令行参数 --compress 临时开启压缩，例如执行 webpack serve --compress。这种方式适合在不修改配置文件的情况下快速验证压缩效果。需要注意的是，compress 只作用于开发服务器运行时，它不会改变 output 中生成的文件内容，也不会在 dist 目录中额外生成 .gz 文件。生产环境仍然需要依赖 Nginx、Apache 或者 CDN 来提供压缩服务。

要确认压缩是否已经生效，可以借助浏览器开发者工具查看响应头，或者使用 curl 命令模拟带 Accept-Encoding 请求头的请求。执行以下命令后，如果响应头中出现 Content-Encoding: gzip，说明开发服务器已经正确返回了压缩后的内容。

curl -I -H "Accept-Encoding: gzip" http://localhost:9000/bundle.js

二、gzip 压缩在 DevServer 中的工作过程

当浏览器请求开发服务器上的资源时，会自动携带 Accept-Encoding 请求头，里面列出了浏览器支持的压缩算法，例如 gzip、deflate、br 等。webpack-dev-server 使用的 compression 中间件会读取这个请求头，判断客户端是否接受 gzip 编码。如果接受，并且响应内容类型符合压缩条件，中间件就会调用 Node.js 的 zlib 模块对响应体进行实时压缩。压缩完成后，响应头中会加入 Content-Encoding: gzip 和 Vary: Accept-Encoding，后者用于告知缓存服务器需要根据请求头区分不同版本。

compression 中间件并不会压缩所有文件。它内部维护了一张 MIME 类型过滤表，默认只处理 text/html、text/css、application/javascript、application/json、image/svg+xml 等文本类或未压缩的矢量图内容。对于已经高度压缩的二进制文件，例如 PNG、JPEG、WebP、WOFF2，再次使用 gzip 不仅几乎没有体积收益，还会白白消耗 CPU 资源。此外，响应体小于一定阈值（默认约 1KB）时，中间件会直接跳过压缩，因为极小的文件压缩产生的开销可能超过传输节省的时间。

从传输行为来看，未压缩的响应通常带有明确的 Content-Length 头，而压缩后的响应因为内容长度需要边压缩边发送，往往会变为 Transfer-Encoding: chunked。这是 gzip 实时压缩的一个典型特征。对于本地开发而言，CPU 压缩带来的延迟远低于网络传输带来的整体耗时，尤其是在加载大型 bundle 文件或者模拟慢速网络时，压缩收益会非常明显。开发者如果想自定义压缩级别或者过滤规则，可以通过 webpack-dev-server 提供的 setupMiddlewares 钩子手动接入 compression 中间件，配置 threshold、level 等参数。

三、常见误区与性能权衡

第一个常见误区是把 devServer.compress 当成生产环境压缩方案。实际上它只对 webpack-dev-server 的运行时响应有效，构建产出的静态文件本身并不会被修改或添加 .gz 版本。生产环境需要在 Web 服务器或 CDN 上配置 gzip_static、brotli_static 等策略，或者让服务器对静态资源进行实时压缩。开发与生产两套策略应该分开管理，不能在部署时依赖开发服务器的配置。

第二个误区是认为开启 compress 后所有响应都会变小。前面已经提到，二进制图片、字体以及小于阈值的文件不会经过压缩处理。如果开发者在浏览器中看到部分资源没有 Content-Encoding: gzip，并不代表配置失败。可以通过响应头中的 Content-Type 和 Content-Length 判断该资源是否属于可压缩类型以及是否达到压缩阈值。例如一张 300 字节的 PNG 不压缩是正常现象。

在性能权衡方面，devServer.compress 会增加一些 CPU 使用率，但在现代开发机器上这种开销通常可以忽略。真正需要注意的是，如果项目本身非常小或者本地网络极快，压缩带来的提升可能并不明显，但开启后也不会产生明显负面影响。因此，在大多数场景下建议直接开启 compress，以获得更接近生产环境的加载体验。对于需要模拟真实网络条件的场景，可以结合浏览器 DevTools 的节流功能一起测试压缩前后的传输差异，从而做出更准确的判断。

WebpackdevServer.compressgzip压缩修改时间：2026-09-19 19:01:55