--- theme: juejin highlight: androidstudio --- ## 前言 **合理利用缓存，可以提高页面的打开速度**，这句话是前端开发者耳熟能详的准则但具体缓存对页面性能有多大的影响呢？为了彻底弄懂浏览器缓存，就从动手验证这条准则开始吧 ## 缓存对页面性能的影响这里就以 [掘金](https://juejin.cn/) 主页为例，来测试有缓存和无缓存这两种情况对页面打开速度的影响验证工具：`Chrome DevTools` + `Lighthouse` **1）无缓存测试** 1、打开控制台，Network 面板勾选 `Disable cache` 选项

2、选择 Lighthouse 工具，点击 `Analyze page load` 按钮

得到如下性能报告： FCP(白屏时间)：**1s** 、TTI(交互响应时间)：**2.8s** 、LCP(最大内容时间) **2.9s**

**2）有缓存测试** 打开控制台，Network 面板取消勾选 `Disable cache` 选项，其他流程一样

得到如下性能报告： FCP(白屏时间)：**0.7s** 、TTI(交互响应时间)：**1.4s** 、LCP(最大内容时间) **1.4s**

前后两次性能对比，有缓存时： - 白屏时间：缩短 **0.3s** - 交互响应时间: 缩短 **1.4s** - 最大内容时间：缩短 **1.5s** 通过该案例验证了：合理利用缓存确实可以提升页面的打开速度 ## 什么是浏览器缓存？当我们访问一个网站时，会加载各种资源，如 HTML文档、JS、CSS、图片等。浏览器会将一些不经常变的资源保存在本地，这样下次访问相同网站时，就直接从本地加载资源，并不通过请求服务器，这就是浏览器缓存如何判断哪些资源是从缓存中获取呢？ Network的Size列表：

在Network面板中的size列表里，会看到两种标识：`from memory cache` 和 `from disk cache` 字样，这就说明该资源来自缓存，memory cache 表示缓存来自内存，disk cache 表示缓存来自硬盘，两者具体的区别下文有讲解 ## 前端常用的缓存方案强缓存与协商缓存相结合的方案 1）HTML 文档配置协商缓存； 2）JS、CSS、图片等资源配置强缓存此方案的好处：当项目版本更新时，可以获取最新的页面；若版本未变化，可继续复用之前的缓存资源；既很好利用了浏览器缓存，又解决了页面版本更新的问题 ## 浏览器的缓存流程

此图是非常经典的浏览器缓存流程，下面来讲解其中具体的细节 ## 强缓存如果资源没过期，就取缓存，如果过期了，则请求服务器，一般用于JS、CSS、图片等资源 ### 如何判断强缓存过期？第一次访问页面，浏览器会根据服务器返回的 response Header 来判断是否对资源进行缓存，如果响应头中有 cache-control 或 expires 字段，代表该资源是强缓存

### Cache-Control 是 HTTP1.1 中控制网页缓存的字段，主要取值为： - public：资源客户端和服务器都可以缓存 - privite：资源只有客户端可以缓存 - no-cache：客户端缓存资源，但是是否缓存需要经过协商缓存来验证 - no-store：不使用缓存 - max-age：缓存保质期，是相对时间上图中，HTTP 响应头中 `Cache-Control 为 max-age = 31536000`，意思是说在 31536000 秒后该资源过期，如果未超过过期时间，浏览器会直接使用缓存结果，强制缓存生效 **Cache-Control: no-cache 和 no-store的区别：** `Cache-Control: no-cache`：这个很容易让人产生误解，误以为是响应不被缓存实际上`Cache-Control: no-cache` 是会被缓存的，是协商缓存的标识，只不过每次都会向服务器发起请求，来验证当前缓存的有效性 `Cache-Control: no-store`：这个才是响应不被缓存的意思 ### Expires 是HTTP1.0控制网页缓存的字段，值为一个时间戳，服务器返回该资源缓存的到期时间但 Expires 有个缺点，就是它判断是否过期是用本地时间来判断的，本地时间是可以自己修改的到了HTTP/1.1，Expire 已经被 Cache-Control 替代，Cache-Control 使用了max-age相对时间，解决了Expires 的缺陷 **注意：当 Cache-Control 与 expires 两者都存在时，Cache-Control 优先级更高** ### memory cache 与 disk cache 的区别？两者都属于**强缓存**，主要区别在于存储位置和读取速度上 1）memory cache 表示缓存来自内存， disk cache 表示缓存来自硬盘 2）memory cache 要比 disk cache 快的多！从磁盘访问可能需要5-20毫秒，而内存访问只需要100纳秒甚至更快 - memory cache 特点：当前tab页关闭后，数据将不存在（资源被释放掉了），再次打开相同的页面时，原来的 memory cache 会变成 disk cache - disk cache 特点：关闭tab页甚至关闭浏览器后，数据依然存在，下次打开仍然会是 from disk cache ① 第一次打开掘金主页并刷新：缓存来自 memory cache 和 disk cache

