背景 缓存是用来做性能优化的好东西,但是,如果用不好缓存,就会产生一系列问题:为什么我的页面显示的还是老版本为什么我的网页白屏请刷新下网页。。。 以上问题大家或多或少都遇到过,归根结底是使用缓存的姿势不对,今天,我们就来一起了解下浏览器是如何进行缓存的,以及我们要怎样科学的使用缓存浏览器的缓存机制1。什么是浏览器缓存? 简单说,浏览器把http请求的资源保存到本地,供下次使用的行为,就是浏览器缓存 这里先记一个点:http响应头,决定了浏览器会对资源采取什么样的缓存策略2。浏览器是读取缓存还是请求数据?用户第一次请求资源 整个完整流程 3。缓存过程分类强缓存协商缓存 根据是否请求服务,我们把缓存过程分为强缓存和协商缓存,也可以理解为必然经过的过程称为强缓存,如果强缓存没有,那在和服务器协商一下强缓存 强缓存看的是响应头的Expires和CacheControl字段Expires是老规范,它表示的是一个绝对有效时间,在该时间之前则命中缓存,如果超过则缓存失效,并且,由于它是跟本地时间(可以随意修改)做比较,会导致缓存混乱CacheControl是新规范,优先级要高于Expires,也是目前主要使用的缓存策略,字段是maxage,表示的是一个相对时间,例如CacheControl:maxage3600,代表着资源的有效期是3600秒。其他配置 nocache:需要进行协商缓存,发送请求到服务器确认是否使用缓存。 nostore:禁止使用缓存,每一次都要重新请求数据。 public:可以被所有的用户缓存,包括终端用户和CDN等中间代理服务器。 private:只能被终端用户的浏览器缓存,不允许CDN等中继缓存服务器对其缓存。协商缓存 当强缓存没有命中的时候,浏览器会发送一个请求到服务器,服务器根据header中的部分信息来判断是否命中缓存。如果命中,则返回304,告诉浏览器资源未更新,可使用本地的缓存。 协商缓存看的是header中的LastModifiedIfModifiedSince和EtagIfNoneMatch缓存生效,返回304,缓存失效,返回200和请求结果 Etag优先级LastModified高LastModifiedIfModifiedSince 浏览器第一次请求一个资源的时候,服务器返回的header中会加上LastModify,Lastmodify是一个时间标识该资源的最后修改时间。 当浏览器再次请求该资源时,request的请求头中会包含IfModifySince,该值为缓存之前返回的LastModify。服务器收到IfModifySince后,根据资源的最后修改时间判断是否命中缓存,命中返回304使用本缓存,否则返回200和请求最新资源。EtagIfNoneMatch etag是更为严谨的校验,一般情况下使用时间检验已经足够,但我们想象一个场景,如果我们在短暂时间内修改了服务端资源,然后又迅速的改回去,理论上这种情况本地缓存还是可以继续使用的,这就是etag诞生的场景。 使用etag时服务端会对资源进行一次类似hash的操作获得一个标识(内容不变标识不变),并返回给客户端。 再次请求时客户端会在IfNoneMatch带上etag的值给服务端进行对比验证,如果命中返回304使用缓存,否则重新请求资源。 注:由于eatg服务端计算会有额外开销,所以性能较差 扩展:DNS缓存与CDN缓存DNS缓存 我们在网上所有的通信行为都需要IP来进行连接,DNS解析是指通过域名获取相应IP地址的过程。 基本上有DNS的地方就有缓存,查询顺序如下: 一般我们日常会接触到的就是有时内网域名访问需要修改本地host映射关系,或者某些科学上网的情况,可以通过修改本地host来正常访问网址CDN缓存 CDN缓存从减轻根服务的分发压力和缩短物理的传输距离(跨地域访问)上2个层面对资源访问进行优化。CDN节点解决了跨运营商和跨地域访问的问题,访问延时大大降低。 大部分请求在CDN边缘节点完成,CDN起到了分流作用,减轻了源服务器的负载。 一般CDN服务都由运营商提供,我们只需要了解如何验证CDN是否生效即可查看域名是否配置了CDN缓存ping{{域名}}会看到转向了其他地址(alikunlun)例如:pingcustomer。kukahome。com 查看我们的页面资源是否命中CDN缓存 通过查看相应头有Xcache:HIT字段,则命中CDN缓存,注意这里名称并不固定,但一般都会有HIT标识,如果是MISS或None之类的,则没有命中缓存 前端针对缓存部署优化方案构建演进 构建方面优化的核心思想是如何更优,更快速的加载资源,以及如何保证资源的新鲜度 这个优化过程也分为几个阶段,有些其实已经不适用现在的场景,但也可以了解下早期的图标合并雪碧图(sprite),多脚本文件整理到一个文件:目的是通过减少碎片化的请求数量来加速资源加载(相关知识点是浏览器一般最多只支持6个并发请求,同一时间请求数量需要控制在合理范围)现在雪碧图已基本被iconfont代替,js加载更多采用分模块异步加载,而不是一味合并随着web应用的推广和浏览器缓存技术的普及,前端缓存问题也随着而来,最常见的就是服务端资源变了,但是客户端资源始终无法更新,这个阶段工程师们想了很多方案。打包时在静态资源路径上加上?vversion或者使用时间戳来给资源文件命名 跟modified缓存有点像,由于时间戳并不能识别出文件内容是否变动,所以有了后来的hash方案,理论上hash出来的文件只要内容不变,文件名就不变,大大提高了缓存的使用寿命,也是现代常用打包工具的默认配置 然后,重点来了,以上我们对html文件里链接的资源做了一系列优化,但是html本身也是一种静态资源,并且,客户在访问页面时是不会带上所谓的时间戳或者版本号的,导致了很多时候虽然服务端资源更新了,但是客户端还是用老的html文本发起请求,这个时候就会导致各种各样的问题了,包括但不限于白屏,展现的旧版本页面等等 为了解决这个问题,目前主流的解决方案是不对html进行缓存(一般单页应用html文件较小,大的是js),只对js,css等静态文件进行本地缓存 那么,如何让浏览器不缓存html呢,目前都是通过设置CacheControl实现,有前端方案和后端方案,风险提示,前端方案很不靠谱,后端很多默认配置会覆盖前端方案,可以做了解,生产中请使用后端配置。通过html标签设置cachecontrol旧协议 旧协议 目前主流部署配置 目前主流的前端部署方式都是使用nginx,我们来看看nginx如何禁用html的缓存location{root;配置页面不缓存html和htm结尾的文件if(requestfilename。。(?:htmhtml)){addheaderCacheControlprivate,nostore,nocache,mustrevalidate,proxyrevalidate;}indexindex。htmlindex。htm;}Private会影响到CDN缓存命中率,但本身CDN缓存也会存在版本问题,量不大的情况下也可以禁掉Nocache可以使用缓存,但是使用前必须到服务端验证,可以是nocache,也可以是maxage0Nostore完全禁用缓存Mustrevalidate与nocache类似,强制到服务端验证,作用于一些特殊场景,例如发送了校验请求,但发送失败了之类Proxyrevalidate与上面类似,要求代理缓存服务验证有效性 以上配置可以跟据项目需要灵活配置,考虑到浏览器对缓存协议支持会有些许差异,只是想简单粗暴禁用html缓存全上也没有关系,并不会有特别大影响,除非特殊场景需要调优时需要关注。资源压缩 都讲到这了,前端构建优化还有一个常用的就是Gzip资源压缩,可以极大减小资源包体积,前端一般构建工具都有插件支持,需要注意的是也需要nginx做配置才能生效http{gzipstaticon;gzipproxiedany;} 如果生效了,响应头里可以看到contentencoding:gzip