静态资源缓存与更新

下图是一个基本的index.html页面和它的样式文件a.css

 

放到服务器，访问页面网络请求200大功告成。

可是咱们思考一个问题，若是每次用户访问页面都须要加载这个a.css的请求，很影响性能和浪费带宽，咱们但愿下面这个样子

利用304让浏览器使用本地缓存，考虑这样是否有问题？有！304叫协商缓存，还须要和服务器通讯一次，因此要消除掉这个交互，变成这样，

 

强制浏览器使用本地缓存(cache-control/expires), 再也不和服务器通讯。这个优化看起来已经很极致了。可是问题来了，不让浏览器发资源请求，缓存如何更新呢？

相信你们都能想到这个办法: 经过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源，以下:

下次上线，把资源地址改为新的版本，资源就进行了更新，看起来没什么问题。考虑下下面这种状况:

页面引用了三个css，而某次上线只改了其中的a.css。若是全部资源连接都更新版本，会致使b.css，c.css的缓存也生效，那样就形成了带宽浪费

要解决这种问题，必须让url的修改与文件内容关联。也就是说，只有文件内容变化，才会致使相应的url的变动，从而实现文件级别的精准缓存控制。

因此咱们天然联想到了【数据摘要算法】对文件摘要，摘要信息与文件内容一一对应，就能够把缓存控制到单个文件的粒度.

上面的url是带摘要信息的，貌似很完美了。不过大公司中仍是 图样图森破！

现代互联网企业，为了进一步提高网站性能，会把静态资源和动态网页分集群部署，静态资源会被部署到CDN节点上，网页中引用的资源也会变成对应的部署路径：

好了，那么当咱们更新静态资源的时候，一样也会更新html中的资源引用，像下面这样

此次发布，同时改了页面结构和样式，也更新了静态资源对应的url地址，如今要发布代码上线，亲爱的前端研发同窗，我们是先上线页面，仍是先上线静态资源？

先部署页面，再部署资源：在两者部署的时间间隔内，若是有用户访问页面，就会在新的页面结构中加载旧的资源，而且把这个旧版本的资源当作新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，不然在资源缓存过时以前，页面会一直执行错误。

先部署资源，再部署页面：在部署时间间隔以内，有旧版本资源本地缓存的用户访问网站，因为请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种状况下页面展示正常；但没有本地缓存或者缓存过时的用户访问网站，就会出现旧版本页面加载新版本资源的状况，致使页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。

好的，上面一坨分析想说的就是：先部署谁都不成！都会致使部署过程当中发生页面错乱的问题。因此，访问量不大的项目，可让研发同窗苦逼一把，等到半夜偷偷上线，先上静态资源，再部署页面，看起来问题少一些。

可是，大公司超变态，没有这样的“绝对低峰期”，只有“相对低峰期”。So，为了稳定的服务，还得继续追求极致啊！

这个奇葩问题，起源于资源的 覆盖式发布，用 待发布资源 覆盖 已发布资源，就有这种问题。解决它也好办，就是实现 非覆盖式发布。

看上图，用文件的摘要信息来对资源文件进行重命名，把摘要信息放到资源文件发布路径中，这样，内容有修改的资源就变成了一个新的文件发布到线上，不会覆盖已有的资源文件。上线过程当中，先全量部署静态资源，再灰度部署页面，整个问题就比较完美的解决了。

因此，大公司的静态资源优化方案，基本上要实现这么几个东西：

1.配置超长时间的本地缓存 —— 节省带宽，提升性能

2.采用内容摘要做为缓存更新依据 —— 精确的缓存控制

3.静态资源CDN部署 —— 优化网络请求

4.更资源发布路径实现非覆盖式发布 —— 平滑升级

全套作下来，就是相对比较完整的静态资源缓存控制方案了，并且，还要注意的是，静态资源的缓存控制要求在 前端全部静态资源加载的位置都要作这样的处理 。是的，全部！什么js、css自没必要说，还要包括js、css文件中引用的资源路径，因为涉及到摘要信息，引用资源的摘要信息也会引发引用文件自己的内容改变，从而造成级联的摘要变化，大概示意图就是：

 

摘要hash和fis解决级联资源定位能够参看 http://www.infoq.com/cn/articles/front-end-engineering-and-performance-optimization-part1/