阅读 313

浏览器缓存策略与webpack持久化缓存

浏览器通过请求头实现缓存,关键的请求头有cache-control,expires,last-Modified,ETag等。我们从时间和空间两个角度来看浏览器缓存。

时间

  • 浏览器发送第一次请求:不缓存,服务端根据设定的缓存策略返回相应的header,如:cache-control,expires,last-Modified,ETag。

  • 浏览器发送第二次请求:

  1. 是否:有cache-control且不过期。是的话返回本地磁盘缓存,状态值200(from cache);否的话
  2. 是否:有expires且不过期。是的话返回本地磁盘缓存,状态值200(from cache);否的话
  3. 是否:有Etag。是的话请求头添加If-None-Match,值就是上次返回的Etag值,然后发送给服务端。服务端对比If-None-Match与现有的Etag值是否一样;一样的话只返回header,状态码304,浏览器从本地磁盘获取缓存信息;不一样走正常流程,返回header+body,状态码200。没有Etag的话
  4. 是否:有last-Modified。是的话添加请求头If-Modified-Since,值是上次返回的last-Modified,然后发送给服务端。服务端对比If-Modified-Since与现有的是否一样;一样的话返回只返回header,状态码304,浏览器从本地磁盘获取缓存信息;不一样走正常流程,返回header+body,状态码200。没有last-Modified的话:
  5. 没有缓存,正常请求

其中1,2阶段称为强缓存策略,它的特点是不需要和服务端通信就决定是否使用缓存,cache-control优先级大于expires。3,4阶段称为协商缓存策略,它的特点是需要和服务端通信决定是否用缓存,Etag优先级大于last-Modified。

如图:

-w605

空间

  • 浏览器和服务端:服务端需要决定使用哪种缓存策略并在响应头返回;前端不需要设置,是浏览器本身机制。
  • html和静态资源:通常html不设置缓存,因为其它资源的入口都是html文件;静态资源(js,css,图片等)会设置缓存

部署时缓存的问题

如果缓存就按理论上设置,那就太简单了。在实际应用有个严重的问题,我们不仅要缓存代码,还需要更新代码。如果静态资源名字不变,怎么让浏览器即能缓存又能在有新代码时更新。最简单的解决方式就是静态资源路径添加一个版本值,版本不变就走缓存策略,版本变了就加载新资源。如下:

<script src="xx/xx.js?v=24334"></script>
复制代码

然而这种处理方式在部署时有问题,在张云龙这篇精彩的文章中,详细介绍了这些缘由,重点总结如下:

静态资源和页面是分开部署的:

  1. 先部署页面再部署静态资源,会出现用户访问到旧的资源
  2. 先部署静态资源再部署页面,会出现没有缓存用户加载到新资源而报错

这些问题的本质是以上的部署方式是“覆盖式发布”,解决方式是“非覆盖式发布”。即用静态资源的文件摘要信息给文件命名,这样每次更新资源不会覆盖原来的资源,先将资源发布上去。这时候存在两种资源,用户用旧页面访问旧资源,然后再更新页面,用户变成新页面访问新资源,就能做到无缝切换。简单来说就是给静态文件名加hash值

那如何实现呢?现在前端代码都用webpack之类的构建工具打包,那么我们看下结合webpack该怎么做,怎么才能做到持久化缓存?

webpack持久化缓存

1. 我们知道webpack给文件名添加hash值是很简单的,问题是有hash/chunkhash/contenthash,使用哪个?

先看下官方定义:

  • hash: unique hash generated for every build
  • chunkhash: hashes based on each chunks' content
  • contenthash: hashes generated for extracted content

hash每次构建都不同(实际上webpack当前版本4.41在内容不变时每次构建是一样的),且多个文件共用一个值,只要其中一个模块内容变了,所有文件名都变了,不能用于缓存。

chunkhash也不行,问题出现在每一个chunk可能包括第三方库或者提取的css文件。比如css文件变了,引用它的js文件所生成的chunk也变了。

contenthash按照内容生成hash,是我们想要的。

我们来实验上面的结论,如下所示,有两个入口文件index和bar,

module.exports = {
  mode: "none",
  entry: {
    index: "./src/index.js",
    bar: "./src/bar.js"
  },
  output: {
    path: path.resolve(__dirname, "dist"),
    filename: "[name].[hash].js"
  },
};
复制代码

验证hash的步骤:先编译,再改变index内容,再编译。观看两次编译的结果。

-w602
-w596

可以看出hash值在同一次编译的不同文件是一样的;只改变index文件内容,bar的值也跟着变了。

注:全篇的内容都是根据以下版本,按照上面这种改变单一变量的方法试验得出,往后结论不一一贴图,各位可自行试验。

