7、数据存储
在开发Web应用的过程中，会涉及一些数据的存储需求，常见的存储方式可能有：
保存登录态的Cookie；
使用浏览器本地存储进行保存的Local Storage和Session Storage；
客户端数据持久化存储方案涉及的Web SQL和IndexedDB；
直接存储在本机的文件系统上等。
文件系统、WebSQL和IndexedDB都是异步方式，
而本地存储的Local Storage和Session Storage方式则是同步方式。
Cache Storage是一种为缓存网络请求与响应而设计的数据存储机制，这些请求与响应可以是在应用程序运行过程中常规创建的，也可以是专门为了在缓存中存储一些数据而创建的。
IndexedDB 的实践
当浏览的网站页面被加载出来时，首先需要向服务器请求相应数据来构造页面显示的状态信息，然后再利用这些信息完成页面渲染，如果能将首次请求的信息保存到IndexedDB中，则能有效减少一些频繁访问页面的加载时间。
1、注意平台兼容性：使用 ArrayBuffer 存储（更兼容）
Blob类型比ArrayBuffer类型多了一个MIME类型的字段，为了能够正确地进行数据类型转化，将ArrayBuffer类型转化为Blob类型时需将该类型字段也加入缓冲区。代码示例如下：
将Blob类型转化为ArrayBuffer类型的过程会稍复杂一些，需要通过异步方式使用FileReader对象以ArrayBuffer格式读取Blob对象，然后在读取完成所触发的loadend事件中处理转化结果。代码示例如下：
2、完善错误处理
在进行数据存储时，会因为很多原因造成数据的读写失败，并且数据存储在某些情况下是不可控的。
由于IndexedDB的主要操作方法都集中在IDBDatabase、IDBTransaction和IDBRequest接口对象上，所以可为它们添加error监听事件，然后根据报错信息进行恰当的错误处理。以监听打开或创建IndexedDB的操作情况为例，代码如下：
3、注意修改、删除和过期
针对历史版本进行相应的升级处理，可以使用IDBOpenDBRequest.onupgradeneeded()方法来捕获IndexedDB版本升级事件，具体代码示例如下：
4、存储性能
虽然操作IndexedDB的API均是异步执行的，但不正确的使用方式依然会带来存储的性能风险，可能阻塞主线程造成应用崩溃或无响应。
产生风险的主要原因是IndexedDB在存储数据对象时，需要首先创建该数据对象的一个结构化副本，而这个复制过程是在主线程中进行的，所以数据对象嵌套的越复杂、规模越大，对主线程的阻塞时间就会越长。因此在操作IndexedDB时可参考这条规则：读写数据的大小不应该大于待访问的数据大小。
对规模较大的状态数据进行频繁改动时，也会给主线程的执行带来很大压力，即便采用了防抖和节流，也可能阻塞主线程的执行，增加数据写入出错的风险。**因此可采取的优化方式是：将原本整个状态对象的存储方式分解为粒度更小的单个状态记录进行存储。**这样可在进行状态更新时，仅更新实际发生修改的状态记录，而不会引起整个应用的状态对象进行大规模的数据存储。
8、缓存技术
缓存的原理是在首次请求后保存一份请求资源的响应副本，当用户再次发起相同请求后，如果判断缓存命中则拦截请求，将之前存储的响应副本返回给用户，从而避免重新向服务器发起资源请求。
缓存的技术种类有很多，比如代理缓存、浏览器缓存、网关缓存、负载均衡器及内容分发网络等，
它们大致可以分为两类：共享缓存和私有缓存。
共享缓存指的是缓存内容可被多个用户使用，如公司内部架设的Web代理；
私有缓存指的是只能单独被用户使用的缓存，如浏览器缓存。
HTTP缓存应该算是前端开发中最常接触的缓存机制之一，它又可细分为强制缓存与协商缓存，二者最大的区别在于判断缓存命中时，浏览器是否需要向服务器端进行询问以协商缓存的相关信息，进而判断是否需要就响应内容进行重新请求。
1、Service Worker
Service Worker是浏览器后台独立于主线程之外的工作线程，正因如此它的处理能力能够脱离浏览器窗体而不影响页面的渲染性能。
Service Worker是伴随着Google推出的PWA（即Progressive Web App渐进式Web应用）一同出现的技术，它能够实现诸如消息推送、后台加载、离线应用及移动端添加到主屏等堪比原生应用的功能，同时还具备小程序“无须安装、用完即走”的体验特点。虽然Service Worker已被列入W3C标准，但在各端上的兼容性并不理想，目前来讲应用比较多的还是在基于Chrome的PC端浏览器上。（最新的兼容性可以查看相应网站）
1、技术由来
JavaScript的执行是单线程的，如果一个任务的执行占用并消耗了许多计算资源，则势必会导致阻塞执行其他任务，这正是单线程的弊端。
为此浏览器引入了Web Worker，它是一个独立于浏览器主线程之外的工作线程，可以将较复杂的运算交给它来处理，而无须担心这是否会对页面渲染产生负面影响。
Service Worker正是在此基础上增加了对离线缓存的管理能力，它的表现弥补了之前HTML 5上采用AppCache实现离线缓存的诸多缺陷。
Service Worker定义了由事件驱动的生命周期，这使得页面上任何网络请求事件都可以被其拦截并加以处理，同时还能访问缓存和IndexedDB，这就可以让开发者制定自定义度更高的缓存管理策略，从而提高离线弱网环境下的Web运行体验。
2、基本特征
●独立于浏览器主线程，无法直接操作DOM。
●在开发过程中可以通过localhost使用，但要部署到线上环境则需要HTTPS的支持。
●能够监听并拦截全站的网络请求，从而进行自定义请求响应控制。
●在不使用的时候会被中止，在需要的时候进行重启。所以我们不能依赖在其onmessage与onfetch的事件监听处理程序中的全局状态，如果有此需要可以通过访问IndexedDB API将全局状态进行存储。
●广泛使用Promise来处理异步。
●消息推送。
●后台同步。
2、Push 缓存
HTTP 2新增了一个强大的功能：服务器端推送，它的出现打破了传统意义上的请求与响应一对一的模式，服务器可以对客户端浏览器的一个请求发送多个响应。
这样会带来性能优化的一个新思路：在传统的网络应用中，客户端若想将应用中所包含的多种资源渲染展示在浏览器中，就需要逐个资源进行请求，但其实一个HTML文件中所包含的JavaScript、样式表及图片等文件资源，是服务器可以在收到该HTML请求后预判出稍后会到来的请求，那么就可以利用服务器端推送节省这些多余的资源请求，来提升页面加载的速度。
1、最后一道缓存
浏览器缓存通常可以分为四个方面：内存中的缓存、Service Worker缓存、HTTP缓存及HTTP 2的Push缓存。
1、内存中的缓存
内存中的缓存是浏览器中响应速度最快且命中优先级最高的一种缓存，但它的驻留周期非常短，通常依赖于渲染进程，一旦页面页签关闭进程结束，内存中的缓存数据就会被回收。
2、缓存命中优先级
浏览器缓存的命中优先级从高到低分别是：内存中的缓存、Service Worker缓存、HTTP缓存及HTTP 2的Push缓存。
3、基于连接的缓存
在了解了缓存命中优先级后，我们还需要明白Push缓存是依赖于HTTP 2连接的，如果连接断开，即便推送的资源具有较高的可缓存性，它们也会丢失，这就意味着需要建立新的连接并重新下载资源。考虑到网络可能存在不稳定性，建议不要长时间依赖Push缓存中的资源内容，它更擅长的是资源推送到页面提取间隔时长较短的使用场景。
4、预加载 与 Push 缓存
Push缓存和预加载还存在一些不同之处，其中主要的不同点是，Push缓存是由服务器端决定何时向客户端预先推送资源的，而预加载则是当客户端浏览器收到HTML文件后，经过解析其中带有preload的标签，才会开启预加载的。
为了方便决定使用Push缓存还是预加载，下面给出一个决策树以供参考：
3、CDN 缓存
CDN全称Content Delivery Network，即内容分发网络，它是构建在现有网络基础上的虚拟智能网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、调度及内容分发等功能模块，使用户在请求所需访问的内容时能够就近获取，以此来降低网络拥塞，提高资源对用户的响应速度。
与前端关系密切的CDN优化点：域名设置。
Cookie的访问遵循同源策略，并且同一域名下的所有请求都会携带全部Cookie信息。若这些完全没有必要的开销积少成多，那么它们所产生的流量浪费就会很大，所以将CDN服务器的域名和主站域名进行区分是非常有价值的实践。
因为浏览器对于同域名下的并发请求存在限制，通常Chrome的并发限制数是6，其他浏览器可能多少会有所差异。这种限制也同时为我们提供了一种解决方案：通过增加类似域名的方式来提高并发请求数，比如对多个图片文件进行并发请求的场景，可以通过扩展如下类似域名的方式来规避限制：