② 关闭页面再打开时：所有的缓存都来自 disk cache

一般情况下，浏览器会将js和图片等文件解析执行后直接存入内存中，这样当刷新页面时，只需直接从内存中读取(from memory cache)；而css文件则会存入硬盘文件中，所以每次渲染页面都需要从硬盘读取缓存(from disk cache) ## 协商缓存浏览器携带缓存标识向服务器发送请求，服务器根据缓存标识来决定该资源是否过期，一般用于html资源，验证版本是否更新触发条件： - Cache-Control 的值为 no-cache （协商缓存） - 或者 Cache-Control: max-age=0 ### 协商缓存的标识 #### Last-Modified Last-Modified：文件在服务器最后被修改的时间，从服务器 Respnse Headers 上获取

**Last-Modified 的验证流程：** 1）第一次访问页面时，服务器的响应头会返回 Last-Modified 字段 2）客户端再次发起该请求时，**请求头 If-Modified-Since 字段会携带上次请求返回的 Last-Modified 值** 3）服务器根据 if-modified-since 的值，与该资源在服务器最后被修改时间做对比，若服务器上的时间大于 Last-Modified 的值，则重新返回资源，返回200，表示资源已更新；反之则返回304，代表资源未更新，可继续使用缓存请求的 Request Headers 上携带 if-modified-since 字段：

#### Etag ETag：当前资源文件的一个唯一标识(由服务器生成)，若文件内容发生变化该值就会改变

**ETag 的验证流程：** 1）第一次访问页面时，服务器的响应头会返回 etag 字段 2）客户端再次发起该请求时，**请求头 If-None-Match 字段会携带上次请求返回的 etag 值** 3）服务器根据 If-None-Match 的值，与该资源在服务器的Etag值做对比，若值发生变化，状态码为200，表示资源已更新；反之则返回304，代表资源无更新，可继续使用缓存请求的 Request Headers 上携带 if-none-match 字段：

**为什么要有 Etag ？** Etag 的出现主要是为了解决一些 Last-Modified 难处理的问题： 1）一些文件也许会周期性的更改，但是内容并不改变(仅仅改变的修改时间)，这时候并不希望客户端认为这个文件被修改了而重新去请求； 2）某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说 1s 内修改了 N 次)，If-Modified-Since 能检查到的粒度是秒级的，使用 Etag 就能够保证这种需求下客户端在 1 秒内能刷新 N 次 cache **注意：Etag 优先级高于 Last-Modified，若 Etag 与 Last-Modified 两者同时存在，服务器优先校验 Etag** ### 协商缓存的两种状态服务器根据请求头携带的缓存标识，判断该资源是否变化，资源未变化返回304，反之返回200 1）资源未变化，返回304

2）资源已更新，返回200

### 协商缓存的流程 1）第一次请求客户端发送请求，服务器处理请求，返回文件内容和一堆Header，包括Etag 和 Last-Modified，状态码200 2）第二次请求 1、客户端发起请求，此时请求头上会带上 **if-none-match值为Etag** 和 **if-modified-since值为last-modified** 2、服务器优先判断 Etag，若资源未变化状态码为304，客户端继续使用本地缓存，若资源发生变化，状态码为200 并返回最新的资源 ## 总结在前端性能优化中，合理利用缓存是非常重要的优化方式，使用好了缓存，对项目性能会有不错的提升最后，可以回过头再看看文中那张**浏览器的缓存流程图**，加深对浏览器缓存的理解 ## 文章系列文章系列地址：[github.com/xy-sea/blog](https://github.com/xy-sea/blog) 文中如有错误或不严谨的地方，请给予指正，十分感谢。如果喜欢或有所启发，欢迎 star