"devDependencies": {
    "webpack": "^4.41.2",
    "webpack-cli": "^3.3.10"
}
复制代码
2. webpack打包的文件不仅包括业务代码,还有第三方库和运行时代码,需要将他们提取出来,缓存才不会相互干扰。
module.exports = {
  entry: {
    index: "./src/index.js",
    bar: "./src/bar.js"
  },
  output: {
    filename: "[name].[contenthash].js"
  },
  optimization: {
    splitChunks: {
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: "vendors",
          chunks: "all"
        }
      }
    },
    runtimeChunk: {
      name: "manifest"
    }
  }
};
复制代码

第三方库提取方式是设置optimization的splitChunks的cacheGroups。splitChunks能提取模块,cacheGroups能缓存模块,并且cacheGroups的配置会覆盖splitChunks相同配置,既能提取又能缓存,故只需设置cacheGroups。

运行时代码的提取方式为配置runtimeChunk,默认为false,表示运行时代码嵌入到不同的chunk文件中;现在将运行时代码提取出来,并命名为manifest。

3. moduleName 和 chunkName 对文件的影响

一个文件被分离为3个文件。我们多出来了一个问题:文件间怎么相互依赖的,会影响彼此打包吗?

-w631

我们看了下index文件编译后的结果,可以看到确实相互依赖,这些数字是moduleId或者chunkId。它们在每一次编译中按数字递增生成,这样有可能我们只是简单添加一个模块,就使得moduleId或chunkId改变,导致缓存失败。解决方法是将moduleId和chunkId改成按照文件路径生成。

optimization: {
    namedModules: true,
    namedChunks: true
},
复制代码

编译后结果如下:这个是名为index的chunk,它由名为"./src/index.js"这个module和名为"manifest"和"vendors"的chunk组成。

-w669

通常我们还会进一步设置moduleIds:

optimization: {
    moduleIds: 'hashed',
    namedModules: true,
    namedChunks: true
},
复制代码

-w679

这样子moduleId在编译后的文件是文件目录的hash值,更加安全。这也是namedChunks在production默认为false的原因,不想依赖的文件路径在编译后的文件直接展示,但是为了持久性缓存,这里也只能打开。

补充一下module/chunk/bundle区别有助于理解:
  • module:就是js模块,
  • chunk:webpack编译过程中由多个module组成的文件
  • bundle:bundle是chunk文件的最终状态,是webpack编译后的结果

比如:

-w684

详情以及截图来源于stackoverflow.com/questions/4…

4. css文件缓存

最后当css代码提取成单独文件,当我们改变css时,怎么保证不影响引用它的js文件呢?配置如下:

plugins: [
  new MiniCssExtractPlugin({
    filename: "[contenthash].css"
  })
]
复制代码
5 总结:webpack持久化缓存目标是当且仅当该文件内容变动才改变该文件名字的hash值

所有配置总结如下,每行配置后面都有详细说明:

const MiniCssExtractPlugin = require("mini-css-extract-plugin");

module.exports = {
  output: {
    filename: [name].[contenthash].js, // 让hash值只在内容变动时更新
    chunkFilename: [name].[contenthash].js // 动态引入的模块命名,同上
  },
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          "loader: MiniCssExtractPlugin.loader",  // 提取出来css
          "css-loader"
        ]
      }
    ]
  },
  optimization: {
     moduleIds: "hashed", // 混淆文件路径名
  	 runtimeChunk: { name: 'manifest' }, // 提取runtime代码命名为manifest
     namedModules: true, // 让模块id根据路径设置,避免每增加新模块,所有id都改变,造成缓存失效的情况
     namedChunks: true, // 避免增加entrypoint,其他文件都缓存失效
     cacheGroups: {
       vendor: {  // 提取第三方库文件
         test: /[\\/]node_modules[\\/]/,
         name: 'vendors',
         chunks: 'all',
       },
     },
  }
  plugins: [
    new webpack.HashedModuleIdsPlugin(), // 与namedModules: true作用一样
    new MiniCssExtractPlugin({
      filename: "[contenthash].css",  // css文件也是按contenthash命名
      chunkFilename: "[contenthash].css", // 动态引入的css命名,同上
    })
  ],
}

复制代码

总结

浏览器有其缓存机制,想要既能缓存又能在部署时没有问题,需要给静态文件名添加hash值。在webpack中,有些配置能让我们实现持久化缓存。当然在探索这些属性的过程中,是用单一变量法,一步步测试得出结果,限于篇幅不一一截图。感兴趣同学可自行验证。

参考资料:

webpack.js.org/guides/cach…

www.zhihu.com/question/20…

github.com/amandakelak…

imweb.io/topic/5b6f2…

coderlt.coding.me/2016/11/21/…

segmentfault.com/a/119000001…

关注下面的标签,发现更多相似文章
评论