在webpack中使用CommonsChunkPlugin时是否需要Etag和Last-Modified头

Question

我正在使用webpack捆绑我所有的资产文件，所以我得到了类似的东西。

bundle.7fb44c37b0db67437e35.js
vendor.495e9142a1f8334dcc8c.js
styles.bc5b7548c97362b683f5582818914909.css

我在名称中使用了chunkhash，因此当浏览器缓存某些内容时，它不会再次缓存，直到哈希发生变化为止。例如，如果我更改样式，捆绑文件并部署，则仅样式中的哈希值会更改，其他样式则不会，因此浏览器将再次从服务器请求样式文件，其余的将从内存缓存中使用。

在响应标头中，我还具有Etag和Last-Modified，每次我为每个文件部署应用程序时，它们都会更改。我应该从响应中删除它们吗？这可以使浏览器无法联系服务器并查看文件是否已更改，即使哈希值仍然相同吗？

Answer 1

很好的问题。这很大程度上取决于后端如何实现以及如何计算标头值。文件是由我们的服务器提供的，还是其他服务器（例如 s3）提供的？我们使用 CDN 吗？我们是否为应用程序服务器使用框架？谁计算这些标头，Web 服务器还是应用程序服务器？

出于本答案的目的并为了简单起见，我们假设我们使用流行的服务器框架Express，没有 CDN 或第 3 方托管。与大多数应用程序服务器一样，Express会根据所提供的文件的内容（而不是文件的名称）进行计算ETagLast-Modified。

浏览器第一次请求我们的文件时，它将收到资源的ETag和Last-Modified。下次请求相同的资源时，浏览器会将缓存ETag和Last-Modified标头发送到服务器。然后，服务器根据这些标头决定浏览器是否需要下载资源的新版本，或者缓存的版本是否是最新版本。如果缓存的资源是最新的，服务器会返回一个304 - Not Modified状态代码。状态代码是整个缓存系统的关键 - 它是浏览器决定是否应该使用缓存资源的方式。

为了生成ETag标头，Express 将Buffer响应正文的二进制表示形式传递给etag模块，该模块根据缓冲区的内容计算 SHA-1 哈希（源：生成 ETag 标头和源：生成哈希）。为了生成Last-Modified标头，Express 使用文件系统的上次修改时间（请参阅lastModified文档）。

当 webpack 构建一个新的包时，即使 chunkhash 相同，文件的二进制文件也会改变。这会导致 Express 输出不同的Etagand Last-Modified，这意味着下次请求资源时它将不会响应 a304。如果没有304状态代码，浏览器将不必要地重新下载捆绑包。

回答

我认为这里最好做的是禁用这些资产的ETag和Last-Modified标头，而是使用Expires或Cache-Control: max-age标头设置为遥远的未来日期（通常是 1 年）。这样，浏览器只会在过期或缓存中不存在的情况下重新下载捆绑包。