阅读 668

前端高级进阶:网站的缓存控制策略最佳实践及注意事项

这是山月关于高级前端进阶暨前端工程系列文章的第 M 篇文章 (M 随便打的,毕竟也不知道能写多少篇),关于前 M-1 篇文章,可以从我的 github repo shfshanyue/blog 中找到,如果点进去的话可以捎带~点个赞~,如果没有点进去的话,那就给这篇文章点个赞。。今天的文章开始了

本篇文章地址在 前端工程化系列,欢迎订阅。

  1. 前端高级进阶:javascript 代码是如何被压缩
  2. 前端高级进阶:如何更好地优化打包资源
  3. 前端高级进阶:网站的缓存控制策略最佳实践及注意事项

对于一个网站来讲,性能关乎用户体验,你在更短的时间内打开网站,你将会留住更多的用户。如果你的页面十秒才能打开,那再好的用户交互也是徒然。

缓存控制是网站性能优化中至为常见及重要的一环,好的缓存控制,除了使网站在性能方面有所提升,在财务方面也有重要提升: 更好的缓存策略意味着更少的请求,更少的流量,更少的峰值带宽,从而节省一大笔服务器或者 CDN 的费用。

缓存控制策略就是 http caching 的策略,化繁为简,最有效的策略往往是很简单的。在最简单的粗略下,你对 http cache 只需要了解一个 Cache-Control 的头部。

一个较好的缓存策略只需要两部分,而它们只需要通过 Cache-Control 控制:

  1. 带指纹资源: 永久缓存
  2. 非带指纹资源: 每次进行新鲜度校验

作图如下:

缓存控制策略

带指纹资源: 永久缓存

Cache-Control: max-age=31536000
复制代码

天下武功,无坚不摧,唯快不破。资源请求最快的方式就是不向服务器发起请求,通过以上响应头可以对资源设置永久缓存。

  1. 静态资源带有 hash 值,即指纹
  2. 对资源设置一年过期时间,即 31536000,一般认为是永久缓存
  3. 在永久缓存期间浏览器不需要向服务器发送请求

那为什么带有 hash 值的资源可以永久缓存呢?

因为该文件的内容发生变化时,会生成一个带有新的 hash 值的 URL。 前端将会发起一个新的 URL 的请求。

非带指纹资源: 每次进行新鲜度校验

Cache-Control: no-cache
复制代码
  1. 由于不带有指纹,每次都需要校验资源的新鲜度。(从缓存中取到资源,可能是过期资源)
  2. 如果校验为最新资源,则从浏览器的缓存中加载资源

index.html 为不带有指纹资源,如果把它置于缓存中,则如何保证服务器刷新数据时,被浏览器可以获取到新鲜的资源?

因此,使用 Cache-Control: no-cache 时,客户端每次对服务器进行新鲜度校验。

PS:no-cache 与 no-store 的区别是什么?

即使每次校验新鲜度,也不需要每次都从服务器下载资源: 如果浏览器/CDN上缓存经校验没有过期。这被称为协商缓存,此时 http 状态码返回 304,指 Not Modified,即没有变更。

幸运的是,关于协商缓存,你无需管理,也无需配置, nginx 或者一些 OSS 都会自动配置协商缓存。

而对于协商缓存,也有它们自己的算法,协商缓存的背后基于响应头 Last-Modified/ETag。浏览器每次请求资源时,会携带上次服务器响应的 ETag/Last-Modified 作为标志,与服务端此时的 ETag/Last-Modified 作比较,来判断内容更改。

http 响应头中的 ETag 值是如何生成的?

而在操作系统底层,Last-Modified 往往通过文件系统(file system)中的 mtime 属性生成。而 ETag 提供比 Last-Modified 更精细的检验粒度,由文件内容的 hash 或者 mtime/size 生成。当然,这是后话。

一定要为你的资源添加 Cache-Control 响应头

我会经常接触到一些网站,他们的资源文件并没有 Cache-Control 这个响应头。究其原因,在于缓存策略配置这个工作的职责不清,有时候它需要协调前端和运维。

那如果不添加 Cache-Control 这个响应头会怎么样?

是不是每次都会自动去服务器校验新鲜度,很可惜,不是。 此时会对资源进行强制缓存,而对不带有指纹信息的资源很有可能获取到过期资源。 如果过期资源存在于浏览器上,还可以通过强制刷新浏览器来获取最新资源。但是如果过期资源存在于 CDN 的边缘节点上,CDN 的刷新就会复杂很多,而且有可能需要多人协作解决。

那默认的强制缓存时间是多少

首先要明确两个响应头代表的含义:

  1. Date: 指源服务器响应报文生成的时间,差不多与发请求的时间等价
  2. Last-Modified: 指静态资源上次修改的时间,取决于 mtime

LM factor 算法认为当请求服务器时,如果没有设置 Cache-Control,如果距离上次的 Last-Modified 越远,则生成的强制缓存时间越长。

用公式表示如下,其中 factor 介于 0 与 1 之间:

MaxAge = (Date - LastModified) * factor
复制代码

LM factor

Bundle Splitting:尽量减少资源变更

得益于单页应用与前端工程化的发展,经过打包后,基本上所有资源都是带有指纹信息的,这意味着所有的资源都是能够设置永久缓存。打包策略如下图所示:

缓存控制策略

但仅仅如此了吗?

如果你所有的 js 资源都打包成一个文件,它确实有永久缓存的优势。但是当有一行文件进行修改时,这一个大包的指纹信息发生改变,永久缓存失效。

所以我们现在需要做到的是:当修改文件后,造成最小范围的缓存失效。webpack 等打包工具虽然在 optimization 上内置了很多性能优化,但它不会帮你做这件事,这件事情需要自己动手。

缓存控制策略

此时我们可以对资源进行分层次缓存的打包方案,这是一个建议方案:

  1. webpack-runtime: 应用中的 webpack 的版本比较稳定,分离出来,保证长久的永久缓存
  2. react/react-dom: react 的版本更新频次也较低
  3. vendor: 常用的第三方模块打包在一起,如 lodashclassnames 基本上每个页面都会引用到,但是它们的更新频率会更高一些。另外对低频次使用的第三方模块不要打进来
  4. pageA: A 页面,当 A 页面的组件发生变更后,它的缓存将会失效
  5. pageB: B 页面
  6. echarts: 不常用且过大的第三方模块单独打包
  7. mathjax: 不常用且过大的第三方模块单独打包
  8. jspdf: 不常用且过大的第三方模块单独打包

随着 http2 的发展,特别是多路复用,初始页面的静态资源不受资源数量的影响。因此为了更好的缓存效果以及按需加载,也有很多方案建议把所有的第三方模块进行单模块打包。

小结

缓存控制策略

与我交流

扫码添加我的机器人微信,将会自动(自动拉人程序正在研发中)把你拉入前端高级进阶学习群

我是山月,可以加我微信 shanyue94 与我交流,备注交流。另外可以关注我的公众号【全栈成长之路】

如果你对全栈面试,前端工程化,graphql,devops,个人服务器运维以及微服务感兴趣的话,可以关注我

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