[TOC] ## 缓存机制 * 协议缓存方案：利用http缓存协议头cache-control做304缓存，或者更精确的ETAG设置依据资源的修改时间来设置缓存方案。但目前更有效或者极端的做法是利用max-expire-time，设置资源的最大缓存时间假设为1年的长缓存，更新采用非覆盖式更新的方式是目前大公司通行的做法。这样每次资源请求的时候都是只从客户端缓存读取（status:200，size:from cache），而不是还要跑一次http请求到服务器端拿到304状态。还是以一张淘宝首页图片长缓存的截图为例：  * appCache应用缓存方案：离线应用缓存是h5提供一个比较有效的离线应用方案，利用navigator.online 、window.applicationCache对象、服务器.appcache(以前是.manifest)配置文件保证在脱机下的移动web应用照常能用，如果要做数据的离线还要加上window.localStorage做离线数据的保存。 > 但App cache 有许多设计缺陷，见：[为什么app cache没有得到大规模应用？它有哪些硬伤吗？](https://www.zhihu.com/question/29876535) > <br> ## 页面切片预加载方案 性能优化静态资源维度最后一块内容就是针对页面，如何尽早输出页面模块，减少留白时间是一个思考点。facebook应用的BigPipe方案是个很不错的借鉴思想，还有淘宝也有首页做了相应的切片方案，对页面合理的分块，在服务器和客户端建立某种对应机制，让各个页面块并行的在服务器端拼接完成并吐出来。 <br> ## CDN 用户和服务器之间距离越远，经过的路由器越多，延迟也就越高。使用CDN的目的之一便是解决这一问题，当然不仅仅如此，CDN还可以分担IDC压力。 其实我们的CDN域名一般是和我们的网站主域名不同的，大家可以看看淘宝、腾讯的官方网站，看看他们存放静态资源的CDN域名，都是和主域名不一样的。为什么要这么做？主要有两个原因： 1. 便于CDN业务独立，能够独立配置缓存。为了降低web压力，CDN系统会遵循Cache-Control和Expires HTTP头标准对改请求返回的内容进行缓存，便于后面的请求不在回源，起到加速功能。而传统CDN（Web与CDN共用域名）的方式，需要对不同类型的文件设置相应的Cache规则或者遵循后端的HTTP头，但这样难以发挥CDN的最大优势，因为动态请求回源的概率非常之大，如果访客与源站的线路并不慢，通过CDN的请求未必快于直接请求源站的。 大型网站为了提升web性能到极致，通常缓存头设置比较大，像谷歌JS设置一年缓存，百度首页logo设置十年缓存，如果将静态元素抽取出来，就可以很方便的对所有静态元素部署规则，而不用考虑动态请求。减少规则的条数可以提升CDN的效率。 2. 抛开无用cookie，减小带宽占用。我们都知道HTTP协议每次发送请求都会自动带上该域名及父级域名下的cookie，但对于CSS，JS还有图片资源，这些cookie是没用的，反而会浪费访客带宽和服务器入带宽。而我们的主站，为了保持会话或者做其他缓存，都会存放着大量的cookie，所以如果将CDN与主站域名分离，就能解决这一问题。 不过这样一来，新的问题就出现了：CDN域名与主站域名不同，DNS解析CDN域名还需要花费额外的时间，增加网络延迟。 这时，我们可以使用DNS Prefetch。 <br> ## HTTP2 <br> ## 参考资料 [鸟瞰前端 , 再论性能优化](https://juejin.im/post/59c2109cf265da066875eff5#comment) [网站性能优化实战——从12.67s到1.06s的故事](https://zhuanlan.zhihu.com/p/35224473) [DNS Prefetching的两三事](https://zhuanlan.zhihu.com/p/22362198) [ 预加载系列一：DNS Prefetching 的正确使用姿势](https://segmentfault.com/a/1190000003944417) [ Head标签里面的dns-prefetch，preconnect，prefetch和prerender](https://segmentfault.com/a/1190000011065339)