变态的静态资源缓存与更新

这是一个非常有趣的 非主流前端领域,这个领域要探索的是如何用工程手段解决前端开发和部署优化的综合问题,入行到现在一直在学习和实践中。

在我的印象中,facebook是这个领域的鼻祖,有兴趣、有梯子的同学可以去看看facebook的页面源代码,体会一下什么叫工程化。

接下来,我想从原理展开讲述,多图,较长,希望能有耐心看完。



让我们返璞归真,从原始的前端开发讲起。上图是一个“可爱”的index.html页面和它的样式文件a.css,用文本编辑器写代码,无需编译,本地预览,确认OK,丢到服务器,等待用户访问。前端就是这么简单,好好玩啊,门槛好低啊,分分钟学会有木有!

然后我们访问页面,看到效果,再查看一下网络请求,200!不错,太?完美了!那么,研发完成。。。。了么?

等等,这还没完呢!对于大公司来说,那些变态的访问量和性能指标,将会让前端一点也不“好玩”。

看看那个a.css的请求吧,如果每次用户访问页面都要加载,是不是很影响性能,很浪费带宽啊,我们希望最好这样:

利用304,让浏览器使用本地缓存。但,这样也就够了吗?不成!304叫协商缓存,这玩意还是要和服务器通信一次,我们的优化级别是变态级,所以必须彻底灭掉这个请求,变成这样:

强制浏览器使用本地缓存(cache-control/expires),不要和服务器通信。好了,请求方面的优化已经达到变态级别,那问题来了:你都不让浏览器发资源请求了,这缓存咋更新?

很好,相信有人想到了办法:通过更新页面中引用的资源路径,让浏览器主动放弃缓存,加载新资源。好像这样:

下次上线,把链接地址改成新的版本,就更新资源了不是。OK,问题解决了么?!当然没有!大公司的变态又来了,思考这种情况:

页面引用了3个css,而某次上线只改了其中的a.css,如果所有链接都更新版本,就会导致b.css,c.css的缓存也失效,那岂不是又有浪费了?!

重新开启变态模式,我们不难发现,要解决这种问题,必须让url的修改与文件内容关联,也就是说,只有文件内容变化,才会导致相应url的变更,从而实现文件级别的精确缓存控制。

什么东西与文件内容相关呢?我们会很自然的联想到利用 数据摘要要算法 对文件求摘要信息,摘要信息与文件内容一一对应,就有了一种可以精确到单个文件粒度的缓存控制依据了。好了,我们把url改成带摘要信息的:

这回再有文件修改,就只更新那个文件对应的url了,想到这里貌似很完美了。你觉得这就够了么?大公司告诉你:图样图森破!

唉~~~~,让我喘口气

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

好了,当我要更新静态资源的时候,同时也会更新html中的引用吧,就好像这样:

这次发布,同时改了页面结构和样式,也更新了静态资源对应的url地址,现在要发布代码上线,亲爱的前端研发同学,你来告诉我,咱们是先上线页面,还是先上线静态资源?

先部署页面,再部署资源:在二者部署的时间间隔内,如果有用户访问页面,就会在新的页面结构中加载旧的资源,并且把这个旧版本的资源当做新版本缓存起来,其结果就是:用户访问到了一个样式错乱的页面,除非手动刷新,否则在资源缓存过期之前,页面会一直执行错误。

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

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

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

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

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

所以,大公司的静态资源优化方案,基本上要实现这么几个东西:

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

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

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

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

全套做下来,就是相对比较完整的静态资源缓存控制方案了,而且,还要注意的是,静态资源的缓存控制要求在 前端所有静态资源加载的位置都要做这样的处理 。是的,所有!什么js、css自不必说,还要包括js、css文件中引用的资源路径,由于涉及到摘要信息,引用资源的摘要信息也会引起引用文件本身的内容改变,从而形成级联的摘要变化,大概示意图就是:

时间: 2024-08-28 19:22:43

变态的静态资源缓存与更新的相关文章

.htaccess设置静态资源缓存(即浏览器缓存)

在HTTP标头中为静态资源设置过期日期或最长存在时间,可指示浏览器从本地磁盘中加载以前下载的资源,而不是通过网络加载.这样, 网站加载速度会更快. 下面的代码都需要放到.htaccess中才能生效. 推荐设置过期时间为一个月, 即: max-age=2592000. 通过FilesMatch设置 <FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|css|js)$">Header set Cache-Control "max-a

清除nginx静态资源缓存

