建议购买原文，前端性能优化原理与实践，本文学习总结用。如有侵权，感谢联系，删除。

1、存储篇

1) 浏览器缓存机制

Memory Cache
Service Worker Cache
HTTP Cache
Push Cache

①、HTTP 缓存机制（HTTP Cache）

HTTP 缓存是我们日常开发中最为熟悉的一种缓存机制。它又分为强缓存和协商缓存。优先级较高的是强缓存，在命中强缓存失败的情况下，才会走协商缓存。

强缓存是利用 http 头中的 Expires 和 Cache-Control 两个字段来控制的。

协商缓存：浏览器与服务器合作之下的缓存策略

图解

当我们的资源内容不可复用时，直接为 Cache-Control 设置 no-store，拒绝一切形式的缓存；否则考虑是否每次都需要向服务器进行缓存有效确认，如果需要，那么设 Cache-Control 的值为 nocache；否则考虑该资源是否可以被代理服务器缓存，根据其结果决定是设置为 private 还是 public；然后考虑该资源的过期时间，设置对应的 max-age 和 s-maxage 值；最后，配置协商缓存需要用到的 Etag、Last-Modiﬁed 等参数。

②、MemoryCache

MemoryCache，是指存在内存中的缓存。从优先级上来说，它是浏览器最先尝试去命中的一种缓存。从效率上来说，它是响应速度最快的一种缓存。

使用场景：Base64 格式的图片，几乎永远可以被塞进 memory cache，这可以视作浏览器为节省渲染开销的“自保行为”；此外，体积不大的 JS、CSS 文件，也有较大地被写入内存的几率——相比之下，较大的 JS、CSS 文件就没有这个待遇了，内存资源是有限的，它们往往被直接甩进磁盘。

③ 、Service Worker Cache

必须以 https 协议为前提
Service Worker 是一种独立于主线程之外的 Javascript 线程。它脱离于浏览器窗体，因此无法直接访问 DOM。

使用：可以帮我们实现离线缓存、消息推送和网络代理等功能，详细使用见掘金小册存储篇

④、Push Cache

Push Cache 是缓存的最后一道防线。浏览器只有在 Memory Cache、HTTP Cache 和 Service
Worker Cache 均未命中的情况下才会去询问 Push Cache。 Push Cache
是一种存在于会话阶段的缓存，当 session 终止时，缓存也随之释放。
不同的页面只要共享了同一个 HTTP2 连接，那么它们就可以共享同一个 Push Cache。

缓存部分的知识，具有“细碎、迭代快”的特点，我们应该尝试先划分出层次和重点，归纳出完整的体系，然后针对每个知识点去各个击破。

2) Cookie

Cookie 的本职工作并非本地存储，而是“维持状态”。

HTTP 协议是一个无状态协议，服务器接收客户端的请求，返回一个响应，故事到此就结束了，服务器并没有记录下关于客户端的任何信息。

它最大只能有 4KB。

同一个域名下的所有请求，都会携带 Cookie。Cookie 虽然小，请求却可以有很多，随着请求的叠加，这样的不必要的 Cookie 带来的开销将是无法想象的。

3) Web Storage

①、Local Storage 与 Session Storage 的区别

两者的区别在于生命周期与作用域的不同。

生命周期：Local Storage是持久化的本地存储，存储在其中的数据是永远不会过期的，使其消失的唯一办法是手动删除；而 Session Storage是临时性的本地存储，它是会话级别的存储，当会话结束（页面被关闭）时，存储内容也随之被释放。
作用域：Local Storage、Session Storage 和 Cookie 都遵循同源策略。但 Session Storage 特别的一点在于，即便是相同域名下的两个页面，只要它们不在同一个浏览器窗口中打开，那么它们的 Session Storage 内容便无法共享。

②、Web Storage 的特性

存储容量大： Web Storage 根据浏览器的不同，存储容量可以达到 5-10M 之间。
仅位于浏览器端，不与服务端发生通信。
存储一些内容稳定的资源。比如图片内容丰富的电商网站会用它来存储 Base64 格式的图片字符串：

笔记--前端性能优化--存储篇