前端静态资源版本控制

发表于 更新于 本文字数： 879 阅读时长 ≈ 1 分钟
本文介绍关于前端静态资源版本控制，包括使用场景、实现细节等，以提高关于前端静态资源版本控制的效率。

对于网页中不变的元素，也就是静态资源，我们希望浏览器但凡拿到就别再请求后端，直到这些资源更新变化。这个需求的本质就是我们需要对前端资源增加版本管理

前端缓存的好处

  1. 减轻客户端请求资源数目，进而提升页面加载速度
  2. 减轻服务端负载压力

看来，多方受益。那如何前端资源版本管理进而实现缓存化呢，其实方法有很多

Cache-Control/Expires，Last-Modified/ETag

Cache-Control/Expires设定后，在缓存时间内，正常进入页面，浏览器不会发出请求，直接读取浏览器缓存资源。如果用户点击“刷新”按钮或缓存时间消失，浏览器会发送请求，并根据Last-Modified/ETag判断内容是否有更新，如果内容没更新，
服务器返回304。

问题

新发版后，访问页面，资源还会是缓存，需要刷新或重新访问，才会请求后端，进行ETag判断

版本号

加版本号使得每次发版，之前的前端资源失效，进而请求新的资源，但是带来的问题。

问题

  1. 版本号必然是加载一批资源上，比如项目所有的前端资源(JS,CSS,IMG)，比如某次紧急发版只是改了一个CSS样式，那么发版就会连带所有的资源缓存失效
  2. 版本号是需要维护的，新发版就要记得更新版本号，大小补丁版本号，维护成本其实并不低

哈希指纹

倘若内容变了，则指纹变了，反之，内容不变指纹即不变，这样从而确保只让改动的内容文件缓存失效。

优点

  1. 特定文件更新，不用像版本号管理一样，导致其它文件失效
  2. 无覆盖式更新，新版旧版名字不同，所以不冲突，这样不会出现新版html使用旧版JS的问题

缺点

想加上哈希指纹，就需要在构建环节增加处理步骤，这样打包必然是多了部分时间开销，但这点开销对于构建服务器即使是个人开发机应该都不是多大的问题

写在最后

如上的几种方式其实也就是WEB开发对于前端资源管理的发展历程，当下，相对最优的方案便是哈希指纹。所以快快搞起来吧，这样7x24随时即刻发版。

参考链接