之前写过一篇如何配置nginx缓存及手动清除缓存的文章: http://www.cnblogs.com/Eivll0m/p/4921829.html 但如果有大量缓存需要清理,手动一条条清理就比较慢了,所以写了个小脚本进行清理,脚本如下: #!/usr/bin/env python # -*- coding: UTF-8 -*- # data:2015-12-08 # author:eivll0m # 脚本用途:清除nginx静态资源缓存 # 使用方法:将要清楚缓存的url粘贴到/app/adm

Nginx配置静态资源缓存时间及实现防盗链

环境源主机:192.168.10.158系统:centos 7.4域名:www.wuxier.cn盗链主机:192.168.10.191(使用Nginx+Tomcat实现负载均衡.动静分离的实验主机,点我进行复盘)系统:centos 7.4域名:www.ajie.com 和 www.taobao.com 创建软件包存放目录 [[email protected] ~]# mkdir /root/software [[email protected] ~]# cd /root/software/ [

zmNgFrameWork 架构升级ng1.5和md5静态资源缓存方案【angular1.x】

前言: 在我前面的博客,angular项目总结——angular + browserify + gulp + bower + less 架构分享  把我开发angular的架构进行了分享,并上传到了github https://github.com/zimv/zmNgFrameWork . 而后我又在我的 gulp系列 里分享了 gulp-rev:项目部署缓存解决方案----gulp系列(六) ,也更新了github上gulpStart的rev分支 https://github.com/zimv

gulp管理静态资源缓存

前端项目在版本迭代的时候,难免会遇到静态缓存的问题,明明开发的是ok的,但是一部署到服务器上,发现页面变得乱七八糟,这是由于静态缓存引起的. 从上面这张图片可以看出,浏览器加载css,js等资源时,size一栏是from cache,也就是直接使用了本地的资源,而没有向服务器请求.这样做的好处是提升页面渲染速度,坏处是当服务器的对应的文件发生变化时,浏览器却还是使用缓存,造成布局混乱的问题. 解决办法 一个比较原始的办法是在修改了文件之后,手动改变文件名称,然后再在html手动更新资源的path

Weex/Vue项目中静态资源缓存处理.md

目录 一.项目缓存问题 二.浏览器本地缓存 三.解决方案 今年公司技术考察,考察了EMAS平台,从而接触了weex,并且为了进行POC测试,大胆采用weex进行新web项目试点.weex内置了vue框架,整体框架与vue一致,好在刚接触了vue一段时间,因此用起来还算顺手,碰到问题weex官方文档没有的,基本都可以参考vue的文档. 一.项目缓存问题 第一次接触这类前后端完全分离的开发模式,一开始的确是一头雾水,一个多月时间,难点一点一点克服,目前进入项目测试阶段,经常碰到bug修复了,测试人员

LAMP+haproxy+varnish实现网站访问的动静分离及静态资源缓存

实验目标:1.    LAMP节点提供用户动态请求访问,数据库单独有数据库节点提供:2.    LAMP动态网站有两台服务器,提供负载均衡:3.    静态网站服务器节点提供用户的静态资源请求访问:存在两台静态web服务器,其网站静态资源在静态服务器上存放:4.    用户的静态请求访问后缓存在varnish服务器上,实现访问加速5.    前端的haproxy提供反向代理功能,将用户的动态资源请求发送给后端LAMP节点,静态资源请求发往后端静态web服务器:6.    该架构考虑还不健全,如静

HappyAA服务器部署笔记2(nginx的静态资源缓存配置)

我近期对服务器进行了少量改进,虽然之前使用了nginx反向代理之后性能有所提高,但仍然不够,需要使用缓存来大幅度提高静态资源的访问速度. 服务器上的静态资源主要有这些:png, jpg, svg, js, css等.下面,我通过新的nginx配置来实现缓存.对红色的字我会额外进行说明. worker_processes 1; events { worker_connections 1024; multi_accept on; use epoll; } http { include mime.ty

静态资源缓存常用的方式

最近遇到项目优化的问题,由于项目用到的框架,函数库比较多,导致首次需要加载3.6M的文件,那么问题来了,当网络很差的时候,很多文件就会timeout.然后就挂了.所以就开始用到离线缓存,一些文件静态的函数库开始缓存起来,一些经常更新的文件每次上线加版本号更新. 下面说说离线缓存,长话短说,很简单,只要完成简单的几个步骤 1,创建一个后缀名为.appcache的文件(如:list.appcache),里面配置项也很简单,同上 CACHE MANIFEST:这里面把你需要缓存的文件列出来,注意路径